pgBouncer чудово працює, але час від часу стає недоступним

Я запускаю pgBouncer перед зайнятою базою даних postgres 9. Більшу частину часу це працює чудово. Але кожні кілька годин я отримуватиму електронний лист із помилкою від своєї програми за винятком psycopg2:

OperationalError ('не вдалося підключитися до сервера. Неможливо призначити запитувану адресу. Чи працює сервер на хості "neo-hulk" і приймає TCP / IP-з'єднання на порту 6432? ")

Це додаток python з купою працівників селери, які виконують завдання. Коли з'являються ці помилки, я перевіряю pbbouncer db і розмір пулу знаходиться в межах. Після деяких експериментів я встановив максимальний розмір пулу до 400, а розмір пулу - 200. Режим пулу - це "сеанс" (запити здебільшого автоматично здійснюються, майже немає транзакцій).

Що робить pgBouncer таким чином "зникає"? це лише на короткий проміжок часу (і загалом ми говоримо про мізерну кількість запитів порівняно з великим обсягом запитів, які його надають), але важливі ті запити, які не вдається.

Дякую!

postgresql python pgbouncer

— Харел
джерело

Операційна система та версія? Версія ядра, якщо Linux? Точні версії PostgreSQL та PgBouncer? Ви запустили PgBouncer на рівні журналу налагодження і побачили, чи повідомляє він щось корисне?

— Крейг Рінгер

Debian 6. Версія Linux 2.6.32-5-amd64 (Debian 2.6.32-48squeeze1) версія pgbouncer версії 1.5.4 Postgres 9.1. Журнал не записує з'єднання / відключення, як я вважав, що це було небагато, але при помилці цих програм немає помилок. Помилка походить від psycopg2, думаючи, що немає db-сервера, з яким би можна було поговорити, хоча ця проблема не існувала до pgbouncer

— Харел,

Гм, настільки поточний PgBouncer, і ядро старовинне, але досить стабільне. Я думаю, вам потрібно ввімкнути більш детальний вхід у систему PgBouncer -vvvі побачити, чи можете ви вчасно співставити аномальний вихід журналу з вашими помилками.

— Крейг Рінгер

Я зробив "set verbose = 1; reload;" в оболонці pgbouncer і не вдалося знайти нічого незвичайного в журналі. це виробнича система, тому не могла зупинити роботу служби як недемон із -vvv. Сподіваюся, у мене такий же результат. зауважте, що помилка говорить про те, що він взагалі не міг підключитися до pgbouncer, тобто не міг знайти його в цьому порту. Існує тисяча з'єднань, які постійно робляться, і дивно, що невелика кількість з них виходить з ладу.

— Харел

Хитрий; це звучить як потенційна умова гонки, але в чому / де ...

— Крейг Рінгер,

Частина " Неможливо призначити запитувану адресу " у повідомленні про помилку надходить із стека TCP ядра. Якщо ви стикаєтесь з перервами, це зазвичай означає, що простір наявних сокетів вичерпано через занадто багато розеток у стані очікування ( TIME_WAITабо менш вірогідно FIN_WAIT_1або FIN_WAIT_2)

Діапазон портів сокет може бути виведений cat /proc/sys/net/ipv4/ip_local_port_range. Значення за замовчуванням для біржового Linux ядра зазвичай 32768 61000.

Ви можете перевірити результат netstat -ton|grep WAITна клієнтах (ах) та на хості pgBouncer, коли система зайнята. На -oпрапорі будуть показані лічильники часу очікування, пов'язані зі станами очікування.

Якщо загальна кількість розеток TCP близька до 61000-32768=28232вичерпання цього діапазону, ймовірно, ваша проблема. Оскільки закритий сокет проводить 60 секунд у TIME_WAITстані в нормальному стані, якщо клієнт-хост підключається більше 28232 разів за одну хвилину, нові з’єднання не зможуть зі згаданою помилкою, поки порти не будуть звільнені.

В якості першого рішення діапазон портів TCP може бути розширений:

 # echo "1025 65535" >/proc/sys/net/ipv4/ip_local_port_range

Якщо це не задовільно, перевірте прапорці tcp_tw_recycleта tcp_tw_reuseпрапори, також відрегульовані через /proc/sys/net/ipv4та sysctl.

Вони визначаються як (від man tcp):

       tcp_tw_recycle (Boolean; типово: вимкнено; оскільки Linux 2.4)
              Увімкніть швидку переробку TIME_WAIT розеток. Увімкнення цього
              варіант не рекомендується, оскільки це створює проблеми під час роботи
              ing з NAT (Переклад мережевих адрес).

       tcp_tw_reuse (Boolean; типово: вимкнено; оскільки Linux 2.4.19 / 2.6)
              Дозволити повторно використовувати TIME_WAIT розетки для нових з'єднань, коли вони є
              безпечно з точки зору протоколу. Його не слід змінювати без
              порада / запит технічних експертів.

Особисто я мав успіх, tcp_tw_recycleколи стикався з цією проблемою з клієнтським додатком MySQL, але не сприймайте це як рекомендацію, оскільки я розумію, що TCP в кращому випадку є поверхневим.

— Даніель Верете
джерело

Ця відповідь показує що-небудь помилку поверхневого розуміння TCP. Дякую тобі за це. Я збільшив діапазон портів і даю йому працювати деякий час, щоб побачити, чи має це якийсь ефект. (Чи потрібно перезавантажуватись після того, як я його встановив?)

— Харел,

Я думаю, що збільшення портів це зробило. Поки що я не отримав жодної помилки. Приблизний підрахунок рядків netstat показує близько 20 К у клієнта, тому звідти до 28K межа за замовчуванням не довга. Дякую за це!

— Харел

Добре! Ви хочете встановити налаштування /etc/sysctl.conf, net.ipv4.ip_local_port_range = 1025 65535щоб воно зберігалося через перезавантаження.

— Даніель Верете

Дякую. Я отримав помилки з тих пір, але не з тих, що все одно добре. Запустивши його кілька днів, і хімічна хімія зміниться. Я радий, що поки що, здається, це працює, тому що інші зміни мене лякають :)

— Харел,