MySQL kietelen
Om alle marketplaces, webshops en klantwebsites goed te laten draaien maken wij gebruik van verschillende dedicated webservers. Persoonlijk vind ik het altijd leuk om zo af en toe de webserver configuratie een beetje te kietelen en hier meer performance uit te halen. Met enkele simpele aanpassingen in de my.cnf, de configuratie file voor MySQL op Linux omgevingen, kan vaak al een enorme performance winst (of verlies) worden gemaakt. In deze blog zet in een aantal configuraties neer die ik heb gebruikt. Probeer ze eens en kijk of ze ook voor jou werken.
Geheugen gebruik optimaliseren
Een van de manieren om meer performance uit je ijzer te halen is door de configuratie van de geheugen toewijziging. Of dit nou caching, logging of andere parameters zijn, hieraan sleutelen helpt. Probeer wel altijd te voorkomen dat je machine gaat swappen. Dat is niet goed, dan heb je teveel geheugen toegewezen (of te weinig geheugen) voor het aantal bezoekers / sessies op je machine. Met de overgang van WordPress naar InnoDB als standaard database zijn tuning parameters wat meer gericht op InnoDB dan de “traditionele” MySQL instellingen. Waar eerder Query Cache een belangrijk item was is dit meer naar de achtergrond geschoven merk ik. Op sommige machines heb ik deze zelfs op 0 staan om meer ruimte te maken voor de innodb_buffer_pool_size (generiek advies is 80% van het totale geheugen, ik zet het liever 25% hoger dan de totale database grootte).
Processorgebruik optimaliseren
Veel hostingmachines hebben meerdere processors of multi-cores. Vet! Maar hoe gebruik je ze? Laat je de standaard configuratie het uitzoeken of help je ze een handje? Dat kan namelijk met de variabelen innodb_buffer_pool_instances en thread_concurrency. Hoewel sommige experts aangeven je tengels van de MySQL configuratie af te blijven ben ik eigenwijzer (met wisselend resultaat).
InnoDB tuning op 8 core machine met 32 GB memory (SATA drivers)
De volgende configuratie regels heb ik gebruikt om wat meer performance uit een machine te halen met 8 cores, 32 GB geheugen en een paar RAID1 SATA drivers. Leuk instap servertje die best te kietelen is.
innodb_buffer_pool_size = 16G
innodb_io_capacity = 220
innodb_log_buffer_size = 32M
innodb_buffer_pool_instances = 8
innodb_log_file_size = 4G
innodb_fast_shutdown = 0
innodb_flush_log_at_trx_commit = 2
innodb_read_io_threads = 64
innodb_write_io_threads = 64
Wanneer je SAS of SSD schijven hebt zou je de innodb_io_capacity wat kunnen opschroeven. De innodb_buffer_pool_instances werken overigens alleen bij een minimale buffer_pool van 16 GB.
De log_buffer_size staat op 32M maar zou nog iets omhoog kunnen (128M). De innodb_flush_log_at_trx_commit is ook een leuke om mee te spelen, maar hou rekening met ACID compliance (waarde 1 = full ACID compliant).
Nog beter resultaat kan je halen met aanpassen van de volgende waarden :
innodb_flush_method = O_DIRECT
Nog meer risico en nog minder ACID compliance kan je bereiken met tegenover een betere performance kan je behalen door :
innodb_flush_log_at_trx_commit = 0
Dit kan je database wel schade toebrengen bij een crash. Gebruik op eigen risico, speel er eens mee. Succes!
