6.1. Рекомендации по проведению тонких замеров производительности

В этом разделе находятся советы по проведению точных микрозамеров производительности во FreeBSD или самой FreeBSD.

Каждый раз невозможно использовать все рекомендации ниже, однако чем больше из них используются, тем качественнее будут результаты замеров по тестированию мелких разничий.

• Отключите APM и все остальные функции по бесполезному занятию часов (ACPI ?).

• Работайте в однопользовательском режиме. К примеру, cron(8) и остальные даемоны только добавляют шума. Даемон sshd(8) также может вызывать проблемы. Если во время проведения тестирования необходим ssh-доступ, то либо отключите генерацию ключа SSHv1, либо прервите работу родительского даемона sshd на время выполнения тестов.

• Не запускайте ntpd(8).

• Если возникают события для syslog(3), то запускайте syslogd(8) с пустым файлом /etc/syslogd.conf, либо не запускайте его совсем.

• Минимизируйте дисковый ввод/вывод, если это возможно, откажитесь от него совсем.

• Не монтируйте файловые системы, которые вам не нужны.

• Монтируйте /, /usr и любые другие файловые системы по возможности в режиме "только для чтения". Это устранит влияние на характеристики ввода/вывода переносов обновлений, связанных с изменением дат доступа к файлам.

• Переинициализируйте тестовую файловую систему для чтения/записи при помощи команды newfs(8) и копируйте её посредством tar(1) или dump(8) перед каждым запуском. Размонтируйте и смонтируйте её перед запуском теста. При этом получается единообразная структура файловой системы. Для теста построения полной системы это будет иметь отношение к каталогу /usr/obj (просто переинициализируйте командой newfs и смонтируйте). Чтобы получить 100% повторяемости, дублируйте файловую систему из файла командой dd(1) (то есть: dd if=myimage of=/dev/ad0s1h bs=1m)

• Используйте разделы на базе malloc или подготовленные при помощи md(4).

• Перезагружайте систему между отдельными итерациями теста, так как это даёт более целостное состояние.

• Удалите из ядра все ненужные драйверы устройств. К примеру, если наличие USB не нужно для тестирования, то не помещайте его поддержку в ядро. Драйверы, которые отвечают за подключения, часто привносят дополнительные задержки.

• Откажитесь от настройки неиспользуемого оборудования. Отключите диски через atacontrol(8) и camcontrol(8), если они не используются в тестировании.

• Не настраивайте сеть, пока не протестируете её, либо подождите завершения теста, чтобы лишь потом передать результаты на другой компьютер.

  Если система должна быть подключена к общей сети, следите за широковещательным трафиком. Хотя его и трудно обнаружить, он отнимает процессорное время. Аналогичные последствия имеет и многоадресное вещание.

• Размещайте каждую файловую систему на отдельных дисках. Это минимизирует влияние от оптимизации операций перемещения головки дисков.

• Минимизируйте вывод на последовательные и VGA-консоли. Выдача результатов в файлы оказывает меньшее влияние. (Последовательные консоли легко становятся узким местом.) Не трогайте клавиатуру при работе теста, даже space или back-space отражаются на результатах.

• Удостоверьтесь в том, что тест достаточно длинный, но не слишком. Если тест слишком короткий, то проблемой становится замер времени. Если же он слишком долог, то на частоту кварцевого кристалла в компьютере будут влиять температурные изменения и отклонения. Следуйте такому правилу: больше минуты, но меньше часа.

• Попытайтесь соблюсти температуру окружающей машину среды максимально стабильной. Это отражается как на кварцевых кристаллах, так и алгоритмах дискового привода. Для получения действительно стабильных часов лучше использовать данные внешних стабильных устройств. Например, используя OCXO + PLL, передавайте выдачу в цепи часов, а не на материнскую плату. Обратитесь к Poul-Henning Kamp <phk@FreeBSD.org> для получения дополнительной информации по этому поводу.

• Запустите тест не менее 3 раз, но лучше сделать это больше 20 раз, как ''перед'', так и ''после'' внесения изменений в код. По возможности пытайтесь чередовать (то есть не запускайте 20 раз до, а потом 20 раз после), это позволит выявить эффекты от окружения. Чередуйте не в отношении 1:1, а 3:3, это выявит эффекты взаимодействия.

  Хорошей последовательностью будет bababa{bbbaaa}*. Это даст результат после первых 1+1 прогонов (так что будет возможно остановить тестирование, если всё идёт неправильно), стандартное отклонение после первых 3+3 прогонов (хорошо показывает, стоит ли продолжать тестирование) и общий результат и параметры по взаимодействию при последующих запусках.

• Используйте usr/src/tools/tools/ministat для определения того, значительны ли показатели. Стоит приобрести книгу ''Введение в статистику в картинках'' ISBN: 0062731025, настоятельно рекомендуемую, если вы подзабыли или никогда не изучали понятие стандартного отклонения.

• Не запускайте в фоне fsck(8), если только тест не является замером производительности фонового fsck. Кроме того, отключите background_fsck в файле /etc/rc.conf, если только замер производительности не запускается по крайней мере после 60+''fsck runtime'' секунд после загрузки. Дело в том, что запускается rc(8), проверяющий, не нужно ли запустить проверку файловых систем при помощи fsck при активированном параметре запуска fsck в фоновом режиме. Таким же образом проверьте, что работаете не со снэпшотами, если только вы не тестируете работу именно снэпшота.

• Если полученная производительность неожиданно низка, проверьте, например, высокую частоту прерываний от неизвестных источников. Сообщалось, что некоторые версии ACPI ''работают некорректно'' и генерируют лишние прерывания. Для диагностирования причин плохих результатов сделайте несколько срезов параметров по команде vmstat -i и поищите что-либо необычное.

• Проверьте, что не упустили из виду параметры оптимизации для ядра и пользовательских программ, например, отладочные параметры. Легко пропустить что-то и позже обнаружить, что при тестировании сравнивались не одни и те же вещи.

• Никогда не проводите замеры производительности со включенными параметрами WITNESS и INVARIANTS, если только целью тестирования не является проверка именно этих функций. WITNESS может снизить производительность более чем на 400%. Аналогичным образом влияние пользовательских параметров malloc(3), указываемых по умолчанию в -CURRENT, отличается от окончательных релизов.