Следующие параметры ядра показывают совсем другое поведение от R6 до R7, и мы не можем понять, почему. Любая помощь приветствуется.
kernel.sched_min_granularity_ns kernel.sched_wakeup_granularity_ns
Задний план :
Приложение оснащено функцией устойчивости, то есть как только задержка начинает увеличиваться более чем на допустимые пороговые уровни (предварительно определенные) или загрузка ЦП превышает 85%, оно прекращает обработку нового запроса (ов), чтобы избежать перегрузки.
Сейчас мы пытаемся выполнить развертывание в виртуальной среде RHEL7 и не можем использовать ЦП в той степени, в которой мы могли бы в RHEL6. Достигнуть 55-60% и увидеть скачки латентности сверх допустимого порога вряд ли удастся.
Ноты :
В R7 мы использовали настроенный профиль, который изменил следующие параметры ядра, влияющие на поведение: kernel.sched_min_granularity_ns = 10000000
kernel.sched_wakeup_granularity_ns = 15000000
Если мы изменим эти значения на R6 по умолчанию (kernel.sched_min_granularity_ns = 4000000
kernel.sched_wakeup_granularity_ns = 4000000), то мы получаем использование процессора до уровней R6 (> 85%).
Однако, когда мы помещаем те же значения в R6 (kernel.sched_min_granularity_ns = 10000000
kernel.sched_wakeup_granularity_ns = 15000000), мы не видим никаких негативных последствий, и ЦП по-прежнему масштабируется до 85-90%, как и раньше. **
Таким образом, значения двух вышеуказанных параметров не по умолчанию: R6 и R7 показывают противоположное влияние.
Итак, мы ищем причину, по которой один и тот же параметр ведет себя по-разному по сравнению с RHEL6 и RHEL7?
Заранее спасибо.
Наконец, мы смогли достичь нашей цели по масштабированию использования ЦП приложения до 80% + в RHEL7. Теперь это очень похоже на то, как приложение работает на RHEL6.
Ниже приведены наши наблюдения и причина, по которой мы пришли к выводу:
"vmstat" показал "работоспособное" количество> общее количество процессоров. Но при этом загрузка процессора составляла всего 50%. Еще одним показателем было количество «переключений контекста» между RHEL6 и RHEL7. RHEL7 показал намного меньшее количество переключений контекста для той же нагрузки приложения по сравнению с RHEL6.
Это означало, что обработка не является медленной, а задачи выполняются, задачи не были назначены ядрам ЦП. После небольшого исследования мы нашли параметр ядра "kernel.sched_migration_cost_ns" который в основном определяет количество времени, до которого выполняемая задача будет перенесена на другой ЦП.
kernel.sched_migration_cost
Время, в течение которого после последнего выполнения задача считается «горячей» кеш-памяти при принятии решений о миграции. «Горячая» задача с меньшей вероятностью будет перенесена, поэтому увеличение этой переменной сокращает миграцию задач. Значение по умолчанию - 500000 (нс). Если время простоя ЦП выше ожидаемого при наличии работающих процессов, попробуйте уменьшить это значение. Если задачи слишком часто переключаются между процессорами или узлами, попробуйте увеличить его.
Уменьшение стоимости kernel.sched_migration_cost примерно до 250 нс (по умолчанию: 500 нс) помогает нам ускорить загрузку процессора до 80%.