redbullmachtfit
Goto Top

MySQL Konfiguration optimieren

Hallo zusammen,
etwa 15-20 Außendienstler nutzen eine eigenentwickelte Software zur Kundenverwaltung mit einer MySQL 5.6 Datenbank. Die Datenbankperformance lässt jedoch teils zu Wünschen übrig, außerdem "frisst" MySQL fast den gesamten Arbeitsspeicher auf, obwohl hier lt. MySQL Tuner kein Problem besteht.

Zur Hardware:
- Windows Server 2008 R2
- MySQL Server 5.6.14 (Community), ausschließlich InnoDB Tabellen
- 8 GB RAM, Intel Xeon Prozessor
- virtualisiert auf VMWare ESXi 5.1

Zwei Probleme lt. MySQL Tuner:
- Sehr geringe Query Cache Effizienz
- Fragmentierte Tabellen, "Optimize" allein hat nichts gebracht

Hier meine my.ini:
[mysqld]
port=3306
basedir="C:/Program Files/MySQL/MySQL Server 5.6/"
datadir="C:/ProgramData/MySQL/MySQL Server 5.6/data\"
character-set-server=utf8

default-storage-engine=INNODB

sql-mode="STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"
log-output=FILE
general_log_file="TS01.log"
long_query_time = 5


log-error="TS01.err"

query_cache_size = 64M

table_open_cache = 8M
tmp_table_size=32M
thread_cache_size = 16

myisam_max_sort_file_size=100G
myisam_sort_buffer_size = 48M

key_buffer_size = 48M

read_buffer_size = 64K
read_rnd_buffer_size=256K

sort_buffer_size = 8M

innodb_additional_mem_pool_size = 48M
innodb_flush_log_at_trx_commit=1
innodb_log_buffer_size = 16M
innodb_buffer_pool_size = 1792M
innodb_log_file_size = 256M
innodb_thread_concurrency = 8
innodb_autoextend_increment=64M
innodb_buffer_pool_instances=8
innodb_concurrency_tickets=5000
innodb_old_blocks_time=1000
innodb_open_files=200
innodb_stats_on_metadata=0
innodb_file_per_table=1
innodb_checksum_algorithm=0
back_log=70
flush_time=0
join_buffer_size = 32M
max_allowed_packet = 16M
max_connect_errors = 1000000
open_files_limit=65535
query_cache_type = 1
table_definition_cache=1400
binlog_row_event_max_size=8K
sync_master_info=10000
sync_relay_log=10000
sync_relay_log_info=10000
max_heap_table_size = 32M
innodb_log_files_in_group = 2
query_cache_limit = 5M
log-queries-not-using-indexes
thread_concurrency = 8
max_connections = 35

innodb_fast_shutdown = 1

query_cache_min_res_unit = 4096

Und hier die Ausgabe von MySQL Tuner:
3aaf37b29d994cb6e9bb8e9e3da8a831

Ich freue mich sehr auf Tipps um die Konfiguration zu optimieren!
Vielen Dank vorab!

Nachtrag:
In einer vorigen Frage von mir, wurde bereits erklärt einen MySQL Dump und Import zu starten um die Tabellen zu defragmentieren. Das habe ich noch nicht eingerichtet.

Content-ID: 218993

Url: https://administrator.de/contentid/218993

Ausgedruckt am: 22.11.2024 um 09:11 Uhr

SlainteMhath
SlainteMhath 10.10.2013 um 14:02:18 Uhr
Goto Top
Moin,

ganz grundsätzliche Frage:was für eine Platten Hardware verbirgt sich denn hinter der VMWare? Evtl. ist hier schon ein Flaschenhals.
Wie sieht denn der Taskmanager in Windows aus, insb. CPU und Plattenauslastung sind hier interessant.

Hast Du schon mal die Indizies der Tabellen überprüft bzw. Indizies angelgt die zu den Queries passen die ihr auf die DB schickt?

außerdem "frisst" MySQL fast den gesamten Arbeitsspeicher auf,
Naja, nichts macht weniger Sinn als Unbenutzter Arbeitsspeicher, oder? face-smile

lg,
Slainte
RedBullmachtfit
RedBullmachtfit 10.10.2013 um 14:26:56 Uhr
Goto Top
Hallo Slainte!
Bei den Platten handelt es sich um 15k SAS-Platten, die dürften weniger der Flaschenhals sein. CPU langweilt sich zum größten Teil und die Festplattenaktivität ist auch normal. Mit dem ungenutzen RAM geb ich dir Recht, allerdings hab ich vermutlich trotzdem nen Fehler in meiner my.ini, sonst würde MySQL keine 6-7 GB RAM verbrauchen. MySQL Tuner sagt, dass max. 39% des RAM genutzt werden, was ja nicht hinkommt face-smile
Gruß
RedBullmachtfit
RedBullmachtfit 10.10.2013 um 14:57:34 Uhr
Goto Top
Die Indizies auf die jeweiligen Tabellen müssten soweit passen, das Problem hatte ich Anfangs schon. Habe dann passend zu den Queries die jeweiligen Indexes angelegt.
RedBullmachtfit
RedBullmachtfit 28.10.2013 um 09:37:07 Uhr
Goto Top
Also, das Problem mit der hohen RAM-Nutzung ist behoben. Offenbar lag es am viel zu niedrigen table_open_cache.