boost asio 壓力測試六小時後 Killed 的原因?

fiendcly

昨天寫了支 SOCKET SERVER.


經過 (PHP-FPM)FAST-CGI 跟 PHP 溝通


我一口氣拉了 2400 個 PHP-FPM  PROCES 來接受 SOCKET SERVER 的請求.

我的測試架構如下 :

PHP<--->PHP-FPM<--->(boost asio 異步IO)SOCKET SERVER <--> (五台) CLIENT STRESS TEST ( 連續開 一千個線程 每個線程 無限制(SLEEP)開 1億個 SOCKET 請求 跑迴圈送資料(DOS 攻擊)  )

SOCKET SERVER 回應字串長度 : 64個字元
CLIENT 端 發送請求 : 64個字元.

SOCKET SERVER 用 CHAR[1024] 限制在 1024.

以下是我的 Ulimit 表..
ulimit -c 102400
ulimit -u 102400
ulimit -n 102400
ulimit -d unlimited
ulimit -m unlimited
ulimit -s unlimited
ulimit -t unlimited
ulimit -v unlimited

使用 CENTOS6.2
HP-DL380Gen8 XEON E52620 , 32G ECC RAM , RAID 10 4個 SAS 一萬轉硬碟做 磁碟陣列

做測試.....

結果 -

SERVER 在六小時又43分:24秒 PROCESS 直接把 SOCKET SERVER 給 KILL 掉

CLIENT 端的( 幾千個 DOS PROCESS )連線全部中斷.

五台 CLIENT 全部 用 SNIFFER 監控封包... KILLED 後 , SOEKCT 的封包全部沒有了 , 因為 SERVER 連線斷了...

到 SERVER 端 發現 . SERVER 端出現 KILLED .

想請教...


KILLED 會發生的原因? 有那些?

什麼方式可以不要讓 KILLED 去關掉 SOCKET SERVER .

如果它會大量使用記憶體 ( 只要不超過 16 G 都是正常的 ) , 因為我有使用 MAP 跟 VECTOR 將 PHP 回應的資料選擇性的 CACHE 在 SOCKET SERVER

以降低 PHP-FPM 的工作...

所以如果是記憶體使用量大而關掉它 ? 有沒有什麼方法可以讓作業系統不要去 KILL 我的 PROCESS.


請有經驗的大大解答...

fiendcly

[root@FIEND sbin]# readelf -l wge

Elf file type is EXEC (Executable file)
Entry point 0x402e60
There are 8 program headers, starting at offset 64

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  PHDR           0x0000000000000040 0x0000000000400040 0x0000000000400040
                 0x00000000000001c0 0x00000000000001c0  R E    8
  INTERP         0x0000000000000200 0x0000000000400200 0x0000000000400200
                 0x000000000000001c 0x000000000000001c  R      1
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
  LOAD           0x0000000000000000 0x0000000000400000 0x0000000000400000
                 0x000000000000e627 0x000000000000e627  R E    200000
  LOAD           0x000000000000f000 0x000000000060f000 0x000000000060f000
                 0x000000000000056c 0x0000000000000ab8  RW     200000
  DYNAMIC        0x000000000000f030 0x000000000060f030 0x000000000060f030
                 0x0000000000000220 0x0000000000000220  RW     8
  NOTE           0x000000000000021c 0x000000000040021c 0x000000000040021c
                 0x0000000000000044 0x0000000000000044  R      4
  GNU_EH_FRAME   0x000000000000c2e0 0x000000000040c2e0 0x000000000040c2e0
                 0x00000000000004c4 0x00000000000004c4  R      4
  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000  RW     8

Section to Segment mapping:
  Segment Sections...
   00
   01     .interp
   02     .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .text .fini .rodata .eh_frame_hdr .eh_frame .gcc_except_table
   03     .ctors .dtors .jcr .dynamic .got .got.plt .data .bss
   04     .dynamic
   05     .note.ABI-tag .note.gnu.build-id
   06     .eh_frame_hdr
   07
[root@FIEND sbin]# readelf -d wge

Dynamic section at offset 0xf030 contains 29 entries:
  Tag        Type                         Name/Value
0x0000000000000001 (NEEDED)             Shared library: [libboost_system.so.1.50.0]
0x0000000000000001 (NEEDED)             Shared library: [libPhpFpm.so]
0x0000000000000001 (NEEDED)             Shared library: [libWgeBase64.so]
0x0000000000000001 (NEEDED)             Shared library: [libWgeJson.so]
0x0000000000000001 (NEEDED)             Shared library: [libZlib.so]
0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
0x000000000000000c (INIT)               0x402840
0x000000000000000d (FINI)               0x40ac58
0x000000006ffffef5 (GNU_HASH)           0x400260
0x0000000000000005 (STRTAB)             0x401040
0x0000000000000006 (SYMTAB)             0x4003c8
0x000000000000000a (STRSZ)              2992 (bytes)
0x000000000000000b (SYMENT)             24 (bytes)
0x0000000000000015 (DEBUG)              0x0
0x0000000000000003 (PLTGOT)             0x60f258
0x0000000000000002 (PLTRELSZ)           2280 (bytes)
0x0000000000000014 (PLTREL)             RELA
0x0000000000000017 (JMPREL)             0x401f58
0x0000000000000007 (RELA)               0x401df0
0x0000000000000008 (RELASZ)             360 (bytes)
0x0000000000000009 (RELAENT)            24 (bytes)
0x000000006ffffffe (VERNEED)            0x401d00
0x000000006fffffff (VERNEEDNUM)         4
0x000000006ffffff0 (VERSYM)             0x401bf0
0x0000000000000000 (NULL)               0x0

fiendcly

Aug 23 20:09:57 localhost kernel: [14354]    99 14354    56060      883   6       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14355]    99 14355    56060      883   6       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14356]    99 14356    56060      883   7       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14357]    99 14357    56060      883   7       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14358]    99 14358    56060      883   1       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14359]    99 14359    56060      883   2       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14360]    99 14360    56060      883   2       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14361]    99 14361    56060      883  10       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14362]    99 14362    56060      882  11       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14363]    99 14363    56060      882   7       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14364]    99 14364    56060      882   1       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14365]    99 14365    56060      882   6       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14366]    99 14366    56060      882  10       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14367]    99 14367    56060      883   6       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14368]    99 14368    56060      883   6       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14369]    99 14369    56060      883   9       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14370]    99 14370    56060      883   6       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14371]    99 14371    56060      883   6       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14372]    99 14372    56060      883   8       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14373]    99 14373    56060      883  11       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14374]    99 14374    56060      883   9       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14375]    99 14375    56060      883   9       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14376]    99 14376    56060      883   6       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14377]    99 14377    56060      883   8       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14378]    99 14378    56060      883   8       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14379]    99 14379    56060      883   6       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14380]    99 14380    56060      883   7       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14381]    99 14381    56124      891   6       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14382]    99 14382    56060      883  10       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14383]    99 14383    56060      883   6       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14384]    99 14384    56060      883   6       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14385]    99 14385    56060      883   8       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14386]    99 14386    56060      914   0       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14387]    99 14387    56060      914   6       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14388]    99 14388    56060      883   8       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14389]    99 14389    56060      883   6       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14390]    99 14390    56060      883  11       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14391]    99 14391    56060      882   8       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14392]    99 14392    56060      882   9       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14393]    99 14393    56060      882   8       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14394]    99 14394    56060      883   6       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14395]    99 14395    56060      883   8       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14396]    99 14396    56060      883   5       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14397]    99 14397    56060      914   1       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14398]    99 14398    56060      914  10       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14399]    99 14399    56060      883   6       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14400]    99 14400    56060      883   2       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14401]    99 14401    56060      883  11       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14402]    99 14402    56060      883   6       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14403]    99 14403    56060      883  10       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14404]    99 14404    56060      883   8       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14405]    99 14405    56060      914   1       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14406]    99 14406    56060      914   8       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14407]    99 14407    56060      883   1       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14408]    99 14408    56060      883   7       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14409]    99 14409    56060      914   1       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14410]    99 14410    56060      914  10       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14411]    99 14411    56060      914   6       0             0 php-fpm
Aug 23 20:09:57 localhost kernel: [14557]    89 14557    19688      274   6       0             0 pickup
Aug 23 20:09:57 localhost kernel: Out of memory: Kill process 9566 (wge) score 652 or sacrifice child
Aug 23 20:09:57 localhost kernel: Killed process 9566, UID 0, (wge) total-vm:22426596kB, anon-rss:22392788kB, file-rss:420kB

fiendcly

Aug 23 20:09:57 localhost kernel: Out of memory: Kill process 9566 (wge) score 652 or sacrifice child
Aug 23 20:09:57 localhost kernel: Killed process 9566, UID 0, (wge) total-vm:22426596kB, anon-rss:22392788kB, file-rss:420kB

找到原因了 是因為 oom-killer 造成的.

fiendcly

[root@FIEND ~]# cat /proc/meminfo
MemTotal:       32879912 kB
MemFree:        28515216 kB
Buffers:           12664 kB
Cached:            36960 kB
SwapCached:            0 kB
Active:          2325292 kB
Inactive:          94472 kB
Active(anon):    2315716 kB
Inactive(anon):    64404 kB
Active(file):       9576 kB
Inactive(file):    30068 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:                68 kB
Writeback:             0 kB
AnonPages:       2370252 kB
Mapped:            15820 kB
Shmem:              9916 kB
Slab:            1182356 kB
SReclaimable:      17908 kB
SUnreclaim:      1164448 kB
KernelStack:       18992 kB
PageTables:       339972 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    16439956 kB
Committed_AS:   10943160 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      329264 kB
VmallocChunk:   34341981564 kB
HardwareCorrupted:     0 kB
AnonHugePages:     22528 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:       10240 kB
DirectMap2M:    33544192 kB

fiendcly

[root@FIEND ~]# free -l
             total       used       free     shared    buffers     cached
Mem:      32879912    4364604   28515308          0      12704      36972
Low:      32879912    4364604   28515308

fiendcly

這裡有一篇對 OOM KILLER 的詳細說明 :

原文作者：Eric Sisler <esisler westminster lib co us>

原文鏈接：http://www.redhat.com/archives/t ... ugust/msg00006.html

由於這個問題似乎在不同的郵件列表中出現，我已經將此消息張貼到紅帽一般性討論列表了，RHEL3（Taroon）和RHEL4（Nahant）列表。很抱歉我沒有時間來更早的發布它。

通常，在大內存（6Gb+）服務器上，out of memory killer (oom-killer)也會殺死進程。在很多case中，人們都困惑地報告說還有剩余內存的情況下，為何oom-killer還會殺死進程？現象是在 /var/log/messages 日誌中，有如下信息：

  Out of Memory: Killed process [PID] [process name].

在我自己的case中，我在VMware中升級了各個RHEL3到RHEL4，有1個16Gb內存的服務器，還是會被oom-killer殺死進程。不用說，這非常令人沮喪。

事實證明，這個問題的原因是low memory耗盡。引用Tom的話“內核使用low memory來跟蹤所有的內存分配，這樣的話一個16GB內存的系統比一個4GB內存的系統，需要消耗更多的low memory，可能有4倍之多。這種額外的壓力從你剛啟動系統那一刻就開始存在了，因為內核結構必須為潛在的跟蹤四倍多的內存分配而調整大小（ The kernel uses low memory to track allocations of all memory thus a system with 16GB of memory will use significantly more low memory than a system with 4GB, perhaps as much as 4 times. This extra pressure happens from the moment you turn the system on before you do anything at all because the kernel structures have to be sized for the potential of tracking allocations in four times as much memory）”。
有兩種方法查看 low memory 和 high memory 的狀態：

# egrep 'High|Low' /proc/meminfo
HighTotal:     5111780 kB
HighFree:         1172 kB
LowTotal:       795688 kB
LowFree:         16788 kB

# free -lm
             total       used       free     shared    buffers     cached
Mem:          5769       5751         17          0          8       5267
Low:           777        760         16          0          0          0
High:         4991       4990          1          0          0          0
-/+ buffers/cache:        475       5293
Swap:         4773          0       4773


當low memory耗盡，不管high memory剩余多少，oom-killer都開始殺死進程，以保持系統的正常運轉。
有兩種方法解決這個問題：

1、如果可能，請升級到64位系統。

這是最好的解決辦法，因為所有的內存都將成為low memory。如果你在這種情況下耗盡了low memory，那就真的是out of memory了。

2、如果受限於必須使用32位系統，最好的解決辦法是使用hugemem內核。

這種內核以不同的方式分割low/high memory，而且在大多數情況下會提供足夠多的low memory到high memory的映射（This kernel splits low/high memory differently, and in most cases should provide enough low memory to map high memory）。在大多數案例中，這是一個很簡單的修復方法：安裝hugemem kernel RPM包，然後重啟即可。

如果運行hugemem內核也不可能，你可以嘗試將 /proc/sys/vm/lower_zone_protection 的值設置為250甚至更多。這將讓內核願意保護low memory，從而在分配內存時多考慮從high memory分配（This will cause the kernel to try to be more aggressive in defending the low zone from allocating memory that could potentially be allocated in the high memory zone.）。據我所知，此選項從2.6.x內核才開始可用。必要的是，您可能需要通過一些實驗來找到您系統環境中最適合的值。可以使用下面方法快速的設置和檢查改值：

  # cat /proc/sys/vm/lower_zone_protection
  # echo "250" > /proc/sys/vm/lower_zone_protection


在 /etc/sysctl.conf 中加入設置，以便啟動就生效：

  vm.lower_zone_protection = 250


作為最後的努力，你可以關閉oom-killer。這個選項可以導致系統掛起，所以請小心使用（風險自負）！

查看當前oom-killer的狀態：

  # cat /proc/sys/vm/oom-kill


關閉/打開oom-killer：

  # echo "0" > /proc/sys/vm/oom-kill
  # echo "1" > /proc/sys/vm/oom-kill


加入到 /etc/sysctl.conf，以便啟動就生效：

  vm.oom-kill = 0


當進程該被oom-killer殺死卻沒有被殺死時，相關信息會記錄到 /var/log/messages:

  "Would have oom-killed but /proc/sys/vm/oom-kill is disabled"


很抱歉啰嗦多了。我希望它能幫助到那些正在被該問題困擾的人們。

--Eric

翻譯完畢，有些句子實在難理解，把原文貼在後面了。

=========再引用些支付寶牛人的文字：==============

http://www.dbanotes.net/database ... ory_oom_killer.html

說白了 OOM Killer 就是一層保護機制，用於避免 Linux 在內存不足的時候不至於出太嚴重的問題，把無關緊要的進程殺掉，有些壯士斷腕的意思。

先要學習點老知識，在 32 位CPU 架構下尋址是有限制的。Linux 內核定義了三個區域：

# DMA: 0x00000000 -  0x00999999 (0 - 16 MB)
# LowMem: 0x01000000 - 0x037999999 (16 - 896 MB) - size: 880MB
# HighMem: 0x038000000 - <硬件特定>


LowMem 區 (也叫 NORMAL ZONE ) 一共 880 MB，而且不能改變(除非用 hugemem 內核)。對於高負載的系統，就可能因為 LowMem 利用不好而引發 OOM Killer 。一個可能原因是 LowFree 太少了，另外一個原因是 LowMem 裏都是碎片，請求不到連續的內存區域【根據我遇到的一個案例，一個猜想是 有些應用一次性請求比較大的內存，恰恰又是 880M 之內的，空閑的(LowFree)不夠大，就會觸發 OOM Killer 出來幹活】。檢查當前 LowFree 的值：

# cat /proc/meminfo |grep LowFree


檢查LowMem內存碎片：

# cat /proc/buddyinfo


上面這條命令要在 2.6 Kernel 環境下有效。據說使用 SysRq 的方式更好，不過 Hang 的時候再用吧。參見 Metalink Note:228203.1 。

根據一些文檔描述，OOM Killer 在 2.4 與 2.6 上表現是不一樣的。2.4 的版本中是把新進來(新申請內存)的進程殺掉。而 2.6 上是殺掉占用內存最厲害的進程(這是很危險的，很容易導致系統應用癱瘓)。

對於 RHEL 4 ，新增了一個參數： vm.lower_zone_protection 。這個參數默認的單位為 MB，默認 0 的時候，LowMem 為 16MB。建議設置 vm.lower_zone_protection = 200 甚至更大以避免 LowMem 區域的碎片，是絕對能解決這個問題的(這參數就是解決這個問題出來的)。

而對於 RHEL 3 (Kernel 2.4) 似乎沒什麽好辦法，一個是用 Hugemem 內核(天知道會不會引入新的毛病)，一個是升級到 2.4.21-47 並且使用新的核心參數 vm.vm-defragment 控制碎片的數量。再就是使用 RHEL 4 (Kernel 2.6)，這又繞回去了。說白了，如果遇到 OOM Killer ，基本上是低版本 Kernel 設計上有點缺陷。

=================================================

hellioncu

这么晚还干活

windoze

如果有这么大的内存占用量，其实我严重建议你用64位系统

fiendcly

windoze 发表于 2012-08-24 12:42
如果有这么大的内存占用量，其实我严重建议你用64位系统

就是 64 喔.

DL380Gen8 XEON E52620 <<< 花了我 二十萬台幣...


>_<" 我是故意讓它吃記憶體的..

因為我同時發動 1 千多個 DOS 在轟炸 SERVER....