Hjalmar 007s it-blogg

(den här posten är någon slags form av terapi/anteckning för framtida bruk)

När servern för nyhetsportalen.se kraschade (igen) så låg sidan nere ett par dagar. För att komma igång fort igen har jag fått låna / hyra / whatever en core2duo-maskin som agerar server. Denna maskin är betydligt mindre bestyckad än den ursprungliga dual opteron-servern jag har kört på innan.

Detta innebär att jag för det första fick plocka bort en del funktioner helt från sidan för att den överhuvudtaget skulle fungera. I andra hand har jag fått försöka optimera. Detta har jag delvis lyckats med genom att installera Sphinx som får de rena sökningarna att gå flera magnituder snabbare (det har dock inneburit att en del sökresultat blir lite konstiga just nu men det kommer).

Det stora problem kvarstår dock (och detta är ett problem jag har haft hela tiden på nyhetsportalen), nämligen att vid nästan alla sökfrågor så måste jag göra en ORDER BY och oftast även en GROUP BY. Detta får effekten att alla index som MySQL möjligen kan använda flyger all världens väg (mysql kan bara använda ett index per tabell utan att börja skriva till tmp-tabellerna). Normalt sett är detta inget problem. För mig är det dock det. Relativt enkla queries för att sammanställa data, exempelvis för att lista de senaste 15 nyheterna en tidning har publicerat måste jag just nu välja data från tre tabeller. När sorteringen skall göras måste den då göras på alla artiklar som tidningen har gett ut (vilket kan vara upp mot 10000), datan måste hämtas från de andra tabellerna och skickas till klienten.

Detta blir då en läsning i varje tabells index, i datafilen samt en sortering som allt för ofta tar mer plats än vad som finns i ramminnet. Sorteringens “delar” hamnar då i tempfiler på disken. Det är här mitt problem uppstår. När en process börjar skriva till disken så hamnar ohjälpligt processorn i vänteläge på att hårddiskarnas IO skall bli klar innan de kan fortsätta. Detta gör att servern ofta står och bara väntar på skriv eller lästid mot diskarna.

När ett par frågor har byggts upp i kö är det nästan oundvikligt att varje enskild fråga börjar ta mer tid än vad som är bra och antalet connections till servern tar slut vilket resulterar i att användaren visas min inte så vackra felsida.

Vad har jag gjort åt detta? Delvis har jag försökt tillgodogöra mig så mycket information jag kan om ämnet genom att läsa mysqls optimeringskapitel, forumtrådar, blogginlägg, tricks och tricks etc.

Eftersom det inte finns något sätt att hindra MySQL från att kräkas ur sig tempfiler på disken om man sorterar på ett annat index än det som används i WHERE-clausen (och det är inget alternativ för mig).

The key used to fetch the rows is not the same as the one used in the ORDER BY SELECT * FROM t1 WHERE key2=constant ORDER BY key1;

Jag kan inte sortera på tidnings-id-nummret när jag gör en sökning efter de senaste 25 artiklarna en tidning har skrivit. Det är samma id-nummer på alla. Jag vill sortera på datum tex.

En del-lösning på detta som hjälper delvis är att göra sorteringen först i en subquery och sedan använda subqueryns resultat som sorterings-ordning. Detta gör att mindre data behöver skrivas till disken eftersom MySQL då inte skriver med all annan data som fanns i queryn.

Allmänna pointers

• Använd inte text/blog i dina queries (LEFT() klipper effektivt ner text till varchars)
• Använd inte mysqls egna fulltextsök utan titta på alternativen (sphinx, lucene), prestandamässigt kommer du INTE ångra dig
• Skall du ändra tmp_table_size så ändra även max_heap_table_size
• Om du har ett stort resultat-set (många kolumner) så försortera i en subquery:
  SELECT * FROM artikel WHERE id IN (SELECT id FROM artikel WHERE tidning=12 ORDER BY datum_tillagd) LIMIT 25 (mysql stödjer inte limit i subqueries)
• Verktyg som lsof, vmstat, iostat och GkrellM hjälper dig identifiera bottlenecks

Så kära läsare, tips?