web-dev-qa-db-ja.com

cgroups(blkioサービスバイト)とiotopが異なる結果を生成するのはなぜですか

私はubuntu14.04でlxcユーザースペースツールを使用しており、コンテナー内でいくつかのストレステストとベンチマークを実行したいと考えています。 freeとhtopがコンテナ内で正しく機能していないことを私は知っています。

コンテナ内でddとbonnie ++を使用して、SSDであるハードディスクに負荷をかけています。

ホスト側では、iotopを使用して、使用されているioの読み取り帯域幅と書き込み帯域幅を確認できますが、cgroupでは結果が異なります。 cgroupはサービスされたバイトのごく一部しかキャプチャしませんが、iotopは数百メガバイトの帯域幅使用量を示します。

Cgroupsで、次のエントリをキャプチャしています:/sys/fs/cgroup/lxc/disk_stress/blkio.throttle.io_service_bytes

値が等しくない理由はありますか?どれが正しいですか?

6
Tropp Meaison

blkioコントローラーに関するカーネルドキュメント の一番下には、次の注記が含まれています。

何が機能するか

  • 現在、同期IOキューのみがサポートされています。すべてのバッファリングされた書き込みはシステム全体であり、グループごとではありません。したがって、グループ間のバッファリングされた書き込み間のサービスの違いはわかりません。

実際には、これは、書き込み操作がカーネルバッファリングをバイパスする場合にのみ、blkio.throttle.io_service_bytesに表示されることを意味します。

ツールfioは、これを非常に簡単に説明できます。バッファリングされていない直接書き込みは、blkio.throttle.io_service_bytesで報告する必要があります。

fio --name wxyz --direct=1 --buffered=0 --size=1g --time_based --runtime=120s --bs=4k --rw=write --ioengine=sync --numjobs=1 

反対の直接オプションとバッファオプションでは、書き込みはカーネルバッファキャッシュを通過し、後でスケジュールされるため、blkio.throttle.io_service_bytesには何も報告されません。

fio --name wxyz --direct=0 --buffered=1 --size=1g --time_based --runtime=120s --bs=4k --rw=write --ioengine=sync --numjobs=1

さらに、 このスレッド cgroupsで作業するRedHatエンジニアは、書き込みがカーネル内の書き込みキャッシュに渡されると、「この余分なキャッシュレイヤーのために、コンテキスト情報が失われる」という点を繰り返します。 IOがデバイスに到達するまでに。」そして、blkioによるアカウンティングは発生しません。

5
stephen.z