Hier mein erster Test des Storage auf einem Ubuntu 12.04 LTS Server. Die Anbindung lief über NFS. Ich muss sagen
mit dem Ergebnis bin ich mehr als zufrieden.
Storagebenchmark:
######################################################################################################
Direkt ins NFS:
dd if=/dev/vda of=/storage/vda.dd bs=512k
88064+0 Datensätze ein
88064+0 Datensätze aus
46170898432 Bytes (46 GB) kopiert, 470,254 s, 98,2 MB/s
iotop:
32142 be/4 root 109.71 M/s 109.61 M/s 0.00 % 74.55 % dd if=/dev/vda of=/storage/vda.dd bs=512k
######################################################################################################
Direkt aus dem NFS:
dd if=/storage/vda.dd of=/dev/null bs=512k
^C14023+0 Datensätze ein
14022+0 Datensätze aus
7351566336 Bytes (7,4 GB) kopiert, 71,6576 s, 103 MB/s
iotop:
32458 be/4 root 107.27 M/s 0.00 B/s 0.00 % 75.32 % dd if=/storage/vda.dd of=/dev/null bs=512k
######################################################################################################
Loop-File im NFS
dd if=/dev/zero of=/storage/loop.dd bs=512k
^C88600+0 Datensätze ein
88600+0 Datensätze aus
46451916800 Bytes (46 GB) kopiert, 421,776 s, 110 MB/s
mkfs.btrfs loop.dd # ca. 5s
mount loop.dd /mnt # im ms-Bereich
dd if=/dev/zero of=/mnt/zero.dd bs=512k
^C10891+0 Datensätze ein
10891+0 Datensätze aus
5710020608 Bytes (5,7 GB) kopiert, 146,373 s, 39,0 MB/s ### keine zusätzliche CPU-Last aber langsamer
dd if=/dev/vda of=/tmp/vda.tmp bs=1024k count=2048
2048+0 Datensätze ein
2048+0 Datensätze aus
2147483648 Bytes (2,1 GB) kopiert, 37,8063 s, 56,8 MB/s
dd if=/dev/vda of=/tmp/vda.tmp bs=1024k count=2048
2048+0 Datensätze ein
2048+0 Datensätze aus
2147483648 Bytes (2,1 GB) kopiert, 37,8063 s, 56,8 MB/s
# mit Kompression
mount -o compress=zlib,defaults loop.dd /mnt
dd if=/tmp/vda.tmp of=/mnt/vda.tmp bs=512k
4096+0 Datensätze ein
4096+0 Datensätze aus
2147483648 Bytes (2,1 GB) kopiert, 186,511 s, 11,5 MB/s #etwas höhere CPU-Last
#allerdings keinerlei Wirkung auf Dienste, da die Last sehr niedrige Priorität zu haben scheint
# Kompression testen
while :; do cp vda.tmp $(echo -n $(date +%s) | md5sum | awk '{print $1;}') ;echo "kopiert";done # kopiert mit ca. 9MB/s
# 21 mal konnte das kopiert werden also so gut wie keine Komprimierung,
# jetzt mit einer gut komprimierbaren Datei
tar -cf etc.tar /etc/
# Ergebnis
3368960 Okt 30 12:09 etc.tar
667306 Okt 30 12:10 etc.tar.gz
# das tar kann also mit gzip auf 1/5 gepackt werden -> 0.19
# während des Kopiervorganges
Total DISK READ: 126.39 K/s | Total DISK WRITE: 7.91 M/s
# Am Ende sagt: df -h
/dev/loop0 44G 42G 15M 100% /mnt
#und: du -h
172G .
# 44G/172G -> ca. 0.25
# also etwas schlechter als gzip aber immerhin auf 1/4
# zur Info: ls | wc -w
54993
# also 54993 Dateien mal 3.3M passt also
# da das jetzt Stunden gedauert hat und stabil 7-9 M/s hatte noch einen Test mit lzo aber weniger Speicher
# mount sagt:
/storage/loop.dd on /mnt type btrfs (rw,compress=zlib)
/storage/loop2.dd on /mnt2 type btrfs (rw,compress=lzo)
# und df -h
/dev/loop0 44G 42G 15M 100% /mnt
/dev/loop1 4,0G 56K 3,6G 1% /mnt2
# das gleiche also noch mal:
# cp etc.tar /mnt2/
# cd /mnt2
# while :; do cp etc.tar $(mktemp --tmpdir=/mnt2);done
# iotop sagt jetzt:
# Total DISK READ: 1050.18 K/s | Total DISK WRITE: 32.64 M/s
# also viel schneller
# du -h
8,9G .
# ls | wc -w
2872
# df -h
/dev/loop1 4,0G 3,6G 15M 100% /mnt2
# 3,6G/8,9G -> 0.40 also schlechter, dafür aber schneller als ohne Komprimierung
#################################################################################################
Ich hoffe der Test hilft euch weiter. Beim Ersten Versuch mit lzo ist der Server abgestürzt,
das kann aber auch mein Fehler gewesen sein, da ich mit dd und find gespielt hatte. War danach nicht
reproduzierbar. Während des gesamten Tests waren alle Dienste vollständig erreichbar und keine
Verlangsamung zu spüren.
Wenn jemand noch einen Test mit qemu-nbd und vmdk/qcow/raw machen
würde wäre ich sehr glücklich. Man sollte qemu-nbd dazu zwingen das Caching abgewöhnen und native ist auch gut:
qemu-nbd -n --aio=native