PDA

Bekijk Volledige Versie : MySQL optimaliseren



Deimos
23/07/02, 01:01
Omdat SQL soms enorm veel CPU tijd in beslag neemt heb ik mijn my.cnf geoptimaliseerd. Hieronder staat deze, maar het kan natuurlijk zijn dat ik dingen over het hoofd zie, vandaar de vraag of dat zo is en zoja wat :).



[client]
port = 3306
socket = /tmp/mysql.sock


# The MySQL server
[mysqld]
port= 3306
socket= /tmp/mysql.sock
skip-locking
set-variable = max_connections=400
set-variable = key_buffer=36M
set-variable = join_buffer=6M
set-variable = record_buffer=6M
set-variable = sort_buffer=10M
set-variable = table_cache=1536
set-variable = myisam_sort_buffer_size=40M
set-variable = thread_cache_size=530
set-variable = connect_timeout=30
set-variable = wait_timeout=30
set-variable = interactive_timeout=28800

# Try number of CPU's*2 for thread_concurrency
set-variable= thread_concurrency=3

log-slow-queries=/var/log/slow.log
log=/var/log/mysql.log
#log-bin
#server-id= 1
# Uncomment the following if you are using Innobase tables
#innodb_data_home_dir = /var/lib/mysql/
#innodb_log_group_home_dir = /var/lib/mysql/
#innodb_log_arch_dir = /var/lib/mysql/
#innodb_data_file_path = ibdata1:25M;ibdata2:37M;ibdata3:100M;ibdata4:300M
#set-variable = innodb_mirrored_log_groups=1
#set-variable = innodb_log_files_in_group=3
#set-variable = innodb_log_file_size=5M
#set-variable = innodb_log_buffer_size=8M
#innodb_flush_log_at_trx_commit=1
#innodb_log_archive=0
#set-variable = innodb_buffer_pool_size=16M
#set-variable = innodb_additional_mem_pool_size=2M
#set-variable = innodb_file_io_threads=4
#set-variable = innodb_lock_wait_timeout=50

# Point the following paths to different dedicated disks
#tmpdir= /tmp/
#log-update = /path-to-dedicated-directory/hostname

[mysqldump]
quick
set-variable= max_allowed_packet=16M

[mysql]
no-auto-rehash
# Remove the next comment character if you are not familiar with SQL
#safe-updates

[isamchk]
set-variable= key_buffer=128M
set-variable= sort_buffer=128M
set-variable= read_buffer=2M
set-variable= write_buffer=2M

[myisamchk]
set-variable= key_buffer=256M
set-variable= sort_buffer=256M
set-variable= read_buffer=8M
set-variable= write_buffer=8M

[mysqlhotcopy]
interactive-timeout

Deimos
24/07/02, 01:23
Is er helemaal niemand die tips heeft voor het verder optimaliseren? Dat bestaat toch bijna niet.

Domenico
24/07/02, 03:01
Ok,

socket= /tmp/mysql.sock
Zou ik verplaatsen naar een andere directory want de tmp dir wordt nogal eens schoongemaakt en dat zou niet erg bevorderlijk zijn in dit geval :)

log-slow-queries=/var/log/slow.log
log=/var/log/mysql.log
Heb je dit echt nodig aangezien dat nogal vertragend kan werken.
Ik zou het alleen maar gebruiken als ik het nodig zou hebben om wat data te analyseren.

set-variable = join_buffer=6M
set-variable = record_buffer=6M
set-variable = sort_buffer=10M
Je weet dat deze waardes 'per thread' worden gealloceerd?
Ik zou ze lager zetten.

Hoeveel geheugen heb je eigenlijk? Dit vraag ik omdat je nogal hoge waarden gebruikt...

Wat is je extended-status output?
mysql> show status;
Ik heb ook een script bijgevoegd waarmee je de MySQL extended-status output kunt bekijken.

Door veel te vergelijken tijdens piekuren kun je een hoop leren.

Kijk ook even op http://www.mysql.com/doc/O/p/Optimising_the_Server.html

Groeten,
Domenico

Deimos
24/07/02, 12:15
De tmp dir maakt eigenlijk niet zoveel uit, indien je maar je sockets goed insteld in beide delen.

Verder zal de waardes iets omlaag schroeven kijken of het uitmaakt. Denkt het eerlijk gezegt niet,

Deimos
24/07/02, 12:18
En hier extended status output :)



+--------------------------+------------+
| Variable_name | Value |
+--------------------------+------------+
| Aborted_clients | 313 |
| Aborted_connects | 93 |
| Bytes_received | 103864817 |
| Bytes_sent | 1600312574 |
| Com_admin_commands | 0 |
| Com_alter_table | 23 |
| Com_analyze | 0 |
| Com_backup_table | 0 |
| Com_begin | 0 |
| Com_change_db | 85175 |
| Com_change_master | 0 |
| Com_check | 0 |
| Com_commit | 0 |
| Com_create_db | 0 |
| Com_create_function | 0 |
| Com_create_index | 0 |
| Com_create_table | 25 |
| Com_delete | 253 |
| Com_drop_db | 0 |
| Com_drop_function | 0 |
| Com_drop_index | 0 |
| Com_drop_table | 5 |
| Com_flush | 0 |
| Com_grant | 0 |
| Com_insert | 2354 |
| Com_insert_select | 2 |
| Com_kill | 0 |
| Com_load | 0 |
| Com_load_master_table | 0 |
| Com_lock_tables | 0 |
| Com_optimize | 1 |
| Com_purge | 0 |
| Com_rename_table | 0 |
| Com_repair | 0 |
| Com_replace | 164 |
| Com_replace_select | 0 |
| Com_reset | 0 |
| Com_restore_table | 0 |
| Com_revoke | 0 |
| Com_rollback | 0 |
| Com_select | 1367825 |
| Com_set_option | 3392 |
| Com_show_binlogs | 0 |
| Com_show_create | 3392 |
| Com_show_databases | 496 |
| Com_show_fields | 3998 |
| Com_show_grants | 0 |
| Com_show_keys | 316 |
| Com_show_logs | 0 |
| Com_show_master_status | 0 |
| Com_show_open_tables | 0 |
| Com_show_processlist | 8 |
| Com_show_slave_status | 0 |
| Com_show_status | 412 |
| Com_show_tables | 1567 |
| Com_show_variables | 316 |
| Com_slave_start | 0 |
| Com_slave_stop | 0 |
| Com_truncate | 0 |
| Com_unlock_tables | 0 |
| Com_update | 30541 |
| Connections | 67735 |
| Created_tmp_disk_tables | 16 |
| Created_tmp_tables | 1388 |
| Created_tmp_files | 0 |
| Delayed_insert_threads | 0 |
| Delayed_writes | 0 |
| Delayed_errors | 0 |
| Flush_commands | 1 |
| Handler_delete | 297 |
| Handler_read_first | 10343 |
| Handler_read_key | 6516261 |
| Handler_read_next | 9138170 |
| Handler_read_prev | 627327 |
| Handler_read_rnd | 835071 |
| Handler_read_rnd_next | 293318247 |
| Handler_update | 5214365 |
| Handler_write | 203755 |
| Key_blocks_used | 722 |
| Key_read_requests | 4688729 |
| Key_reads | 481 |
| Key_write_requests | 21429 |
| Key_writes | 5189 |
| Max_used_connections | 9 |
| Not_flushed_key_blocks | 0 |
| Not_flushed_delayed_rows | 0 |
| Open_tables | 450 |
| Open_files | 872 |
| Open_streams | 0 |
| Opened_tables | 598 |
| Questions | 1567285 |
| Select_full_join | 19 |
| Select_full_range_join | 0 |
| Select_range | 324 |
| Select_range_check | 0 |
| Select_scan | 714281 |
| Slave_running | OFF |
| Slave_open_temp_tables | 0 |
| Slow_launch_threads | 0 |
| Slow_queries | 0 |
| Sort_merge_passes | 0 |
| Sort_range | 10969 |
| Sort_rows | 834952 |
| Sort_scan | 59580 |
| Table_locks_immediate | 1432143 |
| Table_locks_waited | 351 |
| Threads_cached | 9 |
| Threads_created | 10 |
| Threads_connected | 1 |
| Threads_running | 1 |
| Uptime | 566299 |
+--------------------------+------------+

Domenico
25/07/02, 17:17
Deimos, mag ik je serverstats ook even?
Het kopje van de TOP output is prima...

Deimos
25/07/02, 17:21
last pid: 48739; load averages: 0.31, 0.12, 0.06 up 17+22:11:46 16:21:14
39 processes: 1 running, 38 sleeping
CPU states: 0.0% user, 0.0% nice, 0.8% system, 0.8% interrupt, 98.8% idle
Mem: 138M Active, 223M Inact, 93M Wired, 24M Cache, 60M Buf, 20M Free
Swap: 846M Total, 9728K Used, 837M Free, 1% Inuse

almar
13/08/02, 12:41
Wat veel hosters denken is dat ze MySql problemen kunnen oplossen door maar meer geheugen in de bak te stouwen en meer geheugen toe te wijzen. Dit is dus absoluut niet het geval! Het grootste probleem is en blijven de gebruikers. De problemen zitten in 90 % van de gevallen in de indexeringshoek. Omdat de meesten geen verstand hebben van MySql wordt de indexering ook niet goed uitgevoerd. Waardoor de performance van MySql ernstig terugloopt.

Je kan er Gigabytes aan geheugen instoppen en toewijzen, maar dat helpt NIETS!

Enige optie is handmatig query's checken. Overigens zie je het snel genoeg als er een bottleneck is. Die blijft wel een seconde of twee hangen.

Gr,

Almar