[gregoff]

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.

[Clarence]

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.

[gregoff]

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

[patrikweb]

Ursprungligen postat av Clarence

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.

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.

[gregoff]

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?

[Clarence]

Ursprungligen postat av gregoff

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.

[patrikweb]

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.

[Clarence]

Ursprungligen postat av patrikweb

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.

[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?

[jonny]

Ursprungligen postat av Clarence

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.

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.