Apache automatisch Restarten bei Fehlern?

Der große Cache ist mir auch noch ein wenig ein Rätsel.

Zu dem deffekten Baustein, das ist eine gute Idee, ich habe ebereits an den Hoster geschrieben, damit er das mal überprüft.

Danke für eure Hilfe, solltet ihre noch mehr Ideen haben, dann sagt einfach escheid, ich bin dafür dankbar.

mfg
medic
 
Ich hatte eben erneut einen Lag am Server, hab dann den apache2 restartet und es lief alles wie wenn keine Last darauf liegen würde, aber unter top bleibt die selbe Ausgabe:

Code: 
Tasks:  88 total,   3 running,  84 sleeping,   0 stopped,   1 zombie
Cpu(s):  6.0% us,  2.0% sy,  0.0% ni, 88.4% id,  2.6% wa,  0.3% hi,  0.7% si
Mem:   3083260k total,  2916132k used,   167128k free,   170100k buffers
Swap:  2040232k total,    11504k used,  2028728k free,  2309540k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 6442 www-data  16   0 34712  18m 3788 R  7.0  0.6   0:03.09 apache2
  797 root      10  -5     0    0    0 S  0.3  0.0   2:06.42 md1_raid1
32720 mysql     15   0  124m  59m 4180 S  0.3  2.0  59:33.48 mysqld
    1 root      16   0  1588  504  448 S  0.0  0.0   0:01.69 init
    2 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 migration/0
    3 root      34  19     0    0    0 S  0.0  0.0   0:01.97 ksoftirqd/0
    4 root      RT   0     0    0    0 S  0.0  0.0   0:00.11 watchdog/0
    5 root      10  -5     0    0    0 S  0.0  0.0   0:03.23 events/0
    6 root      18  -5     0    0    0 S  0.0  0.0   0:00.00 khelper
    7 root      10  -5     0    0    0 S  0.0  0.0   0:00.00 kthread
   25 root      10  -5     0    0    0 S  0.0  0.0   0:00.29 kblockd/0
   71 root      15   0     0    0    0 S  0.0  0.0   0:11.73 pdflush
   72 root      15   0     0    0    0 S  0.0  0.0   0:01.12 pdflush
   74 root      20  -5     0    0    0 S  0.0  0.0   0:00.00 aio/0
   73 root      15   0     0    0    0 S  0.0  0.0   0:06.08 kswapd0
  666 root      10  -5     0    0    0 S  0.0  0.0   0:00.00 kseriod
  727 root      10  -5     0    0    0 S  0.0  0.0   0:00.00 ata/0
  732 root      16  -5     0    0    0 S  0.0  0.0   0:00.00 scsi_eh_0
  733 root      16  -5     0    0    0 S  0.0  0.0   0:00.00 scsi_eh_1
  808 root      15   0     0    0    0 S  0.0  0.0   1:05.88 kjournald
 1208 root      10  -5     0    0    0 S  0.0  0.0   0:00.00 md0_raid1
 1243 root      15   0     0    0    0 S  0.0  0.0   0:00.00 kjournald
 1576 root      10  -5     0    0    0 S  0.0  0.0   0:00.00 khubd
 2482 root      15   0  2328  744  616 S  0.0  0.0   0:07.92 syslogd
 2485 root      16   0  2412 1276  348 S  0.0  0.0   0:00.04 klogd
 2490 root      32  15 27832  23m 2340 S  0.0  0.8   0:00.37 spamd
 2498 clamav    17   0 30548  18m  884 S  0.0  0.6   0:09.41 clamd
 2539 clamav    16   0  4164 1020  844 S  0.0  0.0   0:00.07 freshclam
 2544 root      19   0  1752  384  316 S  0.0  0.0   0:00.00 courierlogger
 2545 root      16   0  1868  504  412 S  0.0  0.0   0:00.00 authdaemond.pla
 2551 root      16   0  2552  668  584 S  0.0  0.0   0:00.00 couriertcpd
 2553 root      24   0  1756  472  400 S  0.0  0.0   0:00.00 courierlogger
 2555 root      15   0  2056  540  440 S  0.0  0.0   0:00.22 authdaemond.pla
 2556 root      15   0  2056  540  440 S  0.0  0.0   0:00.26 authdaemond.pla
 2557 root      15   0  2056  540  440 S  0.0  0.0   0:00.28 authdaemond.pla
 2558 root      15   0  2056  540  440 S  0.0  0.0   0:00.24 authdaemond.pla
 2559 root      16   0  2056  540  440 S  0.0  0.0   0:00.28 authdaemond.pla
 2569 root      16   0  2556  668  584 S  0.0  0.0   0:00.00 couriertcpd
 2571 root      19   0  1752  468  400 S  0.0  0.0   0:00.00 courierlogger
 2577 root      15   0  2552  664  584 S  0.0  0.0   0:00.59 couriertcpd
 2579 root      25   0  1756  472  400 S  0.0  0.0   0:00.54 courierlogger
 2590 root      16   0  2552  664  584 S  0.0  0.0   0:00.00 couriertcpd
 2592 root      25   0  1752  468  400 S  0.0  0.0   0:00.00 courierlogger
 2726 Debian-e  15   0  9188 1128  896 S  0.0  0.0   0:00.07 exim4
 2732 root      16   0  2320  704  620 S  0.0  0.0   0:01.60 inetd
 3384 root      16   0 42900  860  612 S  0.0  0.0   0:35.30 nscd
 3403 root      16   0  3436  704  612 S  0.0  0.0   0:01.16 sshd
 3408 root      16   0  2172  912  320 S  0.0  0.0   0:32.19 mdadm
 3461 daemon    16   0  1576  292  280 S  0.0  0.0   0:00.00 atd
 3467 root      15   0  1632  528  456 S  0.0  0.0   0:02.17 cron
 3574 root      16   0  1584  412  408 S  0.0  0.0   0:00.00 getty
 3575 root      16   0  1580  412  408 S  0.0  0.0   0:00.00 getty
 3578 root      16   0  1584  412  408 S  0.0  0.0   0:00.00 getty

Das macht doch eigentlich keinen Sinn, oder. Wenn die Prozessorlast und Mem. Last die gleiche wie vor dem Restart ist, aber alles läuft viel schneller.

Wo ist denn da die Logik??

Hat jemand eine Idee dazu?

mfg
medic
 
Last edited by a moderator:
Wenn Du mal Zeit hast und nur wenig Besucher auf dem Server sind, dann schalte doch mal eine Sache nach der anderen ab.
(erst Apache, dann MTA, MySql, ...)
Nach jedem Abschalten schau Dir mal die Werte in Top an, ob sich was verändert.

Beispiel:
Wenn also nach dem Abschalten von MySql plötzlich viel mehr Arbeitsspeicher frei ist, dann könnte es an MySql liegen.

Ich hoffe die Idee, die dahinter steckt ist klar.
 
Danke mal vorab für die Hilfe, die Idee dahinter hab ich verstanden.

Nun habe ich eben mit S4Y telefoniert um ein wenig Licht in die Sache zu bringen. Also bezüglich des Mem. wurde mir erklärt, dass Linux ja Programm in den Ram cached um schneller reagieren zu können. Dieser wird allerding sofort geleert wenn der Arbeitspeicher benötigt wird, dann nutze ich eben mal 500Mb, was eigentlich noch in einem Rahmen ist.

Und das Problem mit den Lags und langen Ladezeiten wurde mir nun so erklärt, dass es seit dem Zwischenfall vor einigen Tagen, als das ges. Rechnerzentrum nicht mehr erreichbar war, der Schaden noch immer nicht behoben werden konnte.
Scheinbar sind die Router dort einfach nur für einen langsamen Betrieb für den Moment irgendwie reaktiviert worden.

Zur Frage, wie lange dieses Problem noch bestehen würde, konnte mir nur gesagt werden, dass es im Bereich von Tagen und nicht Wochen liegen würde.

Das mal zur Info an alle, die möglicherweise im Moment auch einige Geschwindigkeitsprobleme mit Servern aus dem Rechnerzentrum Frankfurt haben.

mfg
medic
 
Ich würde auf diese Aussage nicht 100 % vertrauen. Es kann sein das sie auch dafür verantwortlich ist, dennoch würde ich dem ganzen weiter nach gehen und speziell das mit dem beenden der Prozesse mal versuchen. Was weiß ich morgen um halb vier wird wohl keiner den Server vermissen wenn er mal eine halbe Stunde nicht zuerreichen ist.
 
Ja, danke für den Tip, ich werde auf jeden Fall mal alles so durchtesten.

Möglicherweise ist ja da noch was zu finden, so leicht lass ich mich sowieso nie beruhigen. :D

Ich geb erst dann Ruhe, wenn alles so läuft wie ich das gerne hätte und so wie ich mich kenne bedeutet das wohl nie, denn perfekt ist wohl wunschdenken. :)

Danke auf jedenfall nochmal für eure Hilfe, hat mich ein schönes Stück weiter gebracht mit meinem root.

Ich werde die nächsten Tage mal weiter analysieren und abwarten ob S4Y dieses Problem in den Griff bekommt.

mfg
medic
 
medic said:
und dabei bin ich folgende Anleitung gestossen:
Click to expand...
Schau auf das Datum des Artikels.
Damals war Apache2 noch sehr neu und das HTTP-1.1-Protokol wurde (wie auch heute) nicht wirklich ausgereizt.
Sprich: Damals (vor 2 Jahren kann schon 'damals' sein) hatte man noch nicht die Erfahrung was das angeht.

Du mußt Dir klar machen, was KeepAlive eigendlich heißt, was man damit wollte und warum das die Performance verbessern sollte:
Das HTTP-Protokol v1.1 läßt mehrere Request mit nur einer Connection zu. Im Gegensatz zu der Version 1.0 wird nach dem Request die Verbindung nicht direkt geschlossen sondern aufrecht erhalten um zu warten, ob der Client/Webbrowser nun weitere Anfragen schickt.
Tut dies der Client nicht, oder baut dennoch einen neue Connection auf (um z.B. weitere Bilder nach zuladen), so blockiert der Client plötzlich 2 Apache-Childs. Bei einer gut besuchten und auch bilderreichen Seite kann dies plötzlich ausarten. Und jeder Child wartet nochmal 15 Sekunden, bis er die Connection schließt und einen neuen Client bedient.
So entsteht ein plötzlich ein Server voller Apache-Childs, die alle im Leerlauf vor sich hin dümpeln.

Daher gilt heute eher der Leitsatz: KeepAlive Off

huschi.
 
Ist es vielleicht nicht doch sinnvoll "KeepAlive" auf On zu lassen?
Wie Du ja richtig gesagt hast, wartet die Instanz des Apachen auf neue Anfragen des Users. Wenn ich nun "KeepAlive" auf Off stelle, dann werden zwar die Instanzen schneller wieder beendet aber für jede neue Anfrage muss ich dann erst wieder eine neue Instanz forken und das dauert ja auch einen Moment.
Bei deinem Beispiel mit den Bildern, ist es dann nicht so, dass wenn "KeepAlive" auf On ist, dass dann alle Elemente der Seite von einem Apache-Child gesendet werden? Wenn ich meine Seite aufrufe, die ja doch ein paar Bilder enthält, dann werden die alle von einer Instanz ausgeliefert (getestet mit netstat -an --inet | grep -i ":80")
 
Da ist was wahres dran was Huschi gepostet hat.

Wenn man keep alive auf on stehen hat, dann bleiben die offenen Verbindungen doch auch im Arbeitsspeicher liegen, oder?

Dadurch wird es ja eigentlich noch wilder, bei gleichzeitig 1000 Usern ist der Arbeitsspeicher dann ja ganz schön voll.

Was mich auch noch interessieren würde, ist wie man die mpm Einstellungen am besten setzt.
Ich habe bei meinem Webserver den Apache nicht selbst kompiliert, sondern nutze eine Installation durch meinen Hoster, dadurch steht in der apache2.conf folgendes drin:

Code: 
# Timeout: The number of seconds before receives and sends time out.

Timeout 120

# KeepAlive: Whether or not to allow persistent connections (more than
# one request per connection). Set to "Off" to deactivate.

KeepAlive Off

# MaxKeepAliveRequests: The maximum number of requests to allow
# during a persistent connection. Set to 0 to allow an unlimited amount.
# We recommend you leave this number high, for maximum performance.

MaxKeepAliveRequests 100

# KeepAliveTimeout: Number of seconds to wait for the next request from the
# same client on the same connection.

KeepAliveTimeout 10
##
## Server-Pool Size Regulation (MPM specific)
## 

# prefork MPM
# StartServers ......... number of server processes to start
# MinSpareServers ...... minimum number of server processes which are kept spare
# MaxSpareServers ...... maximum number of server processes which are kept spare
# MaxClients ........... maximum number of server processes allowed to start
# MaxRequestsPerChild .. maximum number of requests a server process serves
<IfModule prefork.c>
StartServers         5
MinSpareServers      5
MaxSpareServers     10
MaxClients          20
MaxRequestsPerChild  0
</IfModule>

# pthread MPM
# StartServers ......... initial  number of server processes to start
# MaxClients ........... maximum  number of server processes allowed to start
# MinSpareThreads ...... minimum  number of worker threads which are kept spare
# MaxSpareThreads ...... maximum  number of worker threads which are kept spare
# ThreadsPerChild ...... constant number of worker threads in each server process
# MaxRequestsPerChild .. maximum  number of requests a server process serves
<IfModule worker.c>
StartServers         2
MaxClients         150 
MinSpareThreads     25
MaxSpareThreads     75
ThreadsPerChild     25
MaxRequestsPerChild  0
</IfModule>

# perchild MPM
# NumServers ........... constant number of server processes
# StartThreads ......... initial  number of worker threads in each server process
# MinSpareThreads ...... minimum  number of worker threads which are kept spare
# MaxSpareThreads ...... maximum  number of worker threads which are kept spare
# MaxThreadsPerChild ... maximum  number of worker threads in each server process
# MaxRequestsPerChild .. maximum  number of connections per server process (then it dies)
<IfModule perchild.c>
NumServers           5
StartThreads         5
MinSpareThreads      5
MaxSpareThreads     10
MaxThreadsPerChild  20
MaxRequestsPerChild  0
AcceptMutex fcntl
</IfModule>

Das ganze läuft auf einem Opteron 148 mit 3Gb Ram (S4Y). Nun sind da schon über 700 User drauf und davon sicher 300 mit Php und MySQL.

Da klettert der Serverload in Spitzenzeiten schon mal bis auf 2 und das macht ganz schön Druck, ich möchte einfach die optimale Leistung raus holen.

Einige Verbesserungsvorschläge??

mfg
medic
 
daseddy said:
Wenn ich nun "KeepAlive" auf Off stelle, dann werden zwar die Instanzen schneller wieder beendet aber für jede neue Anfrage muss ich dann erst wieder eine neue Instanz forken
Click to expand...
Nein. Nicht der Child wird beendet, sondern die Connection. Großer Unterschied.
Ob ein Child beendet wird, dafür sind die Einstellungen Min-/MaxSpareServers und MaxRequestsPerChild zuständig.
Daher auch der MPM-Name 'Prefork'. Also 'vorher geforkt'.

Wenn ich meine Seite aufrufe, die ja doch ein paar Bilder enthält, dann werden die alle von einer Instanz ausgeliefert
Click to expand...
Bei einem wenig genutzten Server sollte dies auch bei KeepAlive Off der Fall sein.


@medic:
Mit dem Speicher kannst Du die Min-/MaxSpareServers und MaxClients verdoppeln. Hab aber danach ein Auge drauf.

Auch die Buffers bei MySQL könntest Du hochschrauben. Vorallem alle, die mit dem Query-Cache zu tun haben.

Ich könnte mir Vorstellen, daß der Server selbst in Hochzeiten immer noch nicht swapt.

huschi.
 
Du meinst unter prefork mpm mal diese drei wetre verdoppeln und den rest einfach mal so belassen?

Das mit dem MySQL Cache hab ich mir auch schon angesehen, das werd ich auf jeden Fall machen.

mfg
medic
 
Okay, momentan hab ich jetzt mal den MySQL Cache erhöht und die Min-/MaxSpareServers und MaxClients verdoppelt.

Das hat sich bisher mehr als nur ausgezahlt, der Seitenaufbau ist jetzt wesentlich schneller.

Danke nochmal für eure Ideen vorallem an Huschi, danke.

Sollte jemand noch weitere Ideen haben und die Performance zu steigern, immer nur her damit.

mfg
medic
 
medic said:
Sollte jemand noch weitere Ideen haben und die Performance zu steigern, immer nur her damit.
Click to expand...
Du brauchst nicht mehr Ideen, sondern Du mußt jetzt mit den Werten spielen.
Du hast 3Gbyte Ram, d.h. Du kannst die Werte noch locker steigern.
Mein Tip: vorallem im MySQL sollten größere Buffer auch Performance-Sprünge machen.

Behalte immer Deinen Swap-Space im Auge.
Sobald er anfängt zu swappen bist Du über das Ziel hinaus.
Du solltest Dir auch noch Speicher-Reserven behalten.

Wenn Du ausreichend viele Apache-Childs zur verfügung stellst, kannst Du es auch wieder mit KeepAlive On versuchen. Setz nur den Timeout auf einen vernüftig niedrigen Wert wie 1 oder 2 Sekunden. (Moderne Browser sollten so schnell sein.)

huschi.
 
Okay,
danke nochmal für die Hinweise, das hat mich wirklich extrem weiter gebracht.

Ich werd jetzt noch ein wenig mit den Werten spielen, möglicherweise kann ich noch was raus holen.:rolleyes:

mfg
medic
 
You must log in or register to reply here.
Back
Top