Trimma MySQL (VPS)
 

Hej alla!

Jag sitter och tweakar min VPS lite och känner att jag nog har en del jobb att fixa när det kommer till MySQL-delen.

Just nu kör jag på standard-configen (som finns direkt efter installation). Använder en VPS hos Glesys med 2 kärnor och 2048 meg ram.

Har hört att det bästa man kan göra är att lägga hela databasen i ram-minnet. Hur gör jag detta? Databasen ifråga ligger på 100-200 meg.

Lägger du hela databasen i minnet är risken för dataförlust så hög att du får lägga ner både mycket tid och resurser på riktigt frekvent och kontrollerad backup. Det är helt enkelt så osäkert att man brukar använda sig av tabellmotorerna som kan ha all eller en del av datan i minnet istället. Som också kan hantera datasäkerheten vid skrivningar till disken istället för att du ska försöka ta hand om det med en egenknackad backuplösning.

Det vanliga är att man utnyttjar innodb (eller percona xtradb) som har en buffer pool som faktiskt har sin aktiva data i minnet, både tabellinnehåll och index. Det finns gott om script som sätter lämplig buffer pool, och andra buffrar, på en bra nivå för din burk och databas. T ex mysqltuner och tuning-primer.

Har du ingen vidare erfarenhet eller kunskap fungerar dessa ofta bättre än om du försöker själv.

En optimal konfiguration beror inte bara på datamängd och ram-mängd utan även hur man använder andra buffers, om man har olika tabelltyper, antal tabeller, typ av queries osv.

Tack för tipsen om mysqltuner och tuning-primer. Ska kika på dessa.

Fast i vettiga servrar så har man ju ECC minnen, sedan använder du ju ofta hela DB i minnet endast för läsning.

Du får även tänka på att alla skrivningar även går direkt till minnet med, då det alltid mer eller mindre finns en write cache.

Om jag nu vill testa dettta (dvs ha databasen i minnet, men att alla skrivningar även sker till hårddisken), någon som har bra tips om vidare läsning?

Just det jag beskrev i tidigare inlägg. Det låter lite som om det även är vad patrikweb föreslår då det är svårt att tyda hans svar annorlunda utan en komplex och ostabil hemmabygd lösning på ett problem som redan lösts. Innodbs buffer pool cachar data och läsningar bör således ske just från minnet när du har en databas som är såpass mycket mindre än tillgängligt minne. Skulle databasen bli större än dedikerat minne för buffer poolen skulle den mest använda datan ligga i din buffer pool.

Data skrivs till disk lite annorlunda beroende på vad du sätter innodb_flush_log_at_trx_commit till. Kan du acceptera 1 sekunds förlorad data om din server skulle krascha kan du sätta den till 0, vill du följa ACID sätter du den till 1 och vill du välja mellanvägen till 2.

Fast write cache finns ju i väldigt många lager, du har ju applikationsnivån. Sedan på filsystem nivå. Sedan på raidkontroller, disklådorna, fysiska disken.

Så om du inte har några andra skrivningar mer än MySQL och du endast har enstaka MB data skrivningar är risken väldigt stor att den ändå ligger i någon write cache.

Förlorade datan sker inte vid flushen. Lyckas inte flushen till disk så rensas inte buffern. Förlorad data är endast de transaktioner som ännu inte flushas till disk. Och har de inte flushats till disk så kommer de heller inte ligga i några filsystems-cache (som för övrigt i stort sett inte används med innodb då man brukar använda direct io) och förloras för att de endast finns i RAM. Men det är som sagt fullt konfigurerbart.

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?

Patrik är väl inne på att det finns cache även direkt i diskarna, raidkontroller och liknande i hårdvarulagret - som du inte kan påverka direkt från databasen.

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.

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?

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.

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).