[SimonP]

Ja, nått måste vara fel om det börjar sega redan vid 40 inloggade samtidigt (såvida inte alla skulle sitta och uploada stora bilder samtidigt). Din diskprestanda verkar som sagt vara extremt låg.

På denna dedikerade server:

CentOS 64bit
2 st CPU (3ghz gamla P4), 4 GB RAM
Apache2, php5 (med eaccelerator) och Mysql server
10k spin SCSI diskar

kör vi:
-Webshop
-VB-forum (45k medlemmar)
-Wordpress som CMS

Den klarar runt 1000 inloggade samtidigt innan det börjar bli lite segt.

[Azone]

Ursprungligen postat av SimonP

Ja, nått måste vara fel om det börjar sega redan vid 40 inloggade samtidigt (såvida inte alla skulle sitta och uploada stora bilder samtidigt). Din diskprestanda verkar som sagt vara extremt låg.

På denna dedikerade server:


kör vi:
-Webshop
-VB-forum (45k medlemmar)
-Wordpress som CMS

Den klarar runt 1000 inloggade samtidigt innan det börjar bli lite segt.

Ja, kan inte annat än hålla med verkar som om diskprestanda kanske är den stora boven här. Visst kanske några samtidigt sitter och laddar upp bilder, men det sker nog mer sällan än det idag segar ihop sig. Tack för bra referens-siffror.

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

[Dennis Holm]

15mb/sec är inte "extremt dålig diskprestanda".
det är dock inte super.. men ganska basic prestanda på en mindre/äldre sata disk .
Speciellt på VPS som ofta har lite omvägar för arbetet och möjligen lite belastning hos andra vpser på värdmaskinen.

Om 15mb/sec är ett problem så kräver det en ganska krävande/stor site.
Har haft väldigt stora forum på hårdvara som snurrar på runt 19mb/sec.
Och det handlar om både stora och många db queries.

Så glöm flaskhalsen om diskprestanda just nu.
Det är något annat som agerar flaskhals .

p.s 1gigabyte/sec prestanda är från minne till minne.. inte ren disk i/o .

[Norman]

Ursprungligen postat av Björklund

Du har hopplöst dålig diskprestanda. Dock så har du inte hög belastning på din server. Så den dåliga diskprestandan borde inte spela någon roll.
Min gissning är du har något lås någonstans... Ex att du anropar externa källor som inte svarar tillräckligt fort.

Skrivprestanda på en av våra servrar:
# dd if=/dev/zero of=/root/test bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 1.16141 seconds, 903 MB/s

Är lite trött nu när jag skriver... så ber om ursäkt om vissa saker är otydliga.

Den disken undrar jag också vad det är för något om det inte är något riktigt SAN på fibrechannel och stora raid grupper som ger hög IOPs.
Det andra jag tror på är att det blir hög minnes lokalitet och cachen funkar bra när man bara skriver nollor i följd.
Att köra if-källa från /dev/zero ger ingen reel mätning av diskar eftersom en intellegent kontroller kommer kunna allokera nollor utan problem.
Man bör istället köra /dev/urandom eller en förgenererad fil (om man inte vill dra massa CPU för att generera /dev/urandom).

Nu ska jag avslöja en stor eller liten hemlighet beroende på hur man ser på det.
VPS:er ligger på delat medium. Oftast så delas IOPs och MB/s skrivhastighet mellan många virtuella maskiner för att göra kostnadsbesparingar i infrastruktur - för att kunna ge så låga priser på VPS som möjligt. Tyvärr tittar de flesta kunder på priset framför reel prestanda. Har du en granne som drar mycket IOPs och MB/s så lär du inte få ut mycket prestanda.
Visst går det att dedikera resurser till de virtuella kunderna också. Det är en kostnadsfråga.
Min gissning är att trådskaparens leverantör har sina virtuella maskiner på glusterfs som är rekommenderad setup för den kontrollpanel de kör, detta är inte det snabbaste meta-lagringsfilsystemet och har en del begränsningar som medför försämrad prestanda. Det ger dock fördelen att det är riktigt billigt.

Vissa VPS-leverantörer i de dyrare tiers har dock riktiga SAN som har dedikerad IOPs . Där får du nog räkna med att du inte kan betala 2kr/GB.. utan det blir tiogånger så dyrt. Varför? Jo, riktiga SAN kostar.
För att få bra IOPs krävs ett bra storage backend, riktiga raidgrupper med många diskar. Jag har börjat skriva lite smått om detta på min blogg www.uppe.nu .

Vad du kan göra för att slippa diskläsningar är att skaffa mer RAM och allokera så att mySQL får nyttja det. En separat VPS/server hjälper också i och med att din apache slipper vänta på IOwait som orsakas av mySQL. Dock får du fortfarande vänta på resultat från din SQL oavsett om du lägger det på annan maskin - du måste alltså se till att optimera dina queries, köra memcached och andra cachningstekniker för att snabba upp local fetch.

Vad man dock får titta på om man ska göra en riktig analys är hur många av dina queries som är av respektive typ.
Sorts, writes, selects osv.
Writes taxerar disklagring mer än sorts och select som mer är läsning från RAM.
Du kan justera mySQL prestanda genom att konfigurera om så att den får göra dirty writes / updates. Dvs att det inte behöver synkas mot disk efter write och att en select får börja göras direkt utan att vänta på en write.

Då måste du dock på applikationslager se till så du kan hantera "fel" och ha vissa datakontroller.

Tillägg:
Ni kan förbättra prestanda i linux på filsystem genom att köra något journalförande filsystem som tillåter optimering/defragmentering.
T.ex. xfs .
Även om ext3 inte är så känsligt för fragmentering så kan det hända - ett system som varit igång länge blir lätt fragmenterat och diskprestanda blir lidande.
Xfs löser detta genom att du kan göra live optimeringar .

[Azone]

Jag har hittat problemet med min site och det beror INTE på diskprestandan eller VPS-leverantör utan helt enkelt på min egen sida som skapar låsningar i databasen. Låsningarna kommer först vid fler än 40 inloggade. Men jag gör om webb-applikationen för att inte få dessa låsningar.

Jag har tagit bort de delar som skapar låsningarna och då snurrar sidan på bra hos både Glesys och Citynetwork (City Cloud). Men visst har Glesys grymt mycket bättre diskprestanda, men enligt Citynetwork är det något de skall åtgärda under hösten/vintern.

Tack för alla hjälp och förslag som jag fått. Det har varit väldigt lärorikt.

mvh
Azone

[Björklund]

Ursprungligen postat av Björklund

Min gissning är du har något lås någonstans...

;-) Skönt att det löste sig!

[Azone]

Ursprungligen postat av Björklund

;-) Skönt att det löste sig!

Ja, du hade helt rätt, det är/var låsningar.

Måste hitta något annat sätt att nå samma resultat bara, för det jag tvingades ta bort från sidan behöver jag i någon form.

[Norman]

Om inte ditt backend (disk IO) är snabbt nog så är det rätt troligt att du märker av låsningar vid updates/writes på din databas. Att lås får ske är helt normalt - det går inte alltid att skriva bort låsningar helt. Ett sätt att fuska sig förbi är att tillåta dirty reads (my.cnf förländring).

Kolla först och främst över din webbplatforms kod, sen kan du undersöka om det är annan flaskhals.