Score:1

AWS i3en.3xlarge iops ต่ำมาก

ธง lk

ฉันเพิ่งเปิดตัวอินสแตนซ์ ec2 ใหม่ประเภท i3en.3xlarge ระบบปฏิบัติการคือ Ubuntu ฉันติดตั้งที่เก็บอินสแตนซ์ NVMe แต่ทุกการทดสอบความเร็วที่ฉันเรียกใช้นั้นต่ำอย่างไม่น่าเชื่อที่ประมาณ 7k iops ผมทำอะไรผิดหรือเปล่า?

นี่คือขั้นตอนที่ฉันทำ:

1) ตรวจสอบ ssds ที่มี nvme -list:

-------------- -------------------- -------------- -------------------------- ------------------------- ----------- ---------------- --------
/dev/nvme0n1 vol012301587a8724842 Amazon Elastic Block Store 1 8.59 GB / 8.59 GB 512 B + 0 B 1.0     
/dev/nvme1n1 AWS16AAAC6C7BFAC4972 พื้นที่จัดเก็บอินสแตนซ์ Amazon EC2 NVMe 1 7.50 TB / 7.50 TB 512 B + 0 B 0

2) สร้างระบบไฟล์ xfs ใหม่สำหรับ nvme1n1:

sudo mkfs -t xfs /dev/nvme1n1.dll

3) ติดไว้ที่ /home

sudo เมานต์ /dev/nvme1n1 /home

4) ตรวจสอบ df -h:

    ubuntu@ip-172-31-35-146:/home$ df -h
ขนาดระบบไฟล์ที่ใช้ Avail Use% Mounted on
/dev/root 7.7G 2.8G 4.9G 37% /
devtmpfs 47G 0 47G 0% /การพัฒนา
tmpfs 47G 0 47G 0% /dev/shm
tmpfs 9.4G 852K 9.4G 1% /รัน
tmpfs 5.0M 0 5.0M 0% /รัน/ล็อค
tmpfs 47G 0 47G 0% /sys/fs/cgroup
/dev/loop0 25M 25M 0 100% /snap/amazon-ssm-agent/4046
/dev/loop3 43M 43M 0 100% /snap/snapd/14066
/dev/loop2 68M 68M 0 100% /snap/lxd/21835
/dev/loop1 56M 56M 0 100% /snap/core18/2284
/dev/loop4 62M 62M 0 100% /snap/core20/1242
/dev/loop6 56M 56M 0 100% /snap/core18/2253
/dev/loop5 44M 44M 0 100% /snap/snapd/14549
/dev/loop7 62M 62M 0 100% /snap/core20/1328
tmpfs 9.4G 0 9.4G 0% /รัน/ผู้ใช้/1000
/dev/nvme1n1 6.9T 49G 6.8T 1% /บ้าน

5)รันการทดสอบด้วย fio:

fio -direct=1 -ioความลึก=1 -rw=randread -ioengine=libaio -bs=4k -size=1G -numjobs=1 -runtime=1000 -group_reporting -filename=iotest -name=Rand_Read_Testing

ผลลัพธ์ Fio:

ฟิโอ-3.16
เริ่มต้น 1 กระบวนการ
Rand_Read_Testing: การวางไฟล์ IO (1 ไฟล์ / 1024MiB)
งาน: 1 (f=1): [r(1)][100.0%][r=28.5MiB/s][r=7297 IOPS][eta 00m:00s]
Rand_Read_Testing: (groupid=0, งาน=1): err= 0: pid=1701: วันเสาร์ที่ 29 มกราคม 22:28:17 2022
  อ่าน: IOPS=7139, BW=27.9MiB/s (29.2MB/s)(1024MiB/36717msec)
    slat (nsec): นาที=2301, สูงสุด=39139, เฉลี่ย=2448.98, stdev=311.68
    ชุด (usec): min=32, max=677, avg=137.06, stdev=26.98
     lat (usec): นาที=35, สูงสุด=680, เฉลี่ย=139.59, stdev=26.99
    เปอร์เซ็นไทล์ลิ่ม (usec):
     | 1.00th=[ 35], 5.00th=[ 99], 10.00th=[ 100], 20.00=[ 124],
     | 30.00th=[ 125], 40.00th=[ 126], 50.00th=[ 139], 60.00th=[ 141],
     | 70.00th=[ 165], 80.00th=[ 167], 90.00th=[ 169], 95.00th=[ 169],
     | 99.00th=[ 172], 99.50th=[ 174], 99.90th=[ 212], 99.95th=[ 281],
     | 99.99th=[ 453]
   bw ( KiB/s): ต่ำสุด=28040, สูงสุด=31152, ต่อ=99.82%, เฉลี่ย=28506.48, stdev=367.13, ตัวอย่าง=73
   iops : นาที= 7010, สูงสุด= 7788, เฉลี่ย=7126.59, stdev=91.80, ตัวอย่าง=73
  lat (usec) : 50=1.29%, 100=9.46%, 250=89.19%, 500=0.06%, 750=0.01%
  ซีพียู : usr=1.43%, sys=2.94%, ctx=262144, majf=0, minf=12
  ความลึก IO : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     ส่ง : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     สมบูรณ์ : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     ออก rwts: รวม = 262144,0,0,0 สั้น = 0,0,0,0 ลดลง = 0,0,0,0
     เวลาแฝง : เป้าหมาย = 0, หน้าต่าง = 0, เปอร์เซ็นต์ไทล์ = 100.00%, ความลึก = 1

รันสถานะกลุ่ม 0 (งานทั้งหมด):
   อ่าน: bw=27.9MiB/s (29.2MB/s), 27.9MiB/s-27.9MiB/s (29.2MB/s-29.2MB/s), io=1024MiB (1074MB), run=36717-36717msec

สถิติดิสก์ (อ่าน/เขียน):
  nvme1n1: ios=259894/5, merge=0/3, ticks=35404/0, in_queue=35404, util=99.77%

ตามมาตรฐานเช่น ที่นี่ ประสิทธิภาพของ iops น่าจะดีกว่านี้

นี่ฉันพลาดอะไรไปหรือเปล่า?

ขอบคุณล่วงหน้า

Tim avatar
gp flag
Tim
หวังว่าจะมีคนช่วยคุณได้ ถ้าไม่ ฉันคิดว่าคุณอาจพบว่าการมี AWS Support มีประโยชน์จริงๆ ด้วยอินสแตนซ์ขนาดใหญ่เช่นนี้ การสนับสนุนสำหรับนักพัฒนานั้นไม่ได้มีราคาแพงเป็นพิเศษและมีประโยชน์จริงๆ
Score:1
ธง lk

ขอบคุณการตอบสนองของ @ shearn89 และการสนับสนุน aws ฉันคิดว่าวิธีที่ฉันรันการทดสอบ fio นั้นเป็นปัญหา

นี่คือสิ่งที่ AWS บอกฉัน:

ในการเริ่มต้น อินสแตนซ์ประเภท i3.4xlarge มี IOPS การอ่าน/เขียนที่ 825k และ 360k ตามลำดับ [1]สามารถรับประสิทธิภาพ IOPS นี้ได้โดยใช้ขนาดบล็อกสูงสุด 4KB และที่ความอิ่มตัวของความลึกของคิว

Volume Queue Length คือจำนวนคำขอ I/O ที่ค้างอยู่สำหรับอุปกรณ์ ความยาวคิวที่เหมาะสมที่สุดจะแตกต่างกันไปสำหรับแต่ละเวิร์กโหลด ขึ้นอยู่กับความไวของแอปพลิเคชันเฉพาะของคุณต่อ IOPS และเวลาแฝง หากปริมาณงานของคุณส่งคำขอ I/O ไม่เพียงพอที่จะใช้งานประสิทธิภาพที่มีอยู่สำหรับไดรฟ์ข้อมูล EBS ของคุณอย่างเต็มที่ ไดรฟ์ข้อมูลของคุณอาจไม่ส่ง IOPS หรือปริมาณงานที่คุณจัดเตรียมไว้ [2]

หากต้องการกำหนดความยาวคิวที่เหมาะสมที่สุดสำหรับปริมาณงานของคุณบนไดรฟ์ข้อมูล SSD เราขอแนะนำให้คุณกำหนดเป้าหมายความยาวคิวเป็น 1 สำหรับทุกๆ 1,000 IOPS ที่มี [3] การเพิ่มความยาวคิวจะเป็นประโยชน์จนกว่าคุณจะบรรลุ IOPS ที่จัดเตรียมไว้ ปริมาณงาน หรือค่าความยาวคิวของระบบที่เหมาะสมที่สุด ซึ่งปัจจุบันตั้งค่าเป็น 32 สำหรับข้อมูลเพิ่มเติมเกี่ยวกับความลึกของคิว โปรดดูบทความของบุคคลที่สามเหล่านี้ซึ่งอธิบายคำศัพท์อย่างละเอียด [4][5][6].

เพื่อจำลองปัญหาของคุณ ฉันเปิดตัวอินสแตนซ์ประเภทเดียวกันและ AMI สร้างอาร์เรย์ RAID 0 โดยใช้อุปกรณ์จัดเก็บ NVMe 2 อินสแตนซ์ [7] และเรียกใช้ fio ด้วยพารามิเตอร์เดียวกับที่คุณระบุ ผลลัพธ์จะคล้ายกับสิ่งที่คุณทำได้:

$ sudo fio -direct=1 -ioความลึก=1 -rw=randread -ioengine=libaio -bs=4k -size=1G -numjobs=1 -runtime=1000 -group_reporting -filename=iotest -name=Rand_Read_Testing
iops : นาที= 8820, สูงสุด= 9196, เฉลี่ย=8905.17, stdev=102.04, ตัวอย่าง=58

$ sudo fio -direct=1 -ioความลึก=1 -rw=randwrite -ioengine=libaio -bs=4k -size=1G -numjobs=1 -runtime=1000 -group_reporting -filename=iotest -name=Rand_Read_Testing
iops : นาที= 1552, สูงสุด= 2012, เฉลี่ย=1883.84, stdev=59.06, ตัวอย่าง=278

ฉันทำการทดสอบข้างต้นซ้ำและสามารถเข้าถึง R/W IOPS ที่ 824k และ 460k ตามลำดับ โดยการตั้งค่าพารามิเตอร์ "ioความลึก=32" และ "numjobs=16":

$ sudo fio --directory=/mnt/raid --name fio_test_file --direct=1 --rw=randread --bs=4k --size=1G --numjobs=16 --time_based --runtime=180 -- group_reporting --norandommap --ioความลึก=32 --ioengine=libaio
iops : นาที=572631, สูงสุด=910386, เฉลี่ย=824619.49, stdev=3518.58, ตัวอย่าง=5745
   
$ sudo fio --directory=/mnt/raid --name fio_test_file --direct=1 --rw=randwrite --bs=4k --size=1G --numjobs=16 --time_based --runtime=180 -- group_reporting --norandommap --ioความลึก=32 --ioengine=libaio
iops : นาที=291970, สูงสุด=509505, เฉลี่ย=360163.50, stdev=2193.22, ตัวอย่าง=5760

โปรดทราบว่า IOPS ของที่จัดเก็บอินสแตนซ์ยังขึ้นอยู่กับปัจจัยหลายอย่างรวมถึงปัจจัยที่กล่าวถึงข้างต้น เช่น ประเภท I/O, ขนาดบล็อก, ขนาด I/O, กลไก I/O, ความลึกของ I/O, จำนวนไฟล์/ อุปกรณ์ และจำนวนเธรด/กระบวนการ สำหรับข้อมูลเพิ่มเติมเกี่ยวกับวิธีปรับแต่งพารามิเตอร์เพื่อเพิ่มประสิทธิภาพ โปรดดูบทความเหล่านี้ [8][9][10]

นอกจากนี้ ที่เก็บอินสแตนซ์ยังมีพื้นที่จัดเก็บชั่วคราวสำหรับอินสแตนซ์ของคุณ และข้อมูลจะสูญหายหากดิสก์พื้นฐานทำงานล้มเหลว หรือหากอินสแตนซ์หยุดทำงาน/ยุติ [11] ดังนั้น หากคุณต้องการพื้นที่จัดเก็บข้อมูลถาวร ให้พิจารณาตัวเลือกที่ทนทานกว่า เช่น Amazon EBS [12]

ฉันหวังว่าคุณจะพบว่าข้อมูลข้างต้นมีประโยชน์ โปรดแจ้งให้เราทราบหากคุณมีคำถามทางเทคนิคเพิ่มเติม

ขอขอบคุณ.

Score:0
ธง cn

ดังนั้นฉันจึงขยายหนึ่งในตัวอย่างเหล่านี้เพื่อทดสอบตัวเอง ขั้นตอนของฉันแตกต่างกันเพียงเล็กน้อย:

  1. แบ่งพาร์ติชันดิสก์ก่อนโดยใช้ แยกทาง
  2. สร้างระบบไฟล์
  3. ติดที่ /เลือก เช่น /บ้าน อยู่ที่นั่นแล้วและมีโฮมไดเร็กตอรี่ของผู้ใช้ของฉันอยู่ใน (อูบุนตู).
  4. ปรับปรุง apt && อัพเกรด aptจากนั้นทำการติดตั้ง ฟิโอ
  5. รันคำสั่งเดียวกับคุณ: fio -direct=1 -ioความลึก=1 -rw=randread -ioengine=libaio -bs=4k -size=1G -numjobs=1 -runtime=1000 -group_reporting -filename=iotest -name=Rand_Read_Testing จากภายใน /เลือก, กับ ซูโด.

ฉันได้ผลลัพธ์ที่คล้ายกันกับ อ่าน: IOPS=7147.

จากนั้นฉันก็ทำการทดสอบอีกครั้ง:

/opt$ sudo fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=fiotest --filename=testfio --bs=4k --ioความลึก=64 --size=8G --readwrite=randrw --rwmixread=75
การทดสอบ: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, ioความลึก=64
ฟิโอ-3.16
เริ่มต้น 1 กระบวนการ
fiotest: การวางไฟล์ IO (1 ไฟล์ / 8192MiB)
งาน: 1 (f=1): [m(1)][100.0%][r=332MiB/s,w=109MiB/s][r=85.1k,w=28.0k IOPS][eta 00m:00s]
fiotest: (groupid=0, งาน=1): err= 0: pid=26470: จ. 31 ม.ค. 09:14:45 น. 2565
  อ่าน: IOPS=91.5k, BW=357MiB/s (375MB/s)(6141MiB/17187msec)
   bw ( KiB/s): นาที=339568, สูงสุด=509896, ต่อ=100.00%, เฉลี่ย=366195.29, stdev=59791.96, ตัวอย่าง=34
   iops : นาที=84892, สูงสุด=127474, เฉลี่ย=91548.82, stdev=14947.99, ตัวอย่าง=34
  เขียน: IOPS=30.5k, BW=119MiB/s (125MB/s)(2051MiB/17187msec); 0 โซนรีเซ็ต
   bw ( KiB/s): นาที=111264, สูงสุด=170424, ต่อ=100.00%, เฉลี่ย=122280.71, stdev=20225.33, ตัวอย่าง=34
   iops : นาที=27816, สูงสุด=42606, เฉลี่ย=30570.18, stdev=5056.32, ตัวอย่าง=34
  ซีพียู : usr=19.73%, sys=41.60%, ctx=742611, majf=0, minf=8
  ความลึก IO : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
     ส่ง : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     สมบูรณ์ : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
     ออก rwts: รวม = 1572145,525007,0,0 สั้น = 0,0,0,0 ลดลง = 0,0,0,0
     เวลาแฝง : เป้าหมาย = 0, หน้าต่าง = 0, เปอร์เซ็นต์ไทล์ = 100.00%, ความลึก = 64

รันสถานะกลุ่ม 0 (งานทั้งหมด):
   อ่าน: bw=357MiB/s (375MB/s), 357MiB/s-357MiB/s (375MB/s-375MB/s), io=6141MiB (6440MB), run=17187-17187msec
  เขียน: bw=119MiB/s (125MB/s), 119MiB/s-119MiB/s (125MB/s-125MB/s), io=2051MiB (2150MB), run=17187-17187msec

สถิติดิสก์ (อ่าน/เขียน):
  nvme1n1: ios=1563986/522310, merge=0/0, ticks=927244/24031, in_queue=951275, util=99.46%

...ซึ่งดูดีกว่ามาก - อ่าน: IOPS=91.5k.

ฉันสงสัยว่าเป็นเพราะการทดสอบแบบอ่านอย่างเดียวทำงานอย่างไร หรือความแตกต่างเล็กน้อยในการอ่านดิสก์ที่คุณเปิดอยู่ และข้อจำกัดอื่นๆ

ฉันทำการทดสอบอีกสองสามครั้งและได้ผลลัพธ์ที่คล้ายกันในแต่ละครั้ง

จากนั้นฉันรันการทดสอบแบบอ่านอย่างเดียวอีกครั้งโดยใช้คำสั่งจาก ที่นี่และได้รับสิ่งนี้:

/opt$ sudo fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=fiotest --filename=testfio --bs=4k --ioความลึก=64 --size=8G --readwrite=randread
การทดสอบ: (g=0): rw=randread, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, ioความลึก=64
ฟิโอ-3.16
เริ่มต้น 1 กระบวนการ
งาน: 1 (f=1): [r(1)][100.0%][r=332MiB/s][r=85.1k IOPS][eta 00m:00s]
fiotest: (groupid=0, งาน=1): err= 0: pid=26503: จ. 31 ม.ค. 09:17:57 น. 2565
  อ่าน: IOPS=88.6k, BW=346MiB/s (363MB/s)(8192MiB/23663msec)
   bw ( KiB/s): นาที=339560, สูงสุด=787720, ต่อ=100.00%, เฉลี่ย=354565.45, stdev=72963.81, ตัวอย่าง=47
   iops : นาที=84890, สูงสุด=196930, เฉลี่ย=88641.40, stdev=18240.94, ตัวอย่าง=47
  ซีพียู : usr=15.37%, sys=31.05%, ctx=844523, majf=0, minf=72
  ความลึก IO : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
     ส่ง : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     สมบูรณ์ : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
     ออก rwts: รวม = 2097152,0,0,0 สั้น = 0,0,0,0 ลดลง = 0,0,0,0
     เวลาแฝง : เป้าหมาย = 0, หน้าต่าง = 0, เปอร์เซ็นต์ไทล์ = 100.00%, ความลึก = 64

รันสถานะกลุ่ม 0 (งานทั้งหมด):
   อ่าน: bw=346MiB/s (363MB/s), 346MiB/s-346MiB/s (363MB/s-363MB/s), io=8192MiB (8590MB), run=23663-23663msec

สถิติดิสก์ (อ่าน/เขียน):
  nvme1n1: ios=2095751/1, merge=0/0, ticks=1468160/0, in_queue=1468159, util=99.64%

ประสิทธิภาพการอ่านที่ดีขึ้นมาก ฉันสงสัยว่าอาร์กิวเมนต์ที่คุณให้คำสั่งไม่อนุญาตให้การทดสอบได้รับประสิทธิภาพที่ดีที่สุดจากดิสก์ อาจเป็นเพราะขนาดบล็อก ขนาดไฟล์ ฯลฯ ฉันสังเกตเห็นว่าอาร์กิวเมนต์ทั้งหมดเป็นอาร์กิวเมนต์แบบเส้นประเดียว (เช่น -bs=4k) ไม่เป็นสองเท่า (--bs=4k) ดังนั้นพวกเขาอาจแยกวิเคราะห์ไม่ถูกต้องด้วยซ้ำ...

Raphael Noero avatar
lk flag
ขอบคุณมากสำหรับคำตอบที่ซับซ้อนนี้ ฉันคิดว่าคุณพูดถูกและนี่ก็คล้ายกับสิ่งที่ฝ่ายสนับสนุน aws บอกฉัน

โพสต์คำตอบ

คนส่วนใหญ่ไม่เข้าใจว่าการถามคำถามมากมายจะปลดล็อกการเรียนรู้และปรับปรุงความสัมพันธ์ระหว่างบุคคล ตัวอย่างเช่น ในการศึกษาของ Alison แม้ว่าผู้คนจะจำได้อย่างแม่นยำว่ามีคำถามกี่ข้อที่ถูกถามในการสนทนา แต่พวกเขาไม่เข้าใจความเชื่อมโยงระหว่างคำถามและความชอบ จากการศึกษาทั้ง 4 เรื่องที่ผู้เข้าร่วมมีส่วนร่วมในการสนทนาด้วยตนเองหรืออ่านบันทึกการสนทนาของผู้อื่น ผู้คนมักไม่ตระหนักว่าการถามคำถามจะมีอิทธิพลหรือมีอิทธิพลต่อระดับมิตรภาพระหว่างผู้สนทนา