🏠: kerberos

Влияние одного параметра на общую производительность системы

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

Статистика за февраль

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

Нагрузка на 6 виртуальных процессоров вчера

Собственно, когда 6 процессоров не справляются, это вызывает вопрос — а всё ли нормально настроено, потому что тупо забрасывать ресурсами кривую систему глубоко неправильно, тем более, просто так добавлять процессоры к виртуальной машине неразумно — этим ситуацию можно скорее ухудшить, ведь реальные процессоры делятся на количество виртуальных, и чем больше их плодить, тем меньше будет выхлоп от отдельно взятого виртуального процессора. Именно поэтому количество виртуальных процессоров лучше максимально сокращать.

Программа top показала, что сам squid весьма скромен в потреблении ресурсов, а процессор загружен процессами аутентификации kerberos negotiate_kerberos_auth. Оказалось, что в kerberos есть replay cache, который пытается бороться с потенциальной подменой ключей шифрования, но, во-первых, он несовершенен, о чём прямо упомянуто в описании, а во-вторых, сильно тормозит более-менее нагруженную систему.

# man negotiate_kerberos_auth

Kerberos can keep a replay cache to detect the reuse of Kerberos
tickets (usually only possible in a 5 minute window). If squid is under
high load with Negotiate (Kerberos) proxy authentication requests the
replay cache checks can create high CPU load. If the environment does
not require high security the replay cache check can be disabled for
MIT based Kerberos implementations by adding the below to the startup
script or use the -t none option.

Добавляем параметр -t none к команде аутентификации:

auth_param negotiate program /usr/lib/squid/negotiate_kerberos_auth -s HTTP/proxy.domain.ru@DOMAIN.RU -t none

Результат очень радует:

Нагрузка на 4 виртуальных процессора сегодня

Хотел сразу оставить два vCPU, но перестраховался, оставил пока четыре, вечерком сделаю.

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