Archive for juni 2015
Thoughts about file location and performance
MyDefrag system scripts put the MFT$ and directories at one third of the size of the disk for better access performance.
Creating a zone of frequently accessed files together also serves as a performance enhancer so the disk takes up less time to get from one file to the other.
Looking at recently accessed files on my laptop show mostly browser cache in /home and system logfiles in /var. The OS files would only be used once at startup, binaries only when starting a program. For a single user system it seems there’s no benefit to optimising the location of files on disk beyond keeping /var and /home close together on disk. (done by using separate partitions for these and using a separate partition for data to keep that out of /home)
On a file server it might benefit to create a data partition of about a third the size of the disk, then a partition for /var, then another partition for data (combining both data partitions through LVM). Then the disk arm would be closer to the files on average, reducing wear and tear.
On a multi user server create the /home partition after / and /var and link the user’s data directories in the profile to a separate data partition.
I’ve done this with Windows terminal servers where I used a separate profiles partition (can be done by modifying the system and moving files in save mode, then creating links of the original directories) after the OS, swap and program files partitions and using policies to link document directories to the the file server (had to be done anyway, otherwise it would have been a larger data partition).
One of the biggest benefits was preventing the OS partition of filling up by users (even local system accounts).
Too bad the Windows profiles directory can’t be linked to a network location like on a *nix machine, creating a NFS link to /home on another server.
Revive old home server
After replacing the failing home server with a decent Synology NAS I got my hands on a HP Storageworks Data Vault X510.
Being curious I wanted to see if I could get it to run with Debian so I could do some tests with mdadm.
Turns out it’s not too difficult.
-place the harddisk to install it on in a standard PC and use that to install the i386 version of Debian (in this case it was Jessie)
-add a fixed IP address for eth0 in /etc/networking/interfaces (the Realtek r8168 (seen as r8169) couldn’t get a DHCP address for some reason)
-place the disk in the X510 and boot
-login with SSH (you did install it, didn’t you?)
-have fun with it
korte mdadm RAID test
Even een korte test gedaan na de Debian Jessie installatie op een HP Storageworks Data Vault X510 (voormalige Windows home server).
Ik wilde zelf eens testen wat het verschil in snelheid is in (random) read en write op mdadm RAID0, RAID5, en RAID10 met layout n2, o2, f2.
De 4 disks zijn een Seagate 250GB en 3 80GB Hitachi (IBM Deskstar) schijven die ik kon misbruiken voor de test. Geen hoogvliegers maar voldoende voor mijn test aangezien het niet om maximale snelheid gaat.
Debian is geïnstalleerd op de Seagate in een 64GB partitie met daarachter 3 4GB partities. De overige schijven heb ik ook 3 partities van 4GB gegeven.
Array md5 is een RAID5 van sda, b, c en d5, md0 is een RAID0 van sda, b, c en d7. Partities sda, b, c, d6 gebruikte ik om telkens een RAID10 met afwisseled layout n2, o2, f2 te maken.
Een snelle blik met hdparm -t /dev/sd[abcd] laat een snelheid van 95 MB/sec zien voor de Seagate en 73 MB/sec voor de Hitachi’s.
Met /dev/md0, 5 en 10 kwam het volgende (gemiddeld):
md0: 253 MB/sec
md5: 180 MB/sec
md10 (n2): 137 MB/sec
md10 (o2): 135 MB/sec
md10 (f2): 232 MB/sec
Uit de simpele test met iozone kwam het volgende:
RAID0;
Command line used: iozone -R -b raid0 -f 0/iodump -i 0 -i 2 -s 1024M
Output is in kBytes/sec
Time Resolution = 0.000001 seconds.
Processor cache size set to 1024 kBytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.
kB reclen write rewrite random read random write
1048576 4 256342 261384 2105037 17029
RAID5;
Command line used: iozone -R -b raid5 -f 5/iodump -i 0 -i 2 -s 1024M
Output is in kBytes/sec
Time Resolution = 0.000001 seconds.
Processor cache size set to 1024 kBytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.
kB reclen write rewrite random read random write
1048576 4 123690 125667 2080483 6000
RAID10 –layout=n2;
Command line used: iozone -R -b raid10-n2 -f 10/iodump -i 0 -i 2 -s 1024M
Output is in kBytes/sec
Time Resolution = 0.000001 seconds.
Processor cache size set to 1024 kBytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.
kB reclen write rewrite random read random write
1048576 4 130257 131265 2085801 7990
RAID10 –layout=o2;
Command line used: iozone -R -b raid10-o2 -f 10/iodump -i 0 -i 2 -s 1024M
Output is in kBytes/sec
Time Resolution = 0.000001 seconds.
Processor cache size set to 1024 kBytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.
kB reclen write rewrite random read random write
1048576 4 132550 132746 2077713 8075
RAID10 –layout=f2;
Command line used: iozone -R -b raid10-f2 -f 10/iodump -i 0 -i 2 -s 1024M
Output is in kBytes/sec
Time Resolution = 0.000001 seconds.
Processor cache size set to 1024 kBytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.
kB reclen write rewrite random read random write
1048576 4 119730 116639 2110766 6574
De conclusie uit deze test is dat RAID0 het snelste is met sequential en random write, random read is ongeveer gelijk met RAID0, 5 en 10. RAID10 layout near en offset is ongeveer gelijk aan elkaar en iets sneller met write dan layout far.
Het verschil zal misschien groter worden met grotere partities.
Drie disks
Een hdparm -t test met RAID10, n2 op partities sdb,c, en d6 laat een snelheid van 101 MB/sec zien. De regel n/2 geldt dus ook voor een oneven aantal disks in RAID10.
Iozone laat hierbij het volgende zien:
kB reclen write rewrite random read random write
1048576 4 97125 98339 2102168 12869
Opvallend is de hogere snelheid bij random write, waarschijnlijk omdat er nu minder keuze is waar een blok geschreven kan worden op een disk.
Wat bij een RAID10 op 2 disks ook opvalt is dat bij de hdparm test de snelheid gelijk is van een enkele disk terwijl via bwm-ng wel te zien is dat er van beide schijven gelezen wordt.
Iozone test:
kB reclen write rewrite random read random write
1048576 4 66043 66612 2103323 8655
Random write zakt nu weer in maar is wel iets sneller dan met 4 disks in raid. Zou een oneven aantal disks in RAID10 effectiever zijn voor gebruik met databases of virtuele machines?
Test met de 3 Hitachi’s in RAID10
Dit is interessant genoeg om eens de drie layout opties te testen met partities van 37GB. De snelheid is drastisch minder vanaf de helft van de disk dus gebruik ik niet de volledige schijf. Dit laat nog eens duidelijk zien dat wanneer snelheid het belangrijkste is, het beter is om niet 100% van de disk te gebruiken. En anders gewoon het geld neerleggen voor SSD’s. :-)
(tijdens de sync ging de snelheid bij 92% ineens heel snel van 67 MB/s naar 37 MB/s, misschien omdat de disks al gedeeltelijk gewist waren?)
(wat ook opviel was dat bij de eerste keer mounten van de array na een ext4 formattering er eerst een hoop disk activiteit is, het lijkt alsof dan pas ext4 echt actief wordt)
Eerst layout n2: hdparm -t kwam met 115 MB/s
iozone:
kB reclen write rewrite random read random write
1048576 4 95773 96159 2107576 12528
Met een 4GB testfile is het heel anders:
kB reclen write rewrite random read random write
4194304 4 87656 87659 660 3977
Met 2 threads en 1GB files:
Command line used: iozone -R -b raid10-n2-3x37G -w -t 2 -F 10/iodump1 10/iodump2 -i 0 -i 2 -s 1024M
Output is in kBytes/sec
Time Resolution = 0.000001 seconds.
Processor cache size set to 1024 kBytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.
Throughput test with 2 processes
Each process writes a 1048576 kByte file in 4 kByte records
Children see throughput for 2 initial writers = 88541.36 kB/sec
Parent sees throughput for 2 initial writers = 80553.47 kB/sec
Min throughput per process = 43050.47 kB/sec
Max throughput per process = 45490.89 kB/sec
Avg throughput per process = 44270.68 kB/sec
Min xfer = 992792.00 kB
Children see throughput for 2 rewriters = 88290.14 kB/sec
Parent sees throughput for 2 rewriters = 82255.72 kB/sec
Min throughput per process = 44094.47 kB/sec
Max throughput per process = 44195.67 kB/sec
Avg throughput per process = 44145.07 kB/sec
Min xfer = 1046688.00 kB
Children see throughput for 2 random readers = 3989.19 kB/sec
Parent sees throughput for 2 random readers = 3988.93 kB/sec
Min throughput per process = 1779.90 kB/sec
Max throughput per process = 2209.29 kB/sec
Avg throughput per process = 1994.60 kB/sec
Min xfer = 844788.00 kB
Children see throughput for 2 random writers = 6503.86 kB/sec
Parent sees throughput for 2 random writers = 6013.46 kB/sec
Min throughput per process = 3240.41 kB/sec
Max throughput per process = 3263.45 kB/sec
Avg throughput per process = 3251.93 kB/sec
Min xfer = 1041236.00 kB
“Throughput report Y-axis is type of test X-axis is number of processes”
“Record size = 4 kBytes ”
“Output is in kBytes/sec”
” Initial write ” 88541.36
” Rewrite ” 88290.14
” Random read ” 3989.19
” Random write ” 6503.86
Deze keer zat de dual core CPU de meeste tijd in wait state, dus daar zit een beperking, Had niet verwacht dat read langzamer was dan write.
RAID10,o2
hdparm: 118 MB/sec
iozone 1GB:
kB reclen write rewrite random read random write
1048576 4 97665 98451 2093890 12945
iozone 4GB:
kB reclen write rewrite random read random write
4194304 4 88329 88755 667 3968
Command line used: iozone -R -b raid10-o2-3x37G -w -t 2 -F 10/iodump1 10/iodump2 -i 0 -i 2 -s 1024M
Output is in kBytes/sec
Time Resolution = 0.000001 seconds.
Processor cache size set to 1024 kBytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.
Throughput test with 2 processes
Each process writes a 1048576 kByte file in 4 kByte records
Children see throughput for 2 initial writers = 88701.92 kB/sec
Parent sees throughput for 2 initial writers = 81542.38 kB/sec
Min throughput per process = 44110.47 kB/sec
Max throughput per process = 44591.45 kB/sec
Avg throughput per process = 44350.96 kB/sec
Min xfer = 1037612.00 kB
Children see throughput for 2 rewriters = 87304.59 kB/sec
Parent sees throughput for 2 rewriters = 80649.30 kB/sec
Min throughput per process = 43106.23 kB/sec
Max throughput per process = 44198.36 kB/sec
Avg throughput per process = 43652.30 kB/sec
Min xfer = 1022844.00 kB
Children see throughput for 2 random readers = 3696.82 kB/sec
Parent sees throughput for 2 random readers = 3696.71 kB/sec
Min throughput per process = 1736.35 kB/sec
Max throughput per process = 1960.46 kB/sec
Avg throughput per process = 1848.41 kB/sec
Min xfer = 928756.00 kB
Children see throughput for 2 random writers = 6555.41 kB/sec
Parent sees throughput for 2 random writers = 6059.91 kB/sec
Min throughput per process = 3267.60 kB/sec
Max throughput per process = 3287.81 kB/sec
Avg throughput per process = 3277.71 kB/sec
Min xfer = 1042196.00 kB
“Throughput report Y-axis is type of test X-axis is number of processes”
“Record size = 4 kBytes ”
“Output is in kBytes/sec”
” Initial write ” 88701.92
” Rewrite ” 87304.59
” Random read ” 3696.82
” Random write ” 6555.41
RAID10, f2
De manier zoals far layout is opgezet is duidelijk tijdens de array sync, het duurt veel langer omdat de snelheid ongeveer de helft is van de n2 layout maar wel constant.
hdparm: verwachte 190 MB/sec
iozone:
Command line used: iozone -R -b raid10-f2-3x37G -w -t 2 -F 10/iodump1 10/iodump2 -i 0 -i 2 -s 1024M
Output is in kBytes/sec
Time Resolution = 0.000001 seconds.
Processor cache size set to 1024 kBytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.
Throughput test with 2 processes
Each process writes a 1048576 kByte file in 4 kByte records
Children see throughput for 2 initial writers = 82377.73 kB/sec
Parent sees throughput for 2 initial writers = 74056.00 kB/sec
Min throughput per process = 40392.30 kB/sec
Max throughput per process = 41985.43 kB/sec
Avg throughput per process = 41188.86 kB/sec
Min xfer = 1009096.00 kB
Children see throughput for 2 rewriters = 80018.49 kB/sec
Parent sees throughput for 2 rewriters = 74390.03 kB/sec
Min throughput per process = 39565.50 kB/sec
Max throughput per process = 40452.99 kB/sec
Avg throughput per process = 40009.24 kB/sec
Min xfer = 1025572.00 kB
Children see throughput for 2 random readers = 3905.55 kB/sec
Parent sees throughput for 2 random readers = 3905.45 kB/sec
Min throughput per process = 1834.01 kB/sec
Max throughput per process = 2071.54 kB/sec
Avg throughput per process = 1952.78 kB/sec
Min xfer = 928376.00 kB
Children see throughput for 2 random writers = 6103.49 kB/sec
Parent sees throughput for 2 random writers = 5581.33 kB/sec
Min throughput per process = 3007.28 kB/sec
Max throughput per process = 3096.21 kB/sec
Avg throughput per process = 3051.75 kB/sec
Min xfer = 1018532.00 kB
“Throughput report Y-axis is type of test X-axis is number of processes”
“Record size = 4 kBytes ”
“Output is in kBytes/sec”
” Initial write ” 82377.73
” Rewrite ” 80018.49
” Random read ” 3905.55
” Random write ” 6103.49
iozone met een enkele 1GB file:
kB reclen write rewrite random read random write
1048576 4 85955 86858 2063179 11344
iozone met een enkele 4GB file:
kB reclen write rewrite random read random write
4194304 4 78394 78492 716 4058
Vraag me af waardoor dat weer zo langzaam is.
Stukje conclusie
Write het snelste met n2, langzaamste met f2. Random read het snelste met n2, langzaamste met o2. Random write het snelste met o2, langzaamste met f2.
Het kleine verschil tussen n2 en o2 is omdat met 3 disks n2 al gedeeltelijk een offset krijgt zoals bij o2. 4 disks en meer haalt die gelijkenis dan alweer weg.
Een mooie test is te vinden bij ilsistemista.net over RAID10 met de layouts en meerdere threads. Daar is ook te zien dat in de meeste situaties de verschillende layouts elkaar niet veel ontlopen.
Welke RAID10 layout het beste toegepast kan worden is afhankelijk van de toepassing. Sequentieel lezen zoals een media server thuis, RAID10,f2. Sequentieel schrijven zoals een backup disk, RAID10,n2. Bij een random mix zoals databases en virtuele omgevingen ontlopen RAID10,n2 en o2 elkaar niet veel maar lijkt f2 dan weer beter met enkele grotere files in single thread om te kunnen gaan.
Wat ook een factor is, is de snelheid van resync van de array, zeker na vervanging van een disk. Hoe simpeler de layout, hoe sneller dat verloopt. Het verschil tussen 10,n2 en 10,o2 is al ongeveer 30%. Als prioriteit ligt bij zekerheid dan is het beste om de standaard 10,n2 aan te houden.
Hoe dan ook, er zijn veel opties met mdadm waardoor de ideale configuratie toch getest moet worden in de praktijk. RAID10,o2 lijkt een goed uitgangspunt om te starten.
RAID5
hdparm: 107 MB/sec
1048576 4 88924 88859 2097663 6485
Toch nog even met 4GB file getest:
kB reclen write rewrite random read random write
4194304 4 79849 80263 567 2862
Command line used: iozone -R -b raid5-3x37G-t2-1G -w -t 2 -F 5/iodump1 5/iodump2 -i 0 -i 2 -s 1024M
Output is in kBytes/sec
Time Resolution = 0.000001 seconds.
Processor cache size set to 1024 kBytes.
Processor cache line size set to 32 bytes.
File stride size set to 17 * record size.
Throughput test with 2 processes
Each process writes a 1048576 kByte file in 4 kByte records
Children see throughput for 2 initial writers = 81796.59 kB/sec
Parent sees throughput for 2 initial writers = 75337.88 kB/sec
Min throughput per process = 40671.98 kB/sec
Max throughput per process = 41124.61 kB/sec
Avg throughput per process = 40898.29 kB/sec
Min xfer = 1037352.00 kB
Children see throughput for 2 rewriters = 83058.53 kB/sec
Parent sees throughput for 2 rewriters = 77321.25 kB/sec
Min throughput per process = 41483.91 kB/sec
Max throughput per process = 41574.62 kB/sec
Avg throughput per process = 41529.27 kB/sec
Min xfer = 1046304.00 kB
Children see throughput for 2 random readers = 1301.06 kB/sec
Parent sees throughput for 2 random readers = 1301.06 kB/sec
Min throughput per process = 649.35 kB/sec
Max throughput per process = 651.71 kB/sec
Avg throughput per process = 650.53 kB/sec
Min xfer = 1044784.00 kB
Children see throughput for 2 random writers = 4279.91 kB/sec
Parent sees throughput for 2 random writers = 3856.96 kB/sec
Min throughput per process = 2138.85 kB/sec
Max throughput per process = 2141.06 kB/sec
Avg throughput per process = 2139.96 kB/sec
Min xfer = 1047600.00 kB
“Throughput report Y-axis is type of test X-axis is number of processes”
“Record size = 4 kBytes ”
“Output is in kBytes/sec”
” Initial write ” 81796.59
” Rewrite ” 83058.53
” Random read ” 1301.06
” Random write ” 4279.91
Dit laat het nadeel zien van RAID met parity, langzamere writes omdat er meer I/O voor nodig is. Ik had wel snellere reads verwacht.
Het voordeel is nog steeds meer diskruimte beschikbaar te hebben, maar met het nadeel van een langzamere sync na vervanging van een disk en het hogere risico van het falen van een andere disk wegens de hogere I/O belasting is het tegenwoordig niet echt meer waard.
De optie om RAID6 te gebruiken kan ook vervangen worden door RAID10 op te zetten met 3 kopieën voor extra redundancy als er toch een flinke hoeveelheid disks gebruikt gaan worden.
Disk groottes
Het is jammer dat de beste prijsverhouding bij 3 à 4TB disks ligt. In een ideale situatie krijgt het OS een eigen disk apart van de disks voor data (en virtuele machines).
Met bijvoorbeeld een OS van 1GB grootte is maar 0,025% van zo’n disk in gebruik. De rest is dan weggegooide ruimte. Alleen bij een kans op een goedkope partij kleine (gewoonlijk oudere modellen) disks kan het gevoel van verspilling verminderd worden. Gelukkig zijn de prijzen van kleine SSD’s nog te overzien en een goede optie.
Het andere alternatief is dan om het OS op een RAID te zetten van kleine partities op alle schijven in de machine. Dan is de belasting beter verdeeld en toch geen ruimte verspild.
Men zou nog een groep van disks kunnen verdelen in RAID10 sets van 2 disks, en telkens de eerste kleine partitie van 1 disk van de set gebruiken om een RAID10 set te maken voor het OS. Dan is het effect van het OS verminderd op elke data RAID set (die dus niet de tweede disk nodig heeft).
De overgebleven partities zouden een array voor swap kunnen worden, wat toch weinig gebruikt wordt met voldoende RAM in de machine.
Een betere machine maakt veel verschil, een test op de HP 8100 die ik op het werk gebruik (3x1TB RAID10,o2, 10GB RAM);
Command line used: iozone -R -b raid10-o2 -f iodump -i 0 -i 2 -s 1024M
iozone met een enkele 1GB file:
kB reclen write rewrite random read random write
1048576 4 508577 556695 3419980 326604
Met 4GB file:
kB reclen write rewrite random read random write
4194304 4 160385 178055 3432041 4320
Test bestanden van een paar gigabyte maken het zelfs snellere schijven net zo lastig in random write.
Ultimate server backbone(?);
cheap servers running RAID10, o3 with lots of RAM and 3 SSD’s/HD’s in 3-node clusters.
Unless reliability is very bad 3 times anything should be enough to cover redundancy.
ff onthouden, diverse dingetjes
Handig?
Starwind tape redirector, maakt tape drives beschikbaar in virtual machines (Windows server 2012 R2 met de gratis virtual SAN installatie).
ITjes en datjes 