zuerst die Config:
Code: Select all
skip-locking
skip_name_resolve
skip_show_database
skip_external_locking
bind-address=127.0.0.1
key_buffer_size = 364M
max_allowed_packet = 16M
max_heap_table_size = 64M
tmp_table_size= 64M
table_cache = 1024
query_cache_type = 1
query_cache_size = 64M
query_cache_limit = 16M
max_connections = 150
innodb_thread_concurrency = 8
innodb_buffer_pool_size = 512M
innodb_additional_mem_pool_size = 16M
innodb_data_file_path = ibdata1:1000M;ibdata2:10M:autoextend
innodb_flush_method = O_DIRECT
innodb_log_file_size = 100M
innodb_log_buffer_size = 8M
innodb_log_files_in_group = 2
innodb_flush_log_at_trx_commit = 2
innodb_max_dirty_pages_pct = 90
innodb_lock_wait_timeout = 120
innodb_file_per_table
Die max_connections sind leider nötig. Einige PHP Scripte die unter "Dauer Last" stehen rufen intern die DB auf um via UPDATE oder SELECT Daten zu schreiben bzw. abzufragen.
Die Last via "top" schwankt dabei zwischen 15% - 95% - die restlichen Prozesse "langweilen" sich in normalen Leveln.
Code: Select all
CPU states: 27.5% user, 0.0% nice, 72.1% system, 0.4% interrupt, 0.0% idle
Mem: 441M Active, 1045M Inact, 334M Wired, 28M Cache, 211M Buf, 87M Free
Swap: 2048M Total, 188K Used, 2048M Free
PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
6298 mysql 53 96 0 1108M 210M ucond 0 15:41 31.05% mysqld
...
Rootkit oder eine Backdoor möchte ich ausschließen, zumindest wurde das System erst neulich durch ein Upgrade neu aufgesetzt und bis auf den Webroot / die Datenbanken alles neu installiert.
Für jegliche Hinweise wäre ich sehr dankbar