OceanBase-OCP-bug之 fgc问题处理

一、遇到问题时，处理过程

关于调整ocp-server的jvm大小解释：1、在docker容器内设置export JVM_HEAP_SIZE=xxxx，然后重启对应的ocp-server进程（/home/admin/ocp-server/bin/ocp-server）,注意这里的大小不要超过docker容器的大小上限。2、在调整完ocp容器的内存大小之后（docker update --memory=60g <container_id_or_name>）,重启ocp容器，容器内的ocp-server进程的jvm大小也会跟着变化，这个原因还是因为/home/admin/ocp-server/bin/ocp-server这个问题里面这个文件定义了ocp-server启动时的大小，如果变量JVM_HEAP_SIZE没有设置的话，它是根据当前系统可用内存的7/10来分配。


docker  ps 
docker  stats

查看容器内存CPU使用情况：
docker stats


【1】 、ocp不定期自动挂掉-fgc问题 处理情况1============================================

【处理】：

修改缓冲池资源的

先添加ocp 容器的内存资源，
docker update --memory 36G --memory-swap -1  {CONTAINER_ID}, 现在是20G ,可以先加到36G, 

然后在  ocp_meta租户的ocp库 里面执行下这个 sql，
 replace into config_properties(`key`, value) 
 values ('ocp.alarm.detect.executor.core_pool_size', 10) ,('ocp.alarm.detect.executor.max_pool_size', 20);  

加资源三个节点都要加，然后再重启下ocp ，我们再观察下。   麻烦再把 ocp docker 里/home/admin/logs/ocp ， gc开头的日志拿一下


有空可以到 ocp 的容器里切换到  admin 用户再执行下 jstat -gcutil <ocp-server-pid> 看下 FGC 
FGC如果是0那就没有什么问题，如果还是有数值，麻烦再联系下我们，


1、
ocp 的容器里切换到  admin 用户再执行下 jstat -gcutil <ocp-server-pid> 看下 FGC [19613 是OCP的进程ID的意思]
ps  -ef  |  grep  ocp 
jstat  -gcutil  19613
stats 

看下延迟的store是否有gc，oms docker里
jstat -gcutil `ps -ef | grep storexxxx | grep java | awk '{print $2}'` 3000


原因分析：
客户环境： ocp_monitor租户 4c16g，这个设置偏小，
影响的主要是内存，CPU 应该对 OCP 的影响不太大，可以看下容器的 load
top 里面就有：机器的 load1、load5、load15 ，哪个进程占用大的内存。
尝试 meta 集群需要加资源，
尝试 ocp上调整unit资源是不是可以解决问题。


工单总结：
1、增加客户OCP内存由20G ——>  36G ，OCP资源观察很多天相对运行稳定。
2、增加cpu的话从8c增加16C，并且 OCP  扩大 64G 后重启 java 进程。
3、建议暂时把awr功能关了，待下个版本修复。这个不确定具体时间，研发老师现在规划还没完整的出来
如果开启awr会导致fcg，那这可能还需要优化，可以建议关掉这个功能，等后续版本优化好了再升级ocp，打开对应功能。

目前，客户环境负载较高，未发生故障和告警，运行稳定但是未能根本解决问题，1是客户增大资源配置，2是等新版解决BUG升级。



问题就是增加租户副本的时候会卡住并失败，重试才能成功，我怀疑是不是监控采集太频繁导致FGC让任务失败，具体的麻烦帮忙看一下


在 metadb 里执行下这个 sql ，里面可以查下管理的规模
select count(1) from ob_cluster;
select count(1) from ob_tenant;
select count(1) from compute_host;

select * from task_definition where name = 'Collect cluster snapshot'
select `key`, value from config_properties where `key` like '%ocp.alarm.detect.executor%';


ocp-server 的容器配置需要看下容器的信息，或者你在镜像里面执行下 ps -ef | grep java 
replace into config_properties(`key`, value) values ('ocp.alarm.detect.executor.core_pool_size', 20) ,('ocp.alarm.detect.executor.max_pool_size', 30);

执行下这个 sql，然后挨个重启下 ocp 的镜像，之后再观察下是否还有 fgc 吧



【2】 、ocp不定期自动挂掉-fgc问题 处理情况2============================================
处理办法：
1、ocp-server 的容器配置需要看下容器的信息，执行下 ps -ef | grep java ，再进入容器中，运行：jstat -gcutil <pid>   ，pid 就是 java 的进程，观察 fgc 使用情况是否很高。
2、看下 ocp-server 的资源分配了多少，管理了多少集群、租户、主机规模
metadb 下执行以下sql：

select count(1) from ob_cluster;
select count(1) from ob_tenant;
select count(1) from compute_host;
select * from task_definition where name = 'Collect cluster snapshot'
select `key`, value from config_properties where `key` like '%ocp.alarm.detect.executor%';

修改执行下这个 sql，将两个参数再调小：
replace into config_properties(`key`, value) values ('ocp.alarm.detect.executor.core_pool_size', 20) ,('ocp.alarm.detect.executor.max_pool_size', 30);

然后重启下各个 ocp 的镜像，之后再观察下是否还有 fgc 


原因：
OCP有些任务比较消耗资源，告警每分钟会并发 100 （默认值）个线程查询监控数据，将两个参数再调小


观察验证：
root@ocp_metna
use  ocp  
metadb执行
select count(1) from ocp_exporter_address where status='inactive'; 
select count(1) from ocp_exporter_address where status='active'; 
点击一下右上角的实时按钮，看OCP界面是否有数据

 

二、再说，故障现象

现象1：

 

现象2：