[Clarence]

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.

[Nerix]

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.



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

[Clarence]

Ursprungligen postat av Nerix

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.



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

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