लिनक्स पर ZFS AWS i2.8xlarge उदाहरण पर 8x SSD का पूरी तरह से उपयोग करने में असमर्थ क्यों है?

Question

मैं ZFS के लिए पूरी तरह से नया हूं, इसलिए मैंने सोचा कि मैं इसके बारे में कुछ सरल बेंचमार्क करूं कि यह कैसे व्यवहार करता है। मैं इसके प्रदर्शन की सीमा को आगे बढ़ाना चाहता था इसलिए मैंने अमेज़ॅन ईसी 2 i2.8xlargeउदाहरण (लगभग $ 7 / घंटा, समय वास्तव में पैसा है!) का प्रावधान किया । इस उदाहरण में 8 800GB SSD हैं।

मैंने fioखुद SSDs पर एक परीक्षण किया, और निम्न आउटपुट (छंटनी) प्राप्त किया:

$ 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 रैंडम राइट्स के लिए 57K IOPS। सम्मानजनक।

मैंने तब सभी में फैले हुए एक ZFS वॉल्यूम को बनाया। पहले तो मेरे पास raidz1सभी 8 SSDs के साथ एक vdev था , लेकिन मैंने उन कारणों के बारे में पढ़ा जो प्रदर्शन के लिए खराब हैं, इसलिए मैंने चार mirrorvdevs के साथ समाप्त किया , जैसे:

$ 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      -      -      -         -      -      -

मैंने रिकॉर्ड को 4K पर सेट किया और अपना परीक्षण चलाया:

$ 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]

मुझे इस ZFS पूल पर केवल 52K IOPS मिलता है। यह वास्तव में एक SSD की तुलना में थोड़ा खराब है।

मुझे समझ नहीं आ रहा है कि मैं यहाँ क्या कर रहा हूँ। क्या मैंने ZFS को गलत तरीके से कॉन्फ़िगर किया है, या यह ZFS के प्रदर्शन की खराब परीक्षा है?

ध्यान दें, मैं आधिकारिक 64-बिट CentOS 7 HVM छवि का उपयोग कर रहा हूं, हालांकि मैंने 4.4.5 elrepo कर्नेल में अपग्रेड किया है:

$ 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 रेपो से ZFS स्थापित किया । मेरे पास zfsपैकेज का संस्करण 0.6.5.5 है ।

अद्यतन : प्रति @ ewwhite का सुझाव मैंने कोशिश की ashift=12और ashift=13:

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

तथा

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

इनमें से किसी ने भी कोई अंतर नहीं किया। जो मैं समझता हूं कि नवीनतम जेडएफएस बिट्स 4K एसएसडी की पहचान करने और उचित चूक का उपयोग करने के लिए पर्याप्त स्मार्ट हैं।

मैंने हालांकि यह देखा कि CPU उपयोग स्पाइकिंग है। @ टिम ने यह सुझाव दिया लेकिन मैंने इसे खारिज कर दिया लेकिन मुझे लगता है कि मैं सीपीयू को लंबे समय तक नोटिस नहीं कर रहा था। इस उदाहरण में 30 सीपीयू कोर जैसे कुछ हैं, और सीपीयू का उपयोग 80% तक बढ़ रहा है। भूख प्रक्रिया? z_wr_issइसके उदाहरण बहुत सारे हैं।

मैंने पुष्टि की कि संपीड़न बंद है, इसलिए यह संपीड़न इंजन नहीं है।

मैं raidz का उपयोग नहीं कर रहा हूं, इसलिए यह समता गणना नहीं होनी चाहिए।

मैंने किया था perf topऔर यह _raw_spin_unlock_irqrestoreअंदर z_wr_int_4और बाहर बिताए गए अधिकांश कर्नेल समय को दिखाता osq_lockहै z_wr_iss।

मुझे अब विश्वास है कि इस प्रदर्शन में अड़चन के लिए एक सीपीयू घटक है, हालांकि मैं यह पता लगाने के लिए करीब नहीं हूं कि यह क्या हो सकता है।

अद्यतन 2 : प्रति @ewwhite और अन्य लोगों के सुझाव कि यह इस वातावरण की आभासीकृत प्रकृति है जो प्रदर्शन अनिश्चितता पैदा करती है, मैं fioपर्यावरण में एसएसडी के चार में फैले यादृच्छिक 4K लिखता था। प्रत्येक SSD अपने आप में ~ 55K IOPS देता है, इसलिए मुझे उम्मीद है कि उनमें से चार के आसपास 240K IO होंगे। मुझे कमोबेश यही मिला:

$ 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]

यह स्पष्ट रूप से पर्यावरण को दिखाता है, हालांकि यह हो सकता है कि मैं देख रहा हूं की तुलना में IOPS को बनाए रख सकता है। जेडएफएस को लागू करने के तरीके के बारे में कुछ इसे शीर्ष गति से रखने से है। मैं अभी पता नहीं लगा सकता कि वह क्या है।

Comments

आप EC2 पर हैं। आपको केवल उतने ही IOPS मिलते हैं जितने Amazon आपको देना चाहता है।

— माइकल हैम्पटन

अमेज़ॅन मुझे इस उदाहरण से जुड़ी प्रति एसएसडी के बारे में 52K IOPS देता है, और इस तरह के आठ एसएसडी संलग्न हैं। अमेज़ॅन डॉक्स से यह स्पष्ट है कि यह आकार भौतिक होस्ट पर चल रहा एकमात्र उदाहरण है जहां वह रहता है। इसके अलावा ये स्थानीय SSDs हैं, EBS वॉल्यूम नहीं हैं, इसलिए IO बैंडविड्थ के लिए कोई अन्य वर्कलोड नहीं है। मैं जो प्रदर्शन देख रहा हूं उसका कोई हिसाब नहीं है।

— ऐलनसन 19:16

क्या यह सीपीयू पर टैक्स लगाना है या मेमोरी की सीमा को रोकना है?

— टिम

क्या आपने लेखों की इस श्रृंखला को पढ़ा है? hatim.eu/2014/05/24/… क्या किसी अन्य लेख ने बिल्कुल मदद की है?

— टिम

बस zfsonlinux की वास्तविक कार्यान्वयन कमियों को दूर करने के लिए, मैं उसी बेंच परीक्षण की कोशिश करूंगा जिसमें सोलारिस 11 उसी उदाहरण पर स्थापित हो।

— वाबेट

Answer 1

यह सेटअप अच्छी तरह से ट्यून नहीं किया जा सकता है। SSDs का उपयोग करते समय /etc/modprobe/zfs.conf फ़ाइल और एशफ़्ट मान दोनों के लिए आवश्यक पैरामीटर हैं

एशिफ्ट = 12 या 13 का प्रयास करें और फिर से परीक्षण करें।

---

संपादित करें:

यह अभी भी एक वर्चुअलाइज्ड समाधान है, इसलिए हम अंतर्निहित हार्डवेयर के बारे में बहुत अधिक नहीं जानते हैं या सब कुछ कैसे जुड़ा हुआ है। मुझे नहीं पता कि आपको इस समाधान से बेहतर प्रदर्शन मिलेगा।

---

संपादित करें:

मुझे लगता है कि मैं इस तरह से एक बादल उदाहरण को अनुकूलित करने की कोशिश करने की बात नहीं देखता। क्योंकि यदि शीर्ष प्रदर्शन का उद्देश्य था, तो आप हार्डवेयर का उपयोग करेंगे, है ना?

लेकिन याद रखें कि ZFS में बहुत सारी ट्यून करने योग्य सेटिंग्स होती हैं, और जो आप डिफ़ॉल्ट रूप से प्राप्त करते हैं वह कहीं भी आपके उपयोग के मामले के करीब नहीं है।

अपने /etc/modprobe.d/zfs.confऔर रिबूट में निम्नलिखित का प्रयास करें । यह वही है जो मैं एप्लिकेशन सर्वर के लिए अपने सभी-एसएसडी डेटा पूल में उपयोग करता हूं। आपकी राखियां 12 या 13 होनी चाहिए। संपीड़न के साथ बेंचमार्क = बंद, लेकिन उत्पादन में संपीड़न = lz4 का उपयोग करें। Atime = बंद सेट करें। मैं डिफ़ॉल्ट (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

Comments

शानदार सुझाव। मैंने अपने मूल प्रश्न को अधिक विस्तार से अद्यतन किया। सारांश: ashift ने मदद नहीं की, और मुझे लगता है कि इस समस्या के लिए एक CPU उपयोग घटक है।

— अनलसन

आप संपीड़न या dedupe का उपयोग कर रहे हैं?

— ewwhite

नहीं, मैंने पुष्टि की संपीड़न के साथ बंद है zfs get compression। Dedupe भी बंद है।

— अनलसन

यह एक उचित बिंदु है लेकिन मैं दिखा सकता हूं कि अंतर्निहित वर्चुअलाइज्ड स्टोरेज डिवाइस बेहतर प्रदर्शन कर रहे हैं। पोस्ट पर अपडेट 2 देखें।

— ऐलसन

@anelson ठीक है। ऊपर सेटिंग्स की कोशिश करें।

— इविहित

Answer 2

ऐसा लगता है कि आप लिनक्स कर्नेल म्यूटेक्स लॉक पर प्रतीक्षा कर रहे हैं जो बदले में एक एक्सन रिंग बफर पर प्रतीक्षा कर सकता है। मैं एक समान मशीन तक पहुंच के बिना इसके बारे में निश्चित नहीं हो सकता, लेकिन मुझे उस विशेषाधिकार के लिए अमेज़ॅन $ 7 / घंटे का भुगतान करने में कोई दिलचस्पी नहीं है।

लंबा लेखन यहाँ है: https://www.reddit.com/r/zfs/comments/4b4r1y/why_is_zfs_on_linux_unable_to_fully_utilize_8x/e1e91wo ; मैं बल्कि यह दो से एक जगह पर होगा।

Answer 3

मैंने इसे ट्रैक करने के लिए समय की एक सभ्य राशि खर्च की है। मेरी विशिष्ट चुनौती: एक सर्वर को पोस्टग्रेट करता है और मैं इसके डेटा वॉल्यूम के लिए ZFS का उपयोग करना चाहता हूं। आधार रेखा XFS है।

और सबसे पहले, मेरे परीक्षणों ने मुझे बताया कि ashift=12गलत है। अगर कुछ मैजिक ashiftनंबर है तो यह 12. मैं उपयोग नहीं कर 0रहा हूं और मुझे बहुत अच्छे परिणाम मिल रहे हैं।

मैंने भी zfs विकल्पों के एक समूह के साथ प्रयोग किया है और जो मुझे नीचे दिए गए परिणाम देते हैं:

atime=off - मुझे एक्सेस टाइम की जरूरत नहीं है

checksum=off - मैं स्ट्रिपिंग कर रहा हूं, मिररिंग नहीं

compression=lz4- संपीड़न संपीड़न के साथ बेहतर है (सीपीयू ट्रेडऑफ?)

exec=off - यह डेटा के लिए है, निष्पादन योग्य नहीं है

logbias=throughput - इंटरव्यू पर पढ़ें यह पोस्टग्रैज के लिए बेहतर है

recordsize=8k - पीजी विशिष्ट 8k blockize

sync=standard- सिंक को बंद करने की कोशिश की; ज्यादा फायदा नहीं देखा

नीचे दिए गए मेरे परीक्षण XFS के प्रदर्शन से बेहतर हैं (यदि आपको मेरे परीक्षणों में त्रुटियां दिखती हैं तो कृपया टिप्पणी करें!)।

इसके साथ मेरा अगला चरण 2 x EBS ZFS फाइल सिस्टम पर चलने वाले Postgres का प्रयास है।

मेरा विशिष्ट सेटअप:

EC2: m4.xlargeउदाहरण

EBS: 250GB gp2वॉल्यूम

कर्नेल: लिनक्स [...] 3.13.0-105-जेनेरिक # 152-उबंटू एसएमपी [...] x86_64 x86_64 x86_64 GNU / लिनक्स *

सबसे पहले, मैं कच्चे ईबीएस प्रदर्शन का परीक्षण करना चाहता था। fioऊपर दिए गए आदेश की भिन्नता का उपयोग करते हुए , मैं नीचे दिए गए झुकाव के साथ आया। नोट: मैं 8k ब्लॉक्स का उपयोग कर रहा हूं क्योंकि मैंने जो पोस्टग्रेक्यूएल लिखा है, वह इस प्रकार है:

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 वॉल्यूम के लिए कच्चा प्रदर्शन है WRITE: io=3192.2MB।

अब, XFS का उसी fioकमांड के साथ परीक्षण :

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%

हमारी आधार रेखा है WRITE: io=3181.9MB; वास्तव में कच्चे डिस्क की गति के करीब।

अब, WRITE: io=3181.9MBसंदर्भ के रूप में ZFS पर :

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

ध्यान दें, यह XFS से बेहतर प्रदर्शन किया WRITE: io=4191.7MB। मुझे पूरा यकीन है कि यह संपीड़न के कारण है।

किक के लिए, मैं एक दूसरी मात्रा जोड़ने जा रहा हूँ:

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

एक दूसरे खंड के साथ WRITE: io=5975.9MB, इसलिए ~ 1.8X लिखता है।

एक तीसरा खंड हमें देता है WRITE: io=6667.5MB, इसलिए ~ 2.1X लिखता है।

और एक चौथा खंड हमें देता है WRITE: io=6552.9MB। इस प्रकार के उदाहरण के लिए, ऐसा लगता है कि मैं लगभग दो संस्करणों के साथ ईबीएस नेटवर्क को कैप करता हूं, निश्चित रूप से तीन के साथ और यह 4 (750 * 3 = 2250 आईओपीएस) के साथ बेहतर नहीं है।

* इस वीडियो से यह सुनिश्चित करें कि आप सभी EBS अच्छाई पाने के लिए 3.8+ linux कर्नेल का उपयोग कर रहे हैं।

Comments

दिलचस्प परिणाम। नोट मुझे लगता है कि आप भ्रमित हैं WRITE: io=; यह गति नहीं है, यह उस समय में लिखे गए डेटा की मात्रा है। केवल उन्हीं परीक्षणों के लिए गति से संबंधित हैं जिनके पास एक निश्चित रनटाइम है, लेकिन अन्य बेंचमार्क के साथ सुसंगतता के लिए IOPS पर ध्यान केंद्रित करना बेहतर है iops=। यदि आप IOPS EBS वॉल्यूम और बड़े उदाहरणों का उपयोग करते हैं तो आपके मामले में परिणाम समान हैं। उदाहरण के आकार के अनुसार अपेक्षित ईबीएस कैप के लिए इस पृष्ठ को देखें । बस सावधान रहें, यदि आप सावधान नहीं हैं तो ईबीएस शुल्क तेजी से जोड़ते हैं!

— ऐलनसन

शानदार प्रतिक्रिया, धन्यवाद @anelson! प्रोन्नत iops को देखा और वे बहुत pricey हैं। हालांकि, मैं एक लॉग वॉल्यूम के लिए एक छोटा प्रावधान किए गए आयोप्स वॉल्यूम बनाने पर विचार कर रहा था जहां ZIL लिखा गया है और कुछ प्रदर्शन लाभ प्राप्त करते हैं। कहीं मैंने पढ़ा है कि ZIL मेमोरी में जो है उससे बड़ा नहीं होता है और मेरे पास इसमें 2G तक सीमित है /etc/modules.d/zfs.conf। अगला प्रश्न यह होगा कि एक एक्जाम 2 के लिए आईओपी की उपयुक्त संख्या क्या है। आपके द्वारा संदर्भित पृष्ठ को देखते हुए यह अभी भी मुश्किल है, और मैं डॉक्स स्थिति के रूप में अच्छा प्रदर्शन नहीं देख रहा हूं।

— बर्टो