chAlx
Advanced Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
obtim:
Цитата:| Есть непонятные пиковые моменты в которые сервак виснет. |
Цитата:| для проги характерна запись INET/inet_error: read errno = 104 |
Ну вот тут видно, что есть две проблемы: актуальная и понятная. Вторая не особо и проблема (так, симптомчик) и не особо мешает. Так что можно про неё забыть до тех пор, пока не будет доказана причинная связь с первой ;)
Про зависоны главный вопрос задан:
Цитата:| Только firebird или весь сервер? |
Т.е. надо локализовать проблему по месту проявления, времени, вызывающим её факторам (это малореально, но хотя бы уловить предшествующие события и характерные симптомы). Для этого нужен мониторинг основных параметров линух-сервера (load, iowait, память, место в разделах, загрузка сети), процесса fbserver (загрузка процессора, памяти, число сетевых соединений) и внутренних метрик Firebird (счётчики транзакций, число коннектов, время последней транзакции, загрузки памяти). Можно в лог писать, можно в систему мониторинга выгружать:
Мониторинг ~40 параметров сервера и базы с помощью Zabbix
Это самопальная выборка. Говорят, сейчас есть более-менее готовые системы мониторинга (отдельно для сервера, отдельно для Firebird).
Добавлено:
miwa
Цитата:| достаточно опыта чтобы такие заявления делать обоснованно |
Я потому так категорично, что тут и изначально натыкаешься на ограничения, и по мере накопления опыта они никуда не уходят, а выявляются новые. Тем более, что вопрос касался обрывов связи, неизбежность которых очевидна, и относился не только к протоколу СУБД, но и к остальным слоям:
(1)долгие TCP-сессии: стандартный keepalive timeout 2 часа. Отвалившаяся сессия (клиент умер или просто закрылся по-быстрому) не рубится и СУБД считает аттач активным.
(2)возможность молчаливой потери пакетов: по-сути тот же контроль целостности. Что-то где-то в сети потерялось, а драйверу (на сервере или на клиенте) пофиг: соберёт и так либо умрёт, пытаясь. Или будет ждать того, чего уже не будет (что более характерно, т.к. посреди TCP-сессии сложно что-то потерять, а в конце легко).
3. DummyPacketInterval - не оно? Оно, спасибо. При переносе сервера осталось в дефолтном нулевом значении: тогда некоторые обслуживающие процедуры по полдня работали без фетча. Теперь надо будет попробовать, несмотря на всеобщее недоверие к этой фиче.
(5) где-то не хватало проверок целостности: точно не вспомню, но вроде дело касалось банальной чексуммы: что пакет пришёл целиком и он верный. "Пакет-убийца" -- это как одно из последствий попадания в него мусора. |
