Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Firebird, InterBase Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3 4 5   вперед  Ctrl      все
 Зависание базы - новые коннекты не реагируют, старые работают  [new]
db20mln
Member

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

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
+
TempDirectories = d:\temp
DefaultDbCachePages = 16000
TempBlockSize = 2M
TempCacheLimit = 3Gb
DeadlockTimeout = 3
WireCrypt = Disabled
LockMemSize = 160M
LockHashSlots = 99971
EventMemSize = 512K
ServerMode = Classic


fb_lock_print
+

C:\Program Files\Firebird\Firebird_3_0>fb_lock_print.exe -d e:\db\database.fdb -r
LOCK_HEADER BLOCK
Version: 146, Creation timestamp: 2016-07-12 21:00:36
Active owner: 0, Length: 167772160, Used: 7200488
Enqs: 801335, Converts: 733469, Rejects: 7261, Blocks: 8319
Deadlock scans: 0, Deadlocks: 0, Scan interval: 3
Acquires: 1600408, Acquire blocks: 5363, Spin count: 0
Mutex wait: 0.3%
Hash slots: 65521, Hash lengths (min/avg/max): 0/ 0/ 6
Remove node: 0, Insert queue: 0, Insert prior: 0
Owners (1): forward: 536968, backward: 536968
Free owners (2): forward: 563840, backward: 2880536
Free locks (31898): forward: 4233744, backward: 6986680
Free requests (32405): forward: 3996720, backward: 3339800



netstat
C:\Program Files\Firebird\Firebird_3_0>netstat -a -n | find /c "TCP"
287
14 июл 16, 22:31    [19411385]     Ответить | Цитировать Сообщить модератору
 Re: Зависание базы - новые коннекты не реагируют, старые работают  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 47080

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

Судя по всему, недобитый CORE-4899. Пиши трекеру. Переходи на суперсервер. Ну и до
текущего снапшота тоже неплохо бы обновиться как минимум.

Posted via ActualForum NNTP Server 1.5

14 июл 16, 22:42    [19411455]     Ответить | Цитировать Сообщить модератору
 Re: Зависание базы - новые коннекты не реагируют, старые работают  [new]
db20mln
Member

Откуда:
Сообщений: 32
SS пробовал - не помогло. Правда не зафиксировал что было в логах.
(SS не подходит, в нашем случае выгоднее чтобы каждый коннект имел свой кеш)
14 июл 16, 22:58    [19411551]     Ответить | Цитировать Сообщить модератору
 Re: Зависание базы - новые коннекты не реагируют, старые работают  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 27844
db20mln
в нашем случае выгоднее чтобы каждый коннект имел свой кеш

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

db20mln
SS пробовал - не помогло.

если ошибка не зависит от архитектуры, значит жди, пока пофиксят. А вообще планируй переход на SS.
14 июл 16, 23:57    [19411659]     Ответить | Цитировать Сообщить модератору
 Re: Зависание базы - новые коннекты не реагируют, старые работают  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 27844
db20mln
- В пишущей апдейтятся от 100 до 150 000 строк в одной транзакции.

кстати, вот тут классик 3.0 будет медленнее супера 3.0, однозначно.
И - у этих транзакций выставлено no_auto_undo?
14 июл 16, 23:58    [19411661]     Ответить | Цитировать Сообщить модератору
 Re: Зависание базы - новые коннекты не реагируют, старые работают  [new]
hvlad
Member

Откуда:
Сообщений: 10195
db20mln,

fb_lock_print нужно делать для той БД, в которой ошибка - в данном случае security3.fdb
Если не знаешь как его запускать, делай c опцией -a.

Если эта проблема стабильно воспроизводится на SS\SC, то имеет смысл снять полный дамп памяти.
Но лучше всего, конечно, сделать воспроизводимый пример.

PS не вижу связи ни с "эта проблема возникала при переходе с 2.0 на 2.5", ни с CORE-4899
15 июл 16, 00:13    [19411686]     Ответить | Цитировать Сообщить модератору
 Re: Зависание базы - новые коннекты не реагируют, старые работают  [new]
hvlad
Member

Откуда:
Сообщений: 10195
kdv
И - у этих транзакций выставлено no_auto_undo?
Надеюсь, ты не советуешь этот флаг использовать ?
15 июл 16, 00:14    [19411687]     Ответить | Цитировать Сообщить модератору
 Re: Зависание базы - новые коннекты не реагируют, старые работают  [new]
hvlad
Member

Откуда:
Сообщений: 10195
db20mln
SS пробовал - не помогло. Правда не зафиксировал что было в логах.
Очень плохо, что не зафиксировал
15 июл 16, 00:15    [19411689]     Ответить | Цитировать Сообщить модератору
 Re: Зависание базы - новые коннекты не реагируют, старые работают  [new]
db20mln
Member

Откуда:
Сообщений: 32
Поставил Firebird-3.0.1.32562-0_x64 - буду тестить.

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

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

SS попробую на днях еще раз, правда кеш надо будет очень большой поставить.
15 июл 16, 01:07    [19411794]     Ответить | Цитировать Сообщить модератору
 Re: Зависание базы - новые коннекты не реагируют, старые работают  [new]
Симонов Денис
Member

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


начинай с 50K. Можно больше, но аккуратно, так как при превышении FileSystemCacheThreshold файловый кеш будет отрублен, что может сказаться как в лучшую. так и худшую сторону.

Если есть запросы с сортировками, то подымай TempCacheLimit.

Хотя все эти советы от этой ошибки скорее всего не спасут.
15 июл 16, 10:41    [19412939]     Ответить | Цитировать Сообщить модератору
 Re: Зависание базы - новые коннекты не реагируют, старые работают  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 27844
hvlad
Надеюсь, ты не советуешь этот флаг использовать ?

советую. потому что он пишет, что "В пишущей апдейтятся от 100 до 150 000 строк в одной транзакции.". Таким образом, все равно undo log при роллбэке "работать" не будет (от 80 тыс до 150 тыс). А в результате апдейты будут работать быстрее.
15 июл 16, 13:58    [19414401]     Ответить | Цитировать Сообщить модератору
 Re: Зависание базы - новые коннекты не реагируют, старые работают  [new]
hvlad
Member

Откуда:
Сообщений: 10195
kdv
А в результате апдейты будут работать быстрее.
С чего бы это ?
15 июл 16, 14:08    [19414451]     Ответить | Цитировать Сообщить модератору
 Re: Зависание базы - новые коннекты не реагируют, старые работают  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 27844
hvlad,

а что, разве нет такого совета "при массовых вставках укажите no_auto_undo"? или вставка от апдейта тут сильно отличается? Я может забыл чего...
15 июл 16, 14:56    [19414775]     Ответить | Цитировать Сообщить модератору
 Re: Зависание базы - новые коннекты не реагируют, старые работают  [new]
Гаджимурадов Рустам
Member

Откуда:
Сообщений: 59631
kdv> или вставка от апдейта тут сильно отличается?

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

Posted via ActualForum NNTP Server 1.5

15 июл 16, 15:05    [19414832]     Ответить | Цитировать Сообщить модератору
 Re: Зависание базы - новые коннекты не реагируют, старые работают  [new]
hvlad
Member

Откуда:
Сообщений: 10195
kdv
а что, разве нет такого совета "при массовых вставках укажите no_auto_undo"?
Первый раз слышу.
Али с Таблоидом много общался ? ;)

Вообще говоря, многое зависит от того, как вставлять - одним оператором или кучкой мелких.
Во втором случае можно сэкономить немного памяти и чуть-чуть скорости. Совсем чуть-чуть.

kdv
или вставка от апдейта тут сильно отличается?
Если не апдейтить одну запись более одного раза - ничем не отличается.
15 июл 16, 15:38    [19415030]     Ответить | Цитировать Сообщить модератору
 Re: Зависание базы - новые коннекты не реагируют, старые работают  [new]
db20mln
Member

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

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

PS: Сейчас в качестве эксперимента пытаюсь избавиться от post_evet, больше уже грешить не на что.
15 июл 16, 16:28    [19415313]     Ответить | Цитировать Сообщить модератору
 Re: Зависание базы - новые коннекты не реагируют, старые работают  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 47080

db20mln
Я собираюсь выделить те несколько полей которые апдейтятся - в отдельную таблицу, чтобы
при апдейте плодились версии более мелких записей.

Бесполезно: в дельту и так включаются только изменённые поля.

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

Бесполезно: твоя проблема никак не связана с основной БД вообще.

Posted via ActualForum NNTP Server 1.5

15 июл 16, 16:30    [19415328]     Ответить | Цитировать Сообщить модератору
 Re: Зависание базы - новые коннекты не реагируют, старые работают  [new]
hvlad
Member

Откуда:
Сообщений: 10195
db20mln
Я собираюсь выделить те несколько полей которые апдейтятся - в отдельную таблицу, чтобы при апдейте плодились версии более мелких записей.
Нет смысла. FB сохраняет сжатую дельту.
Можно выиграть пару байт на дельту, но потерять на заголовках записей и джойнах.
15 июл 16, 16:32    [19415344]     Ответить | Цитировать Сообщить модератору
 Re: Зависание базы - новые коннекты не реагируют, старые работают  [new]
db20mln
Member

Откуда:
Сообщений: 32
Избавление от post_event ничего не дало.

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

И вот fb_lock_print для SECURITY3.FDB
+
C:\Program Files\Firebird\Firebird_3_0>fb_lock_print.exe -d "C:\PROGRAM FILES\FIREBIRD\FIREBIRD_3_0\SECURITY3.FDB" -n
LOCK_HEADER BLOCK
Version: 146, Creation timestamp: 2016-07-15 21:22:24
Active owner: 0, Length: 167772160, Used: 553488
Enqs: 175, Converts: 6, Rejects: 33, Blocks: 2
Deadlock scans: 74535, Deadlocks: 2, Scan interval: 3
Acquires: 74865, Acquire blocks: 3720, Spin count: 0
Mutex wait: 5.0%
Hash slots: 65521, Hash lengths (min/avg/max): 0/ 0/ 4
Remove node: 0, Insert queue: 0, Insert prior: 0
Owners (29): forward: 536968, backward: 553160
Free owners: *empty*
Free locks (5): forward: 541256, backward: 537664
Free requests: *empty*
16 июл 16, 00:35    [19417462]     Ответить | Цитировать Сообщить модератору
 Re: Зависание базы - новые коннекты не реагируют, старые работают  [new]
db20mln
Member

Откуда:
Сообщений: 32
Последняя сборка зависает чаще.
Только что зависла при 20 активных коннектах.
Это бред.
Откатываюсь на 2.5.
17 июл 16, 18:48    [19420846]     Ответить | Цитировать Сообщить модератору
 Re: Зависание базы - новые коннекты не реагируют, старые работают  [new]
hvlad
Member

Откуда:
Сообщений: 10195
db20mln,

ты можешь на SS это воспроизвести и снять полный дамп памяти ?
17 июл 16, 19:42    [19420973]     Ответить | Цитировать Сообщить модератору
 Re: Зависание базы - новые коннекты не реагируют, старые работают  [new]
db20mln
Member

Откуда:
Сообщений: 32
Да, попробую.
Все равно оказалось что просто так на предыдущую через b/r не перейдешь, ибо:
Expected backup version 1..9. Found 10. :(
17 июл 16, 21:05    [19421109]     Ответить | Цитировать Сообщить модератору
 Re: Зависание базы - новые коннекты не реагируют, старые работают  [new]
hvlad
Member

Откуда:
Сообщений: 10195
db20mln
Да, попробую.
Спасибо
db20mln
Все равно оказалось что просто так на предыдущую через b/r не перейдешь, ибо:
Expected backup version 1..9. Found 10. :(
Нужно бекапить gbak'ом от 2.5 и без сервисов
17 июл 16, 21:53    [19421184]     Ответить | Цитировать Сообщить модератору
 Re: Зависание базы - новые коннекты не реагируют, старые работают  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 27844
db20mln,

http://www.ibase.ru/prevver/
"Переход на версию «назад»"
17 июл 16, 22:11    [19421214]     Ответить | Цитировать Сообщить модератору
 Re: Зависание базы - новые коннекты не реагируют, старые работают  [new]
db20mln
Member

Откуда:
Сообщений: 32
Перешел на супер.
Пришлось поставить DefaultDbCachePages = 640000, т.к. с 50000 тормоза.

Сперва база упала из-за udf - может и не из-за нее, но в логах дважды появилась ошибка:
+
DBS Mon Jul 18 12:17:02 2016
The user defined function: MY_STRING_HASH
referencing entrypoint: MyStringHash
in module: MyUDF.dll
caused the fatal exception: 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.


DBS Mon Jul 18 12:17:02 2016
Operating system call TlsGetValue failed. Error code 87


Заменил ее на 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 не зайдешь - тупит сильно, по несколько минут не реагирует.
В клиентское программе - тоже фризы нереальные, поэтому остальные юзеры курят пока не закончатся обработки.
При том что в классике - было нормально.
18 июл 16, 14:19    [19423178]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3 4 5   вперед  Ctrl      все
Все форумы / Firebird, InterBase Ответить