Первоначально Написано Мухаммедом Ирфаном
Здесь, в группе поддержки Percona, мы часто просим клиентов получить статистику диска, чтобы отслеживать ввод-вывод диска и измерять iops и время ожидания блочных устройств. Существует ряд инструментов для контроля ввода-вывода в Linux. iostat является одним из популярных инструментов, и Percona Toolkit, который является бесплатным, содержит для этой цели инструмент pt-diskstats . Инструмент pt-diskstats похож на iostat, но он более интерактивен и содержит расширенную информацию. pt-diskstats сообщает о текущей активности диска и показывает статистику за последнюю секунду (которая по умолчанию равна 1 секунде) и будет продолжаться до тех пор, пока не прервется. Инструмент pt-diskstats собирает образцы / proc / diskstats.
В этой статье я поделюсь некоторыми примерами того, как отслеживать и проверять, правильно ли работает подсистема ввода-вывода или какие-либо диски являются ограничивающим фактором — все это с помощью инструмента pt-diskstats.
Вывод pt-diskstats состоит из числа столбцов, и для интерпретации вывода pt-diskstats нам нужно знать, что представляет каждый столбец.
- rd_s сообщает о количестве операций чтения в секунду, в то время как wr_s представляет количество операций записи в секунду.
- rd_rt и wr_rt показывают среднее время отклика в миллисекундах для чтения и записи соответственно, что аналогично столбцу ожидания вывода инструмента iostat, но pt-diskstats показывает индивидуальное время ответа для чтения и записи на уровне диска. Отметим, что современный iostat разделяет задержки чтения и записи, но большинство дистрибутивов не имеют последнего iostat в своем пакете systat (или эквивалентном).
- rd_mrg и wr_mrg — два других важных столбца в выводе pt-diskstats. * _mrg сообщает нам, сколько исходных операций удалось объединить с помощью лифта ввода-вывода (дискового планировщика), чтобы уменьшить количество операций ввода-вывода в секунду, поэтому * _mrg сообщает нам очень важную вещь, сообщая нам, что планировщик ввода-вывода смог объединить многие или несколько операций. Если rd_mrg / wr_mrg имеет высокий%, то рабочая нагрузка ввода-вывода является последовательной, с другой стороны, если rd_mrg / wr_mrg — низкий%, то рабочая нагрузка ввода-вывода является случайной. Двоичные журналы, журналы повторов (также именуемые ib_logfile *), журнал отмен и буфер двойной записи — все это требует последовательной записи.
- qtime и stime — это последние два столбца в выводе pt-diskstats, где qtime отражает время, проведенное в очереди дискового планировщика, т.е. среднее время очереди перед отправкой его на физическое устройство, а с другой стороны, stime — это среднее время обслуживания, которое является временем, накопленным для обработки физического запрос устройства. Обратите внимание, что qtime не различается между операциями чтения и записи, и вы можете проверить, больше ли время отклика для qtime, чем для сигнала планировщика дисков. Также обратите внимание, что время обслуживания (поле stime и поле svctm в выходных данных pt-diskstats и iostat соответственно) ненадежно в Linux. Если вы читаете IOSTAT руководства вы увидите , что он является устаревшим.
Наряду с этим, есть много других параметров для pt-diskstats — вы можете найти полную документацию здесь . Ниже приведен пример pt-disktats в действии. Я использовал опцию –devices-regex, которая печатает только информацию об устройстве, которая соответствует этому регулярному выражению Perl.
$ pt-diskstats --devices-regex=sd --interval 5 #ts device rd_s rd_avkb rd_mb_s rd_mrg rd_cnc rd_rt wr_s wr_avkb wr_mb_s wr_mrg wr_cnc wr_rt busy in_prg io_s qtime stime 1.1 sda 21.6 22.8 0.5 45% 1.2 29.4 275.5 4.0 1.1 0% 40.0 145.1 65% 158 297.1 155.0 2.1 1.1 sdb 15.0 21.0 0.3 33% 0.1 5.2 0.0 0.0 0.0 0% 0.0 0.0 11% 1 15.0 0.5 4.7 1.1 sdc 5.6 10.0 0.1 0% 0.0 5.2 1.9 6.0 0.0 33% 0.0 2.0 3% 0 7.5 0.4 3.6 1.1 sdd 0.0 0.0 0.0 0% 0.0 0.0 0.0 0.0 0.0 0% 0.0 0.0 0% 0 0.0 0.0 0.0 5.0 sda 17.0 14.8 0.2 64% 3.1 66.7 404.9 4.6 1.8 14% 140.9 298.5 100% 111 421.9 277.6 1.9 5.0 sdb 14.0 19.9 0.3 48% 0.1 5.5 0.4 174.0 0.1 98% 0.0 0.0 11% 0 14.4 0.9 2.4 5.0 sdc 3.6 27.1 0.1 61% 0.0 3.5 2.8 5.7 0.0 30% 0.0 2.0 3% 0 6.4 0.7 2.4 5.0 sdd 0.0 0.0 0.0 0% 0.0 0.0 0.0 0.0 0.0 0% 0.0 0.0 0% 0 0.0 0.0 0.0
Это статистика с 7200 об / мин дисков SATA. Как видите, время ответа на запись очень велико, и большая его часть состоит из времени очереди ввода-вывода. Это показывает проблему точно. Проблема заключается в том, что подсистема ввода-вывода не может обрабатывать рабочую нагрузку записи, потому что количество выполняемых операций записи намного превышает то, что она может обработать. Это означает, что диски не могут обслуживать каждый запрос одновременно . На самом деле рабочая нагрузка во многом зависит от того, где хранятся горячие данные, и, как мы видим в этом конкретном случае, рабочая нагрузка затрагивает только один диск из 4 дисков. Один диск со скоростью 7,2 тыс. Об / мин может выполнять только около 100 случайных операций записи в секунду, что не так много, учитывая большую нагрузку.
Это не проблема аппаратного обеспечения, а проблема аппаратного обеспечения. Тип рабочей нагрузки и количество операций записи в секунду не являются эффективными для подсистемы ввода-вывода. В основном записи создаются на этом сервере, как видно из статистики диска.
Позвольте мне показать вам второй пример. Здесь вы можете увидеть задержку чтения. Значение rd_rt составляет от 10 до 30 мс. Это зависит от скорости вращения дисков и количества дисков. Чтобы справиться с этим, можно решить следующие проблемы: оптимизировать запросы, чтобы избежать сканирования таблиц, по возможности использовать memcached, использовать SSD, поскольку он может обеспечить хорошую производительность ввода-вывода при высоком параллелизме. Вы найдете этот пост полезным на SSD от нашего генерального директора Питера Зайцева.
#ts device rd_s rd_avkb rd_mb_s rd_mrg rd_cnc rd_rt wr_s wr_avkb wr_mb_s wr_mrg wr_cnc wr_rt busy in_prg io_s qtime stime 1.0 sdb 33.0 29.1 0.9 0% 1.1 34.7 7.0 10.3 0.1 61% 0.0 0.4 99% 1 40.0 2.2 19.5 1.0 sdb1 0.0 0.0 0.0 0% 0.0 0.0 7.0 10.3 0.1 61% 0.0 0.4 1% 0 7.0 0.0 0.4 1.0 sdb2 33.0 29.1 0.9 0% 1.1 34.7 0.0 0.0 0.0 0% 0.0 0.0 99% 1 33.0 3.5 30.2 1.0 sdb 81.9 28.5 2.3 0% 1.1 14.0 0.0 0.0 0.0 0% 0.0 0.0 99% 1 81.9 2.0 12.0 1.0 sdb1 0.0 0.0 0.0 0% 0.0 0.0 0.0 0.0 0.0 0% 0.0 0.0 0% 0 0.0 0.0 0.0 1.0 sdb2 81.9 28.5 2.3 0% 1.1 14.0 0.0 0.0 0.0 0% 0.0 0.0 99% 1 81.9 2.0 12.0 1.0 sdb 50.0 25.7 1.3 0% 1.3 25.1 13.0 11.7 0.1 66% 0.0 0.7 99% 1 63.0 3.4 11.3 1.0 sdb1 25.0 21.3 0.5 0% 0.6 25.2 13.0 11.7 0.1 66% 0.0 0.7 46% 1 38.0 3.2 7.3 1.0 sdb2 25.0 30.1 0.7 0% 0.6 25.0 0.0 0.0 0.0 0% 0.0 0.0 56% 0 25.0 3.6 22.2
Из приведенного ниже вывода diskstats кажется, что IO насыщается между чтением и записью. Это можно заметить с высоким значением для столбцов rd_s и wr_s. В этом конкретном случае рассмотрите возможность использования дисков в RAID 5 (лучше для рабочей нагрузки только для чтения) или в массиве RAID 10 вместе с кэшем записи с резервным питанием от аккумулятора (BBWC), поскольку один диск может действительно ухудшить производительность, когда вы ограничены вводом-выводом. ,
device rd_s rd_avkb rd_mb_s rd_mrg rd_cnc rd_rt wr_s wr_avkb wr_mb_s wr_mrg wr_cnc wr_rt busy in_prg io_s qtime stime sdb1 362.0 27.4 9.7 0% 2.7 7.5 525.2 20.2 10.3 35% 6.4 8.0 100% 0 887.2 7.0 0.9 sdb1 439.9 26.5 11.4 0% 3.4 7.7 545.7 20.8 11.1 34% 9.8 11.9 100% 0 985.6 9.6 0.8 sdb1 576.6 26.5 14.9 0% 4.5 7.8 400.2 19.9 7.8 34% 6.7 10.9 100% 0 976.8 8.6 0.8 sdb1 410.8 24.2 9.7 0% 2.9 7.1 403.1 18.3 7.2 34% 10.8 17.7 100% 0 813.9 12.5 1.0 sdb1 378.4 24.6 9.1 0% 2.7 7.3 506.1 16.5 8.2 33% 5.7 7.6 100% 0 884.4 6.6 0.9 sdb1 572.8 26.1 14.6 0% 4.8 8.4 422.6 17.2 7.1 30% 1.7 2.8 100% 0 995.4 4.7 0.8 sdb1 429.2 23.0 9.6 0% 3.2 7.4 511.9 14.5 7.2 31% 1.2 1.7 100% 0 941.2 3.6 0.9
Следующий пример отражает интенсивную запись, но время ответа на запись очень хорошее, менее 1 мс, что показывает, что диски исправны и способны обрабатывать большое количество операций ввода-вывода в секунду.
#ts device rd_s rd_avkb rd_mb_s rd_mrg rd_cnc rd_rt wr_s wr_avkb wr_mb_s wr_mrg wr_cnc wr_rt busy in_prg io_s qtime stime 1.0 dm-0 530.8 16.0 8.3 0% 0.3 0.5 6124.0 5.1 30.7 0% 1.7 0.3 86% 2 6654.8 0.2 0.1 2.0 dm-0 633.1 16.1 10.0 0% 0.3 0.5 6173.0 6.1 36.6 0% 1.7 0.3 88% 1 6806.1 0.2 0.1 3.0 dm-0 731.8 16.0 11.5 0% 0.4 0.5 6064.2 5.8 34.1 0% 1.9 0.3 90% 2 6795.9 0.2 0.1 4.0 dm-0 711.1 16.0 11.1 0% 0.3 0.5 6448.5 5.4 34.3 0% 1.8 0.3 92% 2 7159.6 0.2 0.1 5.0 dm-0 700.1 16.0 10.9 0% 0.4 0.5 5689.4 5.8 32.2 0% 1.9 0.3 88% 0 6389.5 0.2 0.1 6.0 dm-0 774.1 16.0 12.1 0% 0.3 0.4 6409.5 5.5 34.2 0% 1.7 0.3 86% 0 7183.5 0.2 0.1 7.0 dm-0 849.6 16.0 13.3 0% 0.4 0.5 6151.2 5.4 32.3 0% 1.9 0.3 88% 3 7000.8 0.2 0.1 8.0 dm-0 664.2 16.0 10.4 0% 0.3 0.5 6349.2 5.7 35.1 0% 2.0 0.3 90% 2 7013.4 0.2 0.1 9.0 dm-0 951.0 16.0 14.9 0% 0.4 0.4 5807.0 5.3 29.9 0% 1.8 0.3 90% 3 6758.0 0.2 0.1 10.0 dm-0 742.0 16.0 11.6 0% 0.3 0.5 6461.1 5.1 32.2 0% 1.7 0.3 87% 1 7203.2 0.2 0.1
Позвольте мне показать вам последний пример. Я использовал -interval и -iterations параметров для PT-diskstats , который говорит нам ждать в течение нескольких секунд перед печатью следующей статистики диска и ограничить число выборок соответственно. Если вы заметите, в третьей итерации вы увидите высокую задержку (rd_rt, wr_rt) в основном для чтения. Также вы можете заметить высокое значение времени очереди (qtime) и времени обслуживания (stime), где qtime связано с настройками планировщика дискового ввода-вывода. Для серверов баз данных MySQL мы обычно рекомендуем noop / deadline вместо cfq по умолчанию.
$ pt-diskstats --interval=20 --iterations=3 #ts device rd_s rd_avkb rd_mb_s rd_mrg rd_cnc rd_rt wr_s wr_avkb wr_mb_s wr_mrg wr_cnc wr_rt busy in_prg io_s qtime stime 10.4 hda 11.7 4.0 0.0 0% 0.0 1.1 40.7 11.7 0.5 26% 0.1 2.1 10% 0 52.5 0.4 1.5 10.4 hda2 0.0 0.0 0.0 0% 0.0 0.0 0.4 7.0 0.0 43% 0.0 0.1 0% 0 0.4 0.0 0.1 10.4 hda3 0.0 0.0 0.0 0% 0.0 0.0 0.4 107.0 0.0 96% 0.0 0.2 0% 0 0.4 0.0 0.2 10.4 hda5 0.0 0.0 0.0 0% 0.0 0.0 0.7 20.0 0.0 80% 0.0 0.3 0% 0 0.7 0.1 0.2 10.4 hda6 0.0 0.0 0.0 0% 0.0 0.0 0.1 4.0 0.0 0% 0.0 4.0 0% 0 0.1 0.0 4.0 10.4 hda9 11.7 4.0 0.0 0% 0.0 1.1 39.2 10.7 0.4 3% 0.1 2.7 9% 0 50.9 0.5 1.8 10.4 drbd1 11.7 4.0 0.0 0% 0.0 1.1 39.1 10.7 0.4 0% 0.1 2.8 9% 0 50.8 0.5 1.7 20.0 hda 14.6 4.0 0.1 0% 0.0 1.4 39.5 12.3 0.5 26% 0.3 6.4 18% 0 54.1 2.6 2.7 20.0 hda2 0.0 0.0 0.0 0% 0.0 0.0 0.4 9.1 0.0 56% 0.0 42.0 3% 0 0.4 0.0 42.0 20.0 hda3 0.0 0.0 0.0 0% 0.0 0.0 1.5 22.3 0.0 82% 0.0 1.5 0% 0 1.5 1.2 0.3 20.0 hda5 0.0 0.0 0.0 0% 0.0 0.0 1.1 18.9 0.0 79% 0.1 21.4 11% 0 1.1 0.1 21.3 20.0 hda6 0.0 0.0 0.0 0% 0.0 0.0 0.8 10.4 0.0 62% 0.0 1.5 0% 0 0.8 1.3 0.2 20.0 hda9 14.6 4.0 0.1 0% 0.0 1.4 35.8 11.7 0.4 3% 0.2 4.9 18% 0 50.4 0.5 3.5 20.0 drbd1 14.6 4.0 0.1 0% 0.0 1.4 36.4 11.6 0.4 0% 0.2 5.1 17% 0 51.0 0.5 3.4 20.0 hda 0.9 4.0 0.0 0% 0.2 251.9 28.8 61.8 1.7 92% 4.5 13.1 31% 2 29.6 12.8 0.9 20.0 hda2 0.0 0.0 0.0 0% 0.0 0.0 0.6 8.3 0.0 52% 0.1 98.2 6% 0 0.6 48.9 49.3 20.0 hda3 0.0 0.0 0.0 0% 0.0 0.0 2.0 23.2 0.0 83% 0.0 1.4 0% 0 2.0 1.2 0.3 20.0 hda5 0.0 0.0 0.0 0% 0.0 0.0 4.9 249.4 1.2 98% 4.0 13.2 9% 0 4.9 12.9 0.3 20.0 hda6 0.0 0.0 0.0 0% 0.0 0.0 0.0 0.0 0.0 0% 0.0 0.0 0% 0 0.0 0.0 0.0 20.0 hda9 0.9 4.0 0.0 0% 0.2 251.9 21.3 24.2 0.5 32% 0.4 12.9 31% 2 22.2 10.2 9.7 20.0 drbd1 0.9 4.0 0.0 0% 0.2 251.9 30.6 17.0 0.5 0% 0.7 24.1 30% 5 31.4 21.0 9.5
Вы можете увидеть
столбец занятости в выводе pt-diskstats, который совпадает со
столбцом util в iostat — который указывает на использование. На самом деле, pt-diskstats очень похож на инструмент iostat, но pt-diskstats более интерактивен и содержит больше информации. Процент занятости только говорит нам, как долго подсистема ввода-вывода была занята, но не указывает на емкость. Таким образом, единственное время, когда вы заботитесь о% занятости, это когда 100% и в то же время задержка (ожидайте в iostat и rd_rt / wr_rt в выводе diskstats) увеличивается за -say- 5 мс. Вы можете оценить емкость вашей подсистемы ввода-вывода, а затем посмотреть, сколько IOPS используется (столбцы r / s + w / s). Кроме того, система может обрабатывать более одного запроса параллельно (в случае RAID), поэтому% занятости может превысить 100% в выводе pt-diskstats.
Если вам необходимо проверить пропускную способность диска, IOPS на блочном устройстве запустите следующую команду, чтобы получить метрики от вашей подсистемы ввода-вывода и посмотреть, соответствует ли использование другим тревожным симптомам. Я бы предложил захватить статистику диска во время пиковой нагрузки. Вывод можно сгруппировать по образцу или по диску, используя параметр –group-by . Для этой цели вы можете использовать инструмент тестирования sysbench для измерения производительности сервера баз данных. Вы найдете эту ссылку полезной для деталей инструмента sysbench.
$ pt-diskstats --group-by=all --iterations=7200 > /tmp/pt-diskstats.out;
Вывод:
pt-diskstats — один из лучших инструментов Percona Toolkit. Используя этот инструмент, вы можете легко обнаружить узкие места на диске, измерить подсистему ввода-вывода и определить, сколько IOPS может выдержать ваш диск (то есть емкость диска).