Проксі відповідає після перезапуску. За кілька годин нові з'єднання застрягають. Ще один перезапуск купує ще один спокійний інтервал. Ця картина свідчить про накопичення стану, але не вказує, який саме стан винний.

На шляху Linux з відстеженням з'єднань одним із кандидатів є таблиця conntrack. Перевірте ці наявні значення на машині та в мережевому просторі імен, яке обробляє трафік:

/proc/sys/net/netfilter/nf_conntrack_count
/proc/sys/net/netfilter/nf_conntrack_max

Перше повідомляє про виділені записи потоків; друге їх обмежує. Це не лічильники користувачів Squid чи HTTP-запитів. Стан потоку в ядрі може пережити активну роботу застосунку.

Шукайте зв'язок, а не просто велике число

Порівняйте заповненість у часі з початком збоїв нових з'єднань і відповідними повідомленнями ядра. Велике число без належних доказів збою відрізняється від таблиці, яка раз по раз досягає межі саме тоді, коли запити починають вичерпувати час очікування.

Таблиця може обслуговувати більше, ніж проксі. Інші локальні служби, переспрямований трафік або інший завантажений мережевий шлях також можуть робити свій внесок. Те, що перезапуск проксі змінює симптом, не доводить, що причиною був кеш об'єктів Squid.

Тримайте в полі зору конкуруючі пояснення: дескриптори файлів, черги помічників автентифікації, затримки DNS, тиск на пам'ять і повна файлова система також можуть погіршуватися з часом. Запишіть, який ресурс зростає і які операції першими перестають працювати. Те, що довгоживучі з'єднання виживають, поки нові зазнають невдачі, — корисний доказ, але не діагноз сам по собі.

Підвищення ліміту має ціну в пам'яті. Перш ніж змінювати його, визначте навантаження, простір імен і доступну ємність. Бездумне скорочення тайм-аутів може зламати корисні неактивні сеанси; скидання всього стану з'єднань може зашкодити сторонньому трафіку.

Корисний результат — це пояснення накопичення і відповідна зміна ємності або життєвого циклу. Безпечно підвищувати — не властивість, притаманна кожному проксі-серверу.

Схожі статті