阜阳哪里做网站的多培训学校网站

当前位置： 首页 > news >正文

阜阳哪里做网站的多,培训学校网站,承接网站开发 app开发,微信开放平台应用签名了解银河麒麟操作系统更多全新产品#xff0c;请点击访问麒麟软件产品专区#xff1a;https://product.kylinos.cn 现象描述 某服务器系统升级内核至4.19.90-25.22.v2101版本后仍会触发oom导致java进程被kill。 现象分析 oom现象分析 系统messages日志分析#xff0c;故…了解银河麒麟操作系统更多全新产品请点击访问麒麟软件产品专区https://product.kylinos.cn 现象描述 某服务器系统升级内核至4.19.90-25.22.v2101版本后仍会触发oom导致java进程被kill。 现象分析 oom现象分析 系统messages日志分析故障时间2024.3.2 1345左右如图1 图1 从下面的日志信息可以看到java进程是在内核采用GFP_KERNEL|__GFP_COMP分配order3也就是2的3次方8个连续页的时候系统无法提供对应大小的连续内存页导致oom产生并选择java进程进行kill掉了。 现在来分析这一现像是否为正常现像因为oom是内核的正常的机制GFP_KERNEL的首先内存管理区为ZONE_NORMAL。从日志可以看出当前系统一共有3个内存管理区分别是ZONE_DMA、ZONE_DMA32和ZONE_NORMAL。接下来分析这个3个内存管理区的内存使用情况 1)ZONE_DMA的空闲内存是15876kB , 最低水位是32k低水位是44k, 高水位是56k, 空闲内存远大于高水位所以kswapd是不会启动回收的但是Linux内核有一个对低端内存管理区的保护机制lowmem_reserve中有体现加上保护机制最低水位为32K 30759*4KB123068KB这个数据比空闲内存15876KB要大了所以ZONE_DMA是不能分配成功的。 Mar 22 13:45:18 wzhapp13 kernel: [6229155.126208] Mem-Info: Mar 22 13:45:18 wzhapp13 kernel: [6229155.126213] active_anon:1656544 inactive_anon:541287 isolated_anon:0#012 active_file:307018 inactive_file:548893 isolated_file:0#012 unevictable:0 dirty:136 writeback:0 unstable:0#012 slab_reclaimable:3601440 slab_unreclaimable:525232#012 mapped:39889 shmem:22418 pagetables:10064 bounce:0#012 free:124343 free_pcp:63 free_cma:0 Mar 22 13:45:18 wzhapp13 kernel: [6229155.126215] Node 0 active_anon:6626176kB inactive_anon:2165148kB active_file:1228072kB inactive_file:2195572kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:159556kB dirty:544kB writeback:0kB shmem:89672kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 6649856kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no Mar 22 13:45:18 wzhapp13 kernel: [6229155.126216] Node 0 DMA free:15876kB min:32kB low:44kB high:56kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:15992kB managed:15908kB mlocked:0kB kernel_stack:0kB pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB Mar 22 13:45:18 wzhapp13 kernel: [6229155.126218] lowmem_reserve[]: 0 2689 30759 30759 30759 2)ZONE_DMA32的空闲内存是160984kB , 最低水位是5904k低水位是8656k, 高水位是11408k, 空闲内存远大于高水位所以kswapd是不会启动回收的但和DMA区域一样加上lowmem_reserve保护机制最低水位为5904K 28069*4KB128940KB。 Mar 22 13:45:18 wzhapp13 kernel: [6229155.126220] Node 0 DMA32 free:160984kB min:5904kB low:8656kB high:11408kB active_anon:327188kB inactive_anon:52060kB active_file:9776kB inactive_file:17044kB unevictable:0kB writepending:0kB present:3128832kB managed:2801120kB mlocked:0kB kernel_stack:3488kB pagetables:1368kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB Mar 22 13:45:18 wzhapp13 kernel: [6229155.126223] lowmem_reserve[]: 0 0 28069 28069 28069 单纯从空闲内存大小来看似乎可以从DMA32区域分配出java进程所需的内存但我们实际查看ZONE_DMA32的内存分布空闲的160984kb内存大多为低阶的内存页。最大只可提供16KB即order2(2^2*4K16K)的连续内存页无法满足java进程order3的连续内存页请求。 Mar 22 13:45:18 wzhapp13 kernel: [6229155.126233] Node 0 DMA32: 15760*4kB (UME) 5137*8kB (UE) 3547*16kB (UE) 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB 160888kB 3最后ZONE Normal的空闲内存是320512kb, 最低水位是61640k低水位是90380k, 高水位是119120k, 空闲内存高于高水位所以kswapd是不会启动回收的。 Mar 22 13:45:18 wzhapp13 kernel: [6229155.126224] Node 0 Normal free:320512kB min:61640kB low:90380kB high:119120kB active_anon:6298988kB inactive_anon:2113088kB active_file:1218296kB inactive_file:2178680kB unevictable:0kB writepending:544kB present:30408704kB managed:28750204kB mlocked:0kB kernel_stack:41728kB pagetables:38888kB bounce:0kB free_pcp:252kB local_pcp:0kB free_cma:0kB Mar 22 13:45:18 wzhapp13 kernel: [6229155.126227] lowmem_reserve[]: 0 0 0 0 0 但同ZONE_DMA32一样当我们实际查看这320512kb空闲内存的内存详情时我们发现它同样最大只可提供16KB即order2(2^2*4K16K)的连续内存页无法满足java进程order3的连续内存页请求。 Mar 22 13:45:18 wzhapp13 kernel: [6229155.126237] Node 0 Normal: 10802*4kB (UME) 20894*8kB (UE) 6979*16kB (UE) 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB 322024kB 从以上信息来看本次触发OOM的原因和之前类似都是系统内存碎片化空闲内存高于内存回收水位但无法提供进程申请的较大阶数的连续内存页。 但不同的是之前x86服务器是由于内核bug导致managed统计错位从而使得Normal区域的内存回收水位线较小而升级内核则不存在这个bug。只是当前默认的67584KB min_free_kbytes和实际业务场景不太符合。 min_free_kbytes参数分析 从OOM日志来看java进程需要申请较大的连续内存而当前内存水位线较低触发OOM时ZONE Normal虽有320512kb空闲内存但都是零散的这和内存水位线的大小有关。 vm.min_free_kbytes是一个Linux重要的内核参数用于控制系统可用内存的最小空闲大小。它指定了内核应该保留的空闲内存页面的数量以KB为单位以便能够及时满足系统的需要。 当系统运行过程中需要更多的内存时从空闲页面中分配内存是一种快速且高效的方式。vm.min_free_kbytes参数的存在是为了确保系统在处理高内存压力时仍然具有足够的可用内存提供给内核、驱动等关键应用使用这部分预留内存用户态应用通常无法申请。 同时vm.min_free_kbytes的设置衍生出了不同的内存回收水位默认的内存回收水位计算方式如下 1、watermark[min] min_free_kbytes 2、watermark[low] watermark[min] * 5 / 4 3、watermark[high] watermark[min] * 3 / 2 当系统剩余空闲内存大于 high水位时表示此时系统内存足够不会进行内存回收当系统剩余空闲内存内存小于low水位 时表示此时内存存在压力会触发 kswapd 进行后台内存回收直到 pages_high 为止当系统剩余空闲内存内存小于 min 水位时表示此时用户内存耗尽会触发直接内存回收进程被阻塞。若是直接内存回收等方式还是无法释放出应用所需申请的连续内存时就将触发OOM通过强制杀死其他占用大量内存的进程来释放内存。 min_free_kbytes设的越大watermark的线越高同时三个线之间的buffer量也相应会增加。这意味着会较早的启动kswapd进行回收且每次都会回收上来较多的内存直至watermark[high]才会停止但这也会使得系统预留过多的空闲内存从而在一定程度上降低了应用程序可使用的内存量。 min_free_kbytes设的过小则会导致系统预留内存过小。这不仅会导致在内存压力较大空闲内存不足时内核、驱动以及其他GFP-AOTOMIC这种不可等待的内存申请无法进行。由于每次内存回收都是到watermark[high]就停止了较低的min_free_kbytes容易导致每次进行内存回收时都是回收的零散内存而未回收大块的连续内存从而引起系统内存碎片化。 总结 综上所述本次触发OOM的原因和之前的情况较为类似都是系统内存回收水位线较小、内存碎片化空闲内存高于内存回收水位但无法提供进程申请的较大阶数的连续内存页。 但不同的是之前x86服务器是由于内核bug导致managed统计错位从而使得Normal区域的内存回收水位线较小。而升级内核后则不存在这个bug只是当前默认的67584KB min_free_kbytes和实际业务场景不太符合。 对该问题推荐修改watermark_scale_factor的值调大min、low、high三条内存回收水位线的差距使得系统在空闲内存不足时更早、更多地进行内存回收之后对于内存碎片化的情况我们建议可以在业务空闲时指定定时任务规整内存。 后续计划及建议 修改watermark_scale_factor的值来调大min、low、high三条内存回收水位线的差距具体步骤如下。 打开sysctl.conf配置文件vim /etc/sysctl.conf 在其中手动添加vm.watermark_scale_factor XX 该值推荐设置为50-75 完成修改后生效配置sysctl -p 查询参数看是否修改完成cat /proc/sys/vm/watermark_scale_factor 或 sysctl -a |grep watermark_scale_factor 对于内存碎片化的情况如果系统内存高碎片化情况较为频繁条件允许的情况下我们建议在业务空闲时手动进行异步内存规整。 root用户执行echo 1 /proc/sys/vm/compact_memory即可若服务器业务较为规律推荐挑选一天中的业务空闲时间直接写入定时任务执行。