Какое максимальное значение может быть у LockHashSlots?
В настройках выставил LockHashSlots = 90001, но только сейчас заметил,что в выводе:

LOCK_HEADER BLOCK
Version: 145, Active owner: 0, Length: 1476395008, Used: 1445648768
Flags: 0x0001
Enqs: 42838367471, Converts: 111179156, Rejects: 726033999, Blocks: 816925355
Deadlock scans: 12910, Deadlocks: 0, Scan interval: 120
Acquires: 48810792322, Acquire blocks: 14616961785, Spin count: 0
Mutex wait: 29.9%
Hash slots: 65521, Hash lengths (min/avg/max): 0/ 2/ 12
Remove node: 0, Insert queue: 0, Insert prior: 0
Owners (530): forward: 25486296, backward: 78385320
Free owners (242): forward: 104065216, backward: 36896368
Free locks (10853): forward: 548208, backward: 70145520
Free requests (363511191): forward: 492601864, backward: 233647560
Lock Ordering: Enabled

p.s. Firebird 2.5.3

dimitrПереходи на 3.0 SS.
Не могу, увы и ах. Разработчик не я, а автору мигрировать на трешку недосуг. Ну и самостоятельные переходы не приветствуются, потом любые проблемы, связанные с работой софта, вешаются на клиента.
p.s. вопрос можно по двум параметрам?

dimitr, насколько оправдано изменение этих параметров для Classic:

UsePriorityScheduler

PrioritySwitchDelay

PriorityBoost

ProcessPriorityLevel

?

при Length: 1476395008, Used: 1445648768 стоит увеличивать размер памяти для менеджера блокировок?

dimitr Такое ощущение, что задран размер страничного кеша и это напрягает лок-менеджер.
DefaultDbCachePages = 1500, страница 16.

dimitrGallemarDefaultDbCachePages = 1500
и насколько так работает быстрее, чем при 512, например?
Прям 512 или 500?
Обязательно должно быть кратно 8?

уменьшил до 512, завтра посмотрю результаты. В выходные большой нагрузки нет.

Разницы никакой, что 1500, что 512
LOCK_HEADER BLOCK
Version: 145, Active owner: 0, Length: 134217728, Used: 70664344
Flags: 0x0001
Enqs: 9821038027, Converts: 24520218, Rejects: 250574645, Blocks: 111068356
Deadlock scans: 55, Deadlocks: 0, Scan interval: 120
Acquires: 10764377959, Acquire blocks: 2221396072, Spin count: 0
Mutex wait: 20.6%
Hash slots: 65521, Hash lengths (min/avg/max): 0/ 1/ 10
Remove node: 0, Insert queue: 0, Insert prior: 0
Owners (503): forward: 44228280, backward: 70648912
Free owners (27): forward: 65787440, backward: 70657504
Free locks (32107): forward: 2572992, backward: 1958248
Free requests (846110647): forward: 2768424, backward: 10226856
Lock Ordering: Enabled

dimitr,ок

лог уже 2,5 ГБ, оборвать и скинуть что есть?

Скинул 3 ГБ в архиве, процесс ещё идет.

Ещё процесс идет...

hvlad,всё как надо:

hvladGallemar,

без -c он может "идти" ещё неделю
с -с -а и -а идет очень долго.....

Данные после апгрейда сервера:
LOCK_HEADER BLOCK
Version: 145, Active owner: 0, Length: 134217728, Used: 58642680
Flags: 0x0001
Enqs: 2472897879, Converts: 5824508, Rejects: 50375375, Blocks: 13328158
Deadlock scans: 0, Deadlocks: 0, Scan interval: 120
Acquires: 2605729311, Acquire blocks: 495701770, Spin count: 0
Mutex wait: 19.0%
Hash slots: 65521, Hash lengths (min/avg/max): 0/ 0/ 7
Remove node: 0, Insert queue: 0, Insert prior: 0
Owners (468): forward: 676720, backward: 52001176
Free owners (20): forward: 56496976, backward: 54079768
Free locks (4796): forward: 538120, backward: 20756336
Free requests (22159): forward: 49347616, backward: 58296368
Lock Ordering: Enabled

Увеличена память с 256 ГБ до 384Гб,процессоры вместо Xeon E7530 1.87 GHz 4 по 8 ядер теперь Xeon E5-2699 2.2 GHz 2 сокета по 44 ядра

dimitr, помогло, заметно шустрее работает программа, сразу все процессы сократились по времени, пользователи довольны. Хотя бы я доживу спокойно до обновления,чтобы в mon$ лишний раз не лазили. А вообще разработчик не знал,что при любом обращении к mon$ идет создание снепшота по всем таблицам в рамках одной транзакции, иначе бы он не стал делать такой способ входа.

dimitr,ок