디스크 쓰기를 조사하여 SSD에 어떤 프로세스가 쓰기인지 확인하십시오.

새 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에 쓰기가 있습니다. 어떤 프로세스 쓰기를 어떻게 해결할 수 있습니까?

나는 iotop 에 대해 알고 있지만 어떤 파일 시스템에 액세스하고 있는지 보여주지 않습니다.

다음은 커널의 가상 메모리 블록 덤프 메커니즘을 사용합니다. 먼저 펄 스크립트를 얻으십시오 :

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

그런 다음 블록 덤프를 켜십시오.

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/ 에 감사합니다 .

적어도 iotop으로 시작할 수 있습니다. 어떤 파일 시스템이 작성되고 있는지 알려주지는 않지만 조사 할 프로세스를 제공합니다.

sudo apt-get install iotop
sudo iotop

즉각적인 디스크 읽기 및 쓰기와 명령 읽기 또는 쓰기 이름을 표시합니다.

자주 쓰지 않는 프로세스를 포착하려는 경우 --accumulate옵션을 사용 하거나 출력을 파일에 기록 할 수 있습니다 .

sudo -i
iotop --batch > iotop_log_file

분명히 로그 파일 쓰기가 결과에 표시되지만 디스크에 쓰는 다른 프로세스를 grep 할 수도 있습니다.

이 시점에서 일부 후보 의심 프로세스를 찾을 수 있어야합니다. iotop의 왼쪽 열에는 pid가 표시됩니다. 다음으로 프로세스가 어떤 파일 디스크립터를 작성하는지 확인하십시오.

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

프로세스가 다음과 같이 출력 될 때 다음과 같은 출력이 표시되어야합니다.

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

작성할 첫 번째 인수는 파일 설명자입니다. 0, 1 및 2는 stdin, stdout 및 stderr이므로 2보다 큰 값을 찾고있을 것입니다. 파일 설명자 4가 흥미로워 보입니다.

이제 파일 디스크립터가 가리키는 파일을 찾을 수 있습니다.

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

네 번째 열을보십시오. 4w파일 설명자 4가 쓰기 위해 열려 있고 파일이임을 의미합니다 another_test_file.

프로세스가 파일을 열고, 쓰고, 닫을 수 있으며,이 경우 lsof는이를 표시하지 않습니다. 다음과 같은 상황에서 이런 일이 발생할 수 있습니다.

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