Server/Datenbank optimieren - bitte um Expertemeinungen/-tipps

[Silmarillion]

Hallo,

wir sind vor wenigen Tagen auf einen größeren Server gewechselt, da der alte - welch Wunder - doch etwas überfordert war.
Es handelt(e) sich hierbei jeweils um einen MS.

Hier einmal das alte System:

AMD Duron 1300
512 MB RAM
20 GB FP + 80 GB Zusatzplatte

Und hier das aktuelle/neue System:

AMD Athlon XP 2000
1024 MB RAM
40 GB FP + 80 GB Zusatzplatte

Eigentlich gingen wir davon aus, dass durch den Umzug die Probleme (Load) behoben sein müssten/sollten.
Gestern Abend erreichte der Server jedoch erneut Lastspitzen von bis zu 8! (auch wenn Sonntag Abends, aufgrund eines Online-Spieles in einem kurzen Zeitraum deutlich mehr Postings erfolgen, dürfte dies eigentlich nicht sein!)
Das seltsame an dieser Tatsache ist, dass der Load teilweise extrem schwankt.
Mal bummelt der Server bei 0,2 vor sich hin, um wenige Minuten später auf Werte um die 2-3 hochzuschießen. Und das bei gleichbleibender Frequentierung/Beanspruchung.
Ein PHP-Bechleuniger (Zend) ist bereits installiert.
In unserem Forum befinden nie mehr als 60 aktive User, also Mitglieder, gleichzeitig online. Und dafür sollte der Server doch allemal reichen, sprich einen wesentlich geringeren Serverload ausweisen, oder?

Gut - der Server läuft erst seit 3 Tagen...vielleicht muss er sich ja noch warmlaufen.;)
Unser Hoster hat heute Nacht noch ein paar Einstellungen zur Optimierung vorgenommen. Da ich leider keinen Zugriff auf die relevanten Dateien (bspw. my.cnf) habe, kann ich hier selber nicht Hand anlegen. Mittels ACP kann ich mir jedoch die MYSQLVariablen anzeigen lassen.

Werft doch mal bitte einen Blick darauf - sofern Ihr davon etwas versteht;) - und teilt mir mal bitte mit, ob da noch was im Argen liegt bzw. verbessert/optimiert werden könnte. Besten Dank im voraus. :-)

Hilfe MySQL Variablen
Variable_name Value
back_log 50
basedir /
binlog_cache_size 32768
bulk_insert_buffer_size 8388608
character_set latin1
character_sets latin1 big5 czech euc_kr gb2312 gbk latin1_de sjis tis620 ujis dec8 dos german1 hp8 koi8_ru latin2 swe7 usa7 cp1251 danish hebrew win1251 estonia hungarian koi8_ukr win1251ukr greek win1250 croat cp1257 latin5
concurrent_insert ON
connect_timeout 5
convert_character_set
datadir /var/lib/mysql/
default_week_format 0
delay_key_write ON
delayed_insert_limit 100
delayed_insert_timeout 300
delayed_queue_size 1000
flush OFF
flush_time 0
ft_boolean_syntax + -><()~*:""&|
ft_min_word_len 4
ft_max_word_len 254
ft_max_word_len_for_sort 20
ft_stopword_file (built-in)
have_bdb NO
have_crypt YES
have_innodb YES
have_isam YES
have_raid NO
have_symlink YES
have_openssl NO
have_query_cache YES
init_file
innodb_additional_mem_pool_size 1048576
innodb_buffer_pool_size 8388608
innodb_data_file_path ibdata1:10M:autoextend
innodb_data_home_dir
innodb_file_io_threads 4
innodb_force_recovery 0
innodb_thread_concurrency 8
innodb_flush_log_at_trx_commit 1
innodb_fast_shutdown ON
innodb_flush_method
innodb_lock_wait_timeout 50
innodb_log_arch_dir ./
innodb_log_archive OFF
innodb_log_buffer_size 1048576
innodb_log_file_size 5242880
innodb_log_files_in_group 2
innodb_log_group_home_dir ./
innodb_mirrored_log_groups 1
innodb_max_dirty_pages_pct 90
interactive_timeout 28800
join_buffer_size 5238784
key_buffer_size 33554432
language /usr/share/mysql/english/
large_files_support ON
license GPL
local_infile ON
locked_in_memory OFF
log OFF
log_update OFF
log_bin OFF
log_slave_updates OFF
log_slow_queries ON
log_warnings ON
long_query_time 5
low_priority_updates OFF
lower_case_file_system OFF
lower_case_table_names 0
max_allowed_packet 4193280
max_binlog_cache_size 4294967295
max_binlog_size 1073741824
max_connections 100
max_connect_errors 10
max_delayed_threads 20
max_insert_delayed_threads 20
max_heap_table_size 16777216
max_join_size 4294967295
max_relay_log_size 0
max_seeks_for_key 4294967295
max_sort_length 1024
max_user_connections 35
max_tmp_tables 32
max_write_lock_count 4294967295
myisam_max_extra_sort_file_size 268435456
myisam_max_sort_file_size 2147483647
myisam_repair_threads 1
myisam_recover_options OFF
myisam_sort_buffer_size 33554432
net_buffer_length 31744
net_read_timeout 30
net_retry_count 10
net_write_timeout 60
new OFF
open_files_limit 1024
pid_file /var/lib/mysql/xxxx.pid
log_error
port 3007
protocol_version 10
query_alloc_block_size 8192
query_cache_limit 1048576
query_cache_size 33554432
query_cache_type ON
query_prealloc_size 8192
range_alloc_block_size 2048
read_buffer_size 1044480
read_only OFF
read_rnd_buffer_size 262144
rpl_recovery_rank 0
server_id 0
slave_net_timeout 3600
skip_external_locking ON
skip_networking OFF
skip_show_database OFF
slow_launch_time 2
socket /var/lib/mysql/mysql.sock
sort_buffer_size 20971512
sql_mode 0
table_cache 256
table_type MYISAM
thread_cache_size 0
thread_stack 126976
tx_isolation REPEATABLE-READ
timezone CEST
tmp_table_size 33554432
tmpdir /tmp/
transaction_alloc_block_size 8192
transaction_prealloc_size 4096
version 4.0.20-standard-log
version_comment Official MySQL RPM
version_compile_os pc-linux
wait_timeout 30


mfg

[Silmarillion]

Nachtrag: ein weiteres Phänomen/Problem, welches mir persönlich absolut unerklärlich ist, ist die Tatsache, dass eigentlich sämtliche Seiten, in der Regel, schnell und stabil laden - AUSGENOMMEN die Startseite. Dies macht sich besonders bemerkbar, wenn mehrere Mitglieder (ab ca. 20-25) online sind.
Befinde ich mich also in Forum X oder in einem Thread X und wechsele anschließend auf eine x-beliebige andere Seite, lädt diese deutlich schneller, als wenn ich von einer Seite X direkt auf die Startseite zurückklicke!

Wie ist so etwas möglich?:confused:

mfg

[Mystics]

Hast du Hacks in der index.php / in den phpinclude Templates eingebaut?

Wegen der Server-Optimierung, solltest du hier nachfragen:
http://www.vbulletin.com/forum/forumdisplay.php?f=14

Lies aber vorher das:
http://www.vbulletin.com/forum/showthread.php?t=70117

[Silmarillion]

Hallo Mystics,

die einzigen Modifikationen auf der Startseite sind der "Top-X-Threads"- und der Tagesstatistik-Hack. (letzten habe ich im Standardstyle vorerst einmal rausgenommen)

Allerdings funktionierte dies, trotz und mit diesen Hacks, noch bis vor wenigen Wochen einwandfrei.

Meine Vermutung war zuerst, dass es mit der Nutzung von vBSEO (RewriteEngine) zusammenhängen könnte.
Dagegen spricht allerdings, dass bei deaktiviertem Mod-Rewrite keine Besserung (Ladezeit-Startseite) eintritt, und das Programm zudem bei anderen Foren ohne Probleme funktioniert.

Hast Du vielleicht noch eine Idee, wie dieses Phänomen zu erklären wäre? (gerade weil alle anderen Seiten schnell und stabil laden)

Würde hier vielleicht ein reparieren/optimieren diverser Tabellen etwas bringen? (glaube ich persönlich allerdings nicht)

mfg

[Mystics]

Da bin ich leider auch überfragt.

Ein Optimieren aller Tabellen schadet nie, wird aber wahrscheinlich nicht weiterhelfen.

[Znaper]

Hallo Silmarillion,

falls ich mir das ganze mal näher anschauen soll kontaktiere mich doch einfach per ICQ.


mfg Znaper

[Silmarillion]

Hallo Znaper,

erst einmal Danke für Deine Hilfsbereitschaft.
Momentan muss ich wohl nicht auf Dein Angebot zurückkommen.
Der Fehler an sich scheint gefunden:

--> bei uns laufen einige Queries bis zu 22 Sekunden(!), was zu einem Problem mit dem Timeout führte. Daraufhin wurde der Timeout nun erst einmal deaktiviert.

Das Problem mit den Queries ist freilich dadurch nicht beseitigt. Würde mich interessieren, woher dieses resultiert! Wie kann ich dies denn am besten überprüfen?

Folgende Hacks/Modifikationen habe ich installiert:

- Top X Threads (http://www.vbulletin-germany.com/forum/showthread.php?t=13437)

- User-Styleanzeige Postbit (http://www.vbulletin.org/forum/showthread.php?t=63068&highlight=style)

- Hitanzeige (http://www.vbulletin-germany.com/forum/showthread.php?t=11403&highlight=Uhrzeit)

- Datum und Uhrzeit Threaderstellung (forumsdisplay) (http://www.vbulletin.org/forum/showthread.php?t=63791&highlight=start%2A)

- Leserechte Hack (http://www.vbulletin.org/forum/showthread.php?threadid=60178)

Könnte das Query-Problem vielleicht mit einem dieser bzw. diesen Hacks/Mods zusammenhängen?

Eine andere Erklärung habe ich derzeit eigentlich nicht.

mfg

[Christian]

Ich vermute (wenn dann) es liegt an diesem: http://www.vbulletin-germany.com/forum/showthread.php?t=11403&highlight=Uhrzeit

[piepo]

OffTopic:

Wo hostest du denn jetzt überhaupt?

[Silmarillion]

@ Christian: ist auch meine Vermutung. Habe die Anzeige mal ausgebaut. Vielleicht irre ich ja, aber ich meine die Startseite lädt schon schneller. ;-)

@ piepo: aufgrund des guten Supportes und eines fairen Angebotes haben wir uns letzten Endes doch entschlossen all-inkl.com die Treue zu halten.

mfg

[Silmarillion]

NACHTRAG:

Einen wichtigen Hack habe ich noch vergessen:

- Leserechte Hack (http://www.vbulletin.org/forum/showthread.php?threadid=60178)

Der ist schon recht umfangreich. Aber ob es wirklich damit zusammenhängen könnte bzw. ob dieser die genannten Query-Probleme verursacht?

Hier einmal die Änderungen, welche für diesen Hack nötig sind/waren:

http://www.fanlager-community.de/Leserechte/ALLOW_TO_READ_TITLES_NOT_CONTENT.htm

mfg

[ezztro]

Hallo Znaper,

erst einmal Danke für Deine Hilfsbereitschaft.
Momentan muss ich wohl nicht auf Dein Angebot zurückkommen.
Der Fehler an sich scheint gefunden:

--> bei uns laufen einige Queries bis zu 22 Sekunden(!), was zu einem Problem mit dem Timeout führte. Daraufhin wurde der Timeout nun erst einmal deaktiviert.



Nutzt Dir nicht viel wenn der Grund fuer die 22 Sek. nicht gefunden wird. Das kann ein "Teufelskreis" sein, denn die 22 Sek. koennten auch daran liegen, dass die CPU am Anschlag laeuft usw.

Mal davon abgesehen, dass so ein AMD XP keine Server CPU ist und 1GB RAM auch eher fuer die Fuesse sind.

Hatte schon grottenlangsame Server, da war das Schreiben auf die HDs das Problem. Die Sessions wurden gespeicher auf der HD und der Schreibprozess war viel zu langsam usw.

Um zu wissen ob es an den Hacks liegt = plain VB installieren ohne Hacks. Was anderes bleibt da nicht uebrig. Die MySQL DB Zugriffe mal genau im Auge behalten.

[Silmarillion]

Hallo ezztro,

das Board wurde inzwischen auf die 3.0.9 umgestellt und läuft jetzt ohne Hacks.
Dennoch taucht, in der Regel, 2x am Tag (jeweils 5-8 Minuten) der genannte Fehler auf. Hier einmal die Bilanz der letzten Tage:

11.09. (16:47) ~ 11,0 Serverload
12.09. (16:56)
13.09. (17:14)
13.09. (22:17)
14.09. (10:38) ~ 14,0 Serverload
14.09. (17:28)
15.09. (10:25) ~ 20,0 Serverload
15.09. (19:30) ~ 5,5 Serverload
16.09. (12:30) ~ 3.0 Serverload
16.09. (19:39) ~ 9,0 Serverload

Unmittelbar VOR diesen Problemen ist der Serverload, in der Regel, keineswegs auffallend...soll heißen zwischen 0,2-1,0! Auch mit den gleichzeitig aktiven Besuchern kann es nicht zusammenhängen, da dieser Fehler sowohl bei vielen, als auch bei wenigen Online-Usern auftritt.
Ansonsten läuft der Server wirklich einwandfrei, soll heißen schnell und stabil.

Das Problem ist allerdings nicht neu, geschweige denn unbekannt. Sowohl hier, als auch auf vbulletin.com wurde exakt der gleiche Fehler schon unzählige Male gepostet.
Bislang gibt es hierfür noch nicht wirklich eine logische Erklärung...

mfg

[Holger]

Bislang gibt es hierfür noch nicht wirklich eine logische Erklärung das selbe resultat muss ja auch nicht zwingend die gleich ursache haben
wenn man seinen server aber mal monitort sind solche probleme in der regel recht schnell zu beseitigen

mfg

[Odysseus]

Poste mal deine my.cnf Konfigutarionsdatei und gib uns einen Link zu phpinfo.

Du schreibst, dass du zwei Festplatten hast. Wie sind die partitioniert?
Es wäre z.B. eine gute Idee, wenn auf der zweiten Festplatte lediglich das Storage Verzeichnis von MySQL gemountet wird ( /var/lib/mysql ) -- und sonst nichts anderes.

So habe ich das bei mir realisiert, und das ist extrem hilfreich!