Сегодня мы поговорим об отечественных стандартах на проектную документацию. Как эти стандарты работают на практике, чем они плохи и чем хороши. При разработке документации для государственных и серьезных частных заказчиков у нас обычно нет выбора — в требования по документированию ТЗ вписано соблюдение стандартов. На практике мне приходилось сталкиваться с различными примерами недопонимания структуры стандартов, того, что должно быть в документах и зачем эти документы нужны. В итоге из-под пера техписателей, аналитиков и специалистов выходят порой такие перлы, что непонятно, в каком состоянии сознания они писались. А ведь на самом деле все достаточно просто. Поиск по Хабру не вернул ссылок на более-менее целостный материал на данную тему, потому предлагаю закрасить этот досадный пробел.

Операции ввода-вывода, как известно, принадлежат к числу критических ресурсов с точки зрения производительности в современных linux-системах. Выявление и анализ «узких мест» производительности в Linux-системах — дело достаточно сложное. Обычно для этой цели используются специализированные утилиты. В числе наиболее известных инструментов анализа производительности следует в первую очередь назвать утилиты, входящие в пакет sysstat (iostat, sar и т.п.). Однако в некоторых ситуациях информации получаемой с помощью этих утилит, бывает недостаточно. Например, с помощью iostat нельзя узнать, какой именно процесс совершает ту или иную операцию. Между тем такая информация бывает необходимой при решении некоторых специфических задач: например, для поиска и анализа «узких мест» в системах хранения данных.

Известный разработчик ядра Linux Йенс Аксбо в 2007 году создал blktrace — специальную утилиту, осуществляющую трассировку операций ввода-вывода и предоставляющую пользователю подробную информацию о них. В этой статье мы хотели бы подробно рассказать о возможностях blktrace.

abstract: разница между текущей производительностью и производительностью теоретической; latency и IOPS, понятие независимости дисковой нагрузки; подготовка тестирования; типовые параметры тестирования; практическое copypaste howto.

Предупреждение: много букв, долго читать.

Лирика

Очень частой проблемой, является попытка понять «насколько быстрый сервер?» Среди всех тестов наиболее жалко выглядят попытки оценить производительность дисковой подсистемы. Вот ужасы, которые я видел в своей жизни:

• научная публикация, в которой скорость кластерной FS оценивали с помощью dd (и включенным файловым кешем, то есть без опции direct)
• использование bonnie++
• использование iozone
• использование пачки cp с измерениема времени выполнения
• использование iometer с dynamo на 64-битных системах

Это всё совершенно ошибочные методы. Дальше я разберу более тонкие ошибки измерения, но в отношении этих тестов могу сказать только одно — выкиньте и не используйте.