Apache Tuning - wir brauchen Hilfe

Starli · Mar 27, 2010

Hallo,

wir brauche ein wenig Hilfe im Thema Apache Tuning.
Ich habe hier nun schon einige Threads gefunden und habe diese auch ausprobiert.
Doch so wirklich will unser Apache nicht sauber laufen.
Es kommt immer wieder zu hohen Ladezeiten.

Stats von "mod_status"

Code:

Current Time: Saturday, 27-Mar-2010 18:54:30 CET
Restart Time: Saturday, 27-Mar-2010 15:06:27 CET
Parent Server Generation: 22
Server uptime: 3 hours 48 minutes 3 seconds
Total accesses: 689580 - Total Traffic: 7.3 GB
CPU Usage: u30.03 s13.64 cu0 cs0 - .319% CPU load
50.4 requests/sec - 0.5 MB/second - 11.1 kB/request
145 requests currently being processed, 53 idle workers

Apache Config:

Code:

<IfModule mpm_worker_module>
    StartServers          2
    MaxClients          400
    MinSpareThreads      25
    MaxSpareThreads      75 
    ThreadsPerChild      25
    MaxRequestsPerChild   0
</IfModule>

Timeout 15
KeepAlive On
KeepAliveTimeout 5
MaxKeepAliveRequests 10
HostnameLookups Off

Gehostet wird auf einen Intel i7 920 4x 2x 2.66+ GHz mit 8GB DDR3 Ram.
Wir würde uns über ein paar Tipps von euch freuen.
Danke

voodoo44 · Mar 27, 2010

MaxClients 400
Überprüf mal in den Logfiles, ob dein Apache sich beschwert, dass dieser Wert überschritten wird.

http://httpd.apache.org/docs/2.0/de/mod/mpm_common.html#MaxClients

Alternativ auch (wenn CPU-Leistung & Arbeitsspeicher vorrätig ist) die Anzahl paralleler Threads hochdrehen.
Darauf achten, dass auch der SQL-Server hier keine Verzögerungen verursacht.

Starli · Mar 28, 2010

Hey,

habe nochmal ein wenig rumgeschraubt.
Gebracht hat es nur bedingt was - wahrscheinlich lag es nur am Apache Restart.
Wenn ich das richtig verstanden hat zeigt mod_status ja die freien Slots als Punkte an...und da sehe ich mehr als genug Punkte.

Threads verdoppelt und Clients angepasst.

Code:

<IfModule mpm_worker_module>
    StartServers          2
    ServerLimit          50
    MaxClients          1250
    MinSpareThreads      50
    MaxSpareThreads      150 
    ThreadsPerChild      25
    MaxRequestsPerChild   0
</IfModule>

Was mich aber wunder sind die regelmäßigen "Einbrüche".
Da ich nicht wusste wie ich es beschreiben soll habe ich mal ein 30 Sekunden Video gemacht:
http://www.youtube.com/watch?v=ZOnX2zfuZjM

An dem laufenden bzip, ts3 oder srcds liegt es nicht.
Hatte schon einmal Testweise ausgemacht und ein paar Stunden beobachtet.

Das kommt regelmäßig vor das aufeinmal keine Last mehr da ist und nach ein paar Sekunden die ganzen requests "durchkommen".

]MaX[ · Mar 28, 2010

Such doch mal in deinen PHP-Einstellungen und bei MySQL rum, die gehen kurzzeitig auf 100% und scheinen ansonsten auch ganz beschäftigt, bei dem was man sehen kann.

Starli · Mar 28, 2010

Auf der Maschine liegen aktuell rund 1200 Freehosting Kunden.
Manche davon haben schon recht gut besuchte Seiten.

Deswegen bin ich davon ausgegangen das dies normal ist.
Wenn ich mich z.B. in ispCP einlogge geht ein SQL Prozess auch direkt auf 100% weil die ganzen Stats (angelegte SQL DB's, FTP Zugänge, Sub-, Domains, etc.) abgerufen werden.

SQL Config ist standard, nur MaxClients auf 1000 gesetzt.
PHP läuft als fcgi und ebenfalls standard.

traced · Mar 28, 2010

Wenn das so ein gut besuchter Server ist, dann schmeiss doch bitte den Gameserver da runter

Grüsse
Basti

voodoo44 · Mar 28, 2010

Den MySQL solltest du dann mal versuchen via Tuning-Primer-Script zu optimieren:

MySQL Performance Tuning mit Tuning-Primer.sh Script

MySQL Performance Tuning mit Tuning-Primer.sh Script Quelle Das Script ist von den MySQL Programmieren. Es analysiert und macht Verbesserungsvorschläge. Anleitung: (Installation) #per SSH mit root einloggen, dann mit cd /usr cd bin #in das /usr/bin Verzeichnis wechseln. Nun kopieren wir...

serversupportforum.de

Und wie schon erwähnt wurde: Schau mal, dass du den Gameserver deaktivierst

Huschi · Mar 28, 2010

@Starli:
Nur mal so ganz blöd gefragt: Bist Du Dir sicher, dass Du den Apache als Worker drauf hast?
htop ist von seiner Anzeigen her auch nicht immer geeignet. Nutz mal top und poste den Inhalt davon hier in CODE-Tags.

Was aber erkennbar ist: Dein Swap wird unnötiger Weise genutzt. Sowas bremst eine Maschine grundsätzlich aus und ist ein Zeichen dafür, dass Du zuviel Speicher verbrätst.

Abgesehen davon ist bei 1200 Hosting-Kunden PHP als fcgi nicht wirklich die prickelnde Lösung.

huschi.

Starli · Mar 29, 2010

@Huschi:

Wegen Worker:
Apache2 hatte rumgezickt beim restart das die MaxClients automatisch runtergesetzt wurden da die Angabe zu hoch war im gegensatz zu der MaxServer angabe.

Wegen fcgi/fcgid:
Ich habe mich total vertan(gerade nochmal in den mods-enabled geschaut), habe natürlich fcgid laufen mit folgender Config:

Code:

<IfModule mod_fcgid.c>
  AddHandler fcgid-script .php .php5
  SocketPath /var/lib/apache2/fcgid/sock
  IdleTimeout 600
  IdleScanInterval 120
  BusyTimeout 300
  BusyScanInterval 120
  ErrorScanInterval 3
  ZombieScanInterval 3
  ProcessLifeTime 900
  SpawnScoreUpLimit 10
  SpawnScore 1
  TerminationScore 2
  MaxProcessCount 200
  DefaultMaxClassProcessCount 10
  DefaultMinClassProcessCount 1
  IPCConnectTimeout 900
  IPCCommTimeout 900
  MaxRequestsPerProcess 500
</IfModule>

Top auszug(ist aber gerade soweit ruhig - 03.00Uhr)

Code:

Tasks: 1725 total,   2 running, 1723 sleeping,   0 stopped,   0 zombie
Cpu(s):  9.8%us,  2.2%sy,  0.0%ni, 87.8%id,  0.0%wa,  0.0%hi,  0.2%si,  0.0%st
Mem:   8184808k total,  7680404k used,   504404k free,   249240k buffers
Swap: 16777640k total,  8460420k used,  8317220k free,  2167024k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 9904 mysql     40   0  410m 117m 4672 S   23  1.5 465:28.81 mysqld
18777 vu2117    40   0  197m  19m 3912 S   16  0.2   0:08.12 php5-cgi
18778 vu2117    40   0  200m  20m 4012 S   10  0.3   0:08.94 php5-cgi
18677 vu3202    40   0  195m  19m 3624 S    8  0.2   0:01.62 php5-cgi
12830 vu2272    40   0  187m  10m 3024 S    2  0.1   0:04.06 php5-cgi
14321 vu2628    40   0  195m  15m 4060 S    2  0.2   0:09.45 php5-cgi
 7453 www-data  40   0 1282m 124m 3172 S    1  1.6   0:35.05 apache2
 7635 www-data  40   0  583m 121m 3228 S    1  1.5   0:34.73 apache2
12831 vu2272    40   0  187m  10m 3020 S    1  0.1   0:04.18 php5-cgi
14323 vu2628    40   0  198m  18m 4096 S    1  0.2   0:10.04 php5-cgi
21581 root      40   0 20172 2540  936 R    1  0.0   0:00.18 top
 7325 www-data  40   0  963m 123m 3312 S    1  1.5   0:34.95 apache2
18472 vu2176    40   0  185m 8764 3312 S    1  0.1   0:01.93 php5-cgi
18676 vu3202    40   0  196m  20m 3628 S    1  0.3   0:01.60 php5-cgi
 7322 root      40   0 62356  15m 2516 S    0  0.2   0:08.21 ispcp-apache-lo
 7479 teamspea  40   0  254m  10m 3260 S    0  0.1 233:20.41 ts3server_linux
 7672 teamspea  39  19 97688 1384  872 S    0  0.0  17:09.39 server_linux
18473 vu2176    40   0  185m 8764 3312 S    0  0.1   0:01.94 php5-cgi
18535 vu2002    40   0  183m 7156 2872 S    0  0.1   0:00.09 php5-cgi
18537 vu2002    40   0  183m 7388 2884 S    0  0.1   0:00.10 php5-cgi
    1 root      40   0 10312  560  532 S    0  0.0   0:24.80 init
    2 root      40   0     0    0    0 S    0  0.0   0:00.00 kthreadd
    3 root      RT   0     0    0    0 S    0  0.0   0:00.85 migration/0
    4 root      20   0     0    0    0 S    0  0.0   3:18.33 ksoftirqd/0
    5 root      RT   0     0    0    0 S    0  0.0   0:00.95 migration/1
    6 root      20   0     0    0    0 S    0  0.0   0:36.76 ksoftirqd/1
    7 root      RT   0     0    0    0 S    0  0.0   0:01.13 migration/2
    8 root      20   0     0    0    0 S    0  0.0   2:03.63 ksoftirqd/2
    9 root      RT   0     0    0    0 S    0  0.0   0:01.05 migration/3
   10 root      20   0     0    0    0 S    0  0.0   1:41.82 ksoftirqd/3
   11 root      RT   0     0    0    0 S    0  0.0   0:02.49 migration/4
   12 root      20   0     0    0    0 S    0  0.0   1:40.92 ksoftirqd/4
   13 root      RT   0     0    0    0 S    0  0.0   0:02.91 migration/5
   14 root      20   0     0    0    0 S    0  0.0   1:21.62 ksoftirqd/5
   15 root      RT   0     0    0    0 S    0  0.0   0:03.07 migration/6
   16 root      20   0     0    0    0 S    0  0.0   0:28.60 ksoftirqd/6
   17 root      RT   0     0    0    0 S    0  0.0   0:03.35 migration/7
   18 root      20   0     0    0    0 S    0  0.0   0:05.81 ksoftirqd/7
   19 root      20   0     0    0    0 S    0  0.0   0:39.24 events/0
   20 root      20   0     0    0    0 S    0  0.0   1:28.13 events/1
   21 root      20   0     0    0    0 S    0  0.0   1:09.56 events/2
   22 root      20   0     0    0    0 S    0  0.0   0:39.58 events/3
   23 root      20   0     0    0    0 S    0  0.0   1:08.99 events/4
   24 root      20   0     0    0    0 S    0  0.0   1:11.76 events/5
   25 root      20   0     0    0    0 S    0  0.0   0:18.94 events/6
   26 root      20   0     0    0    0 S    0  0.0   0:07.80 events/7
   27 root      20   0     0    0    0 S    0  0.0   0:00.00 cpuset

@voodoo44
Werde ich nochmal anschmeißen wenn der SQL Server die 48 Stunden hinter sich hat.
Danke soweit.

-------------

Ich habe vor ca. 24 Stunden mal KeepAlive auf Off gesetzt wie in Huschis Anleitung beschrieben.
Seit dem konnte ich die besagten Einbrüche die in dem Video zu sehen sind nicht mehr sehen.
Werde das aber noch weiter beobachten.

Huschi · Mar 29, 2010

Starli said:
Wegen Worker:

War noch nicht mal ansatzweise die Antwort auf meine Frage!
PS: "MaxServer" gibt es nicht. Und er hätte beim MPM-Prefork die selbe Warnung ausgegeben.

Swap: 16777640k total, 8460420k used

8 GByte liegen im Swap und Du hast nur 8GB RAM?
Kein Wunder das sich eine hohe Load bildet.

PS: Du hast uns die erste Zeile von top unterschlagen.

huschi.

sebast · Apr 2, 2010

@Straly

Damit Huschi seine Frage beantwortet kriegt einmal das machen. Mein Server läuft z.B. als Prefork...
Aber Huschi sagte ja schon das er zuviel in Swap auslagert. Swap macht die Maschine langsam….

Code:

$ /usr/local/apache/bin/httpd -V
Server version: Apache/2.2.15 (Unix)
Server built:   Mar  9 2010 07:30:34
Server's Module Magic Number: 20051115:24
Server loaded:  APR 1.4.2, APR-Util 1.3.9
Compiled using: APR 1.4.2, APR-Util 1.3.9
Architecture:   32-bit
[B]Server MPM:     Prefork[/B]
  threaded:     no
    forked:     yes (variable process count)
Server compiled with....
 -D APACHE_MPM_DIR="server/mpm/prefork"
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
 -D APR_USE_FLOCK_SERIALIZE
 -D APR_USE_PTHREAD_SERIALIZE
 -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
 -D APR_HAS_OTHER_CHILD
 -D AP_HAVE_RELIABLE_PIPED_LOGS
 -D DYNAMIC_MODULE_LIMIT=128
 -D HTTPD_ROOT="/usr/local/apache"
 -D SUEXEC_BIN="/usr/local/apache/bin/suexec"
 -D DEFAULT_PIDLOG="logs/httpd.pid"
 -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
 -D DEFAULT_LOCKFILE="logs/accept.lock"
 -D DEFAULT_ERRORLOG="logs/error_log"
 -D AP_TYPES_CONFIG_FILE="conf/mime.types"
 -D SERVER_CONFIG_FILE="conf/httpd.conf"

Kann es ggf. sein das php dir den RAM weg frisst? PHP hat ja auch ein memory_limit was ggf. auf 64 - 128MB pro Prozess steht. Der Rest kann einfach ausgerechnet werden...

Starli · Apr 2, 2010

Hey,

sorry für die späte Antwort.
Habe das die ganze Woche beobachtet.

Also so wie ich das derzeit sehe war es PHP.
Die Config war auf gut deutsch beschissen.

Die Prozesse sind nach einer viel zu großen Zeit erst gestorben.
Vorher: ca. 2000-3000 Prozesse
Derzeit: ca. 400-600

Da hat sich wohl ganz schön was aufgestaut.
Schauen wie sich das die Tage weiter entwickelt.
Aber zumindist kann man derzeit sehen das es mal mehr mal weniger sind und die Zahl nicht permanent nach oben hin steigt.

Der SWAP wird derzeit nicht angerührt.
Der RAM verbrauch insgesammt bleibt bei maximal 3,5GB.

@Huschi: Ja, bzip ist rausgeflogen. Dachte es wäre nicht relevant, sorry.
@sebast: Da sagt er mir "Not Found"

Frohe Ostern & Danke!

Apache Tuning - wir brauchen Hilfe

Starli

New Member

voodoo44

Registered User

Starli

New Member

]MaX[

Member

Starli

New Member

traced

Registered User

voodoo44

Registered User

MySQL Performance Tuning mit Tuning-Primer.sh Script

Huschi

Moderator

Starli

New Member

Huschi

Moderator

sebast

Registered User

Starli

New Member

We value your privacy