Pourquoi mon serveur gèle-t-il tous les jours en même temps?
Mon serveur se bloque tous les jours à 00h50. Je ne sais pas ce que ça peut être. Dans les fichiers journaux, j'ai trouvé une telle liste de suspects, mais je ne sais pas ce que cela signifie. Quelqu'un pourrait-il m'aider?
kernel: php5-cgi invoked oom-killer: gfp_mask=0x84d0, order=0, oom_adj=0, oom_score_adj=0
kernel: php5-cgi cpuset=/ mems_allowed=0
kernel: Pid: 20316, comm: php5-cgi Not tainted 2.6.38.2-xxxx-std-ipv6-64 #2
kernel: Call Trace:
kernel: [<ffffffff810de9e8>] ? dump_header+0x88/0x1d0
kernel: [<ffffffff810aa6e3>] ? ktime_get_ts+0xb3/0xe0
kernel: [<ffffffff810de931>] ? oom_unkillable_task+0x91/0xc0
kernel: [<ffffffff8150c7e5>] ? ___ratelimit+0xa5/0x120
kernel: [<ffffffff810def0c>] ? oom_kill_process+0x8c/0x2e0
kernel: [<ffffffff810dedd3>] ? select_bad_process+0x93/0x140
kernel: [<ffffffff810df398>] ? out_of_memory+0x238/0x3e0
kernel: [<ffffffff810e45bd>] ? __alloc_pages_nodemask+0x86d/0x8a0
kernel: [<ffffffff8110ff4a>] ? alloc_pages_current+0xaa/0x120
kernel: [<ffffffff81069d46>] ? pte_alloc_one+0x16/0x40
kernel: [<ffffffff810fa159>] ? __pte_alloc+0x29/0xd0
kernel: [<ffffffff810fa363>] ? handle_mm_fault+0x163/0x200
kernel: [<ffffffff81066077>] ? do_page_fault+0x197/0x410
kernel: [<ffffffff81100556>] ? do_brk+0x286/0x390
kernel: [<ffffffff81a7419f>] ? page_fault+0x1f/0x30
kernel: Mem-Info:
kernel: Node 0 DMA per-cpu:
kernel: CPU 0: hi: 0, btch: 1 usd: 0
kernel: Node 0 DMA32 per-cpu:
kernel: CPU 0: hi: 186, btch: 31 usd: 156
kernel: active_anon:468626 inactive_anon:383 isolated_anon:0
kernel: active_file:66 inactive_file:101 isolated_file:64
kernel: unevictable:0 dirty:0 writeback:0 unstable:0
kernel: free:3426 slab_reclaimable:1691 slab_unreclaimable:13557
kernel: mapped:380 shmem:404 pagetables:10150 bounce:0
kernel: Node 0 DMA free:7932kB min:44kB low:52kB high:64kB active_anon:7056kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15684kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:388kB kernel_stack:16kB pagetables:488kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
kernel: lowmem_reserve[]: 0 1967 1967 1967
kernel: Node 0 DMA32 free:5772kB min:5648kB low:7060kB high:8472kB active_anon:1867448kB inactive_anon:1532kB active_file:264kB inactive_file:404kB unevictable:0kB isolated(anon):0kB isolated(file):256kB present:2014316kB mlocked:0kB dirty:0kB writeback:0kB mapped:1520kB shmem:1616kB slab_reclaimable:6764kB slab_unreclaimable:53840kB kernel_stack:1912kB pagetables:40112kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:1423 all_unreclaimable? no
kernel: lowmem_reserve[]: 0 0 0 0
kernel: Node 0 DMA: 45*4kB 56*8kB 29*16kB 8*32kB 7*64kB 4*128kB 2*256kB 0*512kB 1*1024kB 0*2048kB 1*4096kB = 7940kB
kernel: Node 0 DMA32: 149*4kB 1*8kB 1*16kB 1*32kB 0*64kB 0*128kB 0*256kB 0*512kB 1*1024kB 0*2048kB 1*4096kB = 5772kB
kernel: 646 total pagecache pages
kernel: 0 pages in swap cache
kernel: Swap cache stats: add 0, delete 0, find 0/0
kernel: Free swap = 0kB
kernel: Total swap = 0kB
kernel: 515824 pages RAM
kernel: 12393 pages reserved
kernel: 310091 pages shared
kernel: 436769 pages non-shared
kernel: [ pid ] uid tgid total_vm rss cpu oom_adj oom_score_adj name
kernel: [ 1562] 0 1562 4238 40 0 0 0 upstart-udev-br
kernel: [ 1564] 0 1564 4230 74 0 -17 -1000 udevd
kernel: [ 1656] 0 1656 4229 75 0 -17 -1000 udevd
kernel: [ 1661] 0 1661 4229 73 0 -17 -1000 udevd
kernel: [ 2620] 0 2620 12328 141 0 -17 -1000 sshd
kernel: [ 2631] 101 2631 13713 221 0 0 0 rsyslogd
kernel: [ 2648] 0 2648 1532 30 0 0 0 getty
kernel: [ 2652] 0 2652 1532 29 0 0 0 getty
kernel: [ 2655] 0 2655 1532 29 0 0 0 getty
kernel: [ 2656] 0 2656 1532 29 0 0 0 getty
kernel: [ 2659] 0 2659 1532 30 0 0 0 getty
kernel: [ 2666] 0 2666 5281 65 0 0 0 cron
kernel: [ 2701] 102 2701 32660 5339 0 0 0 named
kernel: [ 2708] 104 2708 63627 11103 0 0 0 mysqld
kernel: [ 2723] 0 2723 3482 38 0 0 0 couriertcpd
kernel: [ 2725] 0 2725 980 17 0 0 0 courierlogger
kernel: [ 2735] 0 2735 3482 38 0 0 0 couriertcpd
kernel: [ 2737] 0 2737 980 17 0 0 0 courierlogger
kernel: [ 2744] 0 2744 3482 41 0 0 0 couriertcpd
kernel: [ 2747] 0 2747 1013 26 0 0 0 courierlogger
kernel: [ 2754] 0 2754 3482 38 0 0 0 couriertcpd
kernel: [ 2757] 0 2757 980 18 0 0 0 courierlogger
kernel: [ 3313] 65534 3313 15729 79 0 0 0 memcached
kernel: [ 3383] 1002 3383 12937 1590 0 0 0 sw-cp-serverd
kernel: [ 3393] 0 3393 4894 58 0 0 0 xinetd
kernel: [ 3535] 2522 3535 1027 28 0 0 0 qmail-send
kernel: [ 3536] 2022 3536 1015 26 0 0 0 splogger
kernel: [ 3537] 0 3537 1025 33 0 0 0 qmail-lspawn
kernel: [ 3538] 2521 3538 1025 17 0 0 0 qmail-rspawn
kernel: [ 3539] 2520 3539 1014 22 0 0 0 qmail-clean
kernel: [ 3621] 0 3621 68797 3424 0 0 0 Apache2
kernel: [ 3622] 0 3622 40565 1745 0 0 0 Apache2
kernel: [ 3922] 106 3922 40087 38746 0 0 0 drwebd.real
kernel: [ 3985] 0 3985 3163 37 0 0 0 mdadm
kernel: [ 4024] 0 4024 1532 30 0 0 0 getty
kernel: [24625] 0 24625 28299 11913 0 0 0 spamd
kernel: [24626] 110 24626 28299 11912 0 0 0 spamd
kernel: [24628] 110 24628 28299 11912 0 0 0 spamd
kernel: [12008] 33 12008 68960 3226 0 0 0 Apache2
kernel: [12016] 33 12016 68946 3232 0 0 0 Apache2
kernel: [12568] 33 12568 68952 3229 0 0 0 Apache2
kernel: [13362] 33 13362 68933 3220 0 0 0 Apache2
kernel: [16894] 33 16894 68946 3204 0 0 0 Apache2
kernel: [16895] 33 16895 68902 3189 0 0 0 Apache2
kernel: [18991] 106 18991 40087 38745 0 0 0 drwebd.real
kernel: [18992] 106 18992 40087 38745 0 0 0 drwebd.real
kernel: [18993] 106 18993 40087 38745 0 0 0 drwebd.real
kernel: [18994] 106 18994 40087 38745 0 0 0 drwebd.real
kernel: [19165] 33 19165 68995 3216 0 0 0 Apache2
kernel: [19178] 33 19178 68947 3225 0 0 0 Apache2
kernel: [19918] 33 19918 68961 3218 0 0 0 Apache2
Si vous avez besoin de plus d'informations, écrivez-moi.
Domaneni
Une solution a été signalée ici: http://www.hskupin.info/2010/06/17/how-to-fix-the-oom-killer-crashe-under-linux/
Alors que s'est-il passé? La raison peut être expliquée brièvement: Le noyau Linux aime toujours allouer de la mémoire si les applications le demandent. Par défaut, il ne vérifie pas vraiment si la mémoire disponible est suffisante. Compte tenu de ce comportement, les applications peuvent allouer plus de mémoire dans la mesure des disponibilités. À un moment donné, cela peut définitivement provoquer une mémoire insuffisante. En conséquence, le tueur de MOO sera invoqué et tuera ce processus:
Jun 11 11:35:21 vsrv03 kernel: [378878.356858] php-cgi invoked oom-killer: gfp_mask=0x1280d2, order=0, oomkilladj=0 Jun 11 11:36:11 vsrv03 kernel: [378878.356880] Pid: 8490, comm: php-cgi Not tainted 2.6.26-2-xen-AMD64 #1L'inconvénient de cette action est que tous les autres processus en cours sont également affectés. En conséquence, la VM complète ne fonctionnait pas et nécessitait un redémarrage.
Pour résoudre ce problème , le comportement du noyau doit être modifié afin qu'il ne surcharge plus la mémoire pour les demandes d'application. Enfin, j'ai inclus ces valeurs mentionnées dans le fichier /etc/sysctl.conf afin qu'elles soient automatiquement appliquées au démarrage:
vm.overcommit_memory = 2 vm.overcommit_ratio = 80
(Redémarrez pour appliquer les modifications.)
En savoir plus sur le surcommit: http://www.win.tue.nl/~aeb/linux/lk/lk-9.html#ss9.6
Qu'est-ce qui se passe est simple, le pourquoi n'est pas (besoin de plus d'informations).
php5-cgi commence à utiliser BEAUCOUP de mémoire à ce moment-là (peut-être une fuite de mémoire ou un effet secondaire), au point que le système manquera de mémoire. Donc, le noyau le supprime (oom-killer est le tueur de mémoire insuffisante du noyau) pour maintenir la stabilité du système.
Cela ressemble à un VPS - est-ce? Quel genre? Les erreurs de MOO sont généralement rares sur les machines physiques disposant de suffisamment (1 Go +) RAM et d'espace de permutation (2x RAM au moins).