私はrsync大容量フォルダを外部3.5 "ドライブから内部3.5"ドライブに移動しています。どちらも5.400rpmです。これを使用してdstat現在のスループットを表示すると、次のパターンが頻繁に表示されます。
--total-cpu-usage-- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai stl| read writ| recv send| in out | int csw
20 6 34 40 0| 98M 90M|1272B 3652B| 0 0 |1702 4455
21 6 37 37 0| 121M 90M|1646B 4678B| 0 0 |2057 6488
17 24 29 30 0| 77M 95M| 630B 2416B| 0 0 |1581 4644
20 5 33 43 0| 86M 84M|1372B 2980B| 0 0 |1560 4146
20 6 30 44 0| 80M 75M| 700B 2722B| 0 0 |1484 3942
11 2 47 39 0| 39M 65M| 642B 1332B| 0 0 | 765 1507
0 0 50 50 0| 0 91M| 70B 354B| 0 0 | 136 70
0 0 50 49 0| 0 71M| 306B 346B| 0 0 | 146 119
0 0 50 50 0| 0 83M| 70B 346B| 0 0 | 145 60
0 0 50 50 0| 0 0 | 70B 346B| 0 0 | 36 84
0 0 50 50 0| 0 0 | 164B 646B| 0 0 | 35 71
0 0 50 50 0| 0 0 | 140B 802B| 0 0 | 30 64
0 0 50 50 0| 0 0 | 70B 346B| 0 0 | 27 68
0 0 50 50 0| 0 34M| 134B 346B| 0 0 | 86 68
0 0 50 50 0| 0 0 | 70B 346B| 0 0 | 30 71
0 0 50 50 0| 0 0 |2320B 346B| 0 0 | 40 76
0 0 50 50 0| 0 0 | 70B 346B| 0 0 | 29 71
0 0 50 50 0| 0 0 | 70B 346B| 0 0 | 25 50
-----------------------------[snip]------------------------------
0 0 50 50 0| 0 0 |2230B 346B| 0 0 | 35 61
0 0 50 50 0| 0 60M| 70B 346B| 0 0 | 118 83
1 7 42 50 0| 256k 104M| 230B 500B| 0 0 | 281 480
21 5 31 42 0| 117M 76M|1120B 3392B| 0 0 |1849 4309
23 5 36 36 0| 137M 56M|1202B 3958B| 0 0 |2149 5782
24 5 36 35 0| 138M 100M|1284B 4112B| 0 0 |2174 6021
たとえば、数秒から1分以内に読み取りと書き込みの両方のスループットがゼロに低下しました。ここでボトルネックは何ですか？
私の言葉は、両方のドライブの速度がほぼ同じであるため、どちらもあまりにも長い間アイドル状態にしてはいけません。さらに一歩進んで、少なくとも1つのドライブは常に読み書き可能でなければなりません。システムは何を待っていますか？
システムはアイドル状態であり、CPUを使用する唯一のものはタスクrsyncです。メモリは8GB、CPUは第7世代i5クアッドコアだ。内蔵ハードドライブはSATA経由でマザーボード（Gigabyte G170X-Ultra Gaming）に接続されています。どちらの場合も、ファイルシステムは内部（書き込み）側でdmcrypt / LUKSを使用して暗号化されたext4です。これが理由なのでしょうか？それでは、dmcryptのパフォーマンスをどのように確認できますか？転送損失が発生すると、CPUは50％アイドル状態で50％スタンバイ状態であることがわかります。これから私はどんな結論を出すことができますか？
カーネルバージョンを備えた最新のArchlinuxです4.13.11-1-ARCH。注意が必要なものはありますか？よろしくお願いします。
修正する: iotopより正確なものと指摘されたdstat。残念ながら、スループットがゼロに低下すると、スループットもiotopゼロとして表示されます。dstat私は一つ作ったスクリーンキャストそれを示すために。
答え1
いくつかのブロックレベルのデバイス統計を取得するための2つのツールセットがあります。最初は遅延ブレンデン・グレグからパフォーマンスツール。これにより、ディスクの作業待ち時間の単純なヒストグラムが生成されます。たとえば、次のようになります。
>=(ms) .. <(ms) : I/O |Distribution |
0 -> 1 : 1913 |######################################|
1 -> 2 : 438 |######### |
2 -> 4 : 100 |## |
4 -> 8 : 145 |### |
8 -> 16 : 43 |# |
16 -> 32 : 43 |# |
32 -> 64 : 1 |# |
ツールセットの別のスクリプトは、コマンドiosnoopとそのアクションを表示します。たとえば、次のようになります。
COMM PID TYPE DEV BLOCK BYTES LATms
/usr/bin/mon 31456 R 8,0 9741888 4096 2.14
/usr/bin/mon 31456 R 8,0 9751408 4096 0.16
/usr/bin/mon 31456 R 8,0 20022728 4096 1.44
/usr/bin/mon 31456 R 8,0 19851752 4096 0.26
jbd2/sda3-41 416 WS 8,0 130618232 65536 1.89
jbd2/sda3-41 416 WS 8,0 209996928 65536 1.92
jbd2/sda3-41 416 WS 8,0 210006528 8192 1.94
以来ブロック追跡パッケージは低レベルのブロック操作を記録し、次の簡単な要約を含むさまざまな情報やその他blktraceのblkparse多くのコマンドを表示します。bttpdfユーザーガイド):
$ sudo blktrace /dev/sda # ^C to stop
=== sda ===
CPU 0: 180 events, 9 KiB data
CPU 1: 1958 events, 92 KiB data
Total: 2138 events (dropped 0), 101 KiB data
$ ls -ltra # one file per cpu
-rw-r--r-- 1 root root 8640 Nov 5 10:16 sda.blktrace.0
-rw-r--r-- 1 root root 93992 Nov 5 10:16 sda.blktrace.1
$ blkparse -O -d combined.output sda.blktrace.* # combine cpus
$ btt -i combined.output
ALL MIN AVG MAX N
Q2Q 0.000001053 0.106888548 6.376503027 253
Q2G 0.000000795 0.000002266 0.000011060 184
G2I 0.000000874 0.000979485 0.002588781 328
Q2M 0.000000331 0.000000599 0.000002716 70
I2D 0.000000393 0.000480112 0.002435491 328
M2D 0.000002044 0.000028418 0.000126845 70
D2C 0.000080986 0.001925224 0.010111418 254
Q2C 0.000087025 0.002603157 0.010120629 254
...
たとえば、D2C はハードウェアデバイスがタスクを実行するのにかかる時間です。
sudo smartctl -a /dev/sda各ディスクで実行して、欠陥があるかどうかを確認することもできます。
答え2
私はこれがdstatアプリケーション呼び出しのファイル記述子レベルのI / O統計を使用し、write()システムdstat呼び出しが返されるとデータが増加することを見ると思います。
しかし、それはデータが実際に記録されたという意味ではありません。一時停止しているように見えるこれらのステップは、バッファがブロックデバイスに書き込まれるステップであると推測されます。これは、この間にI / O待機値dstatがデータ転送が測定されるステップよりもはるかに高いことを意味します。
iotopディスクとキャッシュへの書き込みと読み取りを区別します。たぶんこのツールは興味深い追加情報を提供するかもしれません。