私は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
値が等しくない理由はありますか?どれが正しいですか?
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によるアカウンティングは発生しません。