Permanent Datenbankfehler

Nach dem Umzug auf unseren neuen Server, bekommen wir täglich mehrfach folgenden DB-Fehler:

Datenbankfehler in vBulletin :

mysql_connect() [<a href='function.mysql-connect'>function.mysql-connect</a>]: User v240222 already has more than 'max_user_connections' active connections
/www/htdocs/fanlager/includes/class_core.php on line 273

MySQL-Fehler :
Fehler-Nr. :
Datum : Friday, April 13th 2007 @ 11:16:35 AM
Skript : Stadionverbot f&#252;r Thor Steinar - Seite 2 - Fanlager
Referrer : Stadionverbot f&#252;r Thor Steinar - Fanlager
IP-Adresse : 194.95.75.194
Benutzername :
Klassenname : vB_Database

Nachfolgend unsere aktuellen MySQL-Einstellungen:

auto_increment_increment 1
auto_increment_offset 1
automatic_sp_privileges ON
back_log 50
basedir /
bdb_cache_size 8388600
bdb_home /var/lib/mysql/
bdb_log_buffer_size 524288
bdb_logdir
bdb_max_lock 10000
bdb_shared_data OFF
bdb_tmpdir /tmp/
binlog_cache_size 32768
bulk_insert_buffer_size 8388608
character_set_client latin1
character_set_connection latin1
character_set_database latin1
character_set_filesystem binary
character_set_results latin1
character_set_server latin1
character_set_system utf8
character_sets_dir /usr/share/mysql/charsets/
collation_connection latin1_swedish_ci
collation_database latin1_swedish_ci
collation_server latin1_swedish_ci
completion_type 0
concurrent_insert 1
connect_timeout 60
datadir /var/lib/mysql/
date_format &#37;Y-%m-%d
datetime_format %Y-%m-%d %H:%i:%s
default_week_format 0
delay_key_write ON
delayed_insert_limit 100
delayed_insert_timeout 300
delayed_queue_size 1000
div_precision_increment 4
engine_condition_pushdown OFF
expire_logs_days 0
flush OFF
flush_time 0
ft_boolean_syntax + -><()~*:""&|
ft_max_word_len 84
ft_min_word_len 4
ft_query_expansion_limit 20
ft_stopword_file (built-in)
group_concat_max_len 1024
have_archive YES
have_bdb YES
have_blackhole_engine YES
have_compress YES
have_crypt YES
have_csv YES
have_dynamic_loading YES
have_example_engine YES
have_federated_engine YES
have_geometry YES
have_innodb DISABLED
have_isam NO
have_merge_engine YES
have_ndbcluster DISABLED
have_openssl NO
have_query_cache YES
have_raid NO
have_rtree_keys YES
have_symlink YES
init_connect
init_file
init_slave
innodb_additional_mem_pool_size 1048576
innodb_autoextend_increment 8
innodb_buffer_pool_awe_mem_mb 0
innodb_buffer_pool_size 8388608
innodb_checksums ON
innodb_commit_concurrency 0
innodb_concurrency_tickets 500
innodb_data_file_path
innodb_data_home_dir
innodb_doublewrite ON
innodb_fast_shutdown 1
innodb_file_io_threads 4
innodb_file_per_table OFF
innodb_flush_log_at_trx_commit 1
innodb_flush_method
innodb_force_recovery 0
innodb_lock_wait_timeout 50
innodb_locks_unsafe_for_binlog OFF
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_max_dirty_pages_pct 90
innodb_max_purge_lag 0
innodb_mirrored_log_groups 1
innodb_open_files 300
innodb_rollback_on_timeout OFF
innodb_support_xa ON
innodb_sync_spin_loops 20
innodb_table_locks ON
innodb_thread_concurrency 8
innodb_thread_sleep_delay 10000
interactive_timeout 28800
join_buffer_size 131072
key_buffer_size 134217728
key_cache_age_threshold 300
key_cache_block_size 1024
key_cache_division_limit 100
language /usr/share/mysql/english/
large_files_support ON
large_page_size 0
large_pages OFF
lc_time_names en_US
license GPL
local_infile OFF
locked_in_memory OFF
log OFF
log_bin OFF
log_bin_trust_function_creators OFF
log_error
log_queries_not_using_indexes 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 2096128
max_binlog_cache_size 4294967295
max_binlog_size 1073741824
max_connect_errors 10
max_connections 1500
max_delayed_threads 20
max_error_count 64
max_heap_table_size 16777216
max_insert_delayed_threads 20
max_join_size 18446744073709551615
max_length_for_sort_data 1024
max_prepared_stmt_count 16382
max_relay_log_size 0
max_seeks_for_key 4294967295
max_sort_length 1024
max_sp_recursion_depth 0
max_tmp_tables 32
max_user_connections 100
max_write_lock_count 4294967295
multi_range_count 256
myisam_data_pointer_size 6
myisam_max_sort_file_size 2147483647
myisam_recover_options OFF
myisam_repair_threads 1
myisam_sort_buffer_size 16777216
myisam_stats_method nulls_unequal
ndb_autoincrement_prefetch_sz 32
ndb_force_send ON
ndb_use_exact_count ON
ndb_use_transactions ON
ndb_cache_check_time 0
net_buffer_length 31744
net_read_timeout 30
net_retry_count 10
net_write_timeout 60
new OFF
old_passwords ON
open_files_limit 7500
optimizer_prune_level 1
optimizer_search_depth 62
port 3306
preload_buffer_size 32768
profiling OFF
profiling_history_size 15
protocol_version 10
query_alloc_block_size 8192
query_cache_limit 1048576
query_cache_min_res_unit 4096
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 12578816
read_only OFF
read_rnd_buffer_size 10481664
relay_log_purge ON
relay_log_space_limit 0
rpl_recovery_rank 0
secure_auth OFF
server_id 0
skip_external_locking ON
skip_networking OFF
skip_show_database OFF
slave_compressed_protocol OFF
slave_load_tmpdir /tmp/
slave_net_timeout 3600
slave_skip_errors OFF
slave_transaction_retries 10
slow_launch_time 2
socket /var/lib/mysql/mysql.sock
sort_buffer_size 2097144
sql_big_selects ON
sql_mode
sql_notes ON
sql_warnings OFF
ssl_ca
ssl_capath
ssl_cert
ssl_cipher
ssl_key
storage_engine MyISAM
sync_binlog 0
sync_frm ON
system_time_zone CEST
table_cache 1024
table_lock_wait_timeout 50
table_type MyISAM
thread_cache_size 10
thread_stack 1048576
time_format %H:%i:%s
time_zone SYSTEM
timed_mutexes OFF
tmp_table_size 33554432
tmpdir /tmp/
transaction_alloc_block_size 8192
transaction_prealloc_size 4096
tx_isolation REPEATABLE-READ
updatable_views_with_limit YES
version 5.0.37-max-log
version_bdb Sleepycat Software: Berkeley DB 4.1.24: (March 2, 2007)
version_comment MySQL Community Edition - Experimental (GPL)
version_compile_machine i686
version_compile_os pc-linux-gnu
wait_timeout 190

Die max_user_connections sollten problemlos ausreichen. Ein h&#246;herer Wert macht hier nur noch sehr bedingt Sinn.


Verwendete Software:

- vBulletin 3.6.5
- vBSEO 3.0.0 RC8
- MySQL 5.0.37
- PHP 5.2.1
- Apache 2.2.4
- eAccelerator 0.9.5
- ZendOptimizer 3.2.2

Kann es sein, dass sich unsere vBSEO-Version nicht mit der aktuellsten MySQL-Version vertr&#228;gt? (dies ist zumindest die einzige Fehlerquelle, die mir plausibel erscheint)

Gruss,
Christian

Eine weitere Fehlermeldung:

Datenbankfehler in vBulletin :

mysql_connect() [<a href='function.mysql-connect'>function.mysql-connect</a>]: Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (11)
/www/htdocs/fanlager/includes/class_core.php on line 273

MySQL-Fehler :
Fehler-Nr. :
Datum : Friday, April 13th 2007 @ 11:15:40 AM
Skript : Stadionverbot f&#252;r Thor Steinar - Seite 2 - Fanlager
Referrer : Stadionverbot f&#252;r Thor Steinar - Fanlager
IP-Adresse : 194.95.75.194
Benutzername :
Klassenname : vB_Database

Wohl die Folge aus Fehlermeldung Nummer 1...

Setz doch mal max_user_connections 100 etwas höher, insgesamt erlaubst du max_connections 1500, aber nur 100 pro User (vBulletin-Forum).

Meinst Du denn dies w&#252;rde was bewirken, Thomas?

Mein Hoster hat mir folgendes geschrieben:

der Fehler "MySQL server has gone away" beruht auf einem zu kurzen Timeout das ich nun erh&#246;ht habe. Der Fehler "User v240222 already has more than 'max_user_connections' " beruht aber darauf das die h&#246;chstm&#246;gliche Anzahl der erlaubten mysql-Verbindungen erreicht wurde. Dieser Wert steht aktuell auf 100. Wir k&#246;nnen dies auch weiter erh&#246;hen, aber ich denke eher das diese Verbindungen m&#246;glicherweise durch einen Chat oder unsaubere Scripte verursacht werden, da 100 real laufende, und Daten beziehende Verbindungen den Server bereits in eine erhebliche &#220;berlast treiben w&#252;rden.

Gruss,
Christian

Schreibt ja sogar dein Hoster, dass es daran liegt.

Originally Posted by Thomas Hoehl

Schreibt ja sogar dein Hoster, dass es daran liegt.

Richtig. Jetzt stellt sich halt die Frage, woher dieses Problem rührt? Eine wirkliche Lösung ist die (weitere) Erhöhung der max_user_connections ja nicht wirklich.
Auf welchem Wert steht diese Variable denn bei Dir?

Gruss,
Christian

Ich habe keine 5er MySQL Version.
Und diesen Wert habe ich &#252;berhaupt nicht in meiner my.cnf drin, nur max_connections = 1500.

Aber es ist doch unlogisch max. 1500 freizugeben, aber einem User nur 100.
Hast du also drei vBulletins auf dem Server laufen, bedeutet das, dass jedes Forum nur 100 Connections machen darf.
Wenn sonst keine Datenbanken auf dem Server sind, k&#246;nnte man max.Connections dann auch auf 300 begrenzen.-

Auf dem Server l&#228;uft lediglich ein Forum - ergo auch nur eine DB.
Du w&#252;rdest also empfehlen, die max_user_connections weiter zu erh&#246;hen? Auf welchen Wert?

Gruss,
Christian

Also bei mir l&#228;uft es (im Augenblick ist Server off) problemlos unter mysql 5.0.23 kann daher nicht mit der mysql Version zusammenh&#228;ngen. (edit ach ich sehe gerade5.0.37)
PHP setze ichg 4.4.4 ein.

Allerdings bin ich "noch" nicht so gro&#223; wie Christian sein Fussi Forum.

Dann ist es ja noch unlogischer auf der einen Seite Global 1500 freizugeben, aber der einzigsten Datenbank dies dann nachtr&#228;glich gleich wieder auf 100 zu beschr&#228;nken, oder?

Da ich diesen Eintrag &#252;berhaupt nicht habe, w&#252;rde ich den komplett mit # auskommentieren.

max_user_connections, max_connections

das sollte in deinem fall einfach den gleichen wert haben! (auser im hostingfall da ist es eine nette spielerei)
100 ist genau garnix stelle in deinem fall einfach beides auf 1000 und gut is

mfg

habe bei muskelbody.info ebenfalls nur 25 bei max_user_connection stehen und ab und an die gleichen probleme.

Kann ich das getrost auch auf 1000 stellen ?

Hey,

Holger kennt sich gut aus. Du solltest es, wie er bereits sagt, auf einem Dedi ruhig auf 1000 stellen können

und ab und an die gleichen probleme.

wenn du das bei 25 nur ab und an hast, dann reicht ein wert von 250 locker bei dir!
wenn du alleine auf dem server bist dann kannst du auch beruhigt mehr eintragen!
wenn du persistente verbindungen erlaubst dann sollte der wert deutlisch grösser sein

mfg

also persistente verbindungen habe ich nicht.

all-inkl. der hoster meint, mehr wie 100 würde der server nicht vertragen.

also ich hab derzeit noch das problem, dass trotz wenigen usern online manchmal die beiträge bis zu 20 sek. benötigen um aufgebaut zu werden. davor ist immer eine graue seite (hintergrund) zu sehen.

kann sich das jemand erklären ?

wie sieht es bei euch (den etwas größeren foren) mit dem beitragscache von vb aus ?
habt ihr ihn angeschalten ? wenn ja, wieviel tage habt ihr drin ?
vBulletin Optimisation Tips - vBulletin Setup hier wird von 90 tagen als optimierung gesprochen.