Лак бэкэнд конн. отказ
Использование : лак-3.0.4
Может ли кто-нибудь предложить потенциальную причину сбоя соединения с бэкэндом, обычно это происходит, когда N-Worker_thread выходит за пределы, превышающие значение по умолчанию 100 worker_thread(не обязательно постоянно)?
В одном из нескольких случаев при попытке создать 491 поток в пике он не смог подключиться к бэкэнду. тогда как серверы не были загружены или что-то еще. Чтобы сузить проблему, это не проблема с внутренним сервером, поскольку он здоров и доступен.
backend_unhealthy 0 0.00 Backend conn. not attempted
backend_busy 0 0.00 Backend conn. too many
Как я понял, "backend conn. Fail" противоположен конфигурации 1) Максимальный поток равен 1000 * 2[пулы], 2) Загрузка сервера ниже 1
Theoretically it should be able to handle that many spikes, And i would not see why backend would fail here.
[NOTE, Due to demand of use, it is designed to cache 1s to 5s at most]
n_worker_thread = 100, all good
n_worker_thread = 491, 8 backend_connection failure.
varnishadm
thread_pool_add_delay 2 [milliseconds]
thread_pool_add_threshold 2 [requests]
thread_pool_fail_delay 200 [milliseconds]
thread_pool_max 1000 [threads]
thread_pool_min 50 [threads]
thread_pool_purge_delay 1000 [milliseconds]
thread_pool_stack unlimited [bytes]
thread_pool_timeout 120 [seconds]
thread_pool_workspace 65536 [bytes]
thread_pools 2 [pools]
thread_stats_rate 10 [requests]
varnishstat
32+03:45:05
Hitrate ratio: 2 2 2
Hitrate avg: 0.9404 0.9404 0.9404
backend_conn 4516262 1.63 Backend conn. success
backend_unhealthy 0 0.00 Backend conn. not attempted
backend_busy 0 0.00 Backend conn. too many
backend_fail 9562 0.00 Backend conn. failures
backend_reuse 67350518 24.24 Backend conn. reuses
backend_toolate 361647 0.13 Backend conn. was closed
backend_recycle 67715544 24.38 Backend conn. recycles
backend_retry 5133 0.00 Backend conn. retry
n_backend 5 . N backends
backend_req 71855086 25.87 Backend requests made
LCK.backend.creat 5 0.00 Created locks
LCK.backend.destroy 0 0.00 Destroyed locks
LCK.backend.locks 149007648 53.64 Lock Operations
LCK.backend.colls 0 0.00 Collisions
1 ответ
Привет Шейн, спасибо за ответ,
Просто удалось выяснить, что проблема с бэкенд-связью была не из-за сбоя конфигурации, а из-за аппаратного переключения между бэкендом и лаком.
Это было трудно проанализировать, так как первичный работал бы хорошо, в отличие от вторичного коммутатора, который вызывал проблемы при восстановлении связи при сбое.
Это громко объясняет, что сбой подключения к бэкенду без маловероятного, что другой занятый / слишком много / или перегружен другим бэкэндом n_worker.
Надеюсь, что это будет полезно для кого-то в будущем.