當前位置：首頁 > news >正文

怎么用css做網(wǎng)站背景圖整站優(yōu)化seo公司哪家好

news 2025/7/15 10:23:53

怎么用css做網(wǎng)站背景圖,整站優(yōu)化seo公司哪家好,注冊一個做網(wǎng)站的公司,google網(wǎng)站登錄入口了解銀河麒麟操作系統(tǒng)更多全新產(chǎn)品，請點擊訪問麒麟軟件產(chǎn)品專區(qū)：https://product.kylinos.cn 現(xiàn)象描述某服務器系統(tǒng)升級內(nèi)核至4.19.90-25.22.v2101版本后仍會觸發(fā)oom導致java進程被kill。現(xiàn)象分析 oom現(xiàn)象分析系統(tǒng)messages日志分析，故…

了解銀河麒麟操作系統(tǒng)更多全新產(chǎn)品，請點擊訪問麒麟軟件產(chǎn)品專區(qū)：https://product.kylinos.cn

現(xiàn)象描述

某服務器系統(tǒng)升級內(nèi)核至4.19.90-25.22.v2101版本后仍會觸發(fā)oom導致java進程被kill。

現(xiàn)象分析

oom現(xiàn)象分析

系統(tǒng)messages日志分析，故障時間2024.3.2?13：45左右，如圖1：

圖1

從下面的日志信息，可以看到java進程是在內(nèi)核采用GFP_KERNEL|__GFP_COMP分配order=3也就是2的3次方，8個連續(xù)頁的時候，系統(tǒng)無法提供對應大小的連續(xù)內(nèi)存頁，導致oom產(chǎn)生并選擇java進程進行kill掉了。

現(xiàn)在來分析這一現(xiàn)像是否為正常現(xiàn)像（因為oom是內(nèi)核的正常的機制），GFP_KERNEL的首先內(nèi)存管理區(qū)為ZONE_NORMAL。從日志可以看出，當前系統(tǒng)一共有3個內(nèi)存管理區(qū)，分別是ZONE_DMA、ZONE_DMA32和ZONE_NORMAL。接下來分析這個3個內(nèi)存管理區(qū)的內(nèi)存使用情況：

1)ZONE_DMA的空閑內(nèi)存是15876kB , 最低水位是32k，低水位是44k, 高水位是56k, 空閑內(nèi)存遠大于高水位，所以kswapd是不會啟動回收的，但是Linux內(nèi)核有一個對低端內(nèi)存管理區(qū)的保護機制，lowmem_reserve中有體現(xiàn)，加上保護機制，最低水位為：32K + 30759*4KB=123068KB，這個數(shù)據(jù)比空閑內(nèi)存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的空閑內(nèi)存是160984kB , 最低水位是5904k，低水位是8656k, 高水位是11408k, 空閑內(nèi)存遠大于高水位，所以kswapd是不會啟動回收的，但和DMA區(qū)域一樣加上lowmem_reserve保護機制，最低水位為：5904K + 28069*4KB=128940KB。

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

單純從空閑內(nèi)存大小來看似乎可以從DMA32區(qū)域分配出java進程所需的內(nèi)存，但我們實際查看ZONE_DMA32的內(nèi)存分布，空閑的160984kb內(nèi)存大多為低階的內(nèi)存頁。最大只可提供16KB即order=2(2^2*4K=16K)的連續(xù)內(nèi)存頁，無法滿足java進程order=3的連續(xù)內(nèi)存頁請求。

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的空閑內(nèi)存是320512kb, 最低水位是61640k，低水位是90380k, 高水位是119120k, 空閑內(nèi)存高于高水位，所以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空閑內(nèi)存的內(nèi)存詳情時，我們發(fā)現(xiàn)它同樣最大只可提供16KB即order=2(2^2*4K=16K)的連續(xù)內(nèi)存頁，無法滿足java進程order=3的連續(xù)內(nèi)存頁請求。

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

從以上信息來看，本次觸發(fā)OOM的原因和之前類似，都是系統(tǒng)內(nèi)存碎片化，空閑內(nèi)存高于內(nèi)存回收水位但無法提供進程申請的較大階數(shù)的連續(xù)內(nèi)存頁。

但不同的是，之前x86服務器是由于內(nèi)核bug導致managed統(tǒng)計錯位，從而使得Normal區(qū)域的內(nèi)存回收水位線較小，而升級內(nèi)核則不存在這個bug。只是當前默認的67584KB min_free_kbytes和實際業(yè)務場景不太符合。

min_free_kbytes參數(shù)分析

從OOM日志來看java進程需要申請較大的連續(xù)內(nèi)存，而當前內(nèi)存水位線較低，觸發(fā)OOM時ZONE Normal雖有320512kb空閑內(nèi)存但都是零散的，這和內(nèi)存水位線的大小有關。

vm.min_free_kbytes是一個Linux重要的內(nèi)核參數(shù)，用于控制系統(tǒng)可用內(nèi)存的最小空閑大小。它指定了內(nèi)核應該保留的空閑內(nèi)存頁面的數(shù)量（以KB為單位），以便能夠及時滿足系統(tǒng)的需要。

當系統(tǒng)運行過程中需要更多的內(nèi)存時，從空閑頁面中分配內(nèi)存是一種快速且高效的方式。vm.min_free_kbytes參數(shù)的存在是為了確保系統(tǒng)在處理高內(nèi)存壓力時仍然具有足夠的可用內(nèi)存提供給內(nèi)核、驅動等關鍵應用使用，這部分預留內(nèi)存用戶態(tài)應用通常無法申請。

同時vm.min_free_kbytes的設置衍生出了不同的內(nèi)存回收水位，默認的內(nèi)存回收水位計算方式如下：

1、watermark[min] = min_free_kbytes

2、watermark[low] = watermark[min] * 5 / 4

3、watermark[high] = watermark[min] * 3 / 2

當系統(tǒng)剩余空閑內(nèi)存大于 high水位時，表示此時系統(tǒng)內(nèi)存足夠，不會進行內(nèi)存回收；當系統(tǒng)剩余空閑內(nèi)存內(nèi)存小于low水位時，表示此時內(nèi)存存在壓力，會觸發(fā) kswapd 進行后臺內(nèi)存回收，直到 pages_high 為止；當系統(tǒng)剩余空閑內(nèi)存內(nèi)存小于 min 水位時，表示此時用戶內(nèi)存耗盡，會觸發(fā)直接內(nèi)存回收，進程被阻塞。若是直接內(nèi)存回收等方式還是無法釋放出應用所需申請的連續(xù)內(nèi)存時，就將觸發(fā)OOM，通過強制殺死其他占用大量內(nèi)存的進程來釋放內(nèi)存。

min_free_kbytes設的越大，watermark的線越高，同時三個線之間的buffer量也相應會增加。這意味著會較早的啟動kswapd進行回收，且每次都會回收上來較多的內(nèi)存（直至watermark[high]才會停止），但這也會使得系統(tǒng)預留過多的空閑內(nèi)存，從而在一定程度上降低了應用程序可使用的內(nèi)存量。

min_free_kbytes設的過小，則會導致系統(tǒng)預留內(nèi)存過小。這不僅會導致在內(nèi)存壓力較大，空閑內(nèi)存不足時內(nèi)核、驅動以及其他GFP-AOTOMIC這種不可等待的內(nèi)存申請無法進行。由于每次內(nèi)存回收都是到watermark[high]就停止了，較低的min_free_kbytes容易導致每次進行內(nèi)存回收時都是回收的零散內(nèi)存，而未回收大塊的連續(xù)內(nèi)存，從而引起系統(tǒng)內(nèi)存碎片化。

總結

綜上所述，本次觸發(fā)OOM的原因和之前的情況較為類似，都是系統(tǒng)內(nèi)存回收水位線較小、內(nèi)存碎片化，空閑內(nèi)存高于內(nèi)存回收水位但無法提供進程申請的較大階數(shù)的連續(xù)內(nèi)存頁。

但不同的是，之前x86服務器是由于內(nèi)核bug導致managed統(tǒng)計錯位，從而使得Normal區(qū)域的內(nèi)存回收水位線較小。而升級內(nèi)核后則不存在這個bug，只是當前默認的67584KB min_free_kbytes和實際業(yè)務場景不太符合。

對該問題，推薦修改watermark_scale_factor的值，調(diào)大min、low、high三條內(nèi)存回收水位線的差距，使得系統(tǒng)在空閑內(nèi)存不足時更早、更多地進行內(nèi)存回收；之后對于內(nèi)存碎片化的情況，我們建議可以在業(yè)務空閑時指定定時任務規(guī)整內(nèi)存。