Воспроизводимое тестирование производительности в средах на основе Linux

Данный документ посвящен выявлению и предотвращению потенциальных проблем с воспроизводимостью результатов при выполнении тестов производительности в среде на основе Linux.

Когда я начал работать над регрессионным тестированием производительности кода на языке Julia, я был удивлен тем, что не смог найти актуальный и понятный новичкам контрольный список, в котором бы обобщались знания, разбросанные по различным форумам и статьям. Надеюсь, что этот документ сможет послужить отправной точкой для тех, кто только начинает заниматься тестированием производительности в Linux и пытается понять, почему, казалось бы, идентичные испытания производительности дают существенно различающиеся результаты.

Непосвященным поиск и устранение искажений из-за ОС порой может казаться скорее искусством, чем наукой. Очень быстро вы столкнетесь с тем, что для создания надлежащей среды для тщательного тестирования производительности необходимо «шерстить» Интернет и научную литературу в поисках «тайных знаний» об особенностях планировщика и флагах ядра. Некоторые из этих параметров могут радикально влиять на результаты работы конкретного пакета тестов, в то время как другие могут потребовать несоразмерных усилий на то, чтобы в итоге узнать, что они вообще не влияют на ваши тесты.

Цель данного документа состоит не в том, чтобы улучшить производительность вашего приложения, помочь вам смоделировать реальную рабочую среду или предоставить подробное описание различных механизмов ядра. В настоящее время в нем недостаточно полно освещается технология NUMA, так как, к сожалению, у меня нет доступа к компьютеру с поддержкой NUMA для проведения экспериментов. Уверен, что знающие читатели смогут предложить исправления и дополнения, и я буду благодарен, если вы сообщите о проблеме или откроете запрос на вытягивание в этом репозитории.

Экранирование процессоров — это технология, использующая псевдофайловую систему Linux cpuset для настройки эксклюзивных процессоров и узлов памяти, защищенных от использования планировщиком Linux. Самый простой способ настроить и использовать экранирование процессоров — воспользоваться cset, удобной оболочкой Python для интерфейса cpuset. В Ubuntu cset можно установить, выполнив следующую команду:

Нелишним будет ознакомиться с полным руководством по cset, доступным в RTwiki. Вот небольшой пример того, как можно экранировать процессоры 1 и 3 от нежелательных потоков (включая большинство потоков ядра, заданных флагом -k on):

После настройки экранирования можно запускать процессы под его защитой с помощью флага -e (обратите внимание, что аргументы для процесса должны указываться после разделителя --):

Для немного более низкоуровневого управления можно использовать другие подкоманды cset, proc и set. Фактический интерфейс ядра cpuset предлагает еще больше возможностей, в частности жесткое ограничение доступа к памяти и настройки планирования.

Для обеспечения максимальной согласованности испытаний отдельные потоки, выполняемые под защитой экранирования, всегда должны использовать одну и ту же конфигурацию процессора и узлов памяти. Этого можно добиться за счет использования иерархических наборов ЦП (cpuset) для привязки процессов к дочерним cpuset, созданным в экранированном cpuset. Другие служебные средства для управления привязкой процессов, такие как taskset, numactl или tuna, не так полезны, как cset, поскольку они не защищают выделенные ресурсы от использования планировщиком.

В официальной документации Linux перечислено множество параметров виртуальной памяти для настройки подкачки, страничной организации и кэширования в Linux. Я рекомендую читателям самостоятельно изучить свойства vm.nr_hugepages, vm.vfs_cache_pressure, vm.zone_reclaim_mode и vm.min_free_kbytes. Подробно останавливаться на них я не буду, поскольку в большинстве случаев они вряд ли окажут существенное влияние. Вместо этого я сосредоточусь на двух свойствах, с которыми проще экспериментировать и которые могут иметь менее очевидные последствия: приоритет подкачки (swappiness) и рандомизацию размещения адресного пространства.

Большинство современных процессоров поддерживают динамическое масштабирование частоты, то есть возможность регулировать тактовую частоту для управления энергопотреблением и температурой. В Linux масштабирование частоты контролируется эвристическими средствами, называемыми «диспетчерами», каждое из которых отдает приоритет определенной модели использования ресурсов. Эта функция может повлиять на результаты тестирования производительности, если масштабирование происходит во время тестирования или между испытаниями. Однако, к счастью, мы можем зафиксировать эффективную тактовую частоту, включив соответствующий диспетчер performance для всех процессоров:

Чтобы убедиться в том, что эта команда работает, проверьте, выдает ли cat /proc/cpuinfo | grep 'cpu MHz' те же значения, что и cat /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_max_freq.

Многие процессоры также поддерживают произвольное «повышение» производительности, что аналогично динамическому масштабированию частоты и может оказывать такое же негативное влияние на воспроизводимость результатов тестов производительности. Чтобы отключить ускорение работы процессора, можно выполнить следующую команду:

Гиперпоточность, более известная как одновременная многопоточность (SMT), позволяет нескольким программным потокам «одновременно» выполняться в «независимых» аппаратных потоках на одном ядре ЦП. Недостаток заключается в том, что на практике эти потоки не всегда могут выполняться одновременно, поскольку они конкурируют за общие ресурсы ЦП. К сожалению, Linux предоставляет доступ к этим потокам операционной системы как к дополнительным логическим процессорам, что затрудняет применение таких методов, как экранирование, — как узнать, что экранированный «процессор» на самом деле не использует то же физическое ядро, что и неэкранированный? Если ваша ситуация не требует выполнения тестов в среде с гиперпоточностью, возможно, будет лучше отключить гиперпоточность, чтобы было легче согласованно управлять ресурсами процессора.

Прежде чем отключать гиперпоточность, следует проверить, включена ли она на вашем компьютере. Это можно сделать с помощью lscpu:

В приведенных выше выходных данных поле CPU(s) указывает, что имеется 8 логических процессоров. Другие поля позволяют провести более детальный анализ: Умножаем 1 сокет на 4 ядра и получаем 4 физических ядра. Умножаем их на 2 потока на ядро и получаем 8 логических процессоров. Логических процессоров больше, чем физических ядер, значит, гиперпоточность включена.

Прежде чем отключать процессоры, нужно определить, какие из них используют общее физическое ядро:

Каждая строка выше имеет формат i,j, что означает logical processor i shares a physical core with logical processor j. Мы можем отключить гиперпоточность, деактивировав лишние процессоры и оставив только один логический процессор на каждое физическое ядро. В нашем примере для этого можно отключить процессоры 4, 5, 6 и 7:

Теперь мы можем убедиться в том, что гиперпоточность отключена, еще раз проверив thread_siblings_list каждого процессора:

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

Хорошо то, что для большинства типов IRQ можно задать привязку SMP, указав таким образом, какому процессору ядро должно отправлять IRQ. Если правильно настроить привязку SMP, запросы IRQ будут отправляться неэкранированным процессорам в среде тестирования, что защитит экранированные процессоры от нежелательных прерываний.

Используя псевдофайловую систему Linux proc, можно получить список прерываний, произошедших в системе с момента последней перезагрузки:

Некоторые прерывания, например немаскируемые (NMI), нельзя перенаправить, но для остальных можно изменить привязки SMP, записав индексы процессора в /proc/irq/n/smp_affinity_list, где n — номер IRQ. Вот пример установки привязки SMP для IRQ 22 к процессорам 0, 1 и 2:

Наилучший способ настройки привязок SMP во многом зависит от конкретных тестов производительности и способа их выполнения. Например, если вы выполняете много сетевых тестов производительности, иногда может быть выгоднее равномерно распределять прерывания драйвера Ethernet (обычно обозначаемые как eth0-* или иным подобным образом), чем ограничивать их определенными процессорами.

Для определения влияния запросов IRQ на результаты теста производительности можно провести выборочную проверку, посмотрев, что происходит при включении и отключении балансировщика нагрузки IRQ, например irqbalance. Если это заметно влияет на результаты, возможно, стоит поэкспериментировать с привязками SMP, чтобы выяснить, какие прерывания не следует направлять экранированным процессорам.

Прерывания мониторинга производительности (PMI) отправляются подсистемой perf ядра, которая используется для настройки и управления аппаратными счетчиками производительности, отслеживаемыми другими компонентами ядра. Если perf не является зависимостью процесса тестирования производительности, может быть полезно снизить частоту выборки perf, чтобы прерывания PMI не мешали экспериментам. Это можно сделать, например, присвоив параметру kernel.perf_cpu_time_max_percent значение 1:

В результате ядро сообщает perf о необходимости снизить частоту выборки так, чтобы выборка занимала менее 1 % процессорного времени. После изменения этого параметра в системном журнале могут появиться такие сообщения:

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