Linux'taki ZFS neden AWS i2.8xlarge örneğinde 8x SSD'yi tam olarak kullanamıyor?


12

ZFS'de tamamen yeniyim, bu yüzden başlamak için nasıl davrandığına dair bir fikir edinmek için bazı basit kriterler yapacağımı düşündüm. Performansının sınırlarını zorlamak istedim, böylece bir Amazon EC2 i2.8xlargeörneği sağladım (neredeyse 7 $ / saat, zaman gerçekten para!). Bu örnekte 8 800 GB SSD vardır.

fioSSD'ler üzerinde bir test yaptım ve aşağıdaki çıktıyı aldım (kesilmiş):

$ sudo fio --name randwrite --ioengine=libaio --iodepth=2 --rw=randwrite --bs=4k --size=400G --numjobs=8 --runtime=300 --group_reporting --direct=1 --filename=/dev/xvdb
[trimmed]
  write: io=67178MB, bw=229299KB/s, iops=57324, runt=300004msec
[trimmed]

4K rastgele yazma için 57K IOPS. Saygın.

Daha sonra 8'i kapsayan bir ZFS hacmi oluşturdum. İlk başta raidz1içinde 8 SSD'nin bulunduğu bir vdev vardı , ancak performansın kötü olmasının nedenlerini okudum, bu yüzden dört mirrorvdev ile sonuçlandım :

$ sudo zpool create testpool mirror xvdb xvdc mirror xvdd xvde mirror xvdf xvdg mirror xvdh xvdi
$ sudo zpool list -v
NAME   SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
testpool  2.91T   284K  2.91T         -     0%     0%  1.00x  ONLINE  -
  mirror   744G   112K   744G         -     0%     0%
    xvdb      -      -      -         -      -      -
    xvdc      -      -      -         -      -      -
  mirror   744G    60K   744G         -     0%     0%
    xvdd      -      -      -         -      -      -
    xvde      -      -      -         -      -      -
  mirror   744G      0   744G         -     0%     0%
    xvdf      -      -      -         -      -      -
    xvdg      -      -      -         -      -      -
  mirror   744G   112K   744G         -     0%     0%
    xvdh      -      -      -         -      -      -
    xvdi      -      -      -         -      -      -

Kayıt boyutunu 4K olarak ayarladım ve testimi çalıştırdım:

$ sudo zfs set recordsize=4k testpool
$ sudo fio --name randwrite --ioengine=libaio --iodepth=2 --rw=randwrite --bs=4k --size=400G --numjobs=8 --runtime=300 --group_reporting --filename=/testpool/testfile --fallocate=none
[trimmed]
  write: io=61500MB, bw=209919KB/s, iops=52479, runt=300001msec
    slat (usec): min=13, max=155081, avg=145.24, stdev=901.21
    clat (usec): min=3, max=155089, avg=154.37, stdev=930.54
     lat (usec): min=35, max=155149, avg=300.91, stdev=1333.81
[trimmed]

Bu ZFS havuzunda yalnızca 52K IOPS alıyorum. Bu aslında bir SSD'nin kendisinden biraz daha kötü.

Burada neyi yanlış yaptığımı anlamıyorum. ZFS'yi yanlış yapılandırdım mı yoksa ZFS performansının zayıf testi mi?

Not 4.4.5 elrepo çekirdeğine yükseltme yapmama rağmen resmi 64 bit CentOS 7 HVM görüntüsünü kullanıyorum:

$ uname -a
Linux ip-172-31-43-196.ec2.internal 4.4.5-1.el7.elrepo.x86_64 #1 SMP Thu Mar 10 11:45:51 EST 2016 x86_64 x86_64 x86_64 GNU/Linux

ZFS'yi burada listelenen zfs deposundan yükledim . zfsPaketin 0.6.5.5 sürümü var .

GÜNCELLEME : @ ewwhite'ın önerisine göre denedim ashift=12ve ashift=13:

$ sudo zpool create testpool mirror xvdb xvdc mirror xvdd xvde mirror xvdf xvdg mirror xvdh xvdi -o ashift=12 -f

ve

$ sudo zpool create testpool mirror xvdb xvdc mirror xvdd xvde mirror xvdf xvdg mirror xvdh xvdi -o ashift=13 -f

Bunların hiçbiri bir fark yaratmadı. En son ZFS bitlerini anladığım kadarıyla 4K SSD'leri tanımlamak ve makul varsayılanları kullanmak yeterince akıllı.

Ancak CPU kullanımının arttığını fark ettim. @Tim bunu önerdi ama işten çıkarıldım, ancak CPU'yu fark edecek kadar uzun süre izlemediğimi düşünüyorum. Bu örnekte 30 CPU çekirdeği gibi bir şey var ve CPU kullanımı% 80'e kadar yükseliyor. Aç süreç mi? z_wr_iss, birçok örneği.

Sıkıştırmanın kapalı olduğunu onayladım, bu yüzden sıkıştırma motoru değil.

Raidz kullanmıyorum, bu yüzden parite hesaplaması olmamalı.

Ben yaptım perf topve onu harcanan çekirdek çoğu zaman gösterir _raw_spin_unlock_irqrestoreiçinde z_wr_int_4ve osq_lockiçinde z_wr_iss.

Şimdi bu performans darboğazında bir CPU bileşeni olduğuna inanıyorum, ancak ne olabileceğini anlamaya daha yakın değilim.

GÜNCELLEME 2 : @beyaz ve diğerlerinin performans belirsizliği yaratan bu ortamın sanallaştırılmış doğası olduğuna dair önerisine göre, ortamdaki dört SSD'ye fioyayılmış rastgele 4K yazmalarını karşılaştırırdım. Her SSD tek başına ~ 55K IOPS verir, bu yüzden dördünde 240K IO civarında bir yer bekledim. Ne var ne az ya da çok:

$ sudo fio --name randwrite --ioengine=libaio --iodepth=8 --rw=randwrite --bs=4k --size=398G --numjobs=8 --runtime=300 --group_reporting --filename=/dev/xvdb:/dev/xvdc:/dev/xvdd:/dev/xvde
randwrite: (g=0): rw=randwrite, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=8
...
randwrite: (g=0): rw=randwrite, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=8
fio-2.1.5
Starting 8 processes
[trimmed]
  write: io=288550MB, bw=984860KB/s, iops=246215, runt=300017msec
    slat (usec): min=1, max=24609, avg=30.27, stdev=566.55
    clat (usec): min=3, max=2443.8K, avg=227.05, stdev=1834.40
     lat (usec): min=27, max=2443.8K, avg=257.62, stdev=1917.54
[trimmed]

Bu açıkça görülüyor olsa da, sanallaştırılmış ortamın IOPS'u gördüğümden çok daha yüksek bir seviyede tutabildiğini gösteriyor. ZFS'nin uygulanmasıyla ilgili bir şey, en yüksek hıza çarpmasını engelliyor. Bunun ne olduğunu anlayamıyorum.


EC2'desiniz. Amazon'un size vermek istediği kadar IOPS alırsınız.
Michael Hampton

Amazon bana bu örneğe bağlı SSD başına yaklaşık 52K IOPS veriyor ve buna bağlı sekiz tane SSD var. Amazon belgelerinden, bu boyutun bulunduğu fiziksel ana bilgisayarda çalışan tek örnek olduğu açıktır. Ayrıca bunlar yerel SSD'lerdir, EBS hacimleri DEĞİLDİR, bu nedenle GÇ bant genişliği için başka iş yükü yoktur. Bu gördüğüm performansı hesaba katmıyor.
anelson

Bu CPU'yu vergilendiriyor mu yoksa bellek sınırlarına mı çarpıyor?
Tim

Bu yazı dizisini okudunuz mu? hatim.eu/2014/05/24/… Başka herhangi bir makale yardımcı oldu mu?
Tim

1
Sadece zfsonlinux'un gerçek uygulama eksikliklerini ekarte etmek için, aynı örnekte bir Solaris 11 kurulumu ile aynı tezgah testini deneyeceğim.
the-wabbit

Yanıtlar:


6

Bu kurulum iyi ayarlanmamış olabilir. SSD'leri kullanırken hem /etc/modprobe/zfs.conf dosyası hem de ashift değeri için gerekli parametreler vardır

Ashift = 12 veya 13'ü deneyin ve tekrar test edin.


Düzenle:

Bu hala sanallaştırılmış bir çözümdür, bu nedenle altta yatan donanım veya her şeyin nasıl birbirine bağlandığı hakkında çok fazla şey bilmiyoruz. Bu çözümden daha iyi performans alacağınızı bilmiyorum.


Düzenle:

Bir bulut örneğini bu şekilde optimize etmeye çalıştığımı sanmıyorum. Çünkü en iyi performans hedef olsaydı, donanım kullanırdın, değil mi?

Ancak, ZFS'nin birçok ayarlanabilir ayarı olduğunu ve varsayılan olarak aldığınız şeyin kullanım durumunuza yakın bir yerde olmadığını unutmayın.

Aşağıdakileri deneyin /etc/modprobe.d/zfs.confve yeniden başlatın . Uygulama sunucuları için tüm SSD veri havuzlarımda kullandığım şey bu. Ashiftiniz 12 veya 13 olmalıdır. Sıkıştırma ile gösterge = kapalı, ancak üretimde sıkıştırma = lz4 kullanın. Atime = kapalı olarak ayarlayın. Kayıt boyutunu varsayılan olarak bıraktım (128K).

options zfs zfs_vdev_scrub_min_active=48
options zfs zfs_vdev_scrub_max_active=128
options zfs zfs_vdev_sync_write_min_active=64
options zfs zfs_vdev_sync_write_max_active=128
options zfs zfs_vdev_sync_read_min_active=64
options zfs zfs_vdev_sync_read_max_active=128
options zfs zfs_vdev_async_read_min_active=64
options zfs zfs_vdev_async_read_max_active=128
options zfs zfs_top_maxinflight=320
options zfs zfs_txg_timeout=30
options zfs zfs_dirty_data_max_percent=40
options zfs zfs_vdev_scheduler=deadline
options zfs zfs_vdev_async_write_min_active=8
options zfs zfs_vdev_async_write_max_active=64
options zfs zfs_prefetch_disable=1

Büyük öneri. Orijinal sorumu daha ayrıntılı olarak güncelledim. Özet: ashift yardımcı olmadı ve bu sorunun bir CPU kullanım bileşeni olduğunu düşünüyorum.
anelson

Sıkıştırma veya tekilleştirme kullanıyor musunuz?
ewwhite

hayır Ben sıkıştırma kapalı olduğunu doğruladı zfs get compression. Dedupe de kapalı.
anelson

Bu adil bir nokta ama altta yatan sanallaştırılmış depolama cihazlarının çok daha iyi performans gösterdiğini gösterebilirim. Yayındaki güncelleme 2'ye bakın.
anelson

@anelson Tamam. Yukarıdaki ayarları deneyin.
ewwhite


1

Bunu takip etmek için iyi bir zaman geçirdim. Benim özel zorluk: bir Postgres sunucusu ve ben onun veri hacmi için ZFS kullanmak istiyorum. Temel XFS'dir.

Her şeyden önce, denemelerim bana bunun ashift=12yanlış olduğunu söylüyor. Eğer sihirli bir ashiftsayı varsa 12 değil. 0Çok iyi sonuçlar alıyorum.

Ben de bir sürü zfs seçenekleri ile denedim ve bana aşağıdaki sonuçları veren olanlar:

atime=off - Erişim sürelerine ihtiyacım yok

checksum=off - Çiziyorum, yansıtmıyorum

compression=lz4- Sıkıştırma ile performans daha iyidir (cpu tradeoff?)

exec=off - Bu veriler içindir, yürütülebilir dosyalar değil

logbias=throughput - İnterweb'lerde okuyun bu Postgres için daha iyi

recordsize=8k - PG'ye özgü 8k blok boyutu

sync=standard- senkronizasyonu kapatmaya çalıştı; fazla fayda görmedim

Aşağıdaki testlerim XFS performansından daha iyi görünüyor (lütfen testlerimde hata görürseniz yorum yapın!).

Bu ile bir sonraki adım 2 x EBS ZFS dosya sisteminde çalışan Postgres deneyin.

Özel kurulumum:

EC2: m4.xlargeörnek

EBS: 250 GB gp2ciltler

çekirdek: Linux [...] 3.13.0-105-genel # 152-Ubuntu SMP [...] x86_64 x86_64 x86_64 GNU / Linux *

İlk olarak, ham EBS performansını test etmek istedim. fioYukarıdaki komutun bir varyasyonunu kullanarak , aşağıdaki büyüyü getirdim. Not: Ben 8k blok kullanıyorum çünkü PostgreSQL yazdıklarımı okudum:

ubuntu@ip-172-31-30-233:~$ device=/dev/xvdbd; sudo dd if=/dev/zero of=${device} bs=1M count=100 && sudo fio --name randwrite --ioengine=libaio --iodepth=4 --rw=randwrite --bs=8k --size=400G --numjobs=4 --runtime=60 --group_reporting --fallocate=none --filename=${device}
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 0.250631 s, 418 MB/s
randwrite: (g=0): rw=randwrite, bs=8K-8K/8K-8K/8K-8K, ioengine=libaio, iodepth=4
...
randwrite: (g=0): rw=randwrite, bs=8K-8K/8K-8K/8K-8K, ioengine=libaio, iodepth=4
fio-2.1.3
Starting 4 processes
Jobs: 4 (f=4): [wwww] [100.0% done] [0KB/13552KB/0KB /s] [0/1694/0 iops] [eta 00m:00s]
randwrite: (groupid=0, jobs=4): err= 0: pid=18109: Tue Feb 14 19:13:53 2017
  write: io=3192.2MB, bw=54184KB/s, iops=6773, runt= 60327msec
    slat (usec): min=2, max=805209, avg=585.73, stdev=6238.19
    clat (usec): min=4, max=805236, avg=1763.29, stdev=10716.41
     lat (usec): min=15, max=805241, avg=2349.30, stdev=12321.43
    clat percentiles (usec):
     |  1.00th=[   15],  5.00th=[   16], 10.00th=[   17], 20.00th=[   19],
     | 30.00th=[   23], 40.00th=[   24], 50.00th=[   25], 60.00th=[   26],
     | 70.00th=[   27], 80.00th=[   29], 90.00th=[   36], 95.00th=[15808],
     | 99.00th=[31872], 99.50th=[35584], 99.90th=[99840], 99.95th=[199680],
     | 99.99th=[399360]
    bw (KB  /s): min=  156, max=1025440, per=26.00%, avg=14088.05, stdev=67584.25
    lat (usec) : 10=0.01%, 20=20.53%, 50=72.20%, 100=0.86%, 250=0.17%
    lat (usec) : 500=0.13%, 750=0.01%, 1000=0.01%
    lat (msec) : 2=0.01%, 4=0.01%, 10=0.59%, 20=2.01%, 50=3.29%
    lat (msec) : 100=0.11%, 250=0.05%, 500=0.02%, 750=0.01%, 1000=0.01%
  cpu          : usr=0.22%, sys=1.34%, ctx=9832, majf=0, minf=114
  IO depths    : 1=0.1%, 2=0.1%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=0/w=408595/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
  WRITE: io=3192.2MB, aggrb=54184KB/s, minb=54184KB/s, maxb=54184KB/s, mint=60327msec, maxt=60327msec

Disk stats (read/write):
  xvdbd: ios=170/187241, merge=0/190688, ticks=180/8586692, in_queue=8590296, util=99.51%

EBS hacmi için ham performans WRITE: io=3192.2MB.

Şimdi, XFS'yi aynı fiokomutla test edin :

Jobs: 4 (f=4): [wwww] [100.0% done] [0KB/0KB/0KB /s] [0/0/0 iops] [eta 00m:00s]
randwrite: (groupid=0, jobs=4): err= 0: pid=17441: Tue Feb 14 19:10:27 2017
  write: io=3181.9MB, bw=54282KB/s, iops=6785, runt= 60024msec
    slat (usec): min=3, max=21077K, avg=587.19, stdev=76081.88
    clat (usec): min=4, max=21077K, avg=1768.72, stdev=131857.04
     lat (usec): min=23, max=21077K, avg=2356.23, stdev=152444.62
    clat percentiles (usec):
     |  1.00th=[   29],  5.00th=[   40], 10.00th=[   46], 20.00th=[   52],
     | 30.00th=[   56], 40.00th=[   59], 50.00th=[   63], 60.00th=[   69],
     | 70.00th=[   79], 80.00th=[   99], 90.00th=[  137], 95.00th=[  274],
     | 99.00th=[17024], 99.50th=[25472], 99.90th=[70144], 99.95th=[120320],
     | 99.99th=[1564672]
    bw (KB  /s): min=    2, max=239872, per=66.72%, avg=36217.04, stdev=51480.84
    lat (usec) : 10=0.01%, 20=0.03%, 50=15.58%, 100=64.51%, 250=14.55%
    lat (usec) : 500=1.36%, 750=0.33%, 1000=0.25%
    lat (msec) : 2=0.68%, 4=0.67%, 10=0.71%, 20=0.58%, 50=0.59%
    lat (msec) : 100=0.10%, 250=0.02%, 500=0.01%, 750=0.01%, 1000=0.01%
    lat (msec) : 2000=0.01%, >=2000=0.01%
  cpu          : usr=0.43%, sys=4.81%, ctx=269518, majf=0, minf=110
  IO depths    : 1=0.1%, 2=0.1%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=0/w=407278/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
  WRITE: io=3181.9MB, aggrb=54282KB/s, minb=54282KB/s, maxb=54282KB/s, mint=60024msec, maxt=60024msec

Disk stats (read/write):
  xvdbd: ios=4/50983, merge=0/319694, ticks=0/2067760, in_queue=2069888, util=26.21%

Bizim temelimiz WRITE: io=3181.9MB; gerçekten ham disk hızına yakın.

Şimdi, WRITE: io=3181.9MBreferans olarak ZFS üzerine :

ubuntu@ip-172-31-30-233:~$ sudo zpool create testpool xvdbd -f && (for option in atime=off checksum=off compression=lz4 exec=off logbias=throughput recordsize=8k sync=standard; do sudo zfs set $option testpool; done;) && sudo fio --name randwrite --ioengine=libaio --iodepth=4 --rw=randwrite --bs=8k --size=400G --numjobs=4 --runtime=60 --group_reporting --fallocate=none --filename=/testpool/testfile; sudo zpool destroy testpool
randwrite: (g=0): rw=randwrite, bs=8K-8K/8K-8K/8K-8K, ioengine=libaio, iodepth=4
...
randwrite: (g=0): rw=randwrite, bs=8K-8K/8K-8K/8K-8K, ioengine=libaio, iodepth=4
fio-2.1.3
Starting 4 processes
randwrite: Laying out IO file(s) (1 file(s) / 409600MB)
randwrite: Laying out IO file(s) (1 file(s) / 409600MB)
randwrite: Laying out IO file(s) (1 file(s) / 409600MB)
randwrite: Laying out IO file(s) (1 file(s) / 409600MB)
Jobs: 4 (f=4): [wwww] [100.0% done] [0KB/41328KB/0KB /s] [0/5166/0 iops] [eta 00m:00s]
randwrite: (groupid=0, jobs=4): err= 0: pid=18923: Tue Feb 14 19:17:18 2017
  write: io=4191.7MB, bw=71536KB/s, iops=8941, runt= 60001msec
    slat (usec): min=10, max=1399.9K, avg=442.26, stdev=4482.85
    clat (usec): min=2, max=1400.4K, avg=1343.38, stdev=7805.37
     lat (usec): min=56, max=1400.4K, avg=1786.61, stdev=9044.27
    clat percentiles (usec):
     |  1.00th=[   62],  5.00th=[   75], 10.00th=[   87], 20.00th=[  108],
     | 30.00th=[  122], 40.00th=[  167], 50.00th=[  620], 60.00th=[ 1176],
     | 70.00th=[ 1496], 80.00th=[ 2320], 90.00th=[ 2992], 95.00th=[ 4128],
     | 99.00th=[ 6816], 99.50th=[ 9536], 99.90th=[30592], 99.95th=[66048],
     | 99.99th=[185344]
    bw (KB  /s): min= 2332, max=82848, per=25.46%, avg=18211.64, stdev=15010.61
    lat (usec) : 4=0.01%, 50=0.09%, 100=14.60%, 250=26.77%, 500=5.96%
    lat (usec) : 750=5.27%, 1000=4.24%
    lat (msec) : 2=20.96%, 4=16.74%, 10=4.93%, 20=0.30%, 50=0.08%
    lat (msec) : 100=0.04%, 250=0.03%, 500=0.01%, 2000=0.01%
  cpu          : usr=0.61%, sys=9.48%, ctx=177901, majf=0, minf=107
  IO depths    : 1=0.1%, 2=0.1%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=0/w=536527/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
  WRITE: io=4191.7MB, aggrb=71535KB/s, minb=71535KB/s, maxb=71535KB/s, mint=60001msec, maxt=60001msec

Dikkat edin, bu XFS'den daha iyi performans gösterdi WRITE: io=4191.7MB. Bunun sıkıştırma nedeniyle olduğundan eminim.

Tekmeler için ikinci bir cilt ekleyeceğim:

ubuntu@ip-172-31-30-233:~$ sudo zpool create testpool xvdb{c,d} -f && (for option in atime=off checksum=off compression=lz4 exec=off logbias=throughput recordsize=8k sync=standard; do sudo zfs set $option testpool; done;) && sudo fio --name randwrite --ioengine=libaio --iodepth=4 --rw=randwrite --bs=8k --size=400G --numjobs=4 --runtime=60 --group_reporting --fallocate=none --filename=/testpool/testfile; sudo zpool destroy testpool
randwrite: (g=0): rw=randwrite, bs=8K-8K/8K-8K/8K-8K, ioengine=libaio, iodepth=4
...
randwrite: (g=0): rw=randwrite, bs=8K-8K/8K-8K/8K-8K, ioengine=libaio, iodepth=4
fio-2.1.3
Starting 4 processes
randwrite: Laying out IO file(s) (1 file(s) / 409600MB)
randwrite: Laying out IO file(s) (1 file(s) / 409600MB)
randwrite: Laying out IO file(s) (1 file(s) / 409600MB)
randwrite: Laying out IO file(s) (1 file(s) / 409600MB)
Jobs: 4 (f=4): [wwww] [100.0% done] [0KB/71936KB/0KB /s] [0/8992/0 iops] [eta 00m:00s]
randwrite: (groupid=0, jobs=4): err= 0: pid=20901: Tue Feb 14 19:23:30 2017
  write: io=5975.9MB, bw=101983KB/s, iops=12747, runt= 60003msec
    slat (usec): min=10, max=1831.2K, avg=308.61, stdev=4419.95
    clat (usec): min=3, max=1831.6K, avg=942.64, stdev=7696.18
     lat (usec): min=58, max=1831.8K, avg=1252.25, stdev=8896.67
    clat percentiles (usec):
     |  1.00th=[   70],  5.00th=[   92], 10.00th=[  106], 20.00th=[  129],
     | 30.00th=[  386], 40.00th=[  490], 50.00th=[  692], 60.00th=[  796],
     | 70.00th=[  932], 80.00th=[ 1160], 90.00th=[ 1624], 95.00th=[ 2256],
     | 99.00th=[ 5344], 99.50th=[ 8512], 99.90th=[30592], 99.95th=[60672],
     | 99.99th=[117248]
    bw (KB  /s): min=   52, max=112576, per=25.61%, avg=26116.98, stdev=15313.32
    lat (usec) : 4=0.01%, 10=0.01%, 50=0.04%, 100=7.17%, 250=19.04%
    lat (usec) : 500=14.36%, 750=15.36%, 1000=17.41%
    lat (msec) : 2=20.28%, 4=4.82%, 10=1.13%, 20=0.25%, 50=0.08%
    lat (msec) : 100=0.04%, 250=0.02%, 2000=0.01%
  cpu          : usr=1.05%, sys=15.14%, ctx=396649, majf=0, minf=103
  IO depths    : 1=0.1%, 2=0.1%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=0/w=764909/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
  WRITE: io=5975.9MB, aggrb=101982KB/s, minb=101982KB/s, maxb=101982KB/s, mint=60003msec, maxt=60003msec

İkinci bir ciltle, WRITE: io=5975.9MB~ 1.8X yazar.

Üçüncü cilt bize verir WRITE: io=6667.5MB, böylece ~ 2.1X yazar.

Ve dördüncü cilt bize veriyor WRITE: io=6552.9MB. Bu örnek türü için, kesinlikle üçüyle EBS ağını neredeyse iki ciltle kapadım ve 4 (750 * 3 = 2250 IOPS) ile daha iyi değil gibi görünüyor.

* Bu videodan , tüm EBS iyiliğini elde etmek için 3.8+ linux çekirdeği kullandığınızdan emin olun.


İlginç sonuçlar. Not Bence kafanız karıştı WRITE: io=; hız değil, o zamanda yazılan veri miktarıdır. Sadece sabit bir çalışma süresine sahip testler için hız ile ilgili, ancak diğer kriterlerle tutarlılık için IOPS'a odaklanmak daha iyidir iops=. Durumunuzda benzer sonuçlar Sağlanan IOPS EBS birimlerini ve daha büyük bir örneği kullanırsanız muhtemelen çok daha iyi olabilirsiniz. Örnek boyutuna göre beklenen EBS sınırları için bu sayfaya bakın . Dikkatli değilseniz, EBS ücretleri hızlı bir şekilde toplanır!
anelson

Büyük geribildirim, teşekkürler @anelson! sağlanan iops baktı ve çok pahalı. Ancak, ZIL'in yazıldığı bir günlük birimi için küçük bir sağlanan iops birimi oluşturmayı ve bazı performans avantajlarını elde etmeyi düşünüyordum. ZIL okuduğum bir yerde hafızada olandan daha büyük büyümiyor ve 2G ile sınırlı kalıyorum /etc/modules.d/zfs.conf. Sonraki soru, bir ec2 örneği vermek için uygun iops sayısıdır. Referans verdiğiniz sayfaya bakmak hala zor ve performansı dokümanlar durumu kadar iyi görmüyorum.
berto
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.