Plötzlich Datenbankproblem(e) mit vBulletin

[Silmarillion]

Hallo,

ich zitiere einfach einmal mein Posting von vbulletin-germany.com - vielleicht kann mir ja hier jemand weiterhelfen, oder hat hierfür eine (plausible) Erklärung!?

Originallink (http://www.vbulletin-germany.com/forum/showthread.php?t=15685)


Exakt die gleichen Probleme (ist ja im Grunde genommen schon ein Phänomen) treten nun seit einigen Tagen auch bei mir plötzlich auf.
Das Board ist nun Hackfrei und verwendet Version 3.0.9!

Aktuell (letzte drei Tage) gibt es einmal täglich, zwischen 16:30 uhr und 17:30 uhr jeweils kurzzeitige Probleme mit der Datenbank. (5-8 Minuten)

Unmittelbar VOR diesen Problemen ist der Serverload, in der Regel, keineswegs auffallend...soll heißen zwischen 0,5-1,0!

Während den DB-Problemen ändern sich dann folgende Werte:

http: von 41 auf 78
mysql: von 12 auf 73

Unmittelbar nachdem die Verbindung wiederhergestellt werden kann, beträgt der Serverload um die 6-10...und fällt dann, innnerhalb der nächsten fünf Minuten wieder auf Normalwerte.
Wobei der kurzzeitig erhöhte Load, seltsamerweise, nicht in den Statistiken/Grafiken verzeichnet wird.

Hier die Fehlermeldung:


Datenbankfehler in vBulletin :

Link-ID == false, connect failed
mysql error:

mysql error number: 0

Am Server selbst kann es eigentlich nicht liegen. Daher kommen eigentlich nur noch zwei mögliche Fehlerquellen in Frage:

- MySql-Datenbank
- vBulletin

Da es auf vbulletin.com fast hunderte User gibt, die exakt die gleichen Probleme gemeldet haben, denke ich mittlerweile wirklich schon, dass vBulletin an diesen Problemen nicht ganz unschuldig ist.

Hier einmal ein paar Daten:

Managed-Server (AMD Athlon 2000+/1GB RAM)
MySqL: 4.0.25
Apache: 2.0.54
PHP: 4.4.0
PHP-Beschleuniger: Zend Optimizer
Rewrite-Engine: vBSEO (nutzt Zend Optimizer)

Folgende Einstellungen in der my.cnf:


wait_timeout = 28800
connect_timeout = 15
max_allowed_packet = 16M
max_connect_errors = 20
max_connections = 500
query_cache_limit = 1M
query_cache_size = 16M
query_cache_type = 1

Woran könnte es noch liegen? Bin für Ratschläge wirklich dankbar!

mfg

[xanlosch]

Könnte es sein, dass um diese Zeit bzw. in diesen Zeitraum irgendwelche Skripte via Cronjob laufen ? Oder irgendwelche Backups in dieser Zeit ausgeführt werden ?

[Silmarillion]

Hallo xanlosch,

sehr unwahrscheinlich. Ich habe keine eingerichtet und unser Hoster verneint dies ebenfalls.
(Vermutung liegt/lag natürlich nahe)

mfg

[xanlosch]

Dann würd ich mich mal vor der Zeitspanne bis nach der Zeitspanne einloggen und via top sehen, was da die Prozesslast hervorruft. Wenn du weißt, welcher Prozess das ist, kannst du viel besser vorgehen, sonst wirds nur ein wildes raten.

[Silmarillion]

Ich habe den Server bzw. die Fehlermeldungen in den letzten Tagen einmal genauer beobachtet. Hier das Ergebnis:


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


Jeweils für 5-8 Minuten Datenbankprobleme.

--> Hier einmal die Settings (Mysql 4.0.25):



Hilfe MySQL Variablen
Variable_name Value
back_log 50
basedir /
bdb_cache_size 8388600
bdb_log_buffer_size 65536
bdb_home /var/lib/mysql/
bdb_max_lock 10000
bdb_logdir
bdb_shared_data OFF
bdb_tmpdir /tmp/
bdb_version Sleepycat Software: Berkeley DB 3.2.9a: (June 29, 2005)
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 15
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 YES
have_crypt YES
have_innodb YES
have_isam YES
have_raid YES
have_symlink YES
have_openssl NO
have_query_cache YES
init_file
innodb_additional_mem_pool_size 1048576
innodb_autoextend_increment 8
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
innodb_max_purge_lag 0
innodb_table_locks ON
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 1
long_query_time 5
low_priority_updates OFF
lower_case_file_system OFF
lower_case_table_names 0
max_allowed_packet 16776192
max_binlog_cache_size 4294967295
max_binlog_size 1073741824
max_connections 500
max_connect_errors 20
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 60
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 16777216
net_buffer_length 31744
net_read_timeout 30
net_retry_count 10
net_write_timeout 60
new OFF
open_files_limit 2510
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_cache_wlock_invalidate OFF
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 128
table_type MYISAM
thread_cache_size 0
thread_stack 1048576
tx_isolation REPEATABLE-READ
timezone CEST
tmp_table_size 33554432
tmpdir /tmp/
transaction_alloc_block_size 8192
transaction_prealloc_size 4096
version 4.0.25-Max-log
version_comment Official MySQL RPM
version_compile_os pc-linux-gnu
wait_timeout 28800


Vielleicht kann ja der ein-oder andere etwas damit anfangen und hat ein paar Tipps/Lösungsvorschläge parat. Würde mich freuen.

mfg

[xanlosch]

Welche Prozesse zu diesen Spitzen-Zeiten (von der Last her) liefen, hast du nicht noch, oder ?

[Silmarillion]

Nein, leider nicht. Ist für mich auch schwer zu überprüfen. (kein Confixx und keine Root-Rechte)

Anzumerken bleibt noch, dass der Server ansonsten wirklich schnell und stabil läuft. Zu besagten Zeiten gibt es dann, wie aus dem Nichts heraus, halt die besagten, kurzzeitigen Probleme.

mfg

[xanlosch]

Dann muss ich passen - bin ich froh, dass ich zu meinen Webspace wenigstens nen normalen SSH-Zugang hab ;)

[Silmarillion]

Mich würde halt auch mal interessieren, ob die aktuellen Einstellung (Mysql) vielleicht verbesserungswürdig wären? Vielleicht könnte sich ja mal einer der Experten hierzu äußern. :)

Würde vielleicht ein Umstieg auf 4.1 etwas bewirken?

mfg