[Björklund]

Ursprungligen postat av Azone

Testen säger detta: Är det bra eller dåligt?

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, 69.9753 s, 15.0 MB/s


---------------------------------------------------------------------------
mod_status

apache2ctl status
Apache Server Status for www.exempel.se


Server Version: Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny9 with
Suhosin-Patch mod_python/3.3.1 Python/2.5.2 mod_perl/2.0.4
Perl/v5.10.0

Server Built: Apr 20 2010 15:40:17
__________________________________________________ ________________

Current Time: Tuesday, 05-Oct-2010 21:55:46 CEST
Restart Time: Tuesday, 05-Oct-2010 21:53:07 CEST
Parent Server Generation: 0
Server uptime: 2 minutes 38 seconds
Total accesses: 549 - Total Traffic: 6.2 MB
CPU Usage: u33.68 s4.36 cu0 cs0 - 24.1% CPU load
3.47 requests/sec - 40.1 kB/second - 11.5 kB/request
2 requests currently being processed, 20 idle workers

__W________C____.____.._.._....................... ..............
.................................................. ..............
.................................................. ..............
.................................................. ..............

Scoreboard Key:
"_" Waiting for Connection, "S" Starting up, "R" Reading Request,
"W" Sending Reply, "K" Keepalive (read), "D" DNS Lookup,
"C" Closing connection, "L" Logging, "G" Gracefully finishing,
"I" Idle cleanup of worker, "." Open slot with no current process

---------------------------------------------------------------------------
top - 21:58:31 up 4:55, 2 users, load average: 0.78, 0.93, 1.52
Tasks: 105 total, 2 running, 97 sleeping, 5 stopped, 1 zombie
Cpu(s): 11.3%us, 4.3%sy, 0.0%ni, 83.9%id, 0.3%wa, 0.2%hi, 0.0%si, 0.0%st
Mem: 4065464k total, 3580680k used, 484784k free, 153804k buffers
Swap: 891568k total, 604k used, 890964k free, 2411404k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
10333 mysql 20 0 815m 187m 5684 S 18 4.7 9:25.90 mysqld
11690 www-data 20 0 274m 57m 19m R 11 1.4 0:00.32 apache2
11653 www-data 20 0 0 0 0 Z 1 0.0 0:00.02 apache2 <defunct>
1 root 20 0 10316 748 620 S 0 0.0 0:01.94 init
2 root 15 -5 0 0 0 S 0 0.0 0:00.20 kthreadd
3 root RT -5 0 0 0 S 0 0.0 0:02.90 migration/0
4 root 15 -5 0 0 0 S 0 0.0 0:00.24 ksoftirqd/0
5 root RT -5 0 0 0 S 0 0.0 0:00.24 watchdog/0
6 root RT -5 0 0 0 S 0 0.0 0:03.52 migration/1
7 root 15 -5 0 0 0 S 0 0.0 0:00.50 ksoftirqd/1
8 root RT -5 0 0 0 S 0 0.0 0:00.02 watchdog/1
9 root 15 -5 0 0 0 S 0 0.0 0:02.60 events/0
10 root 15 -5 0 0 0 S 0 0.0 0:03.16 events/1
11 root 15 -5 0 0 0 S 0 0.0 0:00.88 khelper
46 root 15 -5 0 0 0 S 0 0.0 0:03.02 kblockd/0
47 root 15 -5 0 0 0 S 0 0.0 0:02.70 kblockd/1
49 root 15 -5 0 0 0 S 0 0.0 0:00.00 kacpid
50 root 15 -5 0 0 0 S 0 0.0 0:00.00 kacpi_notify
90 root 15 -5 0 0 0 S 0 0.0 0:00.00 ksuspend_usbd
96 root 15 -5 0 0 0 S 0 0.0 0:00.00 khubd
99 root 15 -5 0 0 0 S 0 0.0 0:00.00 kseriod
142 root 15 -5 0 0 0 S 0 0.0 0:00.10 kswapd0
143 root 15 -5 0 0 0 S 0 0.0 0:00.00 aio/0
144 root 15 -5 0 0 0 S 0 0.0 0:00.00 aio/1
650 root 15 -5 0 0 0 S 0 0.0 0:00.00 ata/0
651 root 15 -5 0 0 0 S 0 0.0 0:00.00 ata/1
652 root 15 -5 0 0 0 S 0 0.0 0:00.00 ata_aux
Just nu inte så farlig last iofs
----------------------------------------------------------------------------------

vad säger dessa tester? Är det bra eller dåligt?

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

[Dennis Holm]

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

vad har ni för diskar på er server om den pushar 1 gig/sec..

[Westman]

På en virtuell Debian i prod (fixed size disk i VMware ESX mot SAN-disk) så får jag 153 MB/s och i test (thin provisioning disk i VMware server på lokal disk) så får jag 9,2 MB/s. Det får mig att tro att din leverantör kör med thin provisioning eller liknande vilket i kombination med en normalt belastad host reducerar diskprestanda till den nivån.

Ursprungligen postat av mervinst

vad har ni för diskar på er server om den pushar 1 gig/sec..

Låter inte så orimligt. Jag kommer upp i 588 MB/s på en 4-diskars RAID6 med 2.5" SAS-diskar.

[Björklund]

Ursprungligen postat av mervinst

vad har ni för diskar på er server om den pushar 1 gig/sec..

Det var visserligen ett obelastat system. Men det är 15K SAS-diskar i RAID10 med många spindlar och mycket cache.

[Azone]

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

Vad är externa källor? Vad menas med det? Menar du t ex reklambanners på sidan som är långsamma eller liknande?

Eller något på servern som anropar något? Va skulle det kunna vara tex ?

[Björklund]

Ursprungligen postat av Azone

Vad är externa källor? Vad menas med det? Menar du t ex reklambanners på sidan som är långsamma eller liknande?

Eller något på servern som anropar något? Va skulle det kunna vara tex ?

Ex att ni kör curl-anrop eller liknande.

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

[abergman]

Ursprungligen postat av Azone

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.

Jo det hoppas jag med, bästa är väl att kolla med CityNetwork när de är planerat till att bli fixat.

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