Почему cgroups (blkio обслуживаемые байты) и iotop дают разные результаты

Question

Почему cgroups (blkio обслуживаемые байты) и iotop дают разные результаты

Я работаю с инструментами пользовательского пространства lxc в Ubuntu 14.04 и хочу провести несколько стресс-тестов и тестирование производительности в контейнере. Я знаю, что free и htop не работают должным образом в контейнере.

Я использую dd и bonnie++ внутри контейнера, чтобы подчеркнуть, что жесткий диск - это SSD.

Теперь на стороне хоста, с iotop я могу видеть используемую пропускную способность для чтения и записи, но в cgroups у меня действительно расходящиеся результаты. Cgroups захватывает только небольшую часть обслуживаемых байтов, тогда как iotop показывает использование полосы пропускания в несколько сотен мегабайт.

В cgroups я собираю эту запись: /sys/fs/cgroup/lxc/disk_stress/blkio.throttle.io_service_bytes

Есть идеи, почему значения не равны? Какие из них правильные?

7

linux hard-drive lxc cgroup stress-testing

Источник

Tropp Meaison 17 июн '14 в 05:23

1 ответ

Другие вопросы по тегам linux hard-drive lxc cgroup stress-testing

stephen.z 14 июл '14 в 05:01 2014-07-14 05:01 · Answer 1 · 2014-07-14 05:01

В самой, самой нижней части документации ядра на контроллере blkio есть примечание:

Что работает
В настоящее время поддерживаются только очереди синхронизации ввода-вывода. Все буферизованные записи все еще являются системными и не относятся к группе. Следовательно, мы не увидим различий между буферизованными записями между группами.

Практически это означает, что операции записи будут появляться в 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

Принимая во внимание, что с противоположными опциями direct & buffered, в 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

Кроме того, этот поток с инженером RedHat, который работает с cgroups, повторяет мысль о том, что как только запись передается в кэш записи в ядре: "Из-за этого дополнительного уровня кеша мы теряем контекстную информацию к тому времени, когда IO достигает устройства ". И, таким образом, blkio не может вести учет.