Apache beendet seine Childs nicht

[SebiF]

Hallo.

Ich habe derzeit ein Problem mit meinem vServer. Auf diesem läuft ein Debian 4.0 und Plesk 8.6.0. Der Server hat 512 MB RAM soft, 768 MB hard. Es laufen Apache 2.2.3 mit Prefork und MySQL Ver 14.12 Distrib 5.0.32.
Als Module laufen: alias auth_basic authn_file authz_default authz_groupfile authz_host authz_user cgi dir env mime mod_python negotiation php5 rewrite setenvif ssl status suexec
Auf dem Server befinden sich 6 Foren (WBB. 4 davon nahezu tot, 1 klein (10 Benutzter gleichzeitig) und das größte hat 2600 Mitglieder, 2300 Beiträge pro Tag, meist um die 40 gleichzeitige Unique-Besucher.

Die apache2.conf sieht so aus (auf wichtigste reduziert):

ServerRoot "/etc/apache2"
LockFile /var/lock/apache2/accept.lock
PidFile /var/run/apache2.pid

Timeout 5
KeepAlive On
MaxKeepAliveRequests 30
KeepAliveTimeout 1

<IfModule mpm_prefork_module>
        StartServers       3
        MinSpareServers    3
        MaxSpareServers    15
        MaxClients        25
        MaxRequestsPerChild   2000
</IfModule>

HostnameLookups Off

Die error.log sagt:

[Fri Dec 04 17:31:54 2009] [notice] Apache configured -- resuming normal operations
[Fri Dec 04 17:33:05 2009] [error] server reached MaxClients setting, consider raising the MaxClients setting
[Fri Dec 04 17:37:43 2009] [warn] child process 12226 still did not exit, sending a SIGTERM
[Fri Dec 04 17:37:43 2009] [warn] child process 12232 still did not exit, sending a SIGTERM
[Fri Dec 04 17:37:43 2009] [warn] child process 11975 still did not exit, sending a SIGTERM
[Fri Dec 04 17:37:43 2009] [warn] child process 13359 still did not exit, sending a SIGTERM
[Fri Dec 04 17:37:43 2009] [warn] child process 12236 still did not exit, sending a SIGTERM
[Fri Dec 04 17:37:45 2009] [warn] child process 12226 still did not exit, sending a SIGTERM
[Fri Dec 04 17:37:45 2009] [warn] child process 12232 still did not exit, sending a SIGTERM
[Fri Dec 04 17:37:45 2009] [warn] child process 11975 still did not exit, sending a SIGTERM
[Fri Dec 04 17:37:45 2009] [warn] child process 13359 still did not exit, sending a SIGTERM
[Fri Dec 04 17:37:45 2009] [warn] child process 12236 still did not exit, sending a SIGTERM
[Fri Dec 04 17:37:47 2009] [warn] child process 12226 still did not exit, sending a SIGTERM
[Fri Dec 04 17:37:47 2009] [warn] child process 12232 still did not exit, sending a SIGTERM
[Fri Dec 04 17:37:47 2009] [warn] child process 11975 still did not exit, sending a SIGTERM
[Fri Dec 04 17:37:47 2009] [warn] child process 13359 still did not exit, sending a SIGTERM
[Fri Dec 04 17:37:47 2009] [warn] child process 12236 still did not exit, sending a SIGTERM
[Fri Dec 04 17:37:49 2009] [error] child process 12226 still did not exit, sending a SIGKILL
[Fri Dec 04 17:37:49 2009] [error] child process 12232 still did not exit, sending a SIGKILL
[Fri Dec 04 17:37:49 2009] [error] child process 11975 still did not exit, sending a SIGKILL
[Fri Dec 04 17:37:49 2009] [error] child process 13359 still did not exit, sending a SIGKILL
[Fri Dec 04 17:37:49 2009] [error] child process 12236 still did not exit, sending a SIGKILL
[Fri Dec 04 17:37:50 2009] [notice] caught SIGTERM, shutting down

Was soll ich tun? Ist es wirklich ratsam, die MaxClients zu erhöhen?
In htop sehen die apaches erst ganz normal aus, nach etwa einer halben Stunde verdoppeln Sie sich und haben dann alle den Status "R". Was bedeutet das (siehe Attachment)?

Kurz bevor nichts mehr ging, konnte ich noch folgendes über /server-status erfahren:

Server Version: Apache
Server Built: Nov 13 2009 15:16:06

Current Time: Friday, 04-Dec-2009 18:13:08 UTC
Restart Time: Friday, 04-Dec-2009 17:37:53 UTC
Parent Server Generation: 1
Server uptime: 35 minutes 15 seconds
Total accesses: 959 - Total Traffic: 10.4 MB
CPU Usage: u8.91 s6.8 cu0 cs0 - .743% CPU load
.453 requests/sec - 5.0 kB/second - 11.1 kB/request
25 requests currently being processed, 0 idle workers

WWWWWWWWWWWWWWWWWWWWWWWWW.......................................
................................................................
................................................................
................................................................

 

[Deleted member 4401]

Die "S"-Spalte im Output zeigt den Status des Prozesses an, S=Sleeping, R=Running.

Schau mal per netstat ob tatsächlich so viele Verbindungen vorhanden sind welche die Apache Prozesse belegen, und ob dies "gutartige" Requests sind.

Dein System (bzw. die Resourcen) ist halt, wenn ich mir die Zugriffe anschaue die du angegeben hast, schon ziemlich auf Kante genäht, selbst bei einer guten Konfiguration. Du solltest mal die KeepAliveRequests runtersetzen, probier es mal mit 10 anstatt 30 und schau ob es dann besser läuft, ich tippe darauf dass hier das Problem mit den Child Processes begründet liegt.
Persönlich wären mir 15 MaxSpareServers auch zu viel bei der begrenzten RAM Grösse, geh bei dem Wert auch mal ein wenig runter (7 oder 8 würde ich mal sagen).
Ein externer PHP Cache (eaccelerator z.B.) würde der ServerLoad auch ziemlich zuträglich sein falls noch nicht installiert, ebenso eine gute MySQL Konfiguration.

 

[SebiF]

Hiho.

eAccelerator läuft bereits. Sorry, vergas ich zu erwähnen.
Ich habe mal testweise MaxClients auf 70 gesetzt. Er lief dann sogar 2 Stunden stabil anstatt 30 Minuten.
Ich gehe jetzt nochmals einen radikalen Weg und habe folgendes geändert:

MaxKeepAliveRequests 20
<IfModule mpm_prefork_module>
StartServers 1
MinSpareServers 1
MaxSpareServers 3
MaxClients 35
MaxRequestsPerChild 2000
</IfModule>

Ich beobachte nun, ob und wie lange er stabil bleibt (eigentlich muss er das) und erhöhe dann Schrittweise die Servers. Den Rest belasse ich denke ich. Ich sehe hier des Häufigeren Konfigurationen mit etlichen Boards und Min- und MaxSpareServers von 2 - 3. Ausprobieren kann mans ja.

Auch interessant: wenn die Apaches alle als "Running" hängen bleiben, startet er einen einzelnen Apache auf "Sleeping", aber als root... Das macht mir ein wenig Sorgen.

Edit: Apaches wieder "Running" hängen geblieben nach etwa 30 Minuten.

Jetzt:

MaxKeepAliveRequests 10
<IfModule mpm_prefork_module>
StartServers 1
MinSpareServers 1
MaxSpareServers 1
MaxClients 25
MaxRequestsPerChild 2000
</IfModule>

Edit: Da du es ansprachst, meine my.cnf, eingestellt mit mysqltuner.pl und tuning-primer.sh:

[client]
port = 3306
socket = /var/run/mysqld/mysqld.sock

[mysqld_safe]
socket = /var/run/mysqld/mysqld.sock
nice = 0

skip-bdb

set-variable = innodb_buffer_pool_size=2M
set-variable = innodb_additional_mem_pool_size=500K
set-variable = innodb_log_buffer_size=500K
set-variable = innodb_thread_concurrency=2
[mysqld]
set-variable=local-infile=0
#
# * Basic Settings
#
user = mysql
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
port = 3306
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp
language = /usr/share/mysql/english
skip-external-locking

# * Fine Tuning
#
key_buffer = 128M
max_allowed_packet = 16M
thread_stack = 64K
thread_cache_size = 50
max_connections = 35
long_query_time = 5
table_cache = 2560
open_files_limit = 5120
thread_concurrency = 2
sort_buffer_size = 500K
read_buffer_size = 500K
read_rnd_buffer_size = 768K
join_buffer_size = 1M
tmp_table_size = 64M
max_heap_table_size = 32M
wait_timeout = 14400
interactive_timeout = 14400

#
# * Query Cache Configuration
#
query_cache_limit = 4M
query_cache_size = 40M
query_cache_type = 1

log_slow_queries = /var/log/mysql/mysql-slow.log

skip-bdb

skip-innodb

set-variable = innodb_buffer_pool_size=2M
set-variable = innodb_additional_mem_pool_size=500K
set-variable = innodb_log_buffer_size=500K
set-variable = innodb_thread_concurrency=2
[mysqldump]
quick
quote-names
max_allowed_packet = 16M

[mysql]

[isamchk]
key_buffer = 1M

!includedir /etc/mysql/conf.d/

Edit: Hängt nach 20 Minuten bereits.
Während apache hing habe ich mal netstat bemüht. Das ist die Ausgabe:

lvpsxxx-xxxx-xxx-xx:/etc/mysql# netstat
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp6 0 0 lvpsxxx-xxxx-xxx-xx.:ssh xx29228007.adsl.a:55009 ESTABLISHED
tcp6 0 0 lvpsxxx-xxxx-xxx-xx.:www xx179089116.adsl.a:61297 ESTABLISHED
tcp6 764 0 lvpsxxx-xxxx-xxx-xx.:www xx486A3AA.dip0.t-:54246 CLOSE_WAIT
tcp6 727 0 lvpsxxx-xxxx-xxx-xx.:www xx486A3AA.dip0.t-:54244 CLOSE_WAIT
tcp6 727 0 lvpsxxx-xxxx-xxx-xx.:www xx486A3AA.dip0.t-:54243 CLOSE_WAIT
tcp6 1 0 lvpsxxx-xxxx-xxx-xx.:www xxxxx-202-131-30-:33895 CLOSE_WAIT
tcp6 727 0 lvpsxxx-xxxx-xxx-xx.:www pxx86A3AA.dip0.t-:54241 CLOSE_WAIT
tcp6 566 0 lvpsxxx-xxxx-xxx-xx.:www port-xx268.pppoe.:57343 ESTABLISHED
tcp6 772 0 lvpsxxx-xxxx-xxx-xx.:www port-xx268.pppoe.:57342 ESTABLISHED
tcp6 241 0 lvpsxxx-xxxx-xxx-xx.:www crawl-xxc.cuil.co:36678 CLOSE_WAIT
tcp6 764 0 lvpsxxx-xxxx-xxx-xx.:www p5xx6A3AA.dip0.t-:54248 CLOSE_WAIT
tcp6 204 0 lvpsxxx-xxxx-xxx-xx.:www crawl-2xx-131-30-:33395 ESTABLISHED
tcp6 988 0 lvpsxxx-xxxx-xxx-xx.:www port-92-1xx-119-9:57743 ESTABLISHED
tcp6 878 0 lvpsxxx-xxxx-xxx-xx.:www port-92-1xx-119-9:57744 ESTABLISHED
tcp6 1 0 lvpsxxx-xxxx-xxx-xx.:www pD955B9xx.dip.t-d:64668 CLOSE_WAIT
tcp6 408 0 lvpsxxx-xxxx-xxx-xx.:www ::ffff:93.86.2xx.2:4835 ESTABLISHED
tcp6 1 0 lvpsxxx-xxxx-xxx-xx.:www pD955B9xx.dip.t-d:64670 CLOSE_WAIT
tcp6 930 0 lvpsxxx-xxxx-xxx-xx.:www e1782091xx.adsl.a:60969 ESTABLISHED
tcp6 205 0 lvpsxxx-xxxx-xxx-xx.:www crawl-20xx-131-30-:48271 CLOSE_WAIT
tcp6 919 0 lvpsxxx-xxxx-xxx-xx.:www p5B222Dxx.dip0.t-:51004 ESTABLISHED
tcp6 0 0 lvpsxxx-xxxx-xxx-xx.:www 95-88-2xx-186-dyni:2689 ESTABLISHED
tcp6 727 0 lvpsxxx-xxxx-xxx-xx.:www p5486A3xx.dip0.t-:54288 CLOSE_WAIT
tcp6 566 0 lvpsxxx-xxxx-xxx-xx.:www port-902xx.pppoe.:57345 ESTABLISHED
tcp6 393 0 lvpsxxx-xxxx-xxx-xx.:www p5488CxxA.dip.t-d:60431 CLOSE_WAIT
tcp6 339 0 lvpsxxx-xxxx-xxx-xx.:www crawl-2xx-131-30-:37094 ESTABLISHED
tcp6 1 0 lvpsxxx-xxxx-xxx-xx.:www crawl-1xx.cuil.co:59078 CLOSE_WAIT
tcp6 407 0 lvpsxxx-xxxx-xxx-xx.:www ip-83-1xx-167-72.:51829 CLOSE_WAIT
tcp6 847 0 lvpsxxx-xxxx-xxx-xx.:www 91-115-1xx-193.ad:61942 ESTABLISHED
tcp6 515 0 lvpsxxx-xxxx-xxx-xx.:www p54B25Cxx.dip.t-d:53998 CLOSE_WAIT
tcp6 515 0 lvpsxxx-xxxx-xxx-xx.:www p54B25Cxx.dip.t-d:53999 CLOSE_WAIT
tcp6 1461 0 lvpsxxx-xxxx-xxx-xx.:www p5B0C75xx.dip.t-di:3975 ESTABLISHED
tcp6 1486 0 lvpsxxx-xxxx-xxx-xx.:www p5B0C75xx.dip.t-di:3974 CLOSE_WAIT
tcp6 1486 0 lvpsxxx-xxxx-xxx-xx.:www p5B0C75xx.dip.t-di:3969 CLOSE_WAIT
tcp6 925 0 lvpsxxx-xxxx-xxx-xx.:www ::ffff:82.113.1xx:35495 ESTABLISHED
tcp6 1 0 lvpsxxx-xxxx-xxx-xx.:www dslb-188-098-1xx-2:3563 CLOSE_WAIT
tcp6 952 0 lvpsxxx-xxxx-xxx-xx.:www dslb-188-098-1xx-2:3565 ESTABLISHED
tcp6 953 0 lvpsxxx-xxxx-xxx-xx.:www dslb-188-098-1xx-2:3564 CLOSE_WAIT
tcp6 889 0 lvpsxxx-xxxx-xxx-xx.:www ::ffff:82.113.1xx:24475 ESTABLISHED
tcp6 436 0 lvpsxxx-xxxx-xxx-xx.:www pDxx1F0DC.dip.t-d:55504 CLOSE_WAIT
tcp6 463 0 lvpsxxx-xxxx-xxx-xx.:www spc2-bourx-x-0-cus:4132 ESTABLISHED
tcp6 899 0 lvpsxxx-xxxx-xxx-xx.:www ::ffff:82.113.1xx:58609 ESTABLISHED
tcp6 489 0 lvpsxxx-xxxx-xxx-xx.:www frbg-5fxx00f0.pool:1730 CLOSE_WAIT
tcp6 489 0 lvpsxxx-xxxx-xxx-xx.:www frbg-5fxx00f0.pool:1729 CLOSE_WAIT
tcp6 530 0 lvpsxxx-xxxx-xxx-xx.:www frbg-5fxx00f0.pool:1734 CLOSE_WAIT
tcp6 530 0 lvpsxxx-xxxx-xxx-xx.:www frbg-5fxx00f0.pool:1732 CLOSE_WAIT
tcp6 530 0 lvpsxxx-xxxx-xxx-xx.:www frbg-5fxx00f0.pool:1733 CLOSE_WAIT
tcp6 434 0 lvpsxxx-xxxx-xxx-xx.:www b3xx1041.crawl.ya:57943 ESTABLISHED
tcp6 354 0 lvpsxxx-xxxx-xxx-xx.:www cpe-74-73-106-1xx:51432 CLOSE_WAIT
tcp6 1 0 lvpsxxx-xxxx-xxx-xx.:www p54B6C6xx.dip.t-di:1724 CLOSE_WAIT
tcp6 435 0 lvpsxxx-xxxx-xxx-xx.:www b30910xx.crawl.ya:54207 CLOSE_WAIT
tcp6 0 0 lvpsxxx-xxxx-xxx-xx.:www crawl-66-249-xx-2:34003 ESTABLISHED
tcp6 353 0 lvpsxxx-xxxx-xxx-xx.:www cpe-74-73-106-1xx:51488 ESTABLISHED
tcp6 885 0 lvpsxxx-xxxx-xxx-xx.:www ::ffff:82.113.1xx:39945 ESTABLISHED
tcp6 836 0 lvpsxxx-xxxx-xxx-xx.:www p4FFExxD9.dip.t-d:50079 CLOSE_WAIT
tcp6 836 0 lvpsxxx-xxxx-xxx-xx.:www p4FFExxD9.dip.t-d:50077 CLOSE_WAIT
tcp6 771 0 lvpsxxx-xxxx-xxx-xx.:www p5089xxB6.dip.t-d:54792 CLOSE_WAIT
tcp6 1 0 lvpsxxx-xxxx-xxx-xx.:www p5B0CxxC5.dip.t-di:3955 CLOSE_WAIT
tcp6 1 0 lvpsxxx-xxxx-xxx-xx.:www p5B0CxxC5.dip.t-di:3954 CLOSE_WAIT
tcp6 1486 0 lvpsxxx-xxxx-xxx-xx.:www p5B0CxxC5.dip.t-di:3965 CLOSE_WAIT
tcp6 775 0 lvpsxxx-xxxx-xxx-xx.:www p5089xxB6.dip.t-d:54786 CLOSE_WAIT
tcp6 1486 0 lvpsxxx-xxxx-xxx-xx.:www p5B0CxxC5.dip.t-di:3961 CLOSE_WAIT
tcp6 771 0 lvpsxxx-xxxx-xxx-xx.:www p5089xxB6.dip.t-d:54787 CLOSE_WAIT
tcp6 1486 0 lvpsxxx-xxxx-xxx-xx.:www p5B0CxxC5.dip.t-di:3960 CLOSE_WAIT
tcp6 771 0 lvpsxxx-xxxx-xxx-xx.:www p5089xxB6.dip.t-d:54787 CLOSE_WAIT
tcp6 1486 0 lvpsxxx-xxxx-xxx-xx.:www p5B0CxxC5.dip.t-di:3960 CLOSE_WAIT

Active UNIX domain sockets (w/o servers)
Proto RefCnt Flags Type State I-Node Path
unix 9 [ ] DGRAM 344614628 /dev/log
unix 3 [ ] STREAM CONNECTED 345121072 /var/run/mysqld/mysq ld.sock
unix 3 [ ] STREAM CONNECTED 345121071
unix 2 [ ] DGRAM 345020201
unix 3 [ ] STREAM CONNECTED 344615744
unix 3 [ ] STREAM CONNECTED 344615743
unix 2 [ ] DGRAM 344615650
unix 2 [ ] DGRAM 344615307
unix 2 [ ] DGRAM 344615055
unix 2 [ ] DGRAM 344615036
unix 2 [ ] DGRAM 344615011
unix 2 [ ] DGRAM 344614971

error.log:

[Fri Dec 04 21:34:44 2009] [error] server reached MaxClients setting, consider raising the MaxClients setting

Sonst nichts.

Nächste Maßnahme:

KeepAlive Off

Der Rest bleibt so.

Läuft - es laufen immer nur sehr wenige Apaches (< 10). Das gabs sonst nie.
Vorsichtige Verbesserung der Latenzen, die die User jetzt aushalten müssen:

<IfModule mpm_prefork_module>
StartServers 3
MinSpareServers 3
MaxSpareServers 5
MaxClients 25
MaxRequestsPerChild 2000
</IfModule>

MaxClients lass ich erstmal niedrig.

CPU-Last ist jetzt recht hoch. 20 - 30 % durchgängig (vor KeepAlive Off um die 5 - 10%).

 

[Deleted member 4401]

Ok, gut dass es jetzt schon besser läuft.
Aber bei deine my.cnf fällt mir doch auf dass du SEHR grosszügig mit zugewiesenen Resourcen umgehst, du musst diese immer im Kontext mit dem restlichen System sehen. Die Tips des tuning-primers sind sicherlich sinnvoll, aber bei nur 768MB RAM ("soft" oder "dynamisches" RAM is nix wert, also garnicht erst einrechnen) alleine schon 128 MB dem Keybuffer zu geben ist schon sehr grosszügig.....besser MySQL läuft eben nicht 100% optimal (lt. tuning-primer) als dass dir woanders der Speicher ausgeht. Das Gleiche gilt für die anderen Werte, mit einem zu grosszügigen Umgang mit dem open_files Limit habe ich mir z.B. auch schon mal das System schwer verschlimmbessert und an den Rande des Absturzes gebracht.

Also nicht blind befolgen was empfohlen wird, sondern langsam rantasten und beobachten...

 

[SebiF]

Hi.

Oh... für das gigantische Open-Files-Limit hat mir extra mein Hoster numfiles erhöht, obwohl es dafür das nächsthöhere Paket gebraucht hätte ^^.
Aber die Anzahl an Tabellen ist schon enorm. Etwas über 2000 Stück sinds. Da dachte ich, dass ich den Wert für den table_cache nahe 2000 setze. Und dann halt das 2 - 3 fache für max_open_files.
Aber mysql ist laut htop nicht wirklich das Problem. Es genehmigt sich zuverlässig 200 MB RAM mit der jetzigen Konfiguration.
Bei den Scripten habe ich mich hauptsächlich von den Cache Hits leiten lassen. 45% und sowas klangen einfach nicht gut... jetzt sind es um 97%.
Open_files belegt zudem gut 90% des Limits. Führe ich ein "flush tables" aus, ist es innerhalb von 1 - 2 Minuten wieder dort angekommen. Woltlab Burning Board eben... :-/.
Der RAM-Verbrauch liegt laut Virtuozo-Auskunft (die sollte stimmen) bei 440 MB dauerhaft. Gelber Bereich wird immer mal angekratzt, roter oder gar schwarz aber nie (nicht mal, wenn der Apache hängen bleibt - das ist ein wenig seltsam).
Ich werde mich mal nach unten tasten *g*.

Sollte ein Prod-System aber wirklich nur mit KeepAlive Off stabil sein?

 

[Deleted member 4401]

Sollte ein Prod-System aber wirklich nur mit KeepAlive Off stabil sein?

Nein, das ist schon recht seltsam.
Ich habe nebst meinem Dedicated noch 3 vServer mit gleichen Specs was RAM betrifft, dort läuft phpnuke/phpbb mit einer höheren Anzahl von Besuchern als bei dir, jedoch habe ich in der Hinsicht keinerlei Probleme.

Hier mal meine Apache config:

MaxKeepAliveRequests 10
KeepAliveTimeout 3
<IfModule mpm_prefork_module>
    StartServers       3
    MinSpareServers    2
    MaxSpareServers    5
    MaxClients        40
    MaxRequestsPerChild   0
</IfModule>

Wie hoch ist den denn dein memory_limit in php.ini? Bei den default Werten von 16MB (bzw. 8 MB bei php4) kann das auch gerne mal den Server ausbremsen.

 

[SebiF]

Wie hoch ist den denn dein memory_limit in php.ini? Bei den default Werten von 16MB (bzw. 8 MB bei php4) kann das auch gerne mal den Server ausbremsen.

Das war ein sehr guter Hinweis. Ich habe nachgesehen:

memory_limit = 256M

Bei einem Server mit 512 MB verlässlichem RAM kann das nicht gutgehen. Ich habs auf 32 reduziert. Ich bin gespannt.
Stutzig gemacht hatte mich gerade direkt nach dem Restart des Apaches ein:

Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 858743945 bytes) in /var/www/vhosts/***/httpdocs/lib/data/board/Board.class.php on line 119

Hat leider nicht geholfen.
Ich hab mal deine apache2.conf übernommen. Leider hat das nichts gebracht. Zum testen habe ich von einem anderen Server

ab -n 1000 -c 10 http://www.***.de/

ausgeführt. Ich hätte ja verstanden, wenn der Server daraufhin eine Zeit nicht erreichbar gewesen wäre. Stattdessen verklemmten sich die etwa 12 gerade aktiven Apaches in "Running" und taten augenscheinlich nichts. 100% CPU-Last. :-/

Edit:
Ich habe jetzt die my.cnf ein ganzes Stück zurückgeschraubt:

key_buffer = 32M
max_allowed_packet = 8M
thread_stack = 64K
thread_cache_size = 50
max_connections = 15
long_query_time = 5
table_cache = 1024
open_files_limit = 2048
thread_concurrency = 2
sort_buffer_size = 500K
read_buffer_size = 500K
read_rnd_buffer_size = 768K
join_buffer_size = 1M
tmp_table_size = 32M
max_heap_table_size = 16M
#wait_timeout = 14400
#interactive_timeout = 14400
query_cache_limit = 2M
query_cache_size = 32M
query_cache_type = 1

Als ich mit

ab -n 300 -c 4 http://www.***.de

teste, lief alles gut. Die Apaches arbeiteten und kamen wieder zur Ruhe. Währenddessen konnte ich auf der Seite (wenn auch etwas langsam) surfen.
Dann der Härtetest:

ab -n 1000 -c 10 http://www.***.de

Sofort laufen 12 Apaches auf dem getesteten Server im Status "Running". Mein Server, mit dem ich teste, sagt mir nach etwas Wartezeit:

apr_poll: The timeout specified has expired (70007)
Total of 15 requests completed

Nur 15! Wie kann das sein? Nachdem auf meinem Server der Test schon lange abgebrochen wurde, hat sich der getestete Server immer noch nicht gefangen und ich muss apache manuell restarten.

Ok, jetzt in der apache2.conf MaxClients auf 10 gesetzt, ansonsten deine cfg übernommen.

ab -n 100 -c 10 http://www.***.de/

klappt!
Ausgabe

Concurrency Level: 10
Time taken for tests: 18.997875 seconds
Complete requests: 100
Failed requests: 0

Da denk ich mir, schauen wir doch mal, ob es auch mit 1 User mehr geht:

ab -n 100 -c 11 http://www.***.de/

Ausgabe:

apr_poll: The timeout specified has expired (70007)
Total of 47 requests completed

Zum Kuckuck! Wie kann das sein? Der getestete Server (bzw. dessen Apaches) bleibt auch wieder hängen.

OK. Ich halte fest: mit MaxClients 10 war der Server nicht belastbar mit mehr als 10 Verbindungen. Ich habe jetzt aus lauter Verzweiflung MaxClients auf 5 gesetzt. KeepAlive Off.
Ein

ab -n 500 -c 40 http://www.***.de/

läuft ohne Probleme durch. Ich bin fassungslos. Sobald die CPU auch nur ein einziges mal 100% ausgelastet ist, beenden sich die Apaches nicht mehr. Bei 5 MaxClients wechseln die sich irgendwie besser ab, es kommt nie zu 100% Auslastung...
Ausgabe von ab:

Concurrency Level: 40
Time taken for tests: 105.729203 seconds
Complete requests: 500
Failed requests: 39
(Connect: 0, Length: 39, Exceptions: 0)

Trotzdem erscheint mir die Lösung nicht als Lösung.

 

[Deleted member 4401]

Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 858743945 bytes) in /var/www/vhosts/***/httpdocs/lib/data/board/Board.class.php on line 119

Äähhm...habs jetzt extra 2x nachgerechnet, aber wenn versucht wird 816 MB zuzuweisen kann da was gewaltig nicht stimmen, komischerweise sind anscheinend immer noch 256MB zulässig obwohl du sagtest du hättest das Limit auf 32MB gesetzt.

Das letztere wird wahscheinlich durch einen Override verursacht (.htaccess z.B.), aber um da genaueres zu sagen kenne ich deine Apache config zu wenig.
Die 816 MB die da versucht werden zuzuweisen sind da auf jeden Fall das grössere Problem, solltest der Sache mal auf den Grund gehen und den Source Code des betreffenden Scripts anschauen, kenne mich leider mit WBB nicht die Bohne aus.

 

[SebiF]

Hi.

Da hab ich wohl mit der zeitlichen Abfolge etwas geschludert. Erst las ich deinen Tipp, dann kam der Fehler, dann habe ich das Limit auf 32M gesetzt. Seitdem habe ich den Fehler nicht wieder gesehen.

Aber ja, ein Script, dass ein derart alltagsuntaugliches memory_limit komplett ausnutzt, ist schon eigenartig. Am WBB etwas selbst ändern zu wollen ist... pure Selbstgeißelung. Solange ich den Fehler nicht wiedersehe, bleibe ich bei den normalen Updates.

Ich habe noch ein wenig empirisch herumgeforscht. Bereits ein MaxClients von 6 zwingt den Server in die Knie. Trotz 512 MB RAM und ehrlich gesagt guter CPU-Zusicherung (besser als ichs bei einem anderen, kleineren Anbieter hab, von dem aus ich die Tests gestartet habe).

Naja. Er läuft jetzt erstmal und ich habe eine Kündigungsfrist von einem Monat. Zum Jahreswechsel werde ich zu einem anderen Anbieter wechseln, vorher ein wenig recherchieren, welcher für Foren gut geeignet sein soll (also schön fixe Ladezeiten offeriert), unter 20 € pro Monat kostet und ich werde versuchen ohne Plesk oder Confixx auszukommen.


Ciao,
Sebi.

 

[Deleted member 4401]

Also ich bin mit den RootDS von S4Y immer ganz gut gefahren, aber leider sind die wohl nicht mehr im Angebot, ich weiss nicht inwiefern die mit den "normalen" vServern dort vergleichbar sind.
Habe auch längere Zeit Confixx benutzt und war heilfroh dass ich nach einer Neuinstallation gezwungen war nach einer Alternative zu suchen (Confixx gab es nicht mehr im Template (aber wollte eh weg davon), und Plesk mit den Domain-Beschränkungen ist für mich eine Frechheit)....seitdem benutze ich VHCS2 und bin mehr als zufrieden damit, auch was den RAM-Verbrauch angeht.

 

[Thunderbyte]

Mehr als mehr Speicher hilft nur noch mehr Speicher.

Nimm doch das nächstgrößere Paket mit mehr Speicher. Augenscheinlich läuft Dein großes Board mit den momentanen Ressourcen nicht. Da kannst Du Dich auf den Kopf stellen und mit den Füßen wackeln.

 

[noto]

MySQL nimmt sich bei dir viel zu viel RAM. Würde u.a. die read/sort Buffers wesentlich kleiner machen z.B. 32K

Lese mal hier im MySQL + Apache Performance Tuning Thread

512 MB RAM hast du zur Verfügung. Nun gillt es Apache und MySQL so zu konfigurieren, daß bei 100% Auslastung die 512 MB nicht überschritten werden. Was 100% sind gibst du selbst vor! z.B. 25 gleichzeitige Verbindungen = 25 MaxClients

Linux, Plesk, Dr. Web. Spammassassin, Bind ect. benötigen RAM. Man aktiviert also nur was man auch tatsächlich braucht. Der übrige RAM kann man dann Apache und MySQL zuweisen. Das macht man indem man die httpd Prozesse (MaxClients) und MySQL Buffers/Caches und max_connections ect. begrenzt.

MySQL kommt meist mit recht wenig RAM aus z.B. 40 MB. Zu Fehlermeldungen kommt es immer dann wenn man keine Limits setzt! Und dazu sind die Konfugurationsdateien schließlich da!

MOD EDIT: Link an die neue Forensoftware angepasst.

 

[aho]

Warum beschränkst Du eigentlich die max clients so sehr?

MaxRequestsperChild würde ich nicht auf 0 setzen!