Webserver reagiert teilw. für wenige Sekunden nicht

[freescale]

Hallo zusammen,

zuerst einmal ganz vorweg, ich habe mich gerade erst hier registriert, sollte ich also im falschen Bereich posten oder etwas wichtiges übersehen, bitte ich um Nachsicht.

So, nun aber zu meinem Problem...

Ich habe eine Community-Webseite mit ~11.000 Usern. Zur Rush-Hour abends sind rund 850 User gleichzeitig eingeloggt und aktiv, ansonsten meist rund 600 User. Die Webseite hat eine Mailfunktion (internes Nachrichtensystem), hierüber werden innerhalb von 10 min. zur Spitzenzeit ~2.500 Nachrichten verschickt. Am Tag haben wir knapp über eine Million Seitenabrufe. Die Seite ist komplett in PHP programmiert, als Datenbank wird MySQL verwendet.

Jetzt ist es so, dass sich seit einiger Zeit zur Abendzeit "einfach so" der Webserver mal für wenige Sekunden (zw. 2 bis 30 Sek.) aufhängt, in dieser Zeit geht gar nichts, ...danach läuft wieder alles normal.
Bei einer Seite in dieser Größe ist das nur leider nicht tragbar.

Hat jemand von euch eine Idee, woran das liegen kann, oder wie ich den Engpass herausfinde?
Eigentlich bin ich momentan nämlich noch der Auffassung, dass unsere zwei Server (Server 1 ist ein reiner Webserver, Server 2 nur Datenbank) vollkommen ausreichend sind.

Load-Werte des Webservers siehe Anhang 1,
Load-Werte des Datenbank-Servers siehe Anhang 2 (der Graph mit dem Peak um 4 Uhr)

Als Webserver verwenden wir den Lighttpd 1.4.18, mit aktiviertem XCache, und PHP5.
Der Datenbank-Server läuft unter MySQL 4.3.11.
Das Betriebssystem ist auf beiden Servern Debian Etch Stable, mit gepatchtem (serveroptimiertem) Kernel.

Beide Server haben folgende identische Ausstattung:

cpuinfo:

adriana:~# cat /proc/cpuinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 107
model name      : AMD Athlon(tm) 64 X2 Dual Core Processor 5000+
stepping        : 2
cpu MHz         : 2611.859
cache size      : 512 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 2
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy misalignsse ts fid vid ttp tm stc 100mhzsteps
bogomips        : 5228.69
clflush size    : 64
 
processor       : 1
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 107
model name      : AMD Athlon(tm) 64 X2 Dual Core Processor 5000+
stepping        : 2
cpu MHz         : 2611.859
cache size      : 512 KB
physical id     : 0
siblings        : 2
core id         : 1
cpu cores       : 2
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy misalignsse ts fid vid ttp tm stc 100mhzsteps
bogomips        : 5223.79
clflush size    : 64
 
adriana:~#

meminfo:

adriana:~# cat /proc/meminfo
MemTotal:      4116780 kB
MemFree:        171356 kB
Buffers:        317856 kB
Cached:        3041256 kB
SwapCached:          0 kB
Active:         499056 kB
Inactive:      3059760 kB
HighTotal:     3243968 kB
HighFree:        34340 kB
LowTotal:       872812 kB
LowFree:        137016 kB
SwapTotal:     8393848 kB
SwapFree:      8393816 kB
Dirty:            2584 kB
Writeback:           0 kB
AnonPages:      197700 kB
Mapped:          52032 kB
Slab:           358576 kB
SReclaimable:   277728 kB
SUnreclaim:      80848 kB
PageTables:       5228 kB
NFS_Unstable:        0 kB
Bounce:            400 kB
CommitLimit:  10452236 kB
Committed_AS:  1006864 kB
VmallocTotal:   118776 kB
VmallocUsed:     10164 kB
VmallocChunk:   108464 kB

top: (zu diesem Zeitpunkt sind rund 830 User aktiv gewesen)

top - 20:37:39 up 49 days,  3:24,  1 user,  load average: 0.94, 1.01, 0.98
Tasks: 138 total,   3 running, 135 sleeping,   0 stopped,   0 zombie
Cpu(s): 12.0%us,  2.7%sy,  0.0%ni, 83.5%id,  1.0%wa,  0.2%hi,  0.6%si,  0.0%st
Mem:   4116780k total,  3949840k used,   166940k free,   317904k buffers
Swap:  8393848k total,       32k used,  8393816k free,  3043188k cached
 
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
32469 www-data  20   0  160m  19m 8784 S   24  0.5   0:29.06 php5-cgi
14490 www-data  20   0 29092  25m  820 R   20  0.6  89:18.50 lighttpd
26918 www-data  20   0  154m  13m 8984 R   16  0.3   1:17.61 php5-cgi
31974 www-data  20   0  154m  14m 9172 S    6  0.4   0:57.75 php5-cgi
26613 www-data  20   0  154m  16m  11m S    4  0.4   1:09.07 php5-cgi
31865 www-data  20   0  151m  11m 9064 S    4  0.3   0:43.57 php5-cgi
31977 www-data  20   0  152m  12m 8972 S    4  0.3   0:58.48 php5-cgi
32452 www-data  20   0  152m  11m 8032 S    4  0.3   0:27.78 php5-cgi
32454 www-data  20   0  152m  12m 9068 S    4  0.3   0:29.88 php5-cgi
32465 www-data  20   0  152m  11m 7756 S    4  0.3   0:26.42 php5-cgi
32468 www-data  20   0  152m  13m  10m S    4  0.3   0:28.80 php5-cgi
14498 www-data  20   0  154m  15m 9884 S    2  0.4   1:30.73 php5-cgi
26636 www-data  20   0  152m  14m  11m S    2  0.4   1:11.67 php5-cgi
26661 www-data  20   0  154m  14m 9452 S    2  0.4   1:08.47 php5-cgi
31820 www-data  20   0  152m  11m 8896 S    2  0.3   0:45.35 php5-cgi
31821 www-data  20   0  152m  12m 8884 S    2  0.3   0:45.90 php5-cgi
31959 www-data  20   0  153m  15m  10m S    2  0.4   1:02.09 php5-cgi
31960 www-data  20   0  153m  15m  11m S    2  0.4   0:56.94 php5-cgi
31963 www-data  20   0  153m  15m  10m S    2  0.4   0:56.18 php5-cgi
31976 www-data  20   0  152m  12m 9356 S    2  0.3   0:54.21 php5-cgi
    1 root      20   0  2076  616  528 S    0  0.0   0:18.94 init
    2 root      15  -5     0    0    0 S    0  0.0   0:00.00 kthreadd
    3 root      RT  -5     0    0    0 S    0  0.0   0:00.32 migration/0
    4 root      15  -5     0    0    0 S    0  0.0   0:00.94 ksoftirqd/0
    5 root      RT  -5     0    0    0 S    0  0.0   0:01.70 watchdog/0
    6 root      RT  -5     0    0    0 S    0  0.0   0:00.30 migration/1
    7 root      15  -5     0    0    0 S    0  0.0   0:01.94 ksoftirqd/1
    8 root      RT  -5     0    0    0 S    0  0.0   0:01.82 watchdog/1
    9 root      15  -5     0    0    0 S    0  0.0   3:06.79 events/0
   10 root      15  -5     0    0    0 S    0  0.0   2:02.12 events/1
   11 root      15  -5     0    0    0 S    0  0.0   0:00.02 khelper
   84 root      15  -5     0    0    0 S    0  0.0   0:02.10 kblockd/0
   85 root      15  -5     0    0    0 S    0  0.0   0:02.04 kblockd/1
   87 root      15  -5     0    0    0 S    0  0.0   0:00.00 kacpid
   88 root      15  -5     0    0    0 S    0  0.0   0:00.00 kacpi_notify
  215 root      15  -5     0    0    0 S    0  0.0   0:00.00 ata/0
  216 root      15  -5     0    0    0 S    0  0.0   0:00.00 ata/1
  217 root      15  -5     0    0    0 S    0  0.0   0:00.00 ata_aux
  218 root      15  -5     0    0    0 S    0  0.0   0:00.00 ksuspend_usbd
  223 root      15  -5     0    0    0 S    0  0.0   0:00.00 khubd

stat:

adriana:~# cat /proc/stat
cpu  102332610 45412 22851591 709458560 8316104 1516224 4708749 0
cpu0 51209037 20341 11309583 354826375 4158007 732959 2358333 0
cpu1 51123573 25071 11542008 354632185 4158097 783264 2350415 0
intr 8007573267
ctxt 4917731614
btime 1196784787
processes 1134403
procs_running 3
procs_blocked 2

(weiteres fällt mir auf Anhieb nicht mehr ein...)

Beste Grüße,
freescale

 

[der_harry]

Ich habe keine schlüssige Erklärung wieso dieser Effekt plötzlich auftritt ohne, dass sich etwas an den Parametern geändert hätte.

Allerdings ist mir grundsätzliches aufgefallen, was ich anders mache.

Du hast php-cgi konfiguriert. Das verstehe ich nicht auf einem Soloserver.

Ich verwende in so einem Falle einen selbst kompilierten Apachen 1.3 mit statischem mod_PHP5 und apc als Extention. Diese Konfiguration ist bisher nicht im geringsten ausgelastet. Der Server transportiert ca. 6,9GB/Tag und verarbeitet dabei ca. 400T Pages/Tag. Und der ist bei weitem nicht so groß wie Dein Webserver. Es ist ein DS3000 bei Hetzner.

Vielleicht hast Du Lust diese Konfiguration einmal auszuprobieren. Das geht ja recht komfortabel nebenbei auf der Kiste.

 

[daseddy]

Steht zu der beschriebene Zeit was im syslog oder im (Error-)Logfile des Lighttpd?

 

[freescale]

Hallo,

Ich habe keine schlüssige Erklärung wieso dieser Effekt plötzlich auftritt ohne, dass sich etwas an den Parametern geändert hätte.

nun ja, am System geändert hat sich nichts, aber die Nutzerzahlen wachsen täglich...

Du hast php-cgi konfiguriert. Das verstehe ich nicht auf einem Soloserver.

Ich verwende in so einem Falle einen selbst kompilierten Apachen 1.3 mit statischem mod_PHP5 und apc als Extention.

Soweit ich es bisher gesehen habe, ist das bei Lighttpd leider nicht anders möglich. Das PHP5 ist über die FastCGI-Schnittstelle angebunden.

Apache hat sich bei uns leider schon vor etwa einem halben Jahr disqualifiziert, Lighttpd benötigt hier bedeutend weniger Ressourcen.

Der Server transportiert ca. 6,9GB/Tag und verarbeitet dabei ca. 400T Pages/Tag.

Wir haben einen eingehenden Traffic von 10-15GB/Tag und ausgehend 60-65GB/Tag.
(Dies liegt hauptsächlich an den Profilbildern und Fotogalerien der User)

Vielleicht hast Du Lust diese Konfiguration einmal auszuprobieren. Das geht ja recht komfortabel nebenbei auf der Kiste.

Nagut, das müsste ich dann in einer VM probieren, der Live-Server ist heilig...

Steht zu der beschriebene Zeit was im syslog oder im (Error-)Logfile des Lighttpd?

Ja,

2008-01-23 21:20:52: (server.c.1360) [note] sockets disabled, out-of-fds
2008-01-23 21:21:02: (server.c.1312) [note] sockets enabled again

Das Problem hatten wir vor einigen Monaten schon mal, damals half es die Datenbank komplett auszulagern und auf den Lighttpd umzusteigen.

lighttpd.conf:

server.modules                 = ("mod_expire", "mod_access", "mod_auth", "mod_extforward", "mod_redirect", "mod_fastcgi")
server.bind                    = [entfernt]
server.port                    = 80
server.document-root           = "/var/www/"
server.errorlog                = "/var/log/lighttpd/error.log"
server.name                    = [entfernt]
server.tag                     = [entfernt]
index-file.names               = ( "index.php", "index.html" )
url.access-deny                = ( ".inc", ".inc.php", ".conf", ".ini" )
server.pid-file                = "/var/run/lighttpd.pid"
dir-listing.encoding           = "utf-8"
server.dir-listing             = "disable"
server.username                = "www-data"
server.groupname               = "www-data"
server.max-keep-alive-requests = 4
server.max-keep-alive-idle     = 4

$HTTP["host"] !~ "^(www|static|banner|mail|systemmail)\.([entfernt])$" {
  $HTTP["host"] =~ "^([a-zA-Z0-9_-]{3,15})\.([entfernt])$" {
    url.redirect = (
      "^/(.*)" => "http://www.%2/?profil=%1"
    )
  }
}

$HTTP["url"] =~ ".*\.(jpg|jpeg|gif|png|css|js|htc)$" {
  expire.url = ( "" => "access 14 days" )
}

auth.backend = "htpasswd"
auth.backend.htpasswd.userfile = [entfernt]
auth.require = (
    "/[entfernt]" =>
    (
      "method"  => "basic",
      "realm"   => "Interner Bereich",
      "require" => "valid-user"
    )
  )

[entfernt, mimetypes]

fastcgi.server = ( ".php" =>
  ((
    "bin-path" => "/usr/bin/php5-cgi",
    "socket" => "/tmp/php.socket",
    "max-procs" => 5,
    "idle-timeout" => 20,
    "bin-environment" => (
      "PHP_FCGI_CHILDREN" => "10",
      "PHP_FCGI_MAX_REQUESTS" => "10000"
    ),
    "bin-copy-environment" => (
      "PATH", "SHELL", "USER"
    ),
    "broken-scriptfilename" => "enable"
  ))
)

Ich habe jetzt mal die max-fds und max-connections höher gesetzt, wie in server.max-fdsDetails - lighttpd - secure, fast, compliant, and very flexible web-server - Trac beschrieben, mal sehen ob dies etwas bringt.

Grüße,
freescale

 

[]MaX[]

Vielleicht solltest du mal die

"PHP_FCGI_MAX_REQUESTS" => "10000"

etwas runtersetzten ich halte 10000 für etwas viel, ich habe meine so zwischen 300 und 500 je nach Auslastung.

Desweiteren könntest du dir das hier mal durchlesen.

Docserformance - lighttpd - secure, fast, compliant, and very flexible web-server - Trac

Die Seite beschäftigt sich mit der Performance, dort steht auch das von dir geschriebene server.max-fds

Ansonsten kann ich dir diese Seite noch empfehlen.
Linux / UNIX - lighttpd related howtos, tutorials, and tips

 

[blob]

Bei solch einem intensiven Gebrauch könnte es helfen, den Kernel auf beste multithread -Funktion zu trimmen, und slub statt slab zu verwenden zumal die anfänglichen Probleme inzwischen beseitigt sind. Denn wenn plötzlich viel Arbeit für die Verwaltung der threads oder des Speichers anfällt, kann es zu solchen Aussetzern kommen, auch wenn bei dir scheinbar nicht bzw nicht nennenswert geswapt wird. Wenn dasselbe Problem zuvor schon bei httpd und jetzt auch bei lighttpd auftritt, liegt es wohl nicht an Server und dessen Konfiguration Guck ob du bei deiner Distro einen Kernel findest wo in /boot/.config [-<Version-Nr>] steht: CONFIG_SLUB=y

 

[]MaX[]

War ja klar das sowas wieder von dir kommen muß.

 

[blob]

?? Es war ja gerade eines der Probleme von slab daß bei vielen threads das System oft so mit der Verwaltung beschäftigt war daß es gestockt hat, und nach anfänglichen Problemen die im kerneltrap-Forum diskutiert wurden, läuft das inzwischen sehr gut.

 

[freescale]

Hmm,
weder "slub" noch "slab" sind mir in irgendeiner Form geläufig, daher kann ich dazu nicht im geringstem etwas sagen.

Dafür habe ich jetzt aber gestern Nacht noch einmal die Server-Konfiguration weiter angepasst, und folgende Parameter geändert:

server.max-keep-alive-requests = 4
server.max-keep-alive-idle     = 4
server.max-fds                 = 5120
server.max-connections         = 2048
server.event-handler           = "linux-sysepoll"
server.network-backend         = "linux-sendfile"
server.stat-cache-engine       = "simple"

Bisher läuft es - mit einer Ausnahme - ganz gut, und der Webserver hat load-Werte wie schon lange nicht mehr... obwohl momentan schon 650 User online sind.

Nur gegen 15 Uhr war der Server plötzlich für 4 Minuten mal weg, in den Logs steht dann folgendes:

2008-01-24 15:02:07: (mod_fastcgi.c.2855) backend is overloaded; we'll disable it for 2 seconds and send the request to another backend instead: reconnects: 4 load: 696
2008-01-24 15:02:08: (mod_fastcgi.c.3496) all handlers for  /index.php on .php are down.
2008-01-24 15:02:10: (mod_fastcgi.c.2633) fcgi-server re-enabled:  0 /tmp/php.socket

Woran kann das liegen? Weil momentan ist die Last weitaus höher als um 15 Uhr.

Beste Grüße,
freescale

 

[traced]

Google brachte mich z.B. hier hin: #575 (high-time connections in handle-req impact fastcgi overload calculation) - lighttpd - secure, fast, compliant, and very flexible web-server - Trac und lighttpd forum - 500 internal error

bzw. vielleicht eine Lösung

after some googling
changing
"socket" => "/tmp/php.socket",
into
"socket" => "/tmp/php.socket" + var.PID,
ended my suffering
I dont know if the ulimit helped too!
ssh 'ulimit -c unlimited - www'

As a reference to other people who may still have the same issue, here's
a conf that seems to work fine :
fastcgi.server = ( ".php" =>
((
"bin-path" => "/usr/bin/php5-cgi",
"socket" => "/tmp/php.socket" + var.PID,
"max-procs" => 2,
"idle-timeout" => 20,
"bin-environment" => (
"PHP_FCGI_CHILDREN" => "60",
"PHP_FCGI_MAX_REQUESTS" => "70000"
),
"bin-copy-environment" => (
"PATH", "SHELL", "USER"
),
"broken-scriptfilename" => "enable"
))
)

note the "max-procs" => 2 despite xcache been installed (the doc says to
use "max-procs" => 1)

Vielleicht ein Ansatz.

lg
Basti