Höga värden mysql, optimering hur?
 

Hej,
Har en virtuell cloud server med Ubuntu 12.04, 8GB RAM, 4 cores som jag kör en phpbb sajt på. Lokal MySQL.

Men som ni ser på bilden nedan av top (den svarta) så drar mysqld en hel del kraft. Jag har optimerat tabellerna nyligen. Har även en del röda siffror i körningsvariablarna i phpmyadmin (kolla andra bilden nedan).

Detta är värden från när 200 användare är online, ca.

Delar av my.cnf ser ut såhär:

key_buffer = 128M
max_allowed_packet = 16M
thread_stack = 192K
thread_cache_size = 8
myisam-recover = BACKUP
max_connections = 300
table_open_cache = 1000
tmp_table_size = 32M
max_heap_table_size = 32M
query_cache_limit = 4M
query_cache_size = 128M
max_allowed_packet = 16M
key_buffer = 16M

Är det någon som kan komma med några tips så vore jag ytterst tacksam!

Vet inte om den kan hjälpa dig, men testa och se.
http://tools.percona.com

Svårt att bara titta på värden så, men de är iaf inte helt fel.
Kör mysqltuner med jämna mellanrum. https://github.com/rackerhacker/MySQLTuner-perl

Hej och tack för tipsen.
Jag körde mysqltunern men den visade inte på några stora grejer.

log slow queries var inte påslaget, funderar på att slå på det och se om det kan ge något.

Är det fler som har tips så tages de emot tacksamt!

Det ser ut som att ditt problem kan vara att du har många frågor som inte är bra indexerade eller där för omfattande selects görs. Två alternativ för att se över det:

- Gå igenom de sidor som laddas flest gånger. Kör EXPLAIN på alla frågor där och se vilka som läser alldeles för många rader. Lätt gjort, du behöver inga specialverktyg. Men mer tidskrävande att faktiskt vara säker på att man kommit åt de värsta frågorna.

- Slå på slow_query_log och sätt den på 0 sekunder en timme eller så. Sen kan du köra pt-query-digest på slow_query-loggen och få fram vilka frågor som är i störst behov av optimering. Riktigt effektivt då du får frågorna som tar mest kraft överst färdigt med ett explain-kommando.

Slår du på slow_query-log till exempelvis 2-10 sekunder är det förvisso bra i drift. Men allt som oftast rör det sig om många frågor som har en lägre exekverings-tid än så var och en för sig.

Problemet med MySQL är att databasen inte är trådad per default (till skillnad från te.x Postgresql). Detta betyder att långsamtgående queries blockar alla andra queries, vilket kan ställa till problem.

Jag skulle försökt få MySQL att köras på flera kärnor, på så sätt kan du lastbalansera din applikation. Själv hade jag detta problem för ett projekt. La ner några dagar på att byta över till pg.

Så här såg övergången ut för mig del.

http://i.imgur.com/cfIhsA3.png

EDIT: Ser även att MySQL endast använder ~4% ram. 50% vore mer rimligt.

Kör du InnoDB eller MyISAM?

Om du kör MyISAM kan du testa att byta till InnoDB(se dock till att göra en backup på hela databasen först!). Sedan kan du testa att höja innodb buffer pool till kanske 4 GB.

Hjälper inte det måste du dyka ner i koden pch optimera dina queries eller lägga på någon applikationscache för att avlasta databasen, t.ex. Memcache eller Redis.

MySQL liksom pgSQL är trådade men vad du beskriver beror på arkiktekturen för låsningar snarare än trådningen. En mysqld-process har inga problem att effektivt utnyttja ett par kärnor, men liksom med pgSQL, MSSQL eller Oracle skalar den inte linjärt efter X kärnor.

MySQL liksom pgSQL har olika typer av låsningar för olika typer av operationer. Eftersom MySQL nu använder InnoDB som default så har båda två en väldigt lik låsmodell. Med MyISAM däremot så har du en tabelllåsning för writes istället för rad-låsning för InnoDB och pgSQL.

Vilket databassystem som är snabbare för en viss applikation är väldigt olika. Den största skillnaden i prestanda mellan PgSQL och MySQL kommer av att PgSQLs query optimerare är mycket mer kompetent (om än MySQLs förbättras) och för sämre optimerade queries ofta kan prestera bättre. Men det gäller också XtraDB eller MariaDB för vissa typer av queries och last.

Gällande 4% ram så tror jag inte det gör så stor skillnad att öka på det utifrån siffrorna som visats här. Skulle han däremot använda InnoDB skulle det säkerligen både öka prestandan och få större behov av RAM (se föregående talare ... :))