[Clarence]

Ursprungligen postat av gregoff

jag kikade på mysqltuner.pl och delvis svaret att jag skulle defragmentera ett gäng tabeller (i och med att tabellerna redan var InnoDB, så löste jag det med ALTER table tabellnamn ENGINE=InnoDB), men även:

- Query cache prunes per day: 119781
- Table cache hit rate: 4% (77 open / 1K opened)

Lösningsförslagen här är:
Variables to adjust:
query_cache_size (> 16M)
table_cache (> 400)

Hur hade ni resonerat kring detta?

Jag vet inte exakt hur bra mysqltuner är så det är svårt att säga mycket utan fler siffror.

Man brukar säga att man ska lägga table_cache på en siffra på ungefär max_connections *
<typiskt antal max-tabeller per query>. Men jag tror inte mysqltuner kan lista ut den andra variabeln här utan får gissa. Du vet det nog bättre själv?

Angående query_cache_size är det i stort bara att testa dig fram. Antingen vill du ha en hyffsad hitrate eller så vill du stänga av query cache helt. Jag antar att du redan fick en OK hitrate eftersom den inte varnade om det? Isåfall kan det vara en bra idé att lägga på lite minne för att både minska lowmem prunes och öka hitraten.

[gregoff]

Nu fick jag problem igen (har inte ändrat config sen sist).

Nu käkar mysqld-processen 100% av cpun (finns två kärnor så det är egentligen bara 50%).

Kan jag få php att köra flera mysqld-processer för att balancera det lite?

[Clarence]

Låter som om du behöver titta lite på query-optimering också, det finns för det mesta en hel del att göra oavsett om den som skrivit SQLen är generellt duktig på query optimisering. Det finns ett väldigt bra verktyg för det kallat pt-query-digest, en del av percona toolkit. Där får du fram vilka av dina frågor som tar mest cpu-tid, t ex.

MySQL använder automatiskt alla cores du har, så om din faktiskt bara använder 1 av dina cores är något allvarligt fel i din konfiguration. Det kan dock hända att din last är diskbunden precis vid 50% cpu util, men det vore ju ett rätt osannolikt sammanträffande.

Vill du köra fler processer gör du det på fler servrar, att köra flera på en server är inget som görs i driftmiljöer då det dels är problematiskt och vidare gör mer skada än nytta.

[gregoff]

Hehe visade sig att det inte var något problem. Det var nåt trassel hos Glesys. Vi har fått en extra sekund idag vilket ställde till det en del på vissa håll (exakt vad vet jag dock inte).