做色网站,建站计划书,wordpress 小程序开发,云盘搜索引擎入口1.服务器环境以及配置
【机型】物理机 处理器#xff1a; Intel 内存#xff1a; 126G
【内核版本】
4.19.90-25.16.v2101.ky10.x86_64
【银河麒麟操作系统镜像版本】
Kylin-Server-10-SP2-Release-Shenzhen-Metro-x86-Build01-20220619
Kylin-HA-10-SP2-Release-S…
1.服务器环境以及配置
【机型】物理机 处理器 Intel 内存 126G
【内核版本】
4.19.90-25.16.v2101.ky10.x86_64
【银河麒麟操作系统镜像版本】
Kylin-Server-10-SP2-Release-Shenzhen-Metro-x86-Build01-20220619
Kylin-HA-10-SP2-Release-Shenzhen-Metro-Build01-20220620-x86_64
【第三方软件】
传统售票业务软件、互联网售票业务软件k8s 2.问题现象描述
近期站点存在站点频繁重启问题分析查看日志查看高可用心跳link频繁存在up \down问题触发fence导致重启。临时调整了token值但是目前效果不明显软件厂家表示各厂家占用内存不高不是导致oom问题的原因。
3.问题分析
通过收集的2套近期出现过HA集群服务器被fence的系统sosreport日志可知主机ZP1403SV01在2024.04.10 09:35:37和主机ZP1417SV02在2024.04.01 11:40:39左右被fence发生过系统重启。如图1和图2: 图1 图2 分析主机ZP1417SV02系统日志可知系统在2024.04.01 11:40:39左右系统被fence重启之前有检测到corosync检测心跳状态服务有4秒超时响应的日志信息输出“Token has not been received in 4634 ms”如图3 图3
进一步分析主机ZP1417SV02系统日志可以看到在corosync服务报出检测心跳超时的同时也有很多k8s服务相关进程被oom-killer的日志信息输出报出的堆栈信息基本一致。分析其中一个堆栈报错。可知elastic-operato进程在申请内存的时候显示内核进入到mem_cgroup_out_of_memory这个路径后分配不到内存导致oom产生选择elastic-operato进程kill掉如图4和图5 图4 图5
由此oom-killer报错信息联想到有一个已知系统内核bug对于银河麒麟操作系统V10 SP1/SP2低版本内核内存水位线计算不准确会频繁OOM这一问题。
进一步分别查看分析4台系统节点的Zone Normal的内存水位线。查看/proc/zoneinfo发现这4台主机节点ZP1403SV01、ZP1403SV02、ZP1417SV01和ZP1417SV02Node 0和Node1,zone Movable显示不正常spanned present为0但是managed 很大。正常应spannedpresentmanaged0或者spannedpresentmanaged。如图6至图9 图6 ZP1403SV01 图7 ZP1403SV02 图8 ZP1417SV01 图9 ZP1417SV02 对于银河麒麟V10 SP1/SP2低版本内核内存水位线计算不准确会频繁OOM这一问题为已知bug。该bug是由于openeuler内核麒麟内核基于openeuler内核开发在优化内存时引入了一个bug(commit eb761d6521c32c006a4987260394a61c6684fb35: mm: parallelize deferred struct page initialization within each node)其会导致内存zone的managed_pages统计出现错位。
目前麒麟软件及openeuler都已在官网发布了内核修复公告麒麟内核在SP1 23.30、SP2 25.22版本得到修复SP3内核不存在这个BUG。
公告链接地址KYBA-202212-1011 - 国产操作系统、麒麟操作系统——麒麟软件官方网站 4.此内核bug的分析说明
1内核bug对水位线计算错误的原理以及是否影响所有内存区
本次BUG引发的原因是内核代码引入了不严谨的代码在计算zone中管理的page的数量可能出现错位。
打个比方系统有3个zone,其管page数量分别如下
1号zone 10个page 2号zone是100个page 3号zone是100000个page。而系统在计算水位是依据各个zone的page数量来计算 page数量越多水位越高如果page数据统计错误比如3号zone的page数量算成了100,将导致3号zone的水位严重偏低 。
接着我们从问题patch代码的出错行来看看问题发生的原因 WARN_ON(zid MAX_NR_ZONES populated_zone(zone)); VM_BUG_ON(nr_init ! nr_free); zone-managed_pages nr_free;
问题代码如上所示这里本意是要统计zone中managed_pages的数量将其加上nr_free但是前面的WARN_ON(zid MAX_NR_ZONES populated_zone(zone));有可能将zone进行自加将要统计的nr_free统计到下一个zone上面去了 比如要统计的1号zone上面的结果zone后变成2号zone了出现统计错位这有可能会影向所有的zone的统计 。 2水位线计算错误是否必定出现
对于不同机型不一定必定出现对于同一机型只要一台出问题则其它的都有问题。
接着上一节的代码继续说明产生这种现象的原因如下 因为要出现统计错位则必需要运行zone这个代码才行 WARN_ON(zid MAX_NR_ZONES populated_zone(zone)); 如果zid MAX_NR_ZONES为假则后面的zone不会运行也就不会出现问题反之则出现问题。 3高版本内核是否一定能完全解决内存水位计算异常
高版本内核一定能完全解决这个内存水位计算异常问题因为这个bug非常明确如上所说只需把zone这个操作放在zone-manage_pages nr_free后面即可。
当前内核修改完成的代码如下
zone-managed_pages nr_free; /* Sanity check that the next zone really is unpopulated */
WARN_ON(zid MAX_NR_ZONES populated_zone(zone)); //zone后后面的代码没有出现引用
zone pr_info(node %d initialised, %lu pages in %ums\n, nid, nr_free, jiffies_to_msecs(jiffies - start)); pgdat_init_report_one_done(); return 0; } 4managed不为0spannedpresent都为0与bug的关系
这个问题出现的原因也是如第一条问题的答复内核在统计zone中managed_pages的数量时可能会出现zone进行自加将要统计的nr_free统计到下一个zone上面。
而Linux系统并非所有node、zone都管理着内存比如通常zone Movable、zone Device默认都不管理内存一些开启了numa的机器在非node 0的节点上可能也只有一个zone管理着内存。这是要是触发了上述bug就会将上一个zone的managed统计到这个spanned presend managed本该都为0的zone上。这时就会产生managed不为0spannedpresent都为0的现象。
5.问题分析结果
结合之前出现过此问题的现象研发侧的分析情况可知空闲内存过小在业务突然繁忙时大量的page cache会消耗掉free memory容易导致corosync延迟处理。有可能会导致心跳检测超时触发fence。
对于银河麒麟V10 SP1/SP2低版本内核内存水位线计算不准确会频繁OOM这一问题会产生的影响有机器长时间运行后都有概率出现内存水位太低长时间运行后碎片化严重机器使用久了所有申请大块内存的都会有问题。导致正常的内存申请都有问题从而可能会影响HA集群心跳监控服务corosync服务延迟处理心跳事件有风险触发fence动作系统重启。 6.后续计划与建议
建议升级银河麒麟V10-SP2-x86服务器系统的内核到4.19.90-25.22.v2101.ky10.x86_64版本及其以上运行观察一段时间。
外网源内核下载地址
Index of /NS/V10/V10SP2/os/adv/lic/updates/x86_64/Packages/
