Em có con server chạy Centos 5.2 (Core2 Quad 6600, 8GB RAM, 16 GB swap). Gần đây xuất hiện tình trạng kswapd sử dụng 100% CPU, RAM free chỉ còn hơn 10MB. Server treo không làm gì được. Reboot thi lại chạy bình thường. Không biết vấn đề do đâu?. Mọi người tư vấn giùm em với. 

azteam wrote:

Em có con server chạy Centos 5.2 (Core2 Quad 6600, 8GB RAM, 16 GB swap). Gần đây xuất hiện tình trạng kswapd sử dụng 100% CPU, RAM free chỉ còn hơn 10MB. Server treo không làm gì được. Reboot thi lại chạy bình thường. Không biết vấn đề do đâu?. Mọi người tư vấn giùm em với. 

Trước tiên cần xác định những process nào tạo tình trạng này. Xem "top" thử process nào nuốt memory như vậy rồi từ đó mới xét đến giải pháp. 

top - 11:34:30 up 3 days,  2:24,  5 users,  load average: 143.30, 108.64, 56.17
Tasks: 319 total,  11 running, 299 sleeping,   0 stopped,   9 zombie
Cpu(s): 45.6%us, 10.3%sy,  0.2%ni, 41.9%id,  1.4%wa,  0.0%hi,  0.6%si,  0.0%st
Mem:   8310272k total,  7419692k used,   890580k free,   448252k buffers
Swap: 16482680k total,       76k used, 16482604k free,  5509184k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
  205 root      11  -5     0    0    0 R 101.1  0.0   8:13.03 kswapd0
27209 root      18   0  2028  728  592 R 101.1  0.0   8:17.19 repquota
28935 root      15   0  2324 1048  712 R  1.9  0.0   0:00.01 top
    1 root      15   0  2064  636  548 S  0.0  0.0   0:05.90 init

conmale wrote:

azteam wrote:

Em có con server chạy Centos 5.2 (Core2 Quad 6600, 8GB RAM, 16 GB swap). Gần đây xuất hiện tình trạng kswapd sử dụng 100% CPU, RAM free chỉ còn hơn 10MB. Server treo không làm gì được. Reboot thi lại chạy bình thường. Không biết vấn đề do đâu?. Mọi người tư vấn giùm em với. 

Trước tiên cần xác định những process nào tạo tình trạng này. Xem "top" thử process nào nuốt memory như vậy rồi từ đó mới xét đến giải pháp. 

Hi anh,

Sau khi tìm hiểu, có nhiều khả năng có thể dẫn đến tình trạng trên. Trong đó vấn đề từ kernel cũng có thể xảy ra. Em đã thử update kernel, chạy ổn định được 3 ngày rồi tình trạng nõ vẫn trở lại như cũ.

Tại thời điểm treo CPU, xem "top" process có thông tin chú ý:

Code:

top - 11:34:30 up 3 days,  2:24,  5 users,  load average: 143.30, 108.64, 56.17
Tasks: 319 total,  11 running, 299 sleeping,   0 stopped,   9 zombie
Cpu(s): 45.6%us, 10.3%sy,  0.2%ni, 41.9%id,  1.4%wa,  0.0%hi,  0.6%si,  0.0%st
Mem:   8310272k total,  7419692k used,   890580k free,   448252k buffers
Swap: 16482680k total,       76k used, 16482604k free,  5509184k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
  205 root      11  -5     0    0    0 R 101.1  0.0   8:13.03 kswapd0
27209 root      18   0  2028  728  592 R 101.1  0.0   8:17.19 repquota
28935 root      15   0  2324 1048  712 R  1.9  0.0   0:00.01 top
    1 root      15   0  2064  636  548 S  0.0  0.0   0:05.90 init

Tại thời điểm này tất cả service trên server đều bị stop.

Theo anh và mọi người có thể do đâu?
 

Hi anh,

Vấn đề là khi tình trạng trên xẩy ra em không thể làm gì được, nên không show được thông tin như anh yêu cầu.
"top" process trên là do em để sẵn shell trước khi server bị treo.
Hiện tại em đã phải reboot server để chạy dịch vụ. Thường thì chạy sau vài ngày mới bị lại tình trạng trên.
Em sẽ gửi anh thông tin anh cần sau, nhưng với tình trạng trên thì có thể do đâu?.

Thanks, 

Theo kinh nghiệm và những gì tớ đọc được ở đâu đó, thì swap nên chỉ để tối đa 2GB (Fedora/Centos khi cài đặt chế độ tạo partition mặc định, thì nó luôn tạo swap max 2GB, cho dù RAM = 8GB).
Tại sao thế, vì khi cần memory, một máy 8GB RAM mà OS phải hoán đổi 8GB đó xuống đĩa thì ... vô cùng tệ hại. Đĩa đọc/ghi bị giới hạn tốc độ, như tớ gặp thì nhanh nhất với local disk cỡ 100MB/s, với 8GB hoán đổi mất 80 second là toi hết ứng dụng. 

total       used       free     shared    buffers     cached
Mem:          2004       1946         57          0        592        775
-/+ buffers/cache:        578       1425
Swap:          807          4        803

azteam wrote:

Hi anh,

Vấn đề là khi tình trạng trên xẩy ra em không thể làm gì được, nên không show được thông tin như anh yêu cầu.
"top" process trên là do em để sẵn shell trước khi server bị treo.
Hiện tại em đã phải reboot server để chạy dịch vụ. Thường thì chạy sau vài ngày mới bị lại tình trạng trên.
Em sẽ gửi anh thông tin anh cần sau, nhưng với tình trạng trên thì có thể do đâu?.

Thanks, 

Trên máy chủ ấy em chạy những ứng dụng nào với những biên bản nào? (apache, mysql...) . Hồ sơ cấu hình của chúng ra sao?

Tình trạng trên thường do bị memory leak khiến cho physical memory bị cạn kiệt nên phải nhảy sang dùng swap (bởi thế kswapd0 mới bận rộn mà nuốt quá nhiều CPU như thế). Muốn fix tình trạng này thì cần xác định xem ứng dụng nào nuốt quá nhiều memory.

Thông tin top anh cần không nhất thiết phải ngay lúc server bị crash mà chỉ cần 2 cái cách nhau chừng 30 phút. 

PHP 5.2.9 (cli) (built: Mar 10 2009 02:32:23)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies
    with the ionCube PHP Loader v3.1.32, Copyright (c) 2002-2007, by ionCube Ltd., and
    with Zend Extension Manager v1.2.2, Copyright (c) 2003-2007, by Zend Technologies
    with Suhosin v0.9.27, Copyright (c) 2007, by SektionEins GmbH
    with Zend Optimizer v3.3.3, Copyright (c) 1998-2007, by Zend Technologies
--------
Server version: Apache/2.2.11 (Unix)
Server built:   Mar 10 2009 02:03:31
--------
mysql  Ver 14.12 Distrib 5.0.67, for redhat-linux-gnu (i686) using readline 5.1

top - 17:04:41 up  5:25,  1 user,  load average: 21.17, 17.83, 15.31
Tasks: 184 total,   3 running, 176 sleeping,   1 stopped,   4 zombie
Cpu(s): 63.4%us, 20.7%sy,  0.0%ni, 15.1%id,  0.1%wa,  0.0%hi,  0.8%si,  0.0%st
Mem:   8310272k total,  6167988k used,  2142284k free,   407008k buffers
Swap: 16482680k total,        0k used, 16482680k free,  4953304k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5392 mysql     10  -5  640m 255m 3724 S 80.5  3.1  96:37.16 mysqld
10259 root      18   0 37076  33m 2508 S  0.0  0.4   0:11.88 spamd
 6960 root      17   0 36556  33m 2508 S  0.0  0.4   0:13.77 spamd
26518 nobody    18   0  322m  29m 2152 S  1.7  0.4   0:04.94 httpd
19723 nobody    18   0  321m  29m 2224 S  1.3  0.4   0:07.62 httpd
23291 nobody    24   0  261m  29m 2220 S  0.0  0.4   0:04.89 httpd
 5493 root      15   0 31668  28m 2500 S  0.0  0.4   0:01.65 spamd
28423 nobody    18   0  321m  28m 2224 S  1.0  0.3   0:03.05 httpd
13240 nobody    18   0  290m  28m 2228 S  0.0  0.3   0:07.97 httpd
27906 nobody    18   0  320m  27m 2192 S  1.3  0.3   0:04.15 httpd
29667 nobody    18   0  319m  26m 1996 S  1.3  0.3   0:02.99 httpd
30573 nobody    18   0  319m  26m 1996 S  1.7  0.3   0:02.52 httpd
  723 nobody    18   0  318m  26m 1992 S  0.7  0.3   0:01.19 httpd
32145 nobody    18   0  319m  25m 1988 S  1.0  0.3   0:01.86 httpd
31994 nobody    18   0  317m  25m 1976 S  1.0  0.3   0:02.02 httpd
 2179 nobody    18   0  317m  24m 1988 S  1.7  0.3   0:00.56 httpd
  999 nobody    18   0  176m  24m 1992 S  0.0  0.3   0:01.04 httpd
 2531 nobody    18   0  317m  24m 1996 S  2.0  0.3   0:00.41 httpd
 8799 root      18   0 43860  20m 2476 S  0.0  0.3   0:01.34 httpd
 8805 nobody    20   0 43408  18m 1000 S  0.0  0.2   0:00.00 httpd
 8811 root      18   0 43276  18m  472 S  0.0  0.2   0:00.00 httpd
 3606 usera      17   0 42520  16m 6216 S  4.7  0.2   0:00.14 php
 6391 gdm       19   0 32232  15m 7744 S  0.0  0.2   0:00.48 gdmgreeter
24554 root      37  19 22564  13m 2948 S  0.0  0.2   0:12.26 cpanellogd
14104 anhthe    34  19 22564  11m  880 S  0.0  0.1   0:00.00 cpanellogd
 3563 userx   17   0 35956  11m 5516 S  1.3  0.1   0:00.04 php
 1921 usery   16   0 35668  10m 5480 S  0.0  0.1   0:00.04 php
 2111 userz   17   0 35668  10m 5476 S  0.0  0.1   0:00.04 php
 6051 root      34  19 26500 9.9m 2136 S  0.0  0.1   0:00.03 yum-updatesd

top - 17:26:53 up  5:47,  1 user,  load average: 9.85, 16.56, 20.80
Tasks: 189 total,  23 running, 160 sleeping,   1 stopped,   5 zombie
Cpu(s): 78.7%us, 21.3%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   8310272k total,  6443084k used,  1867188k free,   415072k buffers
Swap: 16482680k total,        0k used, 16482680k free,  5116000k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5392 mysql     10  -5  643m 259m 3724 S 43.2  3.2 116:39.42 mysqld
 3976 nobody    18   0  359m  66m 2204 S  1.3  0.8   0:06.65 httpd
11027 nobody    18   0  347m  55m 2180 S  2.5  0.7   0:02.46 httpd
10259 root      15   0 37076  33m 2508 S  0.0  0.4   0:12.63 spamd
 6960 root      16   0 36556  33m 2512 S  0.0  0.4   0:20.97 spamd
 5493 root      15   0 31668  28m 2500 S  0.0  0.4   0:01.71 spamd
 8407 nobody    18   0  320m  28m 2788 S  2.5  0.3   0:03.29 httpd
 2605 nobody    18   0  319m  27m 2212 S  3.8  0.3   0:05.85 httpd
 1512 nobody    18   0  319m  26m 2212 S  3.8  0.3   0:06.35 httpd
10669 nobody    18   0  318m  26m 2180 S  2.5  0.3   0:02.31 httpd
13113 nobody    18   0  317m  25m 2192 S  3.8  0.3   0:01.04 httpd
14185 nobody    18   0  317m  23m 2176 S  1.3  0.3   0:00.50 httpd
13789 nobody    18   0  316m  23m 2196 S  3.8  0.3   0:00.60 httpd
14920 userg  18   0 46568  22m 6468 R 42.0  0.3   0:00.33 php
14689 nobody    18   0  313m  21m 1964 S  0.0  0.3   0:00.09 httpd
 8799 root      18   0 43860  20m 2476 S  0.0  0.3   0:01.46 httpd
14941 nobody    19   0  313m  19m  452 R  0.0  0.2   0:00.00 httpd
 8805 nobody    17   0 43408  18m 1000 S  0.0  0.2   0:00.00 httpd
 8811 root      18   0 43276  18m  472 S  0.0  0.2   0:00.00 httpd
14933 userf      17   0 43304  17m 6176 R 19.1  0.2   0:00.15 php
14922 usere    18   0 41172  17m 6132 R 20.3  0.2   0:00.16 php
14931 usere    18   0 40928  16m 6104 R 16.5  0.2   0:00.13 php
 6391 gdm       17   0 32232  15m 7744 S  0.0  0.2   0:00.49 gdmgreeter
14921 userd   17   0 38704  14m 6100 R 14.0  0.2   0:00.11 php
14935 userc   17   0 39152  14m 6264 R 26.7  0.2   0:00.21 php
24554 root      37  19 22564  13m 2948 S  0.0  0.2   0:12.26 cpanellogd
14944 usera   18   0 37252  13m 5816 R  8.9  0.2   0:00.07 php
14945 userb      18   0 39260  12m 5556 R  8.9  0.2   0:00.07 php
14943 userb      18   0 38236  11m 5468 R  6.4  0.1   0:00.05 php

Theo như top đưa lên thì thực sự swap không bị sử dụng (chỉ có 76k).
Do đó kswapd chạy như thế là bất thường, có thể lỗi vì bug hoặc swap quá to?
Bạn thử xem trong dmesg log và /var/log/messages xem có thông báo gì đặc biệt.

Theo kinh nghiệm và những gì tớ đọc được ở đâu đó, thì swap nên chỉ để tối đa 2GB (Fedora/Centos khi cài đặt chế độ tạo partition mặc định, thì nó luôn tạo swap max 2GB, cho dù RAM = 8GB).
Tại sao thế, vì khi cần memory, một máy 8GB RAM mà OS phải hoán đổi 8GB đó xuống đĩa thì ... vô cùng tệ hại. Đĩa đọc/ghi bị giới hạn tốc độ, như tớ gặp thì nhanh nhất với local disk cỡ 100MB/s, với 8GB hoán đổi mất 80 second là toi hết ứng dụng. 

conmale wrote:

azteam wrote:

Hi anh,

Vấn đề là khi tình trạng trên xẩy ra em không thể làm gì được, nên không show được thông tin như anh yêu cầu.
"top" process trên là do em để sẵn shell trước khi server bị treo.
Hiện tại em đã phải reboot server để chạy dịch vụ. Thường thì chạy sau vài ngày mới bị lại tình trạng trên.
Em sẽ gửi anh thông tin anh cần sau, nhưng với tình trạng trên thì có thể do đâu?.

Thanks, 

Trên máy chủ ấy em chạy những ứng dụng nào với những biên bản nào? (apache, mysql...) . Hồ sơ cấu hình của chúng ra sao?

Tình trạng trên thường do bị memory leak khiến cho physical memory bị cạn kiệt nên phải nhảy sang dùng swap (bởi thế kswapd0 mới bận rộn mà nuốt quá nhiều CPU như thế). Muốn fix tình trạng này thì cần xác định xem ứng dụng nào nuốt quá nhiều memory.

Thông tin top anh cần không nhất thiết phải ngay lúc server bị crash mà chỉ cần 2 cái cách nhau chừng 30 phút. 

Hi anh,

Server của em chạy các ứng dụng web. Version:
Code:

PHP 5.2.9 (cli) (built: Mar 10 2009 02:32:23)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies
    with the ionCube PHP Loader v3.1.32, Copyright (c) 2002-2007, by ionCube Ltd., and
    with Zend Extension Manager v1.2.2, Copyright (c) 2003-2007, by Zend Technologies
    with Suhosin v0.9.27, Copyright (c) 2007, by SektionEins GmbH
    with Zend Optimizer v3.3.3, Copyright (c) 1998-2007, by Zend Technologies
--------
Server version: Apache/2.2.11 (Unix)
Server built:   Mar 10 2009 02:03:31
--------
mysql  Ver 14.12 Distrib 5.0.67, for redhat-linux-gnu (i686) using readline 5.1

Ngoài ra còn chạy cpanel, modsec2, apf firewall, với một số ứng dụng khác đi kèm.

Kết quả em "top" process khi server đang bình thường:

Code:

top - 17:04:41 up  5:25,  1 user,  load average: 21.17, 17.83, 15.31
Tasks: 184 total,   3 running, 176 sleeping,   1 stopped,   4 zombie
Cpu(s): 63.4%us, 20.7%sy,  0.0%ni, 15.1%id,  0.1%wa,  0.0%hi,  0.8%si,  0.0%st
Mem:   8310272k total,  6167988k used,  2142284k free,   407008k buffers
Swap: 16482680k total,        0k used, 16482680k free,  4953304k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5392 mysql     10  -5  640m 255m 3724 S 80.5  3.1  96:37.16 mysqld
10259 root      18   0 37076  33m 2508 S  0.0  0.4   0:11.88 spamd
 6960 root      17   0 36556  33m 2508 S  0.0  0.4   0:13.77 spamd
26518 nobody    18   0  322m  29m 2152 S  1.7  0.4   0:04.94 httpd
19723 nobody    18   0  321m  29m 2224 S  1.3  0.4   0:07.62 httpd
23291 nobody    24   0  261m  29m 2220 S  0.0  0.4   0:04.89 httpd
 5493 root      15   0 31668  28m 2500 S  0.0  0.4   0:01.65 spamd
28423 nobody    18   0  321m  28m 2224 S  1.0  0.3   0:03.05 httpd
13240 nobody    18   0  290m  28m 2228 S  0.0  0.3   0:07.97 httpd
27906 nobody    18   0  320m  27m 2192 S  1.3  0.3   0:04.15 httpd
29667 nobody    18   0  319m  26m 1996 S  1.3  0.3   0:02.99 httpd
30573 nobody    18   0  319m  26m 1996 S  1.7  0.3   0:02.52 httpd
  723 nobody    18   0  318m  26m 1992 S  0.7  0.3   0:01.19 httpd
32145 nobody    18   0  319m  25m 1988 S  1.0  0.3   0:01.86 httpd
31994 nobody    18   0  317m  25m 1976 S  1.0  0.3   0:02.02 httpd
 2179 nobody    18   0  317m  24m 1988 S  1.7  0.3   0:00.56 httpd
  999 nobody    18   0  176m  24m 1992 S  0.0  0.3   0:01.04 httpd
 2531 nobody    18   0  317m  24m 1996 S  2.0  0.3   0:00.41 httpd
 8799 root      18   0 43860  20m 2476 S  0.0  0.3   0:01.34 httpd
 8805 nobody    20   0 43408  18m 1000 S  0.0  0.2   0:00.00 httpd
 8811 root      18   0 43276  18m  472 S  0.0  0.2   0:00.00 httpd
 3606 usera      17   0 42520  16m 6216 S  4.7  0.2   0:00.14 php
 6391 gdm       19   0 32232  15m 7744 S  0.0  0.2   0:00.48 gdmgreeter
24554 root      37  19 22564  13m 2948 S  0.0  0.2   0:12.26 cpanellogd
14104 anhthe    34  19 22564  11m  880 S  0.0  0.1   0:00.00 cpanellogd
 3563 userx   17   0 35956  11m 5516 S  1.3  0.1   0:00.04 php
 1921 usery   16   0 35668  10m 5480 S  0.0  0.1   0:00.04 php
 2111 userz   17   0 35668  10m 5476 S  0.0  0.1   0:00.04 php
 6051 root      34  19 26500 9.9m 2136 S  0.0  0.1   0:00.03 yum-updatesd

20 mins sau:

Code:

top - 17:26:53 up  5:47,  1 user,  load average: 9.85, 16.56, 20.80
Tasks: 189 total,  23 running, 160 sleeping,   1 stopped,   5 zombie
Cpu(s): 78.7%us, 21.3%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   8310272k total,  6443084k used,  1867188k free,   415072k buffers
Swap: 16482680k total,        0k used, 16482680k free,  5116000k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5392 mysql     10  -5  643m 259m 3724 S 43.2  3.2 116:39.42 mysqld
 3976 nobody    18   0  359m  66m 2204 S  1.3  0.8   0:06.65 httpd
11027 nobody    18   0  347m  55m 2180 S  2.5  0.7   0:02.46 httpd
10259 root      15   0 37076  33m 2508 S  0.0  0.4   0:12.63 spamd
 6960 root      16   0 36556  33m 2512 S  0.0  0.4   0:20.97 spamd
 5493 root      15   0 31668  28m 2500 S  0.0  0.4   0:01.71 spamd
 8407 nobody    18   0  320m  28m 2788 S  2.5  0.3   0:03.29 httpd
 2605 nobody    18   0  319m  27m 2212 S  3.8  0.3   0:05.85 httpd
 1512 nobody    18   0  319m  26m 2212 S  3.8  0.3   0:06.35 httpd
10669 nobody    18   0  318m  26m 2180 S  2.5  0.3   0:02.31 httpd
13113 nobody    18   0  317m  25m 2192 S  3.8  0.3   0:01.04 httpd
14185 nobody    18   0  317m  23m 2176 S  1.3  0.3   0:00.50 httpd
13789 nobody    18   0  316m  23m 2196 S  3.8  0.3   0:00.60 httpd
14920 userg  18   0 46568  22m 6468 R 42.0  0.3   0:00.33 php
14689 nobody    18   0  313m  21m 1964 S  0.0  0.3   0:00.09 httpd
 8799 root      18   0 43860  20m 2476 S  0.0  0.3   0:01.46 httpd
14941 nobody    19   0  313m  19m  452 R  0.0  0.2   0:00.00 httpd
 8805 nobody    17   0 43408  18m 1000 S  0.0  0.2   0:00.00 httpd
 8811 root      18   0 43276  18m  472 S  0.0  0.2   0:00.00 httpd
14933 userf      17   0 43304  17m 6176 R 19.1  0.2   0:00.15 php
14922 usere    18   0 41172  17m 6132 R 20.3  0.2   0:00.16 php
14931 usere    18   0 40928  16m 6104 R 16.5  0.2   0:00.13 php
 6391 gdm       17   0 32232  15m 7744 S  0.0  0.2   0:00.49 gdmgreeter
14921 userd   17   0 38704  14m 6100 R 14.0  0.2   0:00.11 php
14935 userc   17   0 39152  14m 6264 R 26.7  0.2   0:00.21 php
24554 root      37  19 22564  13m 2948 S  0.0  0.2   0:12.26 cpanellogd
14944 usera   18   0 37252  13m 5816 R  8.9  0.2   0:00.07 php
14945 userb      18   0 39260  12m 5556 R  8.9  0.2   0:00.07 php
14943 userb      18   0 38236  11m 5468 R  6.4  0.1   0:00.05 php

Thanks,

 

Nhìn qua 2 cái top này thì thấy ngay mức độ "grow" của mem dùng cho httpd quá nhanh. Nếu apache không triệt tiêu các processes đã được dùng để lấy lại mem kịp thời thì cứ đà này, sau 3 ngày server sẽ hết mem. Đến lúc server hết physical mem thì không có socket nào có thể spawn được nữa (vì chúng dùng physical mem chớ không phải virtual mem). Bởi thế, việc truy cập vào server lúc ấy là việc không thể được (không còn mem để spawn socket mới).

Em thảy lên cái apache config, cụ thể cái httpd-mpm để anh xem thử. Sẵn thảy lên cái php.ini luôn. 

ServerLimit 40
StartServers 2
MaxClients 1000
MinSpareThreads 25
MaxSpareThreads 75
ThreadsPerChild 25
MaxRequestsPerChild 1000

nhiều thầy quá mà không thầy nào thấy đúng bệnh hết. mình cho bạn azteam một cái keyword nè: "không phải cứ hàng khủng là tốt".

vấn đề của bạn đơn giản là nhiều RAM quá, làm tăng số lượng page, khiến cho kswapd nó phải tốn rất nhiều thời gian quý báu của CPU để quét cái page table, khi mà server chạy được một thời gian, RAM bắt đầu giảm xuống. giải pháp tốt nhất là giảm số lượng page trong page table.

còn làm thế nào thì bạn thử xài cái keyword ở trên. mình nghĩ tự làm sẽ hay đó, hiểu thêm về cách linux quản lý bộ nhớ. nhưng nếu mà cần gấp, thì bạn có thể thuê mình, trong vòng 24h sẽ giải quyết xong vấn đề, giá cả phải chăng lol. 

conmale wrote:

Nhìn qua 2 cái top này thì thấy ngay mức độ "grow" của mem dùng cho httpd quá nhanh. Nếu apache không triệt tiêu các processes đã được dùng để lấy lại mem kịp thời thì cứ đà này, sau 3 ngày server sẽ hết mem. Đến lúc server hết physical mem thì không có socket nào có thể spawn được nữa (vì chúng dùng physical mem chớ không phải virtual mem). Bởi thế, việc truy cập vào server lúc ấy là việc không thể được (không còn mem để spawn socket mới).

Em thảy lên cái apache config, cụ thể cái httpd-mpm để anh xem thử. Sẵn thảy lên cái php.ini luôn. 

Apache em build mpm worker với các tham số:

Code:

ServerLimit 40
StartServers 2
MaxClients 1000
MinSpareThreads 25
MaxSpareThreads 75
ThreadsPerChild 25
MaxRequestsPerChild 1000

Còn php.ini của server không biết anh cần những tham số nào trong đấy vì nếu em thảy hết lên thì rất dài . Có những tham số không cần thiết.

Thanks, 

azteam wrote:

conmale wrote:

Nhìn qua 2 cái top này thì thấy ngay mức độ "grow" của mem dùng cho httpd quá nhanh. Nếu apache không triệt tiêu các processes đã được dùng để lấy lại mem kịp thời thì cứ đà này, sau 3 ngày server sẽ hết mem. Đến lúc server hết physical mem thì không có socket nào có thể spawn được nữa (vì chúng dùng physical mem chớ không phải virtual mem). Bởi thế, việc truy cập vào server lúc ấy là việc không thể được (không còn mem để spawn socket mới).

Em thảy lên cái apache config, cụ thể cái httpd-mpm để anh xem thử. Sẵn thảy lên cái php.ini luôn. 

Apache em build mpm worker với các tham số:

Code:

ServerLimit 40
StartServers 2
MaxClients 1000
MinSpareThreads 25
MaxSpareThreads 75
ThreadsPerChild 25
MaxRequestsPerChild 1000

Còn php.ini của server không biết anh cần những tham số nào trong đấy vì nếu em thảy hết lên thì rất dài . Có những tham số không cần thiết.

Thanks, 

Thử chạy:

sysctl -a | grep shmmax

và

sysctl -a | grep huge

rồi gởi thông tin lên đây xem? 

# sysctl -a | grep shmmax
kernel.shmmax = 4294967295
# sysctl -a | grep huge
vm.hugetlb_shm_group = 0
vm.nr_hugepages = 0

Hi anh,

Thông tin anh cần như như sau:

Code:

# sysctl -a | grep shmmax
kernel.shmmax = 4294967295
# sysctl -a | grep huge
vm.hugetlb_shm_group = 0
vm.nr_hugepages = 0

@mrro: Thanks, tớ đang đọc và tìm hiểu thêm về "không phải cứ hàng khủng là tốt", hy vọng sẽ cho kêt quả sớm. 

#!/bin/bash
# Check for the kernel version
KERN=`uname -r | awk -F. '{ printf("%d.%d\n",$1,$2); }'`

# Find out the HugePage size
HPG_SZ=`grep Hugepagesize /proc/meminfo | awk {'print $2'}`

# Start from 1 pages to be on the safe side and guarantee 1 free HugePage
NUM_PG=1

# Cumulative number of pages required to handle the running shared memory segments
for SEG_BYTES in `ipcs -m | awk {'print $5'} | grep "[0-9][0-9]*"`
do
MIN_PG=`echo "$SEG_BYTES/($HPG_SZ*1024)" | bc -q`
if [ $MIN_PG -gt 0 ]; then
NUM_PG=`echo "$NUM_PG+$MIN_PG+1" | bc -q`
fi
done

# Finish with results
case $KERN in
'2.4') HUGETLB_POOL=`echo "$NUM_PG*$HPG_SZ/1024" | bc -q`;
echo "Recommended setting: vm.hugetlb_pool = $HUGETLB_POOL" ;;
'2.6') echo "Recommended setting: vm.nr_hugepages = $NUM_PG" ;;
*) echo "Unrecognized kernel version $KERN. Exiting." ;;
esac

# End

Sau đó, chmod +x setPage.sh

Rồi chạy: ./setPage.sh

Sau đó gởi info lên đây. 

./setPage.sh
Recommended setting: vm.nr_hugepages = 1

# hugepages
vm.nr_hugepages = 1

conmale wrote:

Sau đó, chmod +x setPage.sh

Rồi chạy: ./setPage.sh

Sau đó gởi info lên đây. 

Hi anh,

Em đọc bài của mrro và cũng thử chạy đoạn script(như csript anh hướng dẫn trên). Cho kết quả:

Code:

./setPage.sh
Recommended setting: vm.nr_hugepages = 1

Em mở /etc/sysctl.conf

Thêm vào dòng:
Code:

# hugepages
vm.nr_hugepages = 1

Em đang theo dõi thêm xem thế nào. 

azteam wrote:

conmale wrote:

Sau đó, chmod +x setPage.sh

Rồi chạy: ./setPage.sh

Sau đó gởi info lên đây. 

Hi anh,

Em đọc bài của mrro và cũng thử chạy đoạn script(như csript anh hướng dẫn trên). Cho kết quả:

Code:

./setPage.sh
Recommended setting: vm.nr_hugepages = 1

Em mở /etc/sysctl.conf

Thêm vào dòng:
Code:

# hugepages
vm.nr_hugepages = 1

Em đang theo dõi thêm xem thế nào. 

Thêm dòng ấy vào sysctl.conf mà không làm gì khác thì chẳng có tác dụng gì đâu.

Em có thể load nó thẳng vào kernel bằng cách:
echo 1 > /proc/sys/vm/nr_hugepages

hoặc chạy:
sysctl -p

Để system load cái sysctl.conf mới lên. 

# cat /proc/meminfo | grep Huge
HugePages_Total:     0
HugePages_Free:      0
HugePages_Rsvd:      0
Hugepagesize:     2048 kB

# cat /proc/meminfo | grep Huge
HugePages_Total:     1
HugePages_Free:      1
HugePages_Rsvd:      0
Hugepagesize:     2048 kB

azteam, em đang chạy kernel version mấy vậy? 

@azteam: mình thấy mình viết ở đây với trên blog rõ lắm rồi mà? nếu bạn đọc mà không thấy rõ ràng, thì mình cũng bó tay, mình không có thời gian và cũng không có động lực để ngồi giảng giải chi tiết cho bạn hiểu những gì mình viết.

giờ muốn rõ hơn thì phải ngồi coi server của bạn nó thế nào, rồi tính toán các thông số cho nó thích hợp, mà cái đó thì mình không có làm free.

về thắc mắc của bạn, trước đây chạy ổn vì bạn chưa có thêm RAM vào, mình thấy gần đây bạn mới thêm 4G RAM vào server này, phải hông? vả lại tùy thuộc vào loại ứng dụng đang chạy nữa, mà server mặc dù có cùng cấu hình thì cũng chưa chắc gì có biểu hiện giống nhau.


 

conmale wrote:

azteam, em đang chạy kernel version mấy vậy? 

Hi anh,

Version kernel của server: 2.6.18-128.1.6.el5PAE.

@mrro: Quả thật với trường hợp của mình cũng chưa thấy có gì rõ ràng. Nếu bạn có chút tư vấn nào để minh tìm hiểu thêm. Mình cũng có 4 server cùng cấu hinh như trên. Trước chạy rất ổn., thời gian gần đây mới bị vấn đề trên. Hơn nữa không phải server nào cũng bị.

Thanks,

 

azteam wrote:

conmale wrote:

azteam, em đang chạy kernel version mấy vậy? 

Hi anh,

Version kernel của server: 2.6.18-128.1.6.el5PAE.

@mrro: Quả thật với trường hợp của mình cũng chưa thấy có gì rõ ràng. Nếu bạn có chút tư vấn nào để minh tìm hiểu thêm. Mình cũng có 4 server cùng cấu hinh như trên. Trước chạy rất ổn., thời gian gần đây mới bị vấn đề trên. Hơn nữa không phải server nào cũng bị.

Thanks,

 

Em cho biết thêm dữ kiện cuối. Thử grep cái kernel config:

grep CONFIG_HIGHMEM /path/to/kernel/config

xem nó báo cái gì? 

# CONFIG_HIGHMEM4G is not set
CONFIG_HIGHMEM64G=y
CONFIG_HIGHMEM=y