Лак бэкэнд конн. отказ

Использование : лак-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.

Надеюсь, что это будет полезно для кого-то в будущем.

Другие вопросы по тегам