[abergman]

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

CityNetwork har problem med sitt lagringsbackbone, vi har samma problem på våra maskiner, enligt dem själva så ska det lösas under hösten.

Som jämförelse så får jag det här resultatet på en av våra maskiner som ligger hos CityNetwork:
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, 38.7964 s, 27.0 MB/s

[Azone]

Ursprungligen postat av abergman

CityNetwork har problem med sitt lagringsbackbone, vi har samma problem på våra maskiner, enligt dem själva så ska det lösas under hösten.

Som jämförelse så får jag det här resultatet på en av våra maskiner som ligger hos CityNetwork:
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, 38.7964 s, 27.0 MB/s

Ja, jag fick något liknande när jag testade igen. Hoppas det fixar sig under "hösten" då, för snart är det vinter. Tack för info.

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

[jonny]

Rent spontant känns ju inte 35 användare som särskilt mycket. Låter som det bör vara läge att gå igenom koden. Är det databasfrågorna som tar tid?

[Jonas]

Använder du index korrekt i MySQL ?
Vad säger slow-query.log ?

Vad loggas på maskinen och vad loggas inte?

Hur använder du PHP i Apache? mod_php eller fastcgi ?

[Azone]

Ursprungligen postat av Jonas

Använder du index korrekt i MySQL ?
Vad säger slow-query.log ?

Vad loggas på maskinen och vad loggas inte?

Hur använder du PHP i Apache? mod_php eller fastcgi ?

Vet ej om jag använder index korrekt. Kör Drupal CMS och jag påverkar därmed inte quieriserna manuellt.

Har stängt av loggarna eftersom det slöar ner en del, men har en del "slow-quieries" dock.

Jag kör mod-php. Försökte gå över till fastcgi och mpm-worker men fick det inte att fungera. Funderar på att byta till Nginx för att se om det hjälper något. Segheten kommer efter ett visst antal över 35 är inloggade. De är väldigt aktiva på forumet och använder det nästan som en "chatt". Men vi växer snabbt och behöver lösa detta snarast.

Kör med .htaccess eftersom det är standard i drupal och .htaccess finns i några mappar.

[Magnus_A]

Testa att öka max_connections från 128 till typ 500 i my.cnf