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


11

ฉันพยายามลดการเขียนดิสก์ลงในไดรฟ์ระบบ SSD ใหม่ของฉัน ฉันติดอยู่กับเอาต์พุต iostat:

~ > iostat -d 10 /dev/sdb
Linux 2.6.32-44-generic (Pluto)     13.11.2012  _i686_  (2 CPU)

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sdb               8,60       212,67       119,45   21010156   11800488

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sdb               3,00         0,00        40,00          0        400

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sdb               1,70         0,00        18,40          0        184

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sdb               1,20         0,00        28,80          0        288

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sdb               2,20         0,00        32,80          0        328

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sdb               1,20         0,00        23,20          0        232

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sdb               3,40        19,20        42,40        192        424

ที่ฉันเห็นมีเขียนถึง sdb ฉันจะแก้ไขกระบวนการที่เขียนได้อย่างไร

ฉันรู้เกี่ยวกับไอโซโทปแต่ไม่แสดงว่าระบบไฟล์ใดที่กำลังถูกเข้าถึง

คำตอบ:


7

ข้อมูลต่อไปนี้ใช้กลไกการถ่ายโอนข้อมูลบล็อกหน่วยความจำเสมือนของเคอร์เนล ก่อนรับสคริปต์ Perl:

wget https://raw.githubusercontent.com/true/aspersa-mirror/master/iodump

จากนั้นเปิด block dump:

echo 1 | sudo tee /proc/sys/vm/block_dump

และเรียกใช้ต่อไปนี้:

while true; do sleep 1; sudo dmesg -c; done  | perl iodump

.. และกดControlcเพื่อเสร็จสิ้นคุณจะเห็นสิ่งต่อไปนี้:

^C# Caught SIGINT.
TASK                   PID      TOTAL       READ      WRITE      DIRTY DEVICES
jbd2/sda3-8            620         40          0         40          0 sda3
jbd2/sda1-8            323         21          0         21          0 sda1
#1                    4746         11          0         11          0 sda3
flush-8:0             2759          7          0          7          0 sda1, sda3
command-not-fou       9703          4          4          0          0 sda1
mpegaudioparse8       8167          2          2          0          0 sda3
bash                  9704          1          1          0          0 sda1
bash                  9489          1          0          1          0 sda3
mount.ecryptfs_       9698          1          1          0          0 sda1

และปิดการถ่ายโอนข้อมูลบล็อกเมื่อดำเนินการเสร็จ:

echo 0 | sudo tee /proc/sys/vm/block_dump

ขอบคุณhttp://www.xaprb.com/blog/2009/08/23/how-to-find-per-process-io-statistics-on-linux/สำหรับข้อมูลที่เป็นประโยชน์นี้


10

อย่างน้อยคุณสามารถเริ่มต้นด้วย iotop มันจะไม่บอกคุณว่าระบบไฟล์ใดกำลังถูกเขียน แต่มันจะทำให้คุณมีกระบวนการในการตรวจสอบ

sudo apt-get install iotop
sudo iotop

มันแสดงให้เห็นการอ่านและเขียนดิสก์ทันทีและชื่อของคำสั่งการอ่านหรือการเขียน

หากคุณพยายามจับกระบวนการที่เขียนนาน ๆ ครั้งคุณสามารถใช้--accumulateตัวเลือกหรือบันทึกผลลัพธ์ไปยังไฟล์:

sudo -i
iotop --batch > iotop_log_file

เห็นได้ชัดว่าการเขียนไฟล์บันทึกจะปรากฏในผลลัพธ์ แต่คุณควรสามารถ grep สำหรับกระบวนการอื่น ๆ ที่เขียนไปยังดิสก์

ณ จุดนี้คุณควรจะสามารถค้นหากระบวนการที่ต้องสงสัยว่าเป็นผู้สมัครได้บ้าง คอลัมน์ด้านซ้ายใน iotop แสดง pid จากนั้นค้นหาไฟล์ descriptor ที่กระบวนการกำลังเขียนถึง:

sudo -i
strace -p <pid> 2>&1 | grep write

คุณควรเห็นผลลัพธ์เช่นนี้เมื่อกระบวนการเขียน:

write(1, "\n", 1)                       = 1
write(4, "test\n", 5)                   = 5
write(1, ">>> ", 4)                     = 4

อาร์กิวเมนต์แรกในการเขียนคือ file descriptor เราอาจมองหาค่าที่มากกว่า 2 เพราะ 0, 1 และ 2 เป็นเพียง stdin, stdout และ stderr ตัวอธิบายไฟล์ 4 ดูน่าสนใจ

ตอนนี้คุณสามารถค้นหาไฟล์ที่ไฟล์ descriptor ชี้ไปที่:

lsof -p <pid>

ซึ่งควรให้ผลผลิตเช่น:

...
python  23908  rob  mem    REG    8,1    26258 8392656 /usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache
python  23908  rob    0u   CHR  136,5      0t0       8 /dev/pts/5
python  23908  rob    1u   CHR  136,5      0t0       8 /dev/pts/5
python  23908  rob    2u   CHR  136,5      0t0       8 /dev/pts/5
python  23908  rob    3w   REG   0,25      909 9049082 /home/rob/testfile
python  23908  rob    4w   REG   0,25       20 9049087 /home/rob/another_test_file

ดูที่คอลัมน์ที่ 4 4wหมายความว่าไฟล์อธิบาย 4 another_test_fileเปิดให้บริการสำหรับการเขียนและไฟล์เป็น

เป็นไปได้ที่กระบวนการจะเปิดเขียนและปิดไฟล์ซึ่งในกรณีนี้ lsof จะไม่แสดง คุณอาจพบสิ่งนี้เกิดขึ้นกับ:

strace -p <pid> 2>&1 | grep open

ฉันไม่รู้เกี่ยวกับ - สะสมนั่นเป็นคุณสมบัติที่ยอดเยี่ยมจริงๆ! ขอบคุณมากสำหรับสิ่งนั้น !!! iotop - การเปลี่ยนเส้นทางชุดผลลัพธ์ล้มเหลวด้วย UnicodeEncodeError: 'ascii' codec ไม่สามารถเข้ารหัสอักขระในตำแหน่ง 92-99: ลำดับไม่อยู่ในช่วง (128) ในไฟล์ "/usr/lib/pymodules/python2.6/iotop/ui py ", บรรทัด 405, ใน refresh_display
zuba

ฉันดีใจที่คำตอบของฉันเป็นประโยชน์อย่างน้อย การเปลี่ยนเส้นทางใช้งานได้สำหรับฉัน ไม่แน่ใจฉันสามารถอธิบายได้
Rob Fisher

ตกลงฉันเล่นไปรอบ ๆ และพบว่าฉันสามารถใช้ lsof และ strace เพื่อทำงานนักสืบอย่างน้อยพอที่จะจับกระบวนการเขียนไปยัง SSD หวังว่าในท้ายที่สุดนี้จะตอบคำถามตามที่ถามแม้ว่าดูเหมือนว่าคำตอบของ Colin Ian King นั้นง่ายกว่า
Rob Fisher

1
ขออภัยสำหรับการตอบกลับช้าฉันไม่มีอะไรจะพูดจนกว่าฉันจะเล่นกับ strace ขอบคุณสำหรับวิธีการอันชาญฉลาดนั้นฉันลงคะแนน ฉันพบว่ามันยากที่จะเขียนสคริปต์เพื่อนำไปใช้เนื่องจากมีประสบการณ์น้อยในการเขียนเชลล์สคริปต์ นั่นคือเหตุผลที่ฉันเลือกโซลูชันอื่น ขอบคุณสำหรับการแบ่งปันความรู้ของคุณ!
zuba

ควรเป็น--accumulatedแต่การแลกเปลี่ยนสแต็กต้องมี 6 ตัวอักษรเพื่อยอมรับการแก้ไขโพสต์
h__
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.