с помощью: лак-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
Насколько я понял, "сбой соединения с сервером" противоречит конфигурации 1) Максимальное количество потоков составляет 1000 * 2 [пулов], 2) Загрузка сервера ниже 1.
Теоретически он должен уметь справляться с таким количеством всплесков, и я не понимаю, почему бэкэнд здесь не работает.
[ПРИМЕЧАНИЕ: из-за требований использования он предназначен для кэширования максимум от 1 до 5 секунд]
n_worker_thread = 100, все хорошо
n_worker_thread = 491, 8 сбой подключения backend_connection.
варнишадм
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]
лак
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
Привет, Шейн, спасибо за ответ,
просто удалось выяснить, что проблема с бэкэнд-связью возникла не из-за сбоя конфигурации, а из-за аппаратного переключения между бэкэндом и лаком.
Это было трудно проанализировать, поскольку первичный коммутатор работал бы нормально, в отличие от вторичного коммутатора, который вызывал проблемы при отказе связи.
Это громко объясняет, что сбой подключения к серверу без того, чтобы другой сервер n_worker был занят / слишком много / или превышал очередь, маловероятен.
Надеюсь, это будет кому-то полезно в будущем.