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

[Clarence]

Ursprungligen postat av 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).

Han använder MyISAM och saknar därmed möjlighet att välja isolationsnivå, och för den delen förutsättningen att ens göra dirty reads.