![]() |
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.
|
Citat:
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?
|
Citat:
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. |
Citat:
|
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? |
Citat:
|
Citat:
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).
|
Alla tider är GMT +2. Klockan är nu 13:39. |
Programvara från: vBulletin® Version 3.8.2
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Svensk översättning av: Anders Pettersson