Здравствуйте.
Помогите, пож-та, найти причину проблемы.

Firebird-3.0.0.32483_2_x64 (Classic mode)
XeonE5 х 2шт, SSD Raid10, памяти 64Gb (Win Server 2008 R2 Enterprise)

Есть база 30 Гб - в ней есть 2 большие таблицы:
- примерно на 11 гб и на 8 гб
- с индексами по текстовым полям (плюс FK на мелкие таблицы)

Несколько раз в сутки запускается обработка данных в несколько этапов:
1) чтение и запись в большую таблицу 1
2) чтение из большой таблицы 2
3) чтение из таблицы 1

- Все операции происходит одновременно с 40-50 воркеров (отдельных легких клиентов - Delphi + IBX).
- Каждый воркер работает со своими строками (т.е. воркеры не работают с одними и теми же записями таблиц).
- У каждого воркера есть читающая транзакция и пишущая.
- В пишущей апдейтятся от 100 до 150 000 строк в одной транзакции.
- Каждый воркер отработав со своими данными завершает работу и запускается новый воркер для работы со следующим набором данных.
- В базе один юзер SYSDBA.


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

Через isql коннектиться получается.

У одного из воркеров (только у одного) при этом выскакивает ошибка:
firebird Attachment::start Transaction failed when loading mapping cache

Иногда ошибка:
Your user name and password are not defined. Ask your database administrator to set up a Firebird login.

В логах при этом возникают ошибки - обычно 2 подряд:
Database: C:\PROGRAM FILES\FIREBIRD\FIREBIRD_3_0\SECURITY3.FDB
page 0, page type 1 lock denied (216)

Database:
page 0, page type 1 lock denied (216)

Еще:
Ограничение винды на кол-во коннектов (1024) - убрано, хотя более 370 и не доводилось увидеть.
Память занята не более чем на 30%.
Дисковая подсистема грузится до 90% на запись в пиках.
B/R не помогает, ошибок в базе нет.


PS: Ранее эта проблема возникала при переходе с 2.0 на 2.5, но тогда решилась уменьшением кол-во воркеров со 100 до 60.



firebird.conf


fb_lock_print



netstat
C:\Program Files\Firebird\Firebird_3_0>netstat -a -n | find /c "TCP"
287

SS пробовал - не помогло. Правда не зафиксировал что было в логах.
(SS не подходит, в нашем случае выгоднее чтобы каждый коннект имел свой кеш)

Поставил Firebird-3.0.1.32562-0_x64 - буду тестить.

no_auto_undo не использую.

fb_lock_print для security3.fdb сделаю при ближайшем зависании.

SS попробую на днях еще раз, правда кеш надо будет очень большой поставить.

По поводу пишущей транзакции.
Я собираюсь выделить те несколько полей которые апдейтятся - в отдельную таблицу, чтобы при апдейте плодились версии более мелких записей.
Или как вариант - переделать с update на insert (но придется периодически делать массовые delete) - даже не знаю лучше это или хуже.

Но все это никак не решит проблему, т.к. база виснет и на том этапе, где данных только читаются.

PS: Сейчас в качестве эксперимента пытаюсь избавиться от post_evet, больше уже грешить не на что.

Избавление от post_event ничего не дало.

На последней сборке - клиент показывает более детальное сообщение (раньше была только вторая строчка):
page 0, page type 1 lock denied
IAttachment::startTransaction failed when loading mapping cache.

И вот fb_lock_print для SECURITY3.FDB

Последняя сборка зависает чаще.
Только что зависла при 20 активных коннектах.
Это бред.
Откатываюсь на 2.5.

Да, попробую.
Все равно оказалось что просто так на предыдущую через b/r не перейдешь, ибо:
Expected backup version 1..9. Found 10. :(

Перешел на супер.
Пришлось поставить DefaultDbCachePages = 640000, т.к. с 50000 тормоза.

Сперва база упала из-за udf - может и не из-за нее, но в логах дважды появилась ошибка:


Заменил ее на udr и запустил заново.

После запуска воркеров, начали периодически отваливаться клиентские приложения с одной и той же парой ошибок:
DBS Mon Jul 18 14:04:15 2016
INET/inet_error: read errno = 10054, client host = trm, address = 192.168.99.10/59403, user = red31
DBS Mon Jul 18 14:04:15 2016
INET/inet_error: read errno = 10054, aux client host = trm, address = 192.168.99.10/59440

После чего вообще все упало, на клиентах и воркерах выдало:

Error writing data to the connection.

(Дамп снял - отправлю)


Общие наблюдения:
Выборка и апдейт выполняются дольше, т.е. в сумме все делается в 1.5 - 3 раза дольше.

По монитору ресурсов: загрузка диска на 90-99%, при этом ввод/вывод = 7-20 Мб/с.
При классике было: загрузка диска на 85-95%, ввод/вывод = 20-70 Мб/с.

В время работы воркеров, даже в IB Expert не зайдешь - тупит сильно, по несколько минут не реагирует.
В клиентское программе - тоже фризы нереальные, поэтому остальные юзеры курят пока не закончатся обработки.
При том что в классике - было нормально.

Вот дамп, но я не уверен что это тот, который нужен - т.к. после падения база тут же перезапускается.
https://yadi.sk/d/rUeYqOHCtPomc

Снова упал с ошибкой в логе:

DBS Mon Jul 18 14:31:45 2016
Access violation.
The code attempted to access a virtual
address without privilege to do so.
This exception will cause the Firebird server
to terminate abnormally.

hvladdb20mlnПришлось поставить DefaultDbCachePages = 640000а) накой назначать огромный кеш ВСЕМ БД ?
БД всего одна. При меньшем кеше скорость работы падает.

При работе воркеров они читают большую таблицу - но каждый свою часть данных. Т.е. кеш слишком быстро забивается и освобождается (воркеры запускаются 1500 - 3500 раз, но не более 40-60 одновременно).

Я прикинул что если при классике я ставил 16000 (выбрано после ряда экспериментов), то при 40 одновременных воркерах - это как раз 640000.

hvladб) FileSystemCacheThreshold отредактировал ?
Нет.
Подскажите пож-та какое значение установить.
Мануалы читал, но 2 недели этих проблем уже высушили мозг.

hvladdb20mlnЗаменил ее на udrНа что ???
udr.dll
У меня одна самописная внешняя функция - перед переходом с 2.5 на 3.0 реализовал ее в виде UDR.

hvladdb20mlnПосле чего вообще все упалоА до этого падало как-то иначе, не вообще ?
firebird.log во время падения что-то содержит, кроме INET ошибок ?

До этого клиентские приложения продолжали работать - т.е. я так думал, а после отправки поста понял, что скорее всего юзеры перезапустили прогу и благополучно продолжили работать.

При последнем падении было только то что выше писал


hvladПотому что ты отключил файловый кеш
Я понял что он отключился из-за FileSystemCacheThreshold, подскажите плз какое значение поставить.

Симонов Денисdb20mln,
а ты через новый fbclient работаешь или через тот что от 2.5 остался?
Подключаешься через алиас БД? В databases.conf никакие параметры не переопределял?

P.S. UDF была однозначно кривой. За UDR не скажу от неё вроде как логах ничего не было, но и не факт что если что не так туда оно попадает.
Через GDS32.dll.
databases.conf не трогал.

Я ночью запускал тестовый прогон - все прошло без сбоев, просто очень медленно (видимо отключился файловый кеш).
Раньше на классике - тоже иногда все проходило без сбоев, но чем больше данных запускаешь обрабатывать, тем больше шансов сбоя.

Ну и супер при сбое просто перезапускается и отрубаются все коннекты.
А классик - ну я писал в начале, другое поведение и другие ошибки в логе.

Симонов Денисdb20mln,
ваша UDR тоже кривая.
Даже если и так - как мне об этом узнать, если сообщений об ошибках нет?

GDS32.dll - конечно же новый, который ставится тройкой.
Он и в C:\Windows\SysWOW64\ и в папке с приложением.

hvladДля получения дампа в момент падения чти про WER (windows error reporting)
WER не был включен по умолчанию.
Сейчас включу, снова переключусь на СС и буду ждать сбой :(

Симонов Денисdb20mln,
больше чем DefaultDbCachePages. А вообще логика кажется странной. Почему требуется апдейтить хренову тучу строк? Это же порождает мусор и его сборку. Оно реально всё апдейтится или всё же часть апдейтов просто работают в холостую?
Это не лучшее решение, но оно было частью архитектуры и работало на 2.5.

Сейчас думаю как изменить эту части системы, чтобы радикально уменьшить кол-во апдейтов и инсертов.

hvladЯ правильно понимаю, что была UDF, которая приводила к падениям, и вместо неё была написана UDR (что на порядок сложнее) ? А смысл где ?

Нет.
Была UDF - 32 битная - в ней всего одна функция, она 4 года работала на FB 2.5, ошибок не выдавала.
Когда скомпилировали ее под 64 бита - подключить так и не получилось, выдавала ошибки (под 64 битной FB).

После выхода тройки решил сделать UDR чтобы перейти на 64 битную базу, пока делал - разобрался и с 64 битной версией UDF.
Т.е. по сути могу сейчас использовать и UDF, и UDR.

Ошибки UDF появились первый раз сегодня - при запуске в SS.
Поэтому я и переключился на UDR.

Dimitry SibiryakovА статистика работы кэша вообще собиралась или все изменения параметров проводятся
исключительно на "партийном чутье"?

Нет, не собиралась.
Все делалось замерами времени выполнения.

Симонов Денисдавай сюда код своей UDR/UDF вместе с объявлением метаданных.
https://yadi.sk/d/khuy3SX4tQPXh

Большое спасибо за указанные ошибки, UDF переделаю.
Но база с UDR, последний билд, SS - падения никуда не делись.

Дамп памяти не сохраняется, винда не видит что приложение крашится (в журналах винды нет сообщений о сбоях) - т.е. дамп во время сбоя снять не могу.

По итогу:
Ошибка не отлавливается, причина неизвестна, решения нет - вернулся на 2.5.