» InterBase и FireBird: вопросы по работе и их решение

obtim
Обрыв сетевого подключения к СУБД. Вероятно ваше ПО, подключающееся к СУБД, аварийно закрывается и при этом соединение с СУБД не завершается корректно (без команды DISCONNECT). Или это какие-то неполадки в сетевой инфраструктуре.

Ded0k
Сетевые проблемы уже исключил.
У нас просто специфическое ПО использует FireBird и разработчик не очень активен в решении проблем.
Есть проблемы в последнее время и надо сформулировать задачу.
А аварийно закрывается и некорректно завершает работу с БД может быть синонимом в этом случае?
На сервере с этим Firebird лежит несколько баз. Как-то можно вычленить, к какой именно базе относятся логи?
Имеет ли смысл апгрейд до 2.5.4(стоит 2.5.3)?
P.S. Нашел совет по CONNECTION_TIMEOUT
Попробую поиграться с ним
P.P.S. под винды существует ibconsvc.zip, которая заносит информацию о коннектах и дисконнектах (только tcp) прямо в interbase.log, что позволяет отследить станции или хабы, генерирующие ошибку.
А есть что-нибудь подобное для Unix систем?

obtim,

Цитата:

А аварийно закрывается и некорректно завершает работу с БД может быть синонимом в этом случае?

Конечно может. Например, программа вылетела, команда DISCONNECT на сервер не поступила, он ждет некоторое время, потом закрывает соединение по таймауту и заносит ошибку в лог.

Цитата:

На сервере с этим Firebird лежит несколько баз. Как-то можно вычленить, к какой именно базе относятся логи?

Штатных средств для раздельного ведения лога разных баз сходу не нашел.
Первое что пришло в голову - ставить базы на разные сервера. Это можно сделать в пределах одной машины, но назначить им разные сетевые порты для коннекта.
По Unix не подскажу, не знаю.

Цитата:

А есть что-нибудь подобное для Unix систем?

FBScanner
Правда нужна будет еще одна машина под Win

OXDBA
Спасибо за подсказку. Осталось найти лекарство
Нашел

obtim

Чтобы увидеть TCP-соединения с сервером БД, достаточно утилиты netstat. Чтобы поймать подключения и записать их в лог, можно использовать tcpdump. Только при использовании терминального сервера это неинтересно: все коннекты будут с него.

Firebird-сервер и сам имеет некоторую дополнительную информацию по подключениям ("аттачам"). В частности, подключениям сопоставлен номер процесса, запущенного на машине клиента (т.е. на терминальном сервере). Т.о. можно сравнить этот список с реальным перечнем процессов на терминальном сервере и увидеть те, которые числятся подключенными без фактически запущенного клиентского ПО.

Самый простой способ увидеть подключения -- открыть в IBExpert меню Services - Database Monitoring - Attachments. Смотреть столбцы Remote PID и Remote Process.

ПС: Полностью избавиться от ошибок 104 всё равно не получится из-за специфики сетевых технологий и убогого протокола Interbase/Firebird. Обрывы связи неизбежны и ПО должно это предусматривать. Так что если проблема только в нештатном отключении, то надо проверить наличие зависших транзакций в списке сервера. Если клиент перед вылетом всё нормально закоммитил (особенно запись), то обрыв не на что особо не повлияет.

chAlx


Цитата:

ПС: Полностью избавиться от ошибок 104 всё равно не получится из-за специфики сетевых технологий и убогого протокола Interbase/Firebird.

А можно чуть детальнее о специфике и убогости? Для общего, так сказать, развития?

chAlx
Уменьшил timeout до 170, но не рестартовал firebird(рестарт будет после 21 по МСК)=>результат увижу только завтра.
Прогнал одну из БД через IBAnalyst27

Есть набор плохих индексов и бесполезных.
Вопрос по sweep interval:
он вроде как промаркирован желтым, при этом 20000 это вроде как дефолтное значение.
Физический размер БД 4.8 Гб.
Надо ли для такой БД "оптимизировать" sweep interval?
P.S. Сопоставлять PID буду уже завтра

miwa

Цитата:

Для общего, так сказать, развития?

Это "типа троллинг" в стиле эскуэль-ру или действительно несколько лет работы с субжем не заставило прочувствовать какие-то "особенности"? Просто их там достаточно, чтобы хоть раз на какой-то споткнуться.

По-минимуму: долгие TCP-сессии, возможность молчаливой потери пакетов, отсутствие "пинга" внутри соединения, отсутствие шифрования (это уже на любителя)... Смутно помню, что где-то не хватало проверок целостности. Ну и, субъективно, дико низкая скорость передачи данных.

Что уж говорить, если [возможно, лучшее в истории клиентское приложение] IBExpert год за годом падает в случае тех или иных проблем связи с сервером.

Добавлено:
obtim:

Тут не в автоматическом свипе дело, а в том, что там зависает и надолго ли. Разница между самой старой и самой новой транзакциями ~6500 шт., но актуальность старых неизвестна.

Можно сделать свип и посмотреть, сдвинется ли счётчик старых. Это в реальном времени видно там же, в мониторинге IBExpert.

Заведомых проблем со значением 20000 тут нет.

chAlx
Попробую обрисовать картину, чтобы было более понятно,к чему вопросы.
Имеем сервак с esxi 5.5 на борту.
На нем поднята виртуальная машина Win2008R2 с 12 процами и 16 гигами оперативки.
Имеем второй сервак с esxi 5.5 на борту.
На нем поднята Centos с базой Firebird
Серваки соедиенены по гигабиту. На уровне esxi проблем нет.
В win2008r2 судя по логам проблем нет. Активирован терминальник. Пользователей около 20. Они пользуют самую малость office 2010+firefox и МИС Инфоклиника(использует БД Firebird).
Есть непонятные пиковые моменты в которые сервак виснет.
Методом исключения(system explorer+process hacker) звезды пришли к Инфоклинике.
Инфоклиника использует fastreport(*.fr3) для построения отчетов. По сути это принцип business object.
Отчеты клепает один из сотрудников компании. Отчетов много, поэтому перепроверять их сложновато.
Инфоклиника лицензионная, но там очень сложно с тех. поддержкой.
Есть две мысли: возможно она(или один из отчетов) не корректно работает с БД.
Сейчас пытаюсь ее опровергнуть или подтвердить.
Или глючит репликатор БД(в современных наших реалиях он работает вхолостую и поэтому почти его исключил).
Из двух независимых источников получил, что для проги характерна запись INET/inet_error: read errno = 104 в логах.
С фаербердом знаком на уровне ВУЗа, поэтому чуть позже позадаю еще вопросов

chAlx

Цитата:

Это "типа троллинг" в стиле эскуэль-ру или действительно несколько лет работы с субжем не заставило прочувствовать какие-то "особенности"? Просто их там достаточно, чтобы хоть раз на какой-то споткнуться.

Нет, не тролинг. Судя по ответам у вас (тебя?) достаточно опыта чтобы такие заявления делать обоснованно. Поэтому и интересуюсь.

Я работал с разными технологиями, СУБД, железками и прочим и нередко бывало так, что то, что я по молодости и неопытности считал убогостью или, наоборот, чрезмерной усложненностью, оказывалось логичным, нужным или востребованным. Это приучило сперва спрашивать более опытных людей прежде чем делать какие-то категорические заявления по поводу чего-то, что я не знаю.


Цитата:

По-минимуму: (1)долгие TCP-сессии, (2)возможность молчаливой потери пакетов, (3)отсутствие "пинга" внутри соединения, (4)отсутствие шифрования (это уже на любителя)... Смутно помню, что (5) где-то не хватало проверок целостности. Ну и, субъективно, (6) дико низкая скорость передачи данных.
 
Что уж говорить, если [возможно, лучшее в истории клиентское приложение] IBExpert год за годом падает в случае тех или иных проблем связи с сервером.

Пронумеровал для удобства цитирования.
1. Не понял. В смысле долго инициализируется сессия, или долго держится активной?
2. Это каких пакетов? На уровне ТСР или выше?
3. DummyPacketInterval - не оно?
4. Понято и принято.
5. В смысле можно при желании сформировать неправильный пакет на клиенте, который завалит сервер или повредит данные?
6. Что есть, то есть, тут тоже вопросов нет.

obtim
FastReport, скорее всего, всего лишь визуализирует сформированный отчет, который запросто может долго формироваться в БД или на клиенте.

Цитата:

Есть непонятные пиковые моменты в которые сервак виснет.

Только firebird или весь сервер? Раньше такие проблемы наблюдались или появились внезапно?( На одном из серверов у наших заказчиков наблюдалась аналогичная картина, оказалось сдохла батарейка в SCSI контроллере)


Добавлено:
Кстати, БД в 1 диалекте, это как-то странно в 2015 году.

exteris
Я понимаю.
*.fr3=xml
Немного пожалуюсь:
*.fr3 файлы клепает человек, который с компами на ВЫ. Ему когда-то показали, вот он и наделал. По факту там могут быть кривые запросы.
Перепроверять все отчеты пока нет возможности и желания. Как исключить факт их влияния - пока не понимаю.

obtim:

Цитата:

Есть непонятные пиковые моменты в которые сервак виснет.

Цитата:

для проги характерна запись INET/inet_error: read errno = 104

Ну вот тут видно, что есть две проблемы: актуальная и понятная. Вторая не особо и проблема (так, симптомчик) и не особо мешает. Так что можно про неё забыть до тех пор, пока не будет доказана причинная связь с первой ;)

Про зависоны главный вопрос задан:

Цитата:

Только firebird или весь сервер?

Т.е. надо локализовать проблему по месту проявления, времени, вызывающим её факторам (это малореально, но хотя бы уловить предшествующие события и характерные симптомы). Для этого нужен мониторинг основных параметров линух-сервера (load, iowait, память, место в разделах, загрузка сети), процесса fbserver (загрузка процессора, памяти, число сетевых соединений) и внутренних метрик Firebird (счётчики транзакций, число коннектов, время последней транзакции, загрузки памяти). Можно в лог писать, можно в систему мониторинга выгружать:

[more=Мониторинг ~40 параметров сервера и базы с помощью Zabbix]
Самое верхнее -- разница между next_transaction и oldest_active, oldest_interesting, oldest_snapshot. очень наглядно.
[/more]
Это самопальная выборка. Говорят, сейчас есть более-менее готовые системы мониторинга (отдельно для сервера, отдельно для Firebird).


Добавлено:
miwa

Цитата:

достаточно опыта чтобы такие заявления делать обоснованно

Я потому так категорично, что тут и изначально натыкаешься на ограничения, и по мере накопления опыта они никуда не уходят, а выявляются новые. Тем более, что вопрос касался обрывов связи, неизбежность которых очевидна, и относился не только к протоколу СУБД, но и к остальным слоям:

(1)долгие TCP-сессии: стандартный keepalive timeout 2 часа. Отвалившаяся сессия (клиент умер или просто закрылся по-быстрому) не рубится и СУБД считает аттач активным.
(2)возможность молчаливой потери пакетов: по-сути тот же контроль целостности. Что-то где-то в сети потерялось, а драйверу (на сервере или на клиенте) пофиг: соберёт и так либо умрёт, пытаясь. Или будет ждать того, чего уже не будет (что более характерно, т.к. посреди TCP-сессии сложно что-то потерять, а в конце легко).
3. DummyPacketInterval - не оно? Оно, спасибо. При переносе сервера осталось в дефолтном нулевом значении: тогда некоторые обслуживающие процедуры по полдня работали без фетча. Теперь надо будет попробовать, несмотря на всеобщее недоверие к этой фиче.
(5) где-то не хватало проверок целостности: точно не вспомню, но вроде дело касалось банальной чексуммы: что пакет пришёл целиком и он верный. "Пакет-убийца" -- это как одно из последствий попадания в него мусора.

chAlx
Понятно, спасибо за ответ.

Хочу на всякий случай уточнить, что (1) задается в настройках ОС и хотя конкретное приложение может переопределить это свойство, но тем не менее это считается плохим тоном. Вот отрывок из конфигурационного файла по этому поводу:

Цитата:

# Normally, Firebird uses SO_KEEPALIVE socket option to keep track of
# active connections. If you do not like default 2-hour keepalive timeout
# then adjust your server OS settings appropriately. On UNIX-like OS's,
# modify contents of /proc/sys/net/ipv4/tcp_keepalive_*. On Windows,
# follow instrutions of this article:
# http://support.microsoft.com/default.aspx?kbid=140325

Что же касается (2) и (5), то контроль целостности ТСР сессии - это тоже прерогатива сетевой подсистемы используемой ОС. Аналогично FB не хранит чексуммы страниц записываемых на диск для проверки корректности работы винта и дисковой подсистемы, насколько я помню. Тоесть, позиция разработчиков такова, что "каждый должен делать свою работу".

Опять же, я не защищаю и не выгораживаю FB, просто обращаю внимание на существование других, вполне логичных и обоснованных точек зрения.

По мониторингу еще вопрос - это личная доработка, или «найденная на просторах интернета»?

miwa:

Да, keepalive настраивается на сервере. Для всего сервера сразу (кстати, через /proc это runtime-настройка, а более полезно изменить постоянный sysctl.conf). Даже там, где крутится только база, есть ещё куча сервисов, в т.ч. сетевых. Изменения придётся учитывать для всех. (Что не умаляет факта о чрезмерности дефолтного значения для всех.)

Мониторинг реализован самостоятельно в виде выгрузки нужных данных из ОС и СУБД клиенту системы мониторинга (Cacti или Zabbix). Просторы инета на тот момент ограничивались советом снять статистику и внимательно её прочитать ;)

ПС: Вот только что наткнулся на невалидную запись:

Код: ('uñt;', '17-NOV-1858')

chAlx
Глюк оказался неожиданным:
на этом же esxi крутится машина с prtg(система мониторинга).
При выполнении определенного отчета в МИС(стали им пользоваться часто) и работе одного сенсора в prtg(довольно часто опрашивает одну железку в сетке) случались тормоза терминальника(всего)-МИС выжирала память на терминальнике.

chAlx

Цитата:

ПС: Вот только что наткнулся на невалидную запись:

Почему запись невалидная? DDL какой? Какие данные пытался записать клиент?

obtim

Цитата:

Глюк оказался неожиданным

Да, это у них бывает

obtim
систему мониторинга желательно либо отключать либо своими средствами организовывать работу терминалки так чтобы esxi могла хотябы на бумаге считаться предсказуемым устройством, для этого нужно учитывать трафик мониторинга.

miwa:

Цитата:

Почему запись невалидная?

Да там без разницы, что серверу не понравилось. Может, вообще не эти поля, а пустые последующие (хотя больше похоже на "неправильные" символы). Главное, что в базе когда-то давно появился мусор вместо данных, и хорошо, что при текстовом переносе он обнаружился.

И ещё обнаружилось несколько багов IBExpert. Самый забавный: при выполнении скрипта он так усердно выводит в подзаголовок строку счётчика "(XXXXXXXXXX) Inserting into...", что забивает этим ресурсы всей системы. Даже если окно скрипта перекрыто другими окнами (MDI). Я свернул окно IBExpert и получил снижение загрузки процессора в 3 раза (60%->20%), ускорение выполнения запросов в полтора раза (судя по загрузке сети).

Добавлено:
del

Трабла с TpFIBScripter.
Выполняемый скрипт начинается не совсем корректно

Код:
-- SUSPEND;
--END^

SET TERM ; ^

COMMIT WORK;

--ALTER

http://web.firebirdsql.org/download/snapshot_builds/win/3.0/Firebird-3.0.0.32138-ChangeLog.txt
RC1 что ль?

В последних версиях есть пример examples\interfaces\01.create.pas, где взять Firebird.pas к нему с новыми интерфейсами? Есть в UIB, но хочу и этот.

Есть ли у кого опыт использования firebird в android?

А он там есть ? Где скачать fbclient, откомпилированный под мобильные процессоры ?

На сайте firebird есть драйвер Jaybird2_2_3.jar может кто его использовал уже

Ух ты сколько всего! Спасибо. Мне NDK ближе - пойду пробовать