การวัด 'จำนวนไบต์ทั้งหมดที่เขียน' ภายใต้ Linux

36

เราค่อนข้างสนใจที่จะสำรวจความเป็นไปได้ของการใช้ไดรฟ์ SSD ในสภาพแวดล้อมเซิร์ฟเวอร์ อย่างไรก็ตามสิ่งหนึ่งที่เราจำเป็นต้องสร้างคืออายุการใช้งานที่ยาวนานของไดรฟ์ ตามที่ผู้ผลิตบทความนี้มีการรายงานความอดทนไดรฟ์ในแง่ของ 'รวมไบต์เขียน' (TBW) ตัวอย่างจากบทความนั้น Crucial C400 SSD ได้รับการจัดอันดับที่ 72TB TBW สคริปต์ / เครื่องมือใด ๆ ที่มีอยู่ภายใต้ระบบนิเวศลินุกซ์เพื่อช่วยเราวัด TBW หรือไม่? (จากนั้นทำการตัดสินใจอย่างมีความรู้เกี่ยวกับความเป็นไปได้ของการใช้ไดรฟ์ SSD)

linux ssd io measurement

— ข่าวร้าย
แหล่งที่มา

28

เป็นไปได้ก็คือการดูที่/ proc / diskstats มันไม่ได้คงอยู่ตลอดการบูตเครื่องใหม่ แต่มีข้อมูลสำหรับอุปกรณ์บล็อกทุกตัว ที่น่าสนใจที่สุดสำหรับคุณคือฟิลด์ 10 ซึ่งมีจำนวนภาคทั้งหมดที่เขียน บนระบบที่มีดิสก์ scsi ที่มีขนาดเซกเตอร์ 512 ไบต์คุณสามารถเรียกใช้ได้

awk '/sd/ {print $3"\t"$10 / 2 / 1024}' /proc/diskstats

เพื่อดูจำนวนเมกะไบต์ที่ถูกเขียนลงในแต่ละอุปกรณ์ ผลลัพธ์จะมีลักษณะดังนี้

sda 728.759
sda1 79.0908
sda2 649.668

— Sciurus
แหล่งที่มา

4

ขนาดเซกเตอร์สามารถพบได้โดยใช้คำสั่ง #cat / sys / block / sda / queue / hw_sector_size

— Antonio

@ อันโตนิโอขอบคุณ! ฉันไม่แน่ใจว่าจะมีการเพิ่มเมื่อใด ดูเหมือนว่าจะอยู่ใน 3.2 แต่ไม่ใช่ 2.6.18

— sciurus

@sciurus คุณสามารถอธิบายคณิตศาสตร์ที่อยู่เบื้องหลังการคำนวณของคุณได้ไหม คุณกำลังพูดเกี่ยวกับขนาดของภาค = 512 แต่การคำนวณของคุณจะหารค่าอ่านที่มี 2/1024

— วงกลม

@gyre ฟิลด์ 10 มีจำนวนเซ็กเตอร์ 0.5 กิโลไบต์ ฉันหารด้วย 2 เพื่อให้ได้จำนวนกิโลไบต์ที่เขียน จากนั้นฉันก็หารด้วย 1024 เพื่อแปลงเป็นเมกะไบต์

— sciurus

@antonio ที่ไม่แสดงขนาดเซกเตอร์ที่ถูกนำมาใช้กับฮาร์ดแวร์พื้นฐาน แต่ AFAICT จากแหล่งที่มาเคอร์เนล iostat แหล่งที่มาและการทดสอบเชิงประจักษ์ที่ "ภาค" ตัวเลขที่อยู่ใน / proc / diskstats เสมอหมายถึง 512 ไบต์แม้ในขณะที่hw_sector_sizeมีความแตกต่าง ( อย่างน้อยก็ตั้งแต่ 2.4 ซีรี่ส์) ดูโดยเฉพาะอย่างยิ่งblock/cfq-iosched.c cfqg_stats_update_dispatch()

— พอล

23

ฉันกำลังดิ้นรนกับปัญหาเดียวกันในสมุดบันทึกของฉัน แต่เมื่อฉันเริ่มระบบใหม่ทุกวันคำตอบที่ยอมรับไม่ได้มีประโยชน์ ฉันมี Samsung mSATA SSD ซึ่งมีแอตทริบิวต์ SMART # 241 Total_LBAs_Written อ้างอิงถึงเอกสารที่เป็นทางการ ,

ในการคำนวณขนาดรวม (เป็นไบต์) ให้คูณค่าดิบของแอตทริบิวต์นี้ด้วย 512B

ดังนั้นคำสั่งดังต่อไปนี้จะให้ TB ทั้งหมดที่ฉันเขียนบนดิสก์ SSD

sudo smartctl -A /dev/sdb | awk '/^241/ { print "TBW: "($10 * 512) * 1.0e-12, "TB" } '

ขณะที่มันทำงานบน HDD ของฉันฉันคิดว่ามันควรทำงานบนฮาร์ดดิสก์ที่ทันสมัยทุกชนิด

— Gabriel Miretti aka gmiretti
แหล่งที่มา

3

ไม่ได้มีเฉพาะในไดรฟ์ SSD บางรุ่นเท่านั้น มันไม่ได้เป็นสากล

— Michael Hampton

3

sudo smartctl -A /dev/sda1 | awk '/^241/ { print "TBW: "($10 * 512) * 1.0e-12, "TB" }'ผมอยากจะชี้ให้เห็นว่าสมการของคุณจริงผลิตตัวเลขที่จะปิดมันจะมีความถูกต้องมากขึ้นเป็น:

— Jordon Bedwell

ฉัน Intel SSD มีแอตทริบิวต์เดียวกัน Host_Writes_32MiBแต่ก็เรียกว่า นอกจากนี้ยังมีแอตทริบิวต์ NAND_Writes_1GiB249 ดังนั้นโปรดทราบว่าใน SSD แต่ละตัวนี้ดูเหมือนว่าจะแตกต่างกัน (เช่น mSATA Intel SSD ของฉันไม่มีคุณสมบัติเหล่านั้น)

— reox

บน Intel SSD Pro 5400s (SATA) ของฉันTotal_LBAs_Writtenมีการระบุเป็น GB! ไม่สามารถทำให้ความรู้สึกของ4714สมาร์ทต่ำแสดง แต่การดูในกล่องเครื่องมือ Intel SSD ใน Windows แสดงว่าเป็น GB

— MrCalvin

15

คุณสามารถดูจำนวนข้อมูลที่ถูกเขียนลงในระบบไฟล์ ext4 ได้โดยดูที่ / sys / fs / ext4 / $ DEVICE / ตลอดชีพ _write_kbytes

— Sciurus
แหล่งที่มา

นั่นเป็นคุณสมบัติที่ยอดเยี่ยมที่ฉันไม่รู้! อับอายที่สุดของระบบของเรากำลังทำงาน ext3 และยังมีบางพาร์ทิชัน LVM ดิบสำหรับ VMs :)

— badnews

ext3 (และระดับที่น้อยกว่าเล็กน้อย) ext4 ไม่ได้ถูกออกแบบมาสำหรับการเขียนไปยังแฟลช ความล้มเหลวจะเกิดขึ้นขึ้นอยู่กับจำนวนครั้งที่มีการเขียนตำแหน่ง - และด้วยระบบไฟล์แบบเดิมฮอตสปอตจะพัฒนาอย่างรวดเร็วมาก ตัวเลขที่ผู้ผลิตอ้างถึงนั้นสร้างความเข้าใจผิดมากเนื่องจากพวกเขาคิดว่ามีการเขียนที่แพร่กระจาย มีระบบไฟล์เช่น JFFS2 ออกแบบมาเป็นพิเศษเพื่อยืดอายุการใช้งาน SSD ของคุณ

— symcbean

2

@symcbean - ด้วยอุปกรณ์แฟลชในปัจจุบันนี้ส่วนใหญ่ไม่ใช่ปัญหา พวกเขาทุกคนมีกิจวัตรปรับระดับการสึกหรอที่ติดตั้งไว้ในชุดควบคุมบนบอร์ด

— EEAA

1

@symcbean - มีอุปกรณ์แฟลชสองชนิด อุปกรณ์เทคโนโลยีหน่วยความจำ (หรือ MTD) นำเสนอส่วนต่อประสานโดยตรงกับหน่วยความจำแฟลช โดยทั่วไปจะพบได้ในอุปกรณ์ฝังตัวและเป็นระบบไฟล์เช่น JFFS2 ที่ออกแบบมาสำหรับ อุปกรณ์แฟลชชนิดอื่นซ่อนหน่วยความจำแฟลชไว้ด้านหลัง Flash Translation Later (FTL) เพื่อให้ดูเหมือนอุปกรณ์บล็อกทั่วไป นี่คือวิธีการใช้เทคโนโลยีผู้บริโภคเช่น SSD, usb sticks และการ์ดหน่วยความจำ ระบบไฟล์เช่น JFFS2 ไม่เหมาะสำหรับสิ่งเหล่านี้ แต่คุณต้องใช้ระบบไฟล์เช่น ext4 ที่ออกแบบมาสำหรับอุปกรณ์บล็อก

— sciurus

1

BEWARE: ext4 ตลอดชีพ _write_kbytes และ session_write_kbytes ไม่ได้เป็นตัวแทนของเซลล์หน่วยความจำ SSD ที่เขียน ฉันเคยเห็นระบบหนึ่งระบบรายงาน 15TB สำหรับ ext4 ตลอดชีพ_write_kbytesในขณะที่ตัว SSD รายงานเพียง 1TB ผ่านคุณสมบัติ SMART 241 ฉันสงสัยว่า ext4 อาจเพิ่มขนาดทั้งหมดของพื้นที่ว่างของระบบไฟล์ลงในสถิติทุกครั้งที่ fstrim ทำงานแม้ว่า SSD เห็นได้ชัดว่าตัวควบคุมจะไม่ลบบล็อกที่มีอยู่ทั้งหมดซ้ำ ๆ หากไม่ได้ถูกสัมผัสตั้งแต่การลบครั้งล่าสุด เอาต์พุต tune2fs -l ดูเหมือนจะทำให้เข้าใจผิดในทำนองเดียวกัน

— ʇsәɹoɈ

2

iostatคุณสามารถลอง มันให้สถิติที่เกี่ยวข้องกับการใช้งาน IO และ CPU man iostatมีลักษณะที่เป็นคู่มือ

— เลด
แหล่งที่มา

ผมคิดว่าสามารถทำงานได้ แต่ผมก็หวังว่ามีอะไรบางอย่างในระดับสูงกว่านี้ที่สามารถให้ผลรวมไบต์สะสม :)

— badnews

2

สำหรับ KINGSTON SEDC400S37480G ของฉันภายใต้ Ubuntu Server 14.04 ฉันใช้สคริปต์ต่อไปนี้เพื่อตรวจสอบ TBW ฉันวิ่งจาก cron วันละครั้ง สคริปต์ส่งออกไปยังไฟล์บันทึก

คุณต้องคำนวณเพื่อให้มันใช้งานได้ ติดตั้ง Calc โดยใช้:

apt-get install apcalc

เนื้อหาสคริปต์:

echo "*** $(date -R) ***" >> /scripts/tbw/log.txt
tbw=$(cat /sys/fs/ext4/sda1/lifetime_write_kbytes)
TB=1000000000
echo TB written to sda1: >> /scripts/tbw/log.txt | calc $tbw / $TB >> /scripts/tbw/log.txt

จะส่งออก:

*** Thu, 20 Jul 2017 03:02:51 +0300 ***
TB written to sda1:
    3.062138442

— inteq
แหล่งที่มา

แทนที่จะคำนวณเราสามารถใช้GNU bc

— Elton Carvalho