[Azone]

Ursprungligen postat av Clarence

Kör en SHOW PROCESSLIST; på mysql när det segar. Har du många anslutningar? Ligger många med state locked? Går de upp till max_connections? Thread cache hitrate?

Titta på cpu-stat under top. Har du mycket iowait på CPU-användandet?

Är det myisam-tabeller? Ok hit-rate på key buffern? Stiger slow_queries snabbt under högsta belastningen (show status like 'slow_queries')? Är det samma queries? Hur ser explain ut på dom?

Är query cache på? Hit rate? Är den för låg bör man antingen stänga av det eller åtgärda ration.

Tack! Väldigt bra frågor och svar. Skall titta på dessa parametrar vid nästa belastningstopp. Men följande vet jag redan nu.

• Det är Myisam tabeller (endast)
• Slow Queries stiger vid hög belastning eller om de bara bli vanligare pga fler queries ??
• Query cache är på (=1) och undrar om den motarbetar en del annan caching kring php (eaccelerator mm), läste något om det men vet ej. Det är kanske det du menar med att stänga av den om "hit rate" är för låg.
• Får många "locked" i mtop ibland vid hög belastning (= fler än 35-40 inloggade på sidan).
• Max-connections räcker nu sen jag fick lite koll på global vs thread buffer (minne). Se nedan. Har top 50 connections av 100 möjliga nu, men förväntar tillväxt.
• Jag kör både "MySqltuner.pl" och "Tuninng mysql ...?" Den förstnämnda ger flest ledtrådar till mig iaf. Men den säger konstant att Query cash size och limit bör ökas (men förstår inte varför och rädd att spräcka minesgränser samt att den aldrig verkar få nog).
• Har kört Optimize på samtliga tabeller.
• Kör Drupal 6 och den sägs ju vara ganska databasintensiv och förbättringar förväntas i Drupal 7, men det är ingen monstersida eller monstertrafik, så det borde gå att lösa med befintlig kapacitet tycker jag.

-----------------------------------------------------------------------------

Jag har hittat några allvarliga fel i mysqlkonfugurationen. T ex har/hade jag dålig koll på.

Mysql allokerat minne = globalbuffers + (max_connections + threaded buffers).

global_buffers:
key_buffer
net_buffer
(vilka fler?)

Jämfört med:

thread_buffers:
sort_buffer
myisam_sort_buffer
read_buffer
join_buffer
read_rnd_buffer

Detta gav minnesproblem (allokerade mer än jag fysikt hade).
Nu går det stabilare ur den aspekten men det segar fortfarande ner sig vid många inloggade. Känns bättre med stabilt och segt än att det slår i taket och "totalkraschar".

Har många "locked" i mtop vid vissa situationer. Skall kolla Process list vid nästa belastningstop vid lunch eller kväll, när toppar brukar ske.


--------------------------------------------------------------------

Jag har bestämt mig för att installera om "ALLT" (LAMP eller alternativ). Inte bara beroende på mysql-problem utan för att få en mer korrekt struktur på hela paketet.

Funderar då på att gå över Nginx, eller Apache2 MPM-worker med Fastcgi samt sätta upp en kontrollpanel för att enklare hantera flera domännamn i framtiden.

Funderar på bl a"The perfect server"
http://www.howtoforge.org/perfect-se...nny-ispconfig3
Eller Liknande med Nginx.


mvh
Azone

[Clarence]

Ursprungligen postat av Azone

Query cache är på (=1) och undrar om den motarbetar en del annan caching kring php (eaccelerator mm), läste något om det men vet ej. Det är kanske det du menar med att stänga av den om "hit rate" är för låg.

Nej, de motarbetar inte varandra. Eaccelerator är cachar opcodes för exekveringen av PHP, Qcache arbetar helt på databasnivå. Detta förutsatt att eaccelerator inte används med någon manuell variabel-cache (vet inte ens om det stöds av eaccelerator, men möjligt då det finns i t ex APC).

Ursprungligen postat av Azone

• Det är Myisam tabeller (endast)
• Slow Queries stiger vid hög belastning eller om de bara bli vanligare pga fler queries ??
• Får många "locked" i mtop ibland vid hög belastning (= fler än 35-40 inloggade på sidan).
• Kör Drupal 6 och den sägs ju vara ganska databasintensiv och förbättringar förväntas i Drupal 7, men det är ingen monstersida eller monstertrafik, så det borde gå att lösa med befintlig kapacitet tycker jag.

Ovanstående punkter tillsammans får mig att misstänka att problemet är tabell-låsningar vid skrivning. Myisam låser hela tabellen vid skrivning till en rad medan t ex InnoDB endast låser aktuell(a) rad(er). Att försöka kombinera InnoDB med MyISAM på en server kan dock ha sina problem, framförallt för att minnesanvändningen inte kan kombineras bra med de två då InnoDB slukar mest buffer pool. Alternativet är att gå igenom och åtgärda de frågor som låser upp tabellerna. Förmodligen, utan speciell stor insikt i varken drupal eller din sajt, är det något i stil med en view-counter för trådar/sidor/? som skriver direkt till rätt tabell och blockerar övriga queries. Dessa skrivs isåfall enkelt om till att läggas in i batches och skrivas till en separat tabell dessförinnan. Bättre diskprestanda skulle förvisso också avhjälpa om problemet är detta, men det skulle snarare skjuta upp än lösa det.

[Azone]

Ursprungligen postat av Clarence

Nej, de motarbetar inte varandra. Eaccelerator är cachar opcodes för exekveringen av PHP, Qcache arbetar helt på databasnivå. Detta förutsatt att eaccelerator inte används med någon manuell variabel-cache (vet inte ens om det stöds av eaccelerator, men möjligt då det finns i t ex APC).


Ovanstående punkter tillsammans får mig att misstänka att problemet är tabell-låsningar vid skrivning. Myisam låser hela tabellen vid skrivning till en rad medan t ex InnoDB endast låser aktuell(a) rad(er). Att försöka kombinera InnoDB med MyISAM på en server kan dock ha sina problem, framförallt för att minnesanvändningen inte kan kombineras bra med de två då InnoDB slukar mest buffer pool. Alternativet är att gå igenom och åtgärda de frågor som låser upp tabellerna. Förmodligen, utan speciell stor insikt i varken drupal eller din sajt, är det något i stil med en view-counter för trådar/sidor/? som skriver direkt till rätt tabell och blockerar övriga queries. Dessa skrivs isåfall enkelt om till att läggas in i batches och skrivas till en separat tabell dessförinnan. Bättre diskprestanda skulle förvisso också avhjälpa om problemet är detta, men det skulle snarare skjuta upp än lösa det.

Ja, jag har svårt att påverka queries i drupal (åtminstone med min kunskap), visserligen skulle ja kunna ta bort någon funktion på sidan, men jag tycker ändå som andra varit inne på att 40 användare borde vara rätt få i sammanhanget och dessa eventuella låsningar pga MyISAM borde väl handla om millisekunder istället för halvminuters låsningar. Till dessa 40 får man iofs lägga till de anonyma som brukar var i häraden 20 men de har ingen aktiv del i forumet. Däremot uppdateras väl iofs view-counters och en del annat. Men 60 användare totalt borde väl systemet klara även om det inte är superoptimerat. I mysqltuner är läsningar ca 98% och skrivningar 2% om det nu säger något mera i sammanhanget?

Skall avaktivera view-countern och se om det gör någon skillnad iofs.

Tack för svar.