Großes Forum mit Performanceproblemen

[ermin]

Das Forum läuft bei einer Anzahl von ca. 50 aktiven Benutzern stabil und schnell. Allerdings kommt es zu extremen Performance-Einbußen ab ca. 100 aktiven Benutzern.

Das Forum wurde vor kurzem von einem einzigen Server mit weniger Prozessor-Power aber 16GB Arbeitsspeicher auf die unten beschriebenen Systeme migriert. Bisher lief das Forum allerdings bei gleichen Zugriffszahlen erheblich schneller. Kann es sein, dass die Probleme nur an zu wenig Arbeitsspeicher des Datenbankservers liegen?

Über Hilfestellungen und Tipps von erfahrenen vBulletin Administratoren würde ich mich sehr freuen.

Seit dem Umzug werden übrigens auch die Hits nicht mehr gezählt. In den Logfiles tauchen allerdings keine relevanten PHP-Fehlermeldungen auf.

Angaben zum Forum

Themen: ca. 26.500
Beiträge: ca. 1.150.000
Benutzer: ca. 22.500
Aktive Benutzer: ca. 1.200

Durchschnittliche Zugriffzahlen pro Tag

Besucher: 1800
Besuche: 3600
Seitenzugriffe: 46.000

Hardware

Webserver
DELL PE 2950 III
2 x IX E5405 Quad Core
4096 MB FB RAM
2x146 GB SAS HDD Raid-1

Datenbankserver
DELL PE 2950 III
2 x IX E5405 Quad Core
4096 MB FB RAM
2x146 GB SAS HDD Raid-1

Auf beiden Systemen kommt das Betriebssystem Red Hat EL 4 in aktuellster Version zum Einsatz. Die beiden Server sind über einen dedizierten Switch angebunden und mit 200 Mbits ans Internet angebunden.

Webserver-Konfiguration

Apache 2.0.52 mit folgenden Einstellungen:

Timeout 30
KeepAlive On
MaxKeepAliveRequests 150
KeepAliveTimeout 1
HostnameLookups Off

<IfModule prefork.c>
StartServers 10
MinSpareServers 10
MaxSpareServers 15
ServerLimit 256
MaxClients 256
MaxRequestsPerChild 1000
</IfModule>

<ifmodule mod_expires.c>
<filesmatch "\.(jpg|gif|png|css|js|swf)$">
ExpiresActive on
ExpiresDefault "access plus 1 month"
</filesmatch>
</ifmodule>

Header unset ETag
FileETag None

AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE image/svg+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/atom_xml
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE application/x-httpd-php
AddOutputFilterByType DEFLATE text/html

PHP 5.2.5 u.a. mit folgenden Modulen:

eAccelerator 0.9.5.2
eaccelerator.shm_size="64"
eaccelerator.enable="1"
eaccelerator.optimizer="1"
eaccelerator.check_mtime="1"
eaccelerator.debug="0"
eaccelerator.filter=""
eaccelerator.shm_max="0"
eaccelerator.shm_ttl="0"
eaccelerator.shm_prune_period="0"
eaccelerator.shm_only="0"
eaccelerator.compress="1"
eaccelerator.compress_level="9"

ZendOptimizer 3.3.0a
Optimization Pass 1 = enabled
Optimization Pass 2 = enabled
Optimization Pass 3 = enabled
Optimization Pass 4 = enabled
Optimization Pass 9 = enabled
Obfuscation level = 3

vBulletin 3.6.8 Patch Level 2 mit folgenden Add-ons:

AdminCP Top 10 Statistic 1.00
Custom Queries 1.02
EZ Bounce Management 1.8
Inferno Warning System 1.3
IpInfo 1.3
MarioK - Boardregeln 2.00
MarioK - Impressum 2.00
Template Modification System 1.0.0
vbgooglemap Member Edition by StonyArc 2.5.1
vBI-Gallery 1.23
vBSEO 3.0.0
vBSEO :: Sitemap Generator 2.0

Datenbankserver-Konfiguration

mySQL 5.0.45-community mit folgenden Einstellungen:

[mysqld]
safe-show-database
back_log = 50
skip-innodb
max_connections = 800
key_buffer_size = 16M
myisam_sort_buffer_size = 128M
join_buffer_size = 2M
read_buffer_size = 2M
sort_buffer_size = 4M
table_cache = 6000
thread_cache_size = 768
wait_timeout = 15
connect_timeout = 10
tmp_table_size = 64M
max_heap_table_size = 64M
max_allowed_packet = 64M
net_buffer_length = 16384
max_connect_errors = 10
thread_concurrency = 16
concurrent_insert = 2
table_lock_wait_timeout = 30
read_rnd_buffer_size = 2M
bulk_insert_buffer_size = 8M
query_cache_limit = 6M
query_cache_size = 288M
query_cache_type = 1
query_prealloc_size = 262144
query_alloc_block_size = 65536
transaction_alloc_block_size = 8192
transaction_prealloc_size = 4096
default-storage-engine = MyISAM
max_write_lock_count = 16

[mysqld_safe]
nice = -10
open_files_limit = 8192

[mysqldump]
quick
max_allowed_packet = 16M

[myisamchk]
key_buffer = 64M
sort_buffer = 64M
read_buffer = 16M
write_buffer = 16M

Top des Webservers

top - 21:31:59 up 7 days, 6:36, 2 users, load average: 0.23, 0.22, 0.24
Tasks: 124 total, 1 running, 123 sleeping, 0 stopped, 0 zombie
Cpu(s): 3.4% us, 0.2% sy, 0.0% ni, 96.3% id, 0.0% wa, 0.0% hi, 0.0% si
Mem: 4036928k total, 3539520k used, 497408k free, 177056k buffers
Swap: 2040244k total, 0k used, 2040244k free, 2915856k cached

PID USER PR NI %CPU TIME+ %MEM VIRT RES SHR S COMMAND
31642 apache 15 0 5 0:00.65 0.4 219m 15m 9280 S httpd
31681 apache 15 0 5 0:00.52 0.3 219m 13m 7340 S httpd
31634 apache 16 0 5 0:00.80 0.3 219m 13m 7508 S httpd
31661 apache 16 0 4 0:00.59 0.3 219m 12m 6904 S httpd
31632 apache 15 0 2 0:00.53 0.3 219m 13m 7684 S httpd
31645 apache 15 0 2 0:00.68 0.3 219m 13m 7656 S httpd
31620 apache 16 0 1 0:00.81 0.5 224m 17m 7836 S httpd
31628 apache 16 0 1 0:00.79 0.6 225m 22m 11m S httpd
31664 apache 16 0 1 0:00.27 0.4 224m 17m 7356 S httpd
31688 apache 16 0 1 0:00.18 0.4 224m 15m 5916 S httpd
31689 apache 16 0 1 0:00.25 0.4 224m 15m 5928 S httpd
31627 apache 15 0 0 0:00.85 0.3 219m 13m 7844 S httpd
31650 apache 15 0 0 0:00.62 0.3 219m 13m 7488 S httpd

Top des Datenbankservers

top - 21:32:53 up 7 days, 6:33, 1 user, load average: 10.01, 11.34, 10.82
Tasks: 99 total, 2 running, 97 sleeping, 0 stopped, 0 zombie
Cpu(s): 40.2% us, 58.6% sy, 0.0% ni, 1.1% id, 0.0% wa, 0.0% hi, 0.0% si
Mem: 4036928k total, 3935656k used, 101272k free, 337128k buffers
Swap: 2040244k total, 208k used, 2040036k free, 252772k cached

PID USER PR NI %CPU TIME+ %MEM VIRT RES SHR S COMMAND
3623 mysql 5 -10 791 22:20.74 1.3 390m 51m 4448 S mysqld

[Odysseus]

Mir ist schleierhaft, wie du mit dieser Hardware solche Probleme haben kannst... ich betreibe ein Forum mit doppelt so viel Aktivität auf einem einzelnen Server mit weniger starker Hardware als nur einer von deinen beiden.

So richtig eine Ahnung, woran deine Probleme legen könnten, habe ich aber leider auch nicht. An deiner mysql conf fällt mir folgendes auf:
1) Den Parameter back_log kenne ich nicht
2) Du hast extrem kurze timeouts eingestellt (10-15 Sek?)
3) Der table_cache scheint mir viel zu groß - ich kann mich da aber auch irren
4) Du hast keinen wert für max_connections gesetzt

[ermin]

Vielen Dank für das schnelle Feedback :)

1) Den Parameter back_log kenne ich nicht

Diese Option legt die Größe der queue für eingehende TCP/IP connections fest. Der Wert 50 entspricht allerdings der Standardeinstellung des Servers und dürfte daher zumindest keine negativen Auswirkungen haben.

2) Du hast extrem kurze timeouts eingestellt (10-15 Sek?)

Diese Einstellung stammt aus der folgenden Konfigurationsempfehlung mit ähnlicher Hardware: http://www.vbulletin.com/forum/showthread.php?t=265149

Die Einstellungen habe ich wie folgt geändert:
wait_timeout = 60
connect_timeout = 30

3) Der table_cache scheint mir viel zu groß - ich kann mich da aber auch irren

Für diese Einstellung gilt das gleiche wie oben. Diese Einstellung habe ich wie folgt geändert:
table_cache = 600

4) Du hast keinen wert für max_connections gesetzt

Diese Einstellung ist mir vorhin beim entfernen der Kommentare abhanden gekommen. Meinen Beitrag habe ich entsprechend korrigiert.
Die aktuelle Einstellung ist mit 800 Connections angegeben.

[Hoffi]

Du hast ein Massives mySQL Problem. Und wenn du das im Griff hast, reicht ein Server. Der Server-Load sollte max. der Anzahl der CPU-Kerne sein. Bei Dir max. 8. (Schon krass... soviel Last kann das Forum gar nicht erzeigen... was hast du da alles drauf?)

Ich hab hier mal ein paar nützliche Links gepostes. Ist im allgemeinen ein interessantes Thema geworden: http://www.vbulletin-germany.org/showpost.php?p=8861&postcount=18

Das Thema sollte für Dich auch von Interesse sein: http://www.vbulletin-germany.com/forum/showthread.php?s=&threadid=4183

[heugabel]

Ich hab einen root mit fast gleichen spezifikationen und der rennt wie katze...

hier ein paar auszüge meiner config, vielleicht hilfts...


MaxKeepAliveRequests 10


StartServers 5
MinSpareServers 5
MaxSpareServers 10
ServerLimit 150
MaxClients 150
MaxRequestsPerChild 0


key_buffer = 16M
max_allowed_packet = 16M
thread_stack = 128K
thread_cache_size = 8
#max_connections = 1000
table_cache = 2800
#thread_concurrency = 10


query_cache_limit = 2M
query_cache_size = 32M

max_allowed_packet = 16M

key_buffer = 16M

[Andreas]

Bei der Hardware und gerade mal 100 Usern müsste das Forum abgehen wie Schmidts Katze.

Hast Du gzip in vBulletin aktiviert?
Falls ja deaktivieren (macht Apache ja schon).

eaccelerator.compress_level runter auf 1 - alles andere kostet nur unnötig Resourcen (wobei das eh nur für Content genutzt wird).

Die Googlemap hat ein heftiges Query-Problem - für jeden einzelenen angezeigten Beitrag wird eine Abfrage durchgeführt.
-> Fixen oder das Plugin zur Anzeige des Links im Postbit deaktivieren.

Die anderen Add-ons (außer vBSEO welches bekanntermaßen Resourcen verspeist) scheinen mir recht harmlos,vBIGallery wäre evtl. noch einen Blick wert.

[TheCatcher]

Hast Du gzip in vBulletin aktiviert?
Falls ja deaktivieren (macht Apache ja schon).

Sollte das jeder machen der sein Baord unter Apache laufen hat?

[Onur]

vbseo mal auf Version 3.1 updaten, damit sollte dein eAccelerator besser unterstützt werden

[Andreas]

Sollte das jeder machen der sein Baord unter Apache laufen hat?
Theoretisch dürfte das Apache-Modul einen Tick schneller sein, einen großen Unterschied macht es aber vmtl. nicht.

Wichtig ist lediglich dass Du gzip in vBulletin ausgeschaltet hast wenn ein Apache-Modul das bereits macht.

[ermin]

Vielen dank Hoffi für die Links. Den Thread des ersten Links habe ich bereits vor meinem Posting verfolgt und auch viele der Vorschläge berücksichtigt. Das tuning-primer-script werde ich heute noch mal laufen lassen und die Ergebnisse posten sofern es Sinn macht.

Die Lizenzinhaber-Erkennung habe ich nun auch erfolgreich durchlaufen...

[ermin]

Das gzip in vBulletin ist deaktiviert. So weit ich das gelesen habe, dürfte der Apache das auch ein wenig schneller hin bekommen als die Forenskripte.

Das eaccelerator.compress_level habe ich nun runter auf 1 gesetzt. Leider scheint das aber auch nur ein Tropen auf den heißen Stein zu sein.

[Andreas]

Dein Problem ist die Datenbank, nicht der Webserver.
Hast Du mal alle Plugins incl. vBSEO (.htaccess nicht vergessen!) deaktiviert?

[ermin]

Das vbSEO habe ich grade mal deaktiviert und auch die .htaccess umbenannt. Bei einigen Zugriffen ist es zwar schneller geworden, aber eine Offenbarung ist das auf jeden Fall nicht.

[Andreas]

Alle anderen Plugins auch?

[ermin]

Um auch noch die Frage von Hoffi zu beantworten: Auf dem Server läuft sonst nichts. Es liegt zwar noch eine andere Webanwendung auf dem Server, welche aber zurzeit nur von Betatestern genutzt wird. Man kann also davon ausgehen, dass die Rechenpower nur dem Forum zur Verfügung steht.

[Onur]

was sagt dein Debugmodus denn wieviele Querys bzw ungecachte Templates usw Du am laufen hast?

ist der Datastore auf File oder noch in der DB?

[ermin]

Nun habe ich mal alle PlugIns deaktiviert und dann nach und nach wieder eingeschaltet. Es ist mir noch ein wenig schleierhaft, aber das Plugin vBI-Gallery 1.23 hat dafür gesorgt dass das Forum so langsam war.

Nun rennt das Forum! Und wie ...

Unglaublich einfache Lösung für unserer Problem. Vielen Dank an alle die sich mit Gedanken gemacht haben.

[Andreas]

Siehe Beitrag Nr. 6, da habe ich schon auf vBiGallery hingewiesen ;)
Vmtl. macht das Teil sehr umfangreiche Tabellenscans ohne Indexe.

[ermin]

Du hattest natürlich vollkommen recht mit den Plugins. Aber ich hätte auch niemals gedacht, dass die Probleme von nur einem PlugIn kommen könnten.

Leider besteht das Problem mit den nicht gezählten Hits immer noch. Vielleicht hat auch dazu noch jemand einen guten Tipp? Am Caching des eAccelerators scheint es nicht liegen.

[Andreas]

Tja, Plugins sind trickreiche kleine Biester ;)

Im Worst Case reichen wenige Zeilen Code aus und die kriegst eine Quad-Core Maschine zum Stillstand.
(Oder auch nur eine einzige DB-Abfrage und eine Dual-Opteron Maschine ist 1h beschäftigt ...*pfeif*)

Hits werden nicht gezählt ... was für Hits, Threadviews?

Falls ja überprüfe mal ob der zuständige Cronjob funktioniert (falls diese nicht nicht live aktualisiert werden).

[ermin]

Der Cronjob für die Zählung der Hits konnte nicht ausgeführt werden, da der Datenbankuser keine Berechtigung hatte die notwendigen temporären Tabellen zu erstellen.

Danke für den Tipp und vor allem für den Begriff "Threadviews". Wenn man danach sucht wird man hier im Forum auch sehr schnell fündig.