Linux: servertje met performance goedkrijgen

[Boudewijn]

Hoi,

Ik heb momenteel thuis staan:

* debian sid
* core i3 3220T
* 16gb mem
* OCZ vertex SSD (met OS)
* Areca 1220 met 4x 2tb in raid5
* 4x 7200rpm disk aan de areca . standaard consumer spul (wd ofzo).
* Write back mode voor de raidset.
* VMs in KVM

Het raidvolume is 1 grote schijf geworden met ext4 erop. Mijn probleem is dat de performance van die raid-array om van te janken is; als ik op het lokale netwerk connect met een VMetje merk je dat je soms een 10 seconden delay hebt om een prompt te krijgen , het samba VMetje stikt gewoon in een filmpje kijken over LAN etc.
Een ls kost soms gewoon tijd, en dat is onder normale omstandigheden echt niet best.

Volgens virt-manager trekken dingen niet al teveel CPU en ik kan niet echt een VM pinpointen waar het aan zou moeten liggen; ergo ik ga die bak eens herinstalleren. Ik weet niet zo goed hoe ik dit moet pinpointen namelijk...

Heeft iemand tips voor de performance ? Het hoeft niet top te zijn, maar 2-3 megabyte per seconde uit een VMetje lezen is ruk. De storage hangt trouwens met losse virtuele disks via virtio (mount 9p gebruik ik) aan de VMs en is ook weer ext4.
Het gebruik van de VMtjes is qua disks verschillend: er is er een waar 1tb aan moet hangen en er zijn er waarbij de 8gb die ik als default gebruik meer dan genoeg is.

Wat ik sowieso ga doen is de BBU uit een andere machine halen (ook areca BBU) en in deze bak zetten zodat ik weer write through durf te doen.

[ Voor 5% gewijzigd door Boudewijn op 14-08-2013 19:04 ]

[jb044]

Kijk eens met iotop op de host of je een boosdoener kan vinden en daarna op de guests. Mijn ervaring is dat het met redelijk tot veel random io vrij snel dramatisch wordt, zoals je beschrijft.

[Boudewijn]

Ja klopt, maar de diskarray zou best snel moeten zijn en zo gek veel hosts draaien er niet op.
Uberhaupt: ik compartimenteer mijn dingen graag maar de meeste VMs staan de hele dag geen ruk te doen.

Zal zo even gaan kijken, dank voor de tip!

[RomeoJ]

Misschien denk ik te simpel, maar de laatste keer dat ik slechte performance had met een VM was omdat de virtualisatie-functie van de CPU niet aangezet was. Eigenlijk alle symptomen die jij ervaart, had ik ook last van.

Na deze functie (VT-x) aangezet te hebben in de BIOS was alles een stuk sneller, zoals je zou verwachten.

[jb044]

@work hebben we een IBM rack mount server met IBM raid controller en 1TB aan scsi disks in raid5, volgens mij 15k schijven. Zou dus behoorlijk rap moeten zijn, maar is het alles behalve. Je ziet gewoon af en toe de journal of flush toeslaan en de performance kelderen, nu is het een shared webserver met dus behoorlijk wat random io, maar toch zou ik dit aspect van Linux graag beter tunen. Die " nu ff niet!" momenten hebben me al heel wat hoofdbrekens gekost, dus ik snap waar je tegenaanloopt

@home was ik het zat en zit ik niet zo met angst voor het experimentele, dus heb ik een samsung 840pro ssd aangeschaft en flashcache van facebook voor mijn mdraid array gezet. Weg performance problemen, heb er andere problemen voor terug gekregen maar dat is hiervoor niet zo relevant. Het is dus in elk geval grotendeels een hardware beperking, maar toch tips om hier beter omheen te werken kan ook ik goed gebruiken!

[Boudewijn]

RomeoJ schreef op woensdag 14 augustus 2013 @ 19:36:
Misschien denk ik te simpel, maar de laatste keer dat ik slechte performance had met een VM was omdat de virtualisatie-functie van de CPU niet aangezet was. Eigenlijk alle symptomen die jij ervaart, had ik ook last van.

Na deze functie (VT-x) aangezet te hebben in de BIOS was alles een stuk sneller, zoals je zou verwachten.

Mja dan wil kvm helemaal niet meer zonder. Ennuh volgens /proc/cpuinfo staat vmx wel aan ja.


Ik kom er ook net achter dat een schijf van die array geklapt is... ik verwacht eigenlijk dan dat de buzzer aan gaat en hij gaat biepen. Laten we die ook maar eens vervangen dan . Zou dat veel verklaren? Kan me voorstellen dat als die kaart continu parity-shit moet doen dat dat ook niet goed is voor de performance.

[Xudonax]

Een dooie disk kan inderdaad redelijk wat vertraging veroorzaken ja Dat heb ik @ work wel gemerkt met de Dell RAID controller met RAID6... Schijfjes vervangen en het geheel ging al iets soepeler.

Daarnaast, is je Ext4 aangemaakt met de juiste stripe/stride size? Zonee, dan kan het ook goed zijn dat je FS met kleinere blokken werkt dan je controller, iets wat de performance óók niet ten goede komt volgens mij.

[Boudewijn]

Okay dan ga ik me daar eens op inlezen, interessant!

[CAPSLOCK2000]

Kijk als je dan toch bezig bent ook even naar de alignment van schijven. Een schijf met 4k-blokken verkeerd alignen kan ook een grote impact hebben.

[Verwijderd]

Hoeveel VM's heb je, en hoeveel CPU cores hebben die losse VM's toegewezen gekregen?
Als elke VM alle cores wil gebruiken, staat je systeem effectief constant te wachten. Wijs zo min mogelijk toe zodat elke VM zo snel mogelijk de resources kan gebruiken en weer vrijgeven.

[Boudewijn]

Ik heb 4 VM's en 4 virtuele CPUs in d ehost.
Elke VM heeft 1 CPU core geassigned.


ik ga kijken naar:

- iotop
- alignment
- kijken of ik CPU affinity kan gaan instellen, want volgens mij is dat wat je suggereert Cheatah... naast niet 4 CPUs per VM uitdelen, maar dat was al duidelijk .


Thx voor het meedenken heren!

[HollowGamer]

Ik begrijp het even niet, heb je een SW of HW RAID?

Zelf had ik ook performance problemen bij mijn eerste installatie:
SW RAID (geen HW-mogelijkheid)
HDD Encryptie
Ubuntu Server 12.04 AMD64
SSD (OS)
Twee Green HDD's (LVM)
8GB RAM

Na een herinstallatie, gebruik ik nu de allerlaatste Ubuntu Server versie (geen LTS) en heb ik de SW-raid eraf gegooid. Encryptie/LVM gebruik ik wel nog. De performance schoot opeens erg omhoog! Zelfs nu de SSD eruit is, is de snelheid vrijwel hetzelfde gebleven.

Verder is mijn ervaring met een i3* niet zo positief met VM's. Daarmee wil ik niet zeggen dat het niet sneller kan, alleen de prestaties met een i5/i7 CPU zullen waarschijnlijk wat hoger liggen.

Je kunt ook nog andere kleine trucjes uithalen: noatime flags. GPT, etc.
Wat zijn trouwens de netwerk-prestaties? Aangezien je bestanden ophaalt over SMB.

Anyway, aan de overige tips heb je waarschijnlijk iets meer.

[Zuig]

Raid 5 en KVM werken niet lekker samen, ik ervaar dit hetzelfde met soft-RAID (MDADM) en Debian (was vergelijkbaar op ubuntu) Test gedaan met HW-RAID op Adaptec controller maar exact hetzelfde. ik kan met ca. 45 Mb/s schrijven op een guest, met 500+ op de host.

test gedaan met RAID 10 (MDADM) en ja hoor performace, ca 450+ Mb/s.

ter referentie de operating systems van de guest staan op een MDADM RAID 1 volume met LVM2 en hier ook perfecte performance.

Ik ga nu zelf de samba server verplaatsen naar de host, ondanks dat ik het host OS liever kaal wil hebben, maar ja als ik een nieuw OS wil installeren dan hoef ik alleen maar een backup te hebben van de smb.conf, dus daar komen we ook wel overheen.

dus: tip van mij, mount je RAID 5 volume eens op de host en kijk daar eens naar de performance, ik denk dat het er dan allemaal heel anders uit zal zien...

Het volgende commando kan je gebruiken voor een testfile (100Mb):
dd if=/dev/zero of=testfile1 bs=1M count=100

[Hero of Time]

Zuig schreef op dinsdag 20 augustus 2013 @ 21:45:
Raid 5 en KVM werken niet lekker samen, ik ervaar dit hetzelfde met soft-RAID (MDADM) en Debian (was vergelijkbaar op ubuntu) Test gedaan met HW-RAID op Adaptec controller maar exact hetzelfde. ik kan met ca. 45 Mb/s schrijven op een guest, met 500+ op de host.

test gedaan met RAID 10 (MDADM) en ja hoor performace, ca 450+ Mb/s.
Het volgende commando kan je gebruiken voor een testfile (100Mb):
dd if=/dev/zero of=testfile1 bs=1M count=100

Tja, als je een snelheid op de host haalt van 500 MB/s terwijl je maar een relatief klein bestand gaat schrijven, dan haal je de snelheid van je cache, niet de werkelijke disk performance. Maak eens een bestand van 20 GB aan, dan kan je pas zeggen wat je snelheid is.
Zo zou ik ook kunnen zeggen dat m'n HDD een read snelheid heeft van 4500 MB/s. Terwijl ik niet van de schijf zelf lees, maar z'n cache.

[Verwijderd]

Heb jij de hele reactie gelezen dan? Ik hield al op na "Raid 5 en KVM werken niet lekker samen".
Maar inderdaad, performance testen doe je niet met dd, maar met bijvoorbeeld bonnie++.

[CAPSLOCK2000]

Als je toch aan het tweaken bent, lees ook even wat over schedulers.

Je kernel optimaliseert lees- en schrijfacties. Je VM heeft echter geen compleet beeld, er zijn ook nog andere VMs bezig. Je kan de scheduler van je VM uit te schakelen en het aan de host overlaten.
Met name bij SSDs kan dat de moeite waard zijn.

[Wolfboy]

Verwijderd schreef op dinsdag 20 augustus 2013 @ 23:31:
Heb jij de hele reactie gelezen dan? Ik hield al op na "Raid 5 en KVM werken niet lekker samen".

2nd that...

Naar mijn ervaring wil XFS overigens een stuk beter performen dan Ext4 voor grote raid volumes, mogelijk ook nog een optie voor je. Beiden doen het opzich wel maar ik had minder gezeur met trage journals bij XFS wat toch wel merkbaar kan zijn afhankelijk van het type load.

@TS: bekijk eens wat je IO queue lengte is, dat geeft al heel snel aan of je een IO probleem hebt.

iostat -x 5
...

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
xvdap1            0.00     4.38    0.00    1.39     0.00    23.11    33.14     0.00    2.29    0.00    2.29   1.14   0.16
xvdb              0.00    61.55    0.00   57.77     0.00   477.29    16.52     0.02    0.33    0.00    0.33   0.33   1.91

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          10.73    0.00    6.88    2.43    0.00   79.96

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
xvdap1            0.00     0.00    0.00    0.61     0.00     2.43     8.00     0.00    0.00    0.00    0.00   0.00   0.00
xvdb              0.00    85.83    0.00   84.82     0.00   682.59    16.10     0.03    0.34    0.00    0.34   0.34   2.91

[Hero of Time]

Verwijderd schreef op dinsdag 20 augustus 2013 @ 23:31:
Heb jij de hele reactie gelezen dan? Ik hield al op na "Raid 5 en KVM werken niet lekker samen".
Maar inderdaad, performance testen doe je niet met dd, maar met bijvoorbeeld bonnie++.

Ja, ik heb de hele draad gelezen. Maar hij heeft nog niets gepost waarbij hij z'n performance heeft aangepast. Hij heeft het er alleen over dat 't in z'n VMs ruk is, wat niet zo vreemd is afhankelijk van de manier hoe de VM de boel probeert weg te schrijven. Te kleine blocks en het duurt langer om ze te maken, te grote en je mist de snelheid van de cache.

Met dd kan je wel een ruwe schatting maken van je performance, zo heb ik op 't werk een flink verschil gezien in performance als er multipath wordt gebruikt naar het SAN toe over een 10 Gb link.

[Thc_Nbl]

Nou in het kort dan maar even wat tips.

/quote als ik op het lokale netwerk connect met een VMetje merk je dat je soms een 10 seconden delay hebt om een prompt te krijgen
probleem = DNS niet goed, of dns opzetten of overal hosts files gaan gebruiken of UseDNS No in sshd_config zetten.
gezien ik er hier vanuit gaat dat dat je hier bedoelde traag met login .

controleer al je partities op alignment
parted /dev/sdX align-check optimal 1 ( waarbij 1 staat voor de eerste partities )
( resultaat is b.v. prompt: 1 aligned )

stap af van debian Sid, hou het bij stable. ( of Debian of ubuntu, mijn voorkeur Debian )
en mijn advies, doe geen raid5, hou het simpel met een Raid 1 of 10 heb je gelijk veel beter performance.
raid5 heb ik niets dan ellende mee gehad op linux.

Als trouwens je quote niet klopt, dan zou ik het eens met een ander virtualisatie gebruiken, b.v. Xen.
en kijken wat dat doet, dan vermoed ik problemen met de driver ( kernel) combinatie van je raid controller en de Vm software.

[Zuig]

Hero of Time schreef op woensdag 21 augustus 2013 @ 08:38:
[...]

Ja, ik heb de hele draad gelezen. Maar hij heeft nog niets gepost waarbij hij z'n performance heeft aangepast. Hij heeft het er alleen over dat 't in z'n VMs ruk is, wat niet zo vreemd is afhankelijk van de manier hoe de VM de boel probeert weg te schrijven. Te kleine blocks en het duurt langer om ze te maken, te grote en je mist de snelheid van de cache.

Met dd kan je wel een ruwe schatting maken van je performance, zo heb ik op 't werk een flink verschil gezien in performance als er multipath wordt gebruikt naar het SAN toe over een 10 Gb link.

Je mist de strekking van mijn stuk, wat ik probeerde aan te geven is dat ik een zeer groot verschil zie tussen R5 en R1 performance gezien vanuit een guest gezien. Los van hoe dit door de hypervisor naar de host wordt doorgezet is dit raar. Ik wil Raid 5 blijven gebruiken voor mijn mass-storage dus ga het verplaatsen naar de host, dat is dus mijn personlijke aanpassing.

Een andere optie, zoals die zowel Thc_Nbl en ik aangeven is RAID 10 of 1

[Hero of Time]

Zuig schreef op woensdag 21 augustus 2013 @ 11:27:
[...]


Je mist de strekking van mijn stuk, wat ik probeerde aan te geven is dat ik een zeer groot verschil zie tussen R5 en R1 performance gezien vanuit een guest gezien. Los van hoe dit door de hypervisor naar de host wordt doorgezet is dit raar. Ik wil Raid 5 blijven gebruiken voor mijn mass-storage dus ga het verplaatsen naar de host, dat is dus mijn personlijke aanpassing.

Een andere optie, zoals die zowel Thc_Nbl en ik aangeven is RAID 10 of 1

Er is ergens in de communicatie wat misgegaan lijkt 't op. Ik verwijst met "hij" naar de TS, niet naar jou . Dat is niet helemaal duidelijk, dus bij deze .

Wat jij doet en gaat doen is nu niet echt belangrijk, jij bent niet degene die hier vraagt om z'n performance te laten verbeteren in VMs.

[Wolfboy]

Zuig schreef op woensdag 21 augustus 2013 @ 11:27:
[...]


Je mist de strekking van mijn stuk, wat ik probeerde aan te geven is dat ik een zeer groot verschil zie tussen R5 en R1 performance gezien vanuit een guest gezien. Los van hoe dit door de hypervisor naar de host wordt doorgezet is dit raar. Ik wil Raid 5 blijven gebruiken voor mijn mass-storage dus ga het verplaatsen naar de host, dat is dus mijn personlijke aanpassing.

Een andere optie, zoals die zowel Thc_Nbl en ik aangeven is RAID 10 of 1

No offense maar deze uitspraak is gebaseerd op een implementatie van een raid 5 array door software/hardware en is geen garantie over alle controllers. Gegeven een goede controller hoeft de performance impact van raid 5 echt niet bijzonder groot te zijn en is het prima geschikt voor VM's met wat raid cache op de kaart.

[Zuig]

Wolfboy schreef op woensdag 21 augustus 2013 @ 12:20:
[...]
No offense maar deze uitspraak is gebaseerd op een implementatie van een raid 5 array door software/hardware en is geen garantie over alle controllers. Gegeven een goede controller hoeft de performance impact van raid 5 echt niet bijzonder groot te zijn en is het prima geschikt voor VM's met wat raid cache op de kaart.

Daar ben ik het dus niet mee eens, waarom functioneerd R1 en R10 perfect terwijl R5 niet naar verwachting werkt, zelfde disken en zelfde controller...

@Hero of Time: clear

ik denk dat de TS nu wel door heeft dat er voldoende mogelijkheden zijn, los van problemen en uitdagingen van mijzelf en anderen ben ik erg benieuwd wat er gebeurd met de performance als de TS een test doen met R1 of R10

[Hero of Time]

Zuig schreef op woensdag 21 augustus 2013 @ 12:29:
[...]


Daar ben ik het dus niet mee eens, waarom functioneerd R1 en R10 perfect terwijl R5 niet naar verwachting werkt, zelfde disken en zelfde controller...

Dat is bij jou het geval en dat is eenvoudig te verklaren: R5 is een leuke toevoeging, maar niet de core functie van die kaart. Net zoals er vele kaarten zijn die R6 kunnen, maar dat niet optimaal doen. Gevolg: brakke performance.

[Zuig]

Hero of Time schreef op woensdag 21 augustus 2013 @ 12:52:
[...]

Dat is bij jou het geval en dat is eenvoudig te verklaren: R5 is een leuke toevoeging, maar niet de core functie van die kaart. Net zoals er vele kaarten zijn die R6 kunnen, maar dat niet optimaal doen. Gevolg: brakke performance.

Alle disken hangen aan de controller(s) met JBOD, Raid config met MDADM. Dan gaat jouw opmerking (volgens mij) niet op...

[Hero of Time]

Nope, geld alleen met hardware-matige oplossing via de kaart zelf, niet als je gebruik maakt van software-RAID. Dan moet je even verder kijken wat de bottleneck is (CPU?).

[Thc_Nbl]

Even nog inhakende over die raid 5 of raid 1(0)

ik heb alles raid 1 draaien onder Linux, het grootste voordeel is dan, mist je alle drivers in je initrd hebt zitten. gaat b.v. je mainboard stuk, pak een willekeurige pc of server hand de boel over en draaien maar.
kan je raid controller niet over, pak 1 schijf van de raid 1 en ook dan kan je opstarten, mits je de schijf natuurlijk ergens kan aansluiten.

mijn ervaring is, met meerder raid controllers, dell, hp, 3ware, dat als er wat gebeurd en raid 5 gaat stuk, is er maar 1 optie alle her installeren en backup terugzetten. ik heb zo'n 5 "vage" crashes gehad, door bugs of defecte hardware, waarna ik kon herinstalleren. met de raid 1, ook wel defecten gehad met servers, maar dan was ik binnen 30-60 min weer up en running, wel even met 1 schijf maar wel draaien.
dan is even de druk van de ketel bedrijf kan weer door, en ik regel de rest.

maar goed het is net waarvoor je het gaat gebruiken, ik heb veel databases draaien en raid 5 en databases moet je gewoon niet willen (doen), genoeg over te vinden op het internet zou ik zeggen.
als je puur file server wilt draaien is raid 5 ( of 6) weer prima, het is maar net wat je wilt en hoe je het wilt inzetten en gebruiken.

De keuze is, aan wat je verwachtingen, moeten zijn.

[Hero of Time]

Thc_Nbl schreef op woensdag 21 augustus 2013 @ 22:16:
Even nog inhakende over die raid 5 of raid 1(0)

...

Maar goed het is net waarvoor je het gaat gebruiken, ik heb veel databases draaien en raid 5 en databases moet je gewoon niet willen (doen), genoeg over te vinden op het internet zou ik zeggen.
als je puur file server wilt draaien is raid 5 ( of 6) weer prima, het is maar net wat je wilt en hoe je het wilt inzetten en gebruiken.

RAID5/6 en databases is net wat je nodig hebt. Als je met een grote database te maken hebt, is RAID1 of 10 niet altijd een optie omdat je niet genoeg storage kan creëren. Op 't werk hebben we nu een database op ons SAN draaien, maar vraagt net iets te veel dan we willen en ik ga 'm dan ook verhuizen naar een fysieke machine met RAID6 zodat de rest geen last er meer van heeft, en toch genoeg opslag heb om de DB op te kunnen zetten. Het is een afweging die je maakt. Iig 10x beter dan wat 't ooit was met RAID0 (dat hebben we geweten! ).

[Wolfboy]

Zuig schreef op woensdag 21 augustus 2013 @ 12:29:
[...]


Daar ben ik het dus niet mee eens, waarom functioneerd R1 en R10 perfect terwijl R5 niet naar verwachting werkt, zelfde disken en zelfde controller...

Omdat je blijkbaar een controller hebt die niet goed performt met raid 5 (of doel je op software, dan is je software niet slim genoeg en/of cpu niet snel genoeg).

Met een goede hardware controller met goede processor is het performance verschil niet bijzonder groot, nog steeds wel aanwezig maar veel meer dan N versus N-1 (waarbij N het aantal schijven is) zou het verschil tussen raid 1/10 en 5 niet moeten zijn.

Kijk bijvoorbeeld eens naar benchmarks van controller geproduceerd door LSI of Areca.

[Verwijderd]

Even over Raid5 (parity raid) vs Raid1(0) (non-parity raid):

Ik lees in dit topic echt een hoop tegenstrijdige adviezen, die allemaal tot een bepaalde hoogte zowel kloppen als niet kloppen.

Het is allemaal niet zo simpel over 1 kam te scheren. Uiteindelijk heeft het er allemaal mee te maken wat je precies wilt bereiken.
Ik zal proberen in wat simpele taal een en ander te verduidelijken.

Laten we even bij het begin starten:
We kennen 2 soorten IO acties, nl: Read en Write.

Wanneer ik een Raid1 IO subsysteem heb met 2 disken gebeurt het volgende in het IO subsysteem:
100 Read IO acties in het OS --> Blijven 100 Read IO acties
100 Write IO acties in het OS --> Worden 200 Write IO acties in het IO subsysteem (iedere IO actie moet 2x worden weggeschreven, nl. op beide disken).


Wanneer ik een Raid5 IO subsysteem heb met 3 disken gebeurt het volgende in het IO subsysteem:
100 Read IO acties in het OS --> Blijven 100 Read IO acties
100 Write IO acties in het OS --> Kunnen zomaar eens 400 IO acties worden in het IO subsysteem

Dit laatste verhaal komt doordat in grote lijnen het volgende gebeurd:
- page wordt weggeschreven naar disk (bv. 16KB)
- Vervolgens moet de complete stripe unit, waarin deze page valt, opnieuw worden ingelezen (bv 128KB)
- Parity over deze stripe unit moet berekend worden
- De parity data moet weggeschreven worden naar de parity disk

Een database applicatie die met kleine pages werkt (bv. MySQL heeft 16KB pages), kan nog al wat performance hinder ondervinden van een Raid5 doordat de Raid5 penalty voor extra overhead zorgt op zowel de disken als op een reken unit (bv. CPU bij software raid).

Gaat het dus om een database die erg veel performance nodig heeft en die een vloeiende gebruikers ervaring moet hebben, is het verstandig om geen parity raid te gebruiken. Echter gaat dit ook weer niet altijd op omdat sommige SAN vendors (bv. NetApp) weer bepaalde optimalisaties doorvoeren (bv. units die hardwarematig parity bereken of NVRam optimalisaties) waardoor parity raid niet zo'n onwijze performance impact zal hebben.

Op de huis tuin en keuken hardware zal je altijd wel een performance impact merken tussen een parity raid en non-parity raid.

Belangrijk is gewoon altijd afvragen bij een applicatie wat voor performance deze moet leveren, en dan pas bepalen hoe je het IO subsysteem voor die specifieke applicatie gaat inrichten/sizen. Doe je dat niet dan zul je met je keuzes moeten leven, of later evt. het risico lopen op een migratie.


Heb even getracht simpel uit te leggen hoe zaken werken, echter mist dit verhaal nog behoorlijk wat diepgang, maar heb daar geen tijd voor nu om alles zo diep uit te werken.

[Boudewijn]

CAPSLOCK2000 schreef op woensdag 14 augustus 2013 @ 21:11:
Kijk als je dan toch bezig bent ook even naar de alignment van schijven. Een schijf met 4k-blokken verkeerd alignen kan ook een grote impact hebben.

Even kijken, ik heb:
De areca vormt een 6tb volume van de 4x2tb disks.

Stripe Size 128KBytes
Block Size 4096Bytes

Mijn huidige fs instellingen:

root@blablabla # tune2fs -l /dev/sdb1
tune2fs 1.42.5 (29-Jul-2012)
Filesystem volume name:   <none>
Last mounted on:          /raid
Filesystem UUID:          384713ca-6ecb-49ae-a760-a5e49c046ef7
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              183144448
Block count:              1465135424
Reserved block count:     0
Free blocks:              506201996
Free inodes:              181872631
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      674
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         4096
Inode blocks per group:   256
Flex block group size:    16
Filesystem created:       Sat Nov 10 02:47:27 2012
Last mount time:          Mon Aug 19 20:46:45 2013
Last write time:          Mon Aug 19 20:46:45 2013
Mount count:              26
Maximum mount count:      -1
Last checked:             Sat Nov 10 02:47:27 2012
Check interval:           0 (<none>)
Lifetime writes:          5838 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      e6718081-8218-4b00-a950-5a38eb70a003
Journal backup:           inode blocks

Ik heb alle data even overgenomen wellicht dat mensen hier nog wat interessants aan zien....

Het gaat dus om 4k blocks, volgens mij zou dat juist goed moeten alignen omdat je dan niet meer raid blocks leest per fs block. Agree, of mis ik eea?

HollowGamer schreef op donderdag 15 augustus 2013 @ 14:19:
Ik begrijp het even niet, heb je een SW of HW RAID?

Zelf had ik ook performance problemen bij mijn eerste installatie:
SW RAID (geen HW-mogelijkheid)
HDD Encryptie
Ubuntu Server 12.04 AMD64
SSD (OS)
Twee Green HDD's (LVM)
8GB RAM

Mja ik heb geen software raid, maar een dikke raid controller. En geen hdd encryptie, domweg omdat ik inderdaad ook geen performance issues wil.

Verder is mijn ervaring met een i3* niet zo positief met VM's. Daarmee wil ik niet zeggen dat het niet sneller kan, alleen de prestaties met een i5/i7 CPU zullen waarschijnlijk wat hoger liggen.

Mja als je software raid draait is de performance altijd minder. Het is een thuis-servertje, dus de zuinigheid van de 3220T is wel relevant voor me. Colocated hangt wat ander spul .

Je kunt ook nog andere kleine trucjes uithalen: noatime flags. GPT, etc.
Wat zijn trouwens de netwerk-prestaties? Aangezien je bestanden ophaalt over SMB.

Anyway, aan de overige tips heb je waarschijnlijk iets meer.

Iig thanks . Gigabit, maar gezien het feit dat een ssh-prompt al even kan duren denk ik dat het netwerk niet de bottleneck is. De load is bij tijd en wijlen ook fors hoog (>15).
Netwerk ga ik wel debuggen, maar later.

CAPSLOCK2000 schreef op woensdag 21 augustus 2013 @ 00:18:
Als je toch aan het tweaken bent, lees ook even wat over schedulers.

Je kernel optimaliseert lees- en schrijfacties. Je VM heeft echter geen compleet beeld, er zijn ook nog andere VMs bezig. Je kan de scheduler van je VM uit te schakelen en het aan de host overlaten.
Met name bij SSDs kan dat de moeite waard zijn.

Goed punt. alhoewel het hier om disk-based raid gaat is het alsnog nuttig om die schedulers eruit te slopen.

Wolfboy schreef op woensdag 21 augustus 2013 @ 00:36:
@TS: bekijk eens wat je IO queue lengte is, dat geeft al heel snel aan of je een IO probleem hebt.

Ik zal straks eens een 'stress-ding' aanzetten (sabnzb+ in een VMetje) en dan de io queue checken. Thx.

Thc_Nbl schreef op woensdag 21 augustus 2013 @ 11:12:
Nou in het kort dan maar even wat tips.


probleem = DNS niet goed, of dns opzetten of overal hosts files gaan gebruiken of UseDNS No in sshd_config zetten.
gezien ik er hier vanuit gaat dat dat je hier bedoelde traag met login .

Nop dat is het niet, staat al uit en als de server het rustig heeft heb ik ook instant login .

controleer al je partities op alignment
parted /dev/sdX align-check optimal 1 ( waarbij 1 staat voor de eerste partities )
( resultaat is b.v. prompt: 1 aligned )

Gaan we even naar kijken .

stap af van debian Sid, hou het bij stable. ( of Debian of ubuntu, mijn voorkeur Debian )
en mijn advies, doe geen raid5, hou het simpel met een Raid 1 of 10 heb je gelijk veel beter performance.
raid5 heb ik niets dan ellende mee gehad op linux.

Ik heb eigenlijk maar een paar x gedoe gehad met raid5. Raid1 is zonde van de disks voor wat ik doe (ik doe weinig DB meuk).

Als trouwens je quote niet klopt, dan zou ik het eens met een ander virtualisatie gebruiken, b.v. Xen.
en kijken wat dat doet, dan vermoed ik problemen met de driver ( kernel) combinatie van je raid controller en de Vm software.

KVM is redelijk stable, en de areca's worden ook al jaren prima ondersteund. Juist spul zoals Xen wil ik niet ik vind KVM erg charmant en leuk te managen... itt xen en de andere bekende oplossingen.

Hero of Time schreef op woensdag 21 augustus 2013 @ 12:52:
[...]

Dat is bij jou het geval en dat is eenvoudig te verklaren: R5 is een leuke toevoeging, maar niet de core functie van die kaart. Net zoals er vele kaarten zijn die R6 kunnen, maar dat niet optimaal doen. Gevolg: brakke performance.

Lijkt me hier niet het geval. Iets met geen hakkie-takkie kaartje.

@Gsmurf: meeste is idd bekend maar ik ga hem zo nog even lezen , dank voor de toelichting.

[Wolfboy]

Verwijderd schreef op donderdag 22 augustus 2013 @ 15:13:
Wanneer ik een Raid5 IO subsysteem heb met 3 disken gebeurt het volgende in het IO subsysteem:
100 Read IO acties in het OS --> Blijven 100 Read IO acties
100 Write IO acties in het OS --> Kunnen zomaar eens 400 IO acties worden in het IO subsysteem

Dit laatste verhaal komt doordat in grote lijnen het volgende gebeurd:
- page wordt weggeschreven naar disk (bv. 16KB)
- Vervolgens moet de complete stripe unit, waarin deze page valt, opnieuw worden ingelezen (bv 128KB)
- Parity over deze stripe unit moet berekend worden
- De parity data moet weggeschreven worden naar de parity disk

Daarom heb je ook write cache en zorg je voor goede alignment zodat dit niet gebeurd. Als je 400 IO acties doet voor 100 IO acties bij je OS dan heb je een extreem waardeloze raid 5 implementatie of veel te weinig cache en heel veel pech.

Je feiten kloppen overigens niet helemaal, bij raid 5 heb je geen "parity disk", alle disks zijn parity disks.

Een database applicatie die met kleine pages werkt (bv. MySQL heeft 16KB pages), kan nog al wat performance hinder ondervinden van een Raid5 doordat de Raid5 penalty voor extra overhead zorgt op zowel de disken als op een reken unit (bv. CPU bij software raid).

Prima op te lossen met raid cache.

Gaat het dus om een database die erg veel performance nodig heeft en die een vloeiende gebruikers ervaring moet hebben, is het verstandig om geen parity raid te gebruiken. Echter gaat dit ook weer niet altijd op omdat sommige SAN vendors (bv. NetApp) weer bepaalde optimalisaties doorvoeren (bv. units die hardwarematig parity bereken of NVRam optimalisaties) waardoor parity raid niet zo'n onwijze performance impact zal hebben.

Genoeg theorie, laten we even wat testresultaten erbij pakken:
reviews: Comparison of nine Serial ATA RAID 5 adapters

Neem bijvoorbeelde de Areca ARC-1160 met 1GB cache (helaas wat ouder model, maar ik zag even geen nieuwere benchmarks):
Raid 10 met 4 schijven: ~595 IOps, 880MB/s, ruimte: 148 GB
Raid 5 met 4 schijven: ~560 IOps, 840MB/s, ruimte: 222 GB
Raid 5 met 6 schijven: ~670 IOps, 950MB/s, ruimte 370 GB

Raid 5 is dus zeker prima bruikbaar voor databases en VM's, vooral als je veel schijfruimte nodig hebt.
Als je echt veel performance nodig hebt en niet teveel diskspace eisen hebt dan moet je gewoon direct voor SSD's gaan.

[Boudewijn]

Mensen, zouden we aub mijn issues kunnen bespreken ipv de algemene raid5 geschiktheid?

[Hero of Time]

Verder gebrabbel over RAID settings en performance graag in Opslagtechnologie plaatsen dus. Hier hoort 't niet.

[Boudewijn]

Wolfboy schreef op woensdag 21 augustus 2013 @ 00:36:

@TS: bekijk eens wat je IO queue lengte is, dat geeft al heel snel aan of je een IO probleem hebt.

...

Net even een VMetje gestart en ik zie dat ik inderdaad forse await queues krijg met iostat:

^Cboudewijn@leiden:~$ sudo iostat -x  5
Linux 3.8.0-27-generic (leiden)         08/22/2013      _x86_64_        (4 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          22.54    0.01    3.10    0.44    0.00   73.91

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.28     0.86    0.50    1.48    20.31    47.93    68.84     0.02   11.70    4.42   14.18   0.41   0.08
sdb               0.00     0.23    1.43    3.17    68.72    97.03    72.03     0.17   37.25   15.83   46.93   3.76   1.73

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          13.00    0.00    6.45   19.60    0.00   60.94

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.00     0.00    0.00    1.60     0.00    63.20    79.00     0.00    0.50    0.00    0.50   0.50   0.08
sdb               0.00     0.20   32.40  119.20   560.00   683.20    16.40    56.21  323.13   12.67  407.52   3.44  52.08

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          13.65    0.00    1.31   17.28    0.00   67.76

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.00     1.40    0.00    3.00     0.00    17.60    11.73     0.00    0.00    0.00    0.00   0.00   0.00
sdb               0.00     0.20  146.80   39.80  5585.60   691.20    67.28     8.41   83.77    8.88  359.98   2.79  52.00

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.68    0.00    0.60    1.56    0.00   94.16

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.00     0.40    0.00    0.40     0.00     3.20    16.00     0.00    0.00    0.00    0.00   0.00   0.00
sdb               0.00     0.20    2.20   13.80    17.60   129.60    18.40     0.60   37.55   18.91   40.52   3.50   5.60

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           2.77    0.00    0.45    0.25    0.00   96.52

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.00     0.00    0.00    0.40     0.00     3.20    16.00     0.00    0.00    0.00    0.00   0.00   0.00
sdb               0.00     0.20    0.00    3.20     0.00    30.40    19.00     0.04   12.50    0.00   12.50   3.75   1.20

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.15    0.00    0.75    0.45    0.00   95.65

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.00     1.60    0.00    0.40     0.00     8.00    40.00     0.00    0.00    0.00    0.00   0.00   0.00
sdb               0.00     0.00    0.00    2.00     0.00    89.60    89.60     0.09   45.20    0.00   45.20  10.80   2.16

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.55    0.00    0.55    0.25    0.00   95.65

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.00     0.00    0.00    0.40     0.00     2.40    12.00     0.00    0.00    0.00    0.00   0.00   0.00
sdb               0.00     0.20    0.00    3.20     0.00    29.60    18.50     0.06   19.25    0.00   19.25   4.50   1.44

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.26    0.00    0.60    0.75    0.00   95.38

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.00     0.80    0.00    0.40     0.00     4.80    24.00     0.00    0.00    0.00    0.00   0.00   0.00
sdb               0.00     0.20    0.60    5.00     2.40    84.80    31.14     0.12   21.86    5.33   23.84   6.86   3.84

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           2.87    0.00    0.70    0.60    0.00   95.83

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.00     1.80    0.80    0.60     5.60     9.60    21.71     0.00    0.57    0.00    1.33   0.57   0.08
sdb               0.20     0.20    2.00   27.00    61.60   127.20    13.02     4.98  171.56   14.40  183.20   2.70   7.84

Ik ga eens inlezen wat die getallen exact betekenen .