Pokazywanie postów oznaczonych etykietą macierze. Pokaż wszystkie posty
Pokazywanie postów oznaczonych etykietą macierze. Pokaż wszystkie posty

ZFS compresja i deduplikacja na przykładzie danych z systemu NEXUS (Zettabyte File System)

Go to start of metadata
Wersja zfs:
cat /sys/module/zfs/version
0.7.5-1

Niestety, w tym konkretnym systemie NEXUS'a trzymane są pliki ".jar", a nie tylko kody i dane konfiguracyjne. Implikuje to dwa zaobserwowane efekty:
1) Duże, i przecież już skompresowane, pliki są przechowywane na dysku, zamiast samych kodów i mechanizmów budujących je. Nie można efektywnie skompresować pliku poddanego już kompresji, więc mechanizm kompresujący na poziomie systemu plików (sektorów) okazał się nieefektywny.
2) Nawet minimalna zmiana kodów powoduje, że zbudowane archiwum ma inne położenie bajtów (sektory są różne, chociaż zmiany w kodzie mogą dotyczyć jednej linii),czyli nie da się efektywnie przeprowadzić deduplikacji. 
Poniżej screeny ze statystykami. Kompresja na poziomie 1,16 - co nie jest najgorszym wynikiem. Deduplikacja na poziomie 1,23 - co jest już nie do przyjęcia, ze względu na relację: koszt obliczeniowy i zajętość pamięci RAM do zysku w postaci zwiększenia miejsca na dysku. W tym konkretnym przypadku, za względu na wadliwe użycie menadżera repozytoriów, zastosowanie mechanizmów systemu ZFS nie przynosi oczekiwanego zysku.


 ********

Więcej informacji:
Informatyka, FreeBSD, Debian


***

Inne wpisy:



Update: 2018.07.17
Create: 2018.07.17

Prosty test szybkości procesorów, dysków i MYSQL

Do prostego i szybkiego porównania wydajności procesorów użyć https://github.com/akopytov/sysbench:
yum install sysbench

Podstawową komendą, której używam jest:
sysbench --test=cpu --cpu-max-prime=20000 --num-threads=1 run

Przykładowe wyniki dla trzech zwirtualizowanych serwerów serwerów i laptopa:
Jak widać na kilkuletnim laptopie test wykonał się w czasie krótszym, niż na serwerach:
  • sasha: 33 s
  • bibi: 36 s
  • jenna: 32 s
  • laptop: 24 s

Inne systemy:
Amazon Cloud (AWS) t2.medium
Intel Xeon E5-2676 v3  @ 2.4 GHz
10 s

Amazon Cloud (AWS) m4.large
Intel Xeon E5-2686 v4 @ 2.3 GHz
10 s

Intel Core i7 870  @ 2.93 GHzCode name: DELION (smile)
10 s
 



Jak można sprawdzić, jakie procesory są zainstalowane? Podstawową komendą jest:
cat /proc/cpuinfo

Przydatne bywa polecenie:
nproc

Ja użyję poniższej komendy:
lscpu

 W serwerach są zainstalowane procesory:
Jak widać wirtualizacja KVM ukrywa prawdziwy typ procesora. W takim właśnie przypadku użyteczne jest porównanie wydajności procesorów komendą "sysbench".
Dane zwracane przez "lscpu" na laptopie:

Dla porównania dane jeszcze z dwóch serwerów:



Można też testować system plików (wielkość danych powinna znacząco przekraczać rozmiar pamięci RAM).
Pierwsze polecenie "sysbench" generuje pliki testowe, a dopiero drugie przeprowadza właściwy test. Domyślną wartością parametru "file-num" jest 128.
mkdir testio
cd testio
sysbench --test=fileio --file-total-size=15G prepare
sysbench --test=fileio --file-total-size=15G --file-test-mode=rndrw --init-rng=on --max-time=300 --max-requests=0 run
Należy pamiętać, by po zakończeniu testów usunąć utworzone pliki.
sysbench --test=fileio --file-total-size=15G cleanup

Wynik testu dysku na laptopie z dyskiem SSD:

Wynik testu dysku na zwirtualizowanym serwerze, wolumen "/":

Wynik testu dysku na zwirtualizowanym serwerze, zamontowany wolumen NFS:

Zebrane dane wydajności dysków:
 
laptop
jenna "/"
jenna NFS
Mb/s:8,94260,4700,287
Requests/sec executed:57229,4117,99
approx. 95 percentile (ms):0,1893,466,7

Ciekawym testem jest też "fio", chociaż nie użyłem go do ww. serwerów i laptopa:
yum install fio

Random Write:
fio --name=randwrite --ioengine=libaio --iodepth=1 --rw=randwrite --bs=4k --direct=0 --size=512M --numjobs=8 --runtime=240 --group_reporting

Random Read:
fio --name=randread --ioengine=libaio --iodepth=16 --rw=randread --bs=4k --direct=0 --size=512M --numjobs=8 --runtime=240 --group_reporting

Oczywiście watro używać też klasycznego testu "Bonnie++", oraz "iozone":
#Sequential Write, 64K requests, 32 threads:
iozone -I -t 32 -M -O -r 64k -s 500m -+u -w -i 0
 
#Sequential Read, 64K requests, 32 threads:
iozone -I -t 32 -M -O -r 64k -s 500m -+u -w -i 1
 
#Random Read/Write, 4K requests, 32 threads:
iozone -I -t 32 -M -O -r 4k -s 500m -+u -w -i 2




Można też testować wydajność MYSQL:
Testy przeprowadziłem w chmurze Amazon AWS, co dla AMI opartych o system przygotowany przez Amazona wymaga następującej instalacji oprogramowania testującego:
yum -y install bzr
yum -y install automake
yum -y install libtool
yum -y install mysql-devel
bzr branch lp:sysbench
cd sysbench
./autogen.sh
./configure
make
cd sysbench
Poniżej komendy przygotowujące, uruchamiające i sprzątające po teście:
mysql -u admin -ppaselko -h host.us-east-1.rds.amazonaws.com -e "CREATE DATABASE systest;"
 
./sysbench --test=tests/db/oltp.lua --oltp-table-size=1000000 --mysql-db=systest --mysql-user=admin --mysql-password=paselko --mysql-host=host.us-east-1.rds.amazonaws.com prepare
 
 
./sysbench --test=tests/db/oltp.lua --oltp-table-size=1000000 --mysql-db=systest --mysql-user=admin --mysql-password=paselko --max-time=300 --oltp-read-only=on --max-requests=0 --num-threads=8 --mysql-host=host.us-east-1.rds.amazonaws.com run
 
 
./sysbench --test=tests/db/oltp.lua --mysql-db=systest --mysql-user=admin --mysql-password=paselko --mysql-host=host.us-east-1.rds.amazonaws.com cleanup

Przykładowy rezultat testu:
W tym teście uzyskaliśmy 890 transakcji na sekundę. Serwerem RDS był "db.t2.large":
  • vCPU: 2
  • ECU: 2
  • Memory (GB): 8
  • EBS Optimized: No
  • Network Performance: Moderate
Serwerem z programem testującym był "t2.large":
  • vCPU: 2
  • Memory (GB): 8




********

Więcej informacji:
Informatyka, FreeBSD, Debian


***

Inne wpisy:



Update: 2018.07.17
Create: 2018.07.17