Durch einen Serverabsturz bin ich heute auf eine etwas verwirrende Standardeinstellung im Apache gestoßen, die laut einigen Foren offenbar nur Debian Etch betrifft.
MaxRequestsPerChild 0
macht den Apache in einigen Situationen zu einem Speicherfresser. Das ganze geht soweit, das der Kernel keinen neuen Speicher mehr allociieren kann, kein Speicher mehr für andere Anwendungen zur Verfügung steht und das System damit lahmgelegt wird. Das ganze äußert sich zunächst dadurch das außer PING nichts mehr funktioniert. Ein Server reboot richtet dann wieder alles, allerdings ist es dann nur eine Frage der Zeit, bis das Problem erneut zuschlägt. Wer in seinem „syslog“ Meldungen finden, die wiefolgt aussehen:
kernel: Mem-info: kernel: Node 0 DMA per-cpu: kernel: cpu 0 hot: high 0, batch 1 used:0 kernel: cpu 0 cold: high 0, batch 1 used:0 kernel: Node 0 DMA32 per-cpu: kernel: cpu 0 hot: high 186, batch 31 used:179 kernel: cpu 0 cold: high 62, batch 15 used:49 kernel: Node 0 Normal per-cpu: empty kernel: Node 0 HighMem per-cpu: empty kernel: Free pages: 8012kB (0kB HighMem) kernel: Active:117054 inactive:113464 dirty:0 writeback:0 unstable:0 free:2003 slab:5445 mapped:1 pagetables:11467 kernel: Node 0 DMA free:3996kB min:24kB low:28kB high:36kB active:3980kB inactive:3840kB present:6556kB pages_scanned:9555 all_unreclaimable? yes kernel: lowmem_reserve[]: 0 993 993 993 kernel: Node 0 DMA32 free:4016kB min:4016kB low:5020kB high:6024kB active:464236kB inactive:450016kB present:1017008kB pages_scanned:1088596 all_unreclaimable? yes kernel: lowmem_reserve[]: 0 0 0 0 kernel: Node 0 Normal free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no kernel: lowmem_reserve[]: 0 0 0 0 kernel: Node 0 HighMem free:0kB min:128kB low:128kB high:128kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no kernel: lowmem_reserve[]: 0 0 0 0 kernel: Node 0 DMA: 1*4kB 1*8kB 1*16kB 0*32kB 0*64kB 1*128kB 1*256kB 1*512kB 1*1024kB 1*2048kB 0*4096kB = 3996kB Feb 24 15:19:42 catfish kernel: Node 0 DMA32: 2*4kB 15*8kB 9*16kB 5*32kB 10*64kB 1*128kB 1*256kB 1*512kB 0*1024kB 1*2048kB 0*4096kB = 4016kB kernel: Node 0 Normal: empty kernel: Node 0 HighMem: empty kernel: Swap cache: add 3754206, delete 3754206, find 550796/967590, race 100+121 kernel: Free swap = 0kB kernel: Total swap = 2104504kB kernel: Free swap: 0kB kernel: 261872 pages of RAM kernel: 5006 reserved pages kernel: 46543 pages shared kernel: 0 pages swap cached kernel: printk: 180 messages suppressed. kernel: oom-killer: gfp_mask=0x201d2, order=0 kernel: kernel: Call Trace: kernel: [<ffffffff802a666e>] out_of_memory+0x33/0x216 kernel: [<ffffffff8020e020>] __alloc_pages+0x220/0x2a9 kernel: [<ffffffff80210db1>] __do_page_cache_readahead+0x95/0x206 kernel: [<ffffffff8022683e>] sync_page+0x0/0x42 kernel: [<ffffffff8025cad3>] io_schedule+0x28/0x33 kernel: [<ffffffff8022683e>] sync_page+0x0/0x42 kernel: [<ffffffff8025cd6a>] __wait_on_bit_lock+0x5b/0x66 kernel: [<ffffffff8023d749>] __lock_page+0x5e/0x64 kernel: [<ffffffff802116ed>] filemap_nopage+0x148/0x314 kernel: [<ffffffff80208718>] __handle_mm_fault+0x375/0x91a kernel: [<ffffffff8020a69c>] do_page_fault+0x39d/0x706 kernel: [<ffffffff8025c35e>] thread_return+0x0/0xe7 kernel: [<ffffffff802588e5>] error_exit+0x0/0x84
der sollte mal in sein Apache Konfigurationsfile schauen und darüber nachdenken den besagten Wert z.B. wiefolgt abzuändern:
MaxRequestsPerChild 100
Damit wird verhindert, dass der Prozess Amok läuft, denn nach 100 Requests wird er einfach abgesetzt und ein neuer tritt an seine Stelle. Mal sehen, ob das jetzt auch hilft…