Я использую blktrace для захвата трафика, который идет на мое устройство, и столкнулся с некоторыми болезненными проблемами. Интересно, сможете ли вы подтвердить/исправить мои выводы.
Похоже, что blktrace пропускает некоторые события. Я пытался получить распределение задержки для команд чтения, выданных устройству. Я знаю, что blkparse и btt делают это. Однако при более внимательном рассмотрении результатов blkparse оказывается, что цифры задержки на самом деле являются задержками от ответа к ответу (C к C), а не от команды к ответу (D к C). BTT также терпит неудачу, поскольку сталкивается с командами, на которые нет ответов (D есть, но C отсутствует).
Поэтому я попытался разработать свой собственный код и понял, что есть много случаев, когда команды выдаются без ответа (есть D, но нет C для него). Также много случаев, когда есть ответ без команды для него (есть C, но нет предыдущего D). Чтобы подтвердить свое открытие, я запустил FIO на устройстве nullblk (использует DRAM, поэтому он довольно быстрый) и включил blktrace для отслеживания устройства nullblk. Я вижу, что когда FIO регистрирует 80 ГБ записи данных, blktrace захватывает только около 50 ГБ данных на диск. Я немного сбит с толку и не уверен в этом выводе, но, похоже, blktrace при больших рабочих нагрузках сбрасывает события.
Вы тоже это заметили? Может кто-нибудь указать мне на мой неправильный анализ или подтвердить мои выводы?
Я использовал следующую команду fio:
sudo fio --name=seqwrite --ioengine=libaio --iodepth=1 --rw=randwrite --bs=128k --direct=0 --size=130M --numjobs=600 --runtime=300 --group_reporting
решение1
К сожалению, вы не включили ваш сводный вывод blktrace - упоминается ли в нем ненулевое количество отброшенных событий? Если да, то, скорее всего, кольцевой буфер, который хранит события до тех пор, пока их не удастся прочитать, переполнен. Если это так, вы можете обойти проблему, запросив больший буфер с помощью--buffer-sizeопция, упомянутая на странице руководства...