Apache stottert

[jabba]

Hallo

Ich habe merkwürdiges Problem: Der Apache reagiert manchmal nicht. Anfragen werden nicht beantwortet. Bei einem minütlichen Monitoring passiert das mehrmals je Stunde. Sekunden später ist alles wieder OK.
Das Monitoring meldet jedoch nur Fehler für hhtp-Anfragen. Alles andere ist erreichbar (IMAP, POP3, FTP etc.). Ein lokales Monitoring auf der Maschine zeigt keinen Ausfall an! Ebenso läuft ein Monitorung über eine andere Maschine aus dem Rack über eine lokale IP auf die zweite NIC. Auch hier derselbe Fehler: Nur Apache hat Aussetzer.
Die Http-Fehler werden durch direkten Aufruf der Seiten ermittelt. PHP-Seite als auch reine HTML-Seiten reagieren gleichermaßen.

Server:
2 x Dual XEON 4cores
4 GB Ram
Debian ETCH

Gesamte Software direkt aus Debian installiert:
Apache 2.2 (prefork)
PHP (Web-Scripte werden über suPHP asugeführt)
MySQL 5
etc.

Apache:

Code: Select all

Timeout 150
KeepAlive Off
MaxKeepAliveRequests 100
KeepAliveTimeout 15
<IfModule mpm_prefork_module>
    StartServers          5
    MinSpareServers      20
    MaxSpareServers      30
    MaxClients          250
    MaxRequestsPerChild   10000
</IfModule>

Die Maschine ist auch nicht überlastet:
top:

Code: Select all

top - 22:55:33 up 2 days,  6:59,  2 users,  load average: 0.24, 0.41, 0.65
Tasks: 183 total,   1 running, 181 sleeping,   0 stopped,   1 zombie
Cpu(s):  2.7%us,  0.7%sy,  0.0%ni, 96.3%id,  0.2%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   4150528k total,  3839628k used,   310900k free,   235172k buffers
Swap:  3903752k total,       64k used,  3903688k free,  2826632k cached

Die prefork-Paramter wurden schon mehrmals verändert, aber Besserung hat das nicht gebracht. Die Apache/MySQL-Konfig ist auch identisch mit anderen Maschinen und bislang gab es keinerlei solcher Probleme. Langsam weiss ich nicht mehr weiter.

[Joe User]

Irgendwelche Cronjobs die den Apache regelmässig reloaden/restarten? Logs?

[jabba]

Nein, Apache wird nicht regelmäßig reloaded oder neu gestartet.
Das error-Log des Apachen zeigt nichts passendes an - es kommt auch nichts an, wenn er gerade nicht erreichbar ist.
Welche Logs brauchst Du ggf?
Das Kernel-Log bringt einige Meldungen dieser Art:

Code: Select all

... kernel: TCP: Treason uncloaked! Peer 84.145.247.212:54064/80 shrinks window 1747121750:1747137722. Repaired.

Das gibt es aber auch auf anderen Maschinen und macht dort keine Probleme.

Das lokale Monitoring zeigt an, das der Apache läuft, aber er ist temporär nicht von außen erreichbar.
Als ob etwas die Erreichbarkeit des Port 80 und Port 443 stört. IpTables sieht aber normal aus und der Kernel hat bislang auch keine Macken gezeigt. Allerdings ist die Maschine recht neu und läuft erst wenige Wochen, so das keine Langzeiterfahrung mit dem Kernel (2.6.22.6) gemacht sind. Wir überlegen schon den gerade aktellen Kernel zu kompilieren.
Der einzigste Unterschied der Maschine zu anderen ist der Kernel (und natürlich die Web die drauf laufen).

[aubergine]

Stelle StartServers mal hoch auf 8 oder 10 und schaue was passiert.

[jabba]

Das legt doch lediglich fest wie viele Child-Prozesse _erstmalig_ beim Start des Apachen gestartet werden. Für das weitere Leben das Apachen hat das meines Wissen keine Bedeutung mehr. Aber gut, greife mittlerweile nach Strohhalmen und habe den Parameter mal auf 10 gestellt.

[Joe User]

lspci? Apaches Loglevel testweise auf debug gesetzt? Vollständige Systemupdates werden regelmässig gemacht? Ist die Anbindung des Servers stabil? suPHP mal durch FastCGi ersetzt?

[jabba]

lspci

Code: Select all

00:00.0 Host bridge: Intel Corporation 5000P Chipset Memory Controller Hub (rev b1)
00:02.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x8 Port 2-3 (rev b1)
00:04.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x8 Port 4-5 (rev b1)
00:06.0 PCI bridge: Intel Corporation 5000 Series Chipset PCI Express x8 Port 6-7 (rev b1)
00:08.0 System peripheral: Intel Corporation 5000 Series Chipset DMA Engine (rev b1)
00:10.0 Host bridge: Intel Corporation 5000 Series Chipset Error Reporting Registers (rev b1)
00:10.1 Host bridge: Intel Corporation 5000 Series Chipset Error Reporting Registers (rev b1)
00:10.2 Host bridge: Intel Corporation 5000 Series Chipset Error Reporting Registers (rev b1)
00:11.0 Host bridge: Intel Corporation 5000 Series Chipset Reserved Registers (rev b1)
00:13.0 Host bridge: Intel Corporation 5000 Series Chipset Reserved Registers (rev b1)
00:15.0 Host bridge: Intel Corporation 5000 Series Chipset FBD Registers (rev b1)
00:16.0 Host bridge: Intel Corporation 5000 Series Chipset FBD Registers (rev b1)
00:1c.0 PCI bridge: Intel Corporation 631xESB/632xESB/3100 Chipset PCI Express Root Port 1 (rev 09)
00:1d.0 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #1 (rev 09)
00:1d.1 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #2 (rev 09)
00:1d.2 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #3 (rev 09)
00:1d.7 USB Controller: Intel Corporation 631xESB/632xESB/3100 Chipset EHCI USB2 Controller (rev 09)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d9)
00:1f.0 ISA bridge: Intel Corporation 631xESB/632xESB/3100 Chipset LPC Interface Controller (rev 09)
00:1f.1 IDE interface: Intel Corporation 631xESB/632xESB IDE Controller (rev 09)
00:1f.3 SMBus: Intel Corporation 631xESB/632xESB/3100 Chipset SMBus Controller (rev 09)
01:00.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Upstream Port (rev 01)
01:00.3 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express to PCI-X Bridge (rev 01)
02:00.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Downstream Port E1 (rev 01)
02:02.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Downstream Port E3 (rev 01)
03:00.0 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI Bridge A (rev 09)
03:00.2 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI Bridge B (rev 09)
06:00.0 Ethernet controller: Intel Corporation 631xESB/632xESB DPT LAN Controller Copper (rev 01)
06:00.1 Ethernet controller: Intel Corporation 631xESB/632xESB DPT LAN Controller Copper (rev 01)
08:00.0 RAID bus controller: 3ware Inc Unknown device 1004 (rev 01)
0b:01.0 VGA compatible controller: ATI Technologies Inc ES1000 (rev 02)

Logs auf Debug: Werde ich mal checken

Systemupdatedes: werden regelmäßig gemacht.

Anbindung: Ja stabil.
Alles andere funktioniert einwandfrei. Währen dder Apache gerade mal "weg" ist kann ich problemlos via FTP Downloaden etc.

Fast/CGI: Nein, habe ich nicht getestet, ist auch nicht "mal eben" in einem Produktivsystem machbar.

[jabba]

Nachtrag:
Man kann eine gewisse Lastabhängigkeit beobachten: Je mehr Last, desto häufiger ist der Apache weg.
Das kann aber auch Zufall sein.

[djcrackman]

Wie sieht der server-status aus?

[jan10001]

Gibt es irgendwelche Scripte die MySQL Abfragen machen?

[jabba]

Server-Status: Kann augenblicklich nicht angezeigt werden (Err 403). Muss ich mir später mal ansehen.

MySQL-Zugriffe: Ja gibt es jede Menge. Hier gibt es aber keine bekannten Engpässe auf der Maschine. Falls die MySQL-Verbindungen nicht zustande kämen, würden aber die Apache-Zugriffe dennoch geloggt werden. Werden Sie aber nicht! Das Problem tritt also schon früher auf. Apache wird gar nicht erreicht.

Wir tippen aktuell auf folgendes:
http://www.heise.de/security/Daemme-geg ... el/43066/1

/proc/sys/net/ipv4/tcp_max_syn_backlog steht bereits auf 1024

/proc/sys/net/ipv4/tcp_syncookies steht allerdings auf 0
Wir überlegen hier die Syncookies zu aktivieren mit:
# echo 1 > /proc/sys/net/ipv4/tcp_syncookies

Kernel wurde damals übersetzt mit dieser Option: CONFIG_SYN_COOKIES=y
Somit sollten Syncookies also auch funktionieren.

Frage: Wirkt das sofort oder muss man neu booten? Im ersten Fall: Überlegt die Einstellung einen reboot?

[jabba]

Hiermit konnte nun mehr Stabilität in das System gebracht werden.

Code: Select all

echo 1 > /proc/sys/net/ipv4/tcp_syncookies
echo 3 > /proc/sys/net/ipv4/tcp_synack_retries
echo 2048 > /proc/sys/net/ipv4/tcp_max_syn_backlog

Es ist in der Tat wohl so gewesen, das die Anzahl der Verbindungen nicht mehr gehandelt werden konnte.
Jetzt müssen wir weiter beoachten, aber bislang keine Ausfälle mehr. Diverse SYN-Floods konnten nun locker weggesteckt werden.