Недавно перешли с FB 1.5 на 2.5.3 superserver. Размер базы 3gb.
Перед переходом оттестировались на тестовом сервере - "повылазившие" проблемы с производительностью были устранены. Сейчас при работе на "боевом" сервере наблюдаю "тормоза". Для проверки поднял бекап свежей базы на тестовом сервере и "погонял" тестовыми запросами. Наблюдаю значительное ~3-4 раза снижение производительности "боевого" сервера (тестировал при минимальной нагрузке со стороны других пользователей - ночью) по сравнению с тестовым. Админ серверов убеждает меня в том, что "боевой" сервер гораздо мощнее тестового по железу, правда на нем "крутится" (другим процессом на отдельном порту) такой же сервер FB 2.5.3 как у меня (тоже superserver). "Знатоки", подскажите, пожалуйста в какую сторону следует "покопать". Спасибо.

Dimitry SibiryakovТогда встаёт логичный вопрос: почему твоя база не крутится на нём.

По политическим не зависящим от меня соображениям.

Спасибо за помощь.
Для тестирования сварганил процедуру вызывающую в цикле "проблемную" процедуру VIDOPLAT. Помогите "найти отличия":
"Боевой" сервер:
Plan
------------------------------------------------
PLAN (VIDOPLAT NATURAL)(K INDEX (KADR_IDX1, KADR_IDX2))
Query Time
------------------------------------------------
Prepare : 16,00 ms
Execute : 1 025 379,00 ms
Avg fetch time: 926,27 ms
Memory
------------------------------------------------
Current: 71 570 728
Max : 150 391 152
Buffers: 2 048
Operations
------------------------------------------------
Read : 758 286
Writes : 3 615
Fetches: 0
Marks : 5 013
Enchanced Info:
+-------------------------------+-----------+-----------+-------------+---------+---------+---------+----------+----------+------
Table Name | Records | Indexed | Non-Indexed | Updates | Deletes | Inserts | Backouts | Purges | Expunges |
| | Total | reads | reads | | | | | | |
+-------------------------------+-----------+-----------+-------------+---------+---------+---------+----------+----------+------|KADR | 0 | 1633 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
|SPRNU | 0 | 4298 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
|ZARPARH | 0 | 954136 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
+-------------------------------+-----------+-----------+-------------+---------+---------+---------+----------+----------+------

Тестовый сервер:
Plan
------------------------------------------------
PLAN (VIDOPLAT NATURAL)(K INDEX (KADR_IDX1, KADR_IDX2))
Query Time
------------------------------------------------
Prepare : 31,00 ms
Execute : 10 842,00 ms
Avg fetch time: 9,82 ms
Memory
------------------------------------------------
Current: 9 693 456
Max : 10 485 456
Buffers: 2 048
Operations
------------------------------------------------
Read : 373 795
Writes : 0
Fetches: 1 939 767
Marks : 0
Enchanced Info:
+-------------------------------+-----------+-----------+-------------+---------+---------+---------+----------+----------+------
| Table Name | Records | Indexed | Non-Indexed | Updates | Deletes | Inserts | Backouts | Purges | Expunges |
| | Total | reads | reads | | | | | | |
+-------------------------------+-----------+-----------+-------------+---------+---------+---------+----------+----------+------|KADR | 0 | 1630 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
|SPRNU | 0 | 4303 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
|ZARPARH | 0 | 956467 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
+-------------------------------+-----------+-----------+-------------+---------+---------+---------+----------+----------+------

Оба сервера в сети, размер страницы тот же (это та же самая база - после бекап-ресторе 2 дня назад).
переделал под isql:

"боевой":

Current memory = 58124732
Delta memory = -17346924
Max memory = 150391152
Elapsed time= 1948.53 sec
Buffers = 2048
Reads = 1400220
Writes 3514
Fetches = 296066521


тестовый:

Current memory = 9491880
Delta memory = 440136
Max memory = 9531736
Elapsed time= 17.29 sec
Buffers = 2048
Reads = 374183
Writes 0
Fetches = 1942442

Симонов ДенисТы случайно с боевого сервера не под нагрузкой статистику снимаешь? А то в супере показатели статистики по кешу общие для всех сессий.

Конечно под нагрузкой, понимаю что сравнение не совсем корректно, но я исхожу из следующих соображений:

1) База однозначно одна и та же, версия сервера тоже.
2) Различие железа на серверах врядли может оказывать столь странный эффект на статистику при выполнении запроса.
3) Методом исключения получаем виновника-"нагрузку". А вот что это за такая "чудная нагрузка" которая дает такой эффект мне предстоит разобраться, надеюсь в вашей помощью.
Если я ошибаюсь в своих размышлениях, поправьте, пожалуйста.

Dimitry SibiryakovРезультат gstat -h мы увидим когда-нибудь?..

сделал через IBAnalyst.
"боевой":
Database header page information:
Flags 0
Checksum 12345
Generation 70366
Page size 4096
ODS version 11.2
Oldest transaction 33681
Oldest active 33682
Oldest snapshot 33682
Next transaction 70253
Bumped transaction 1
Sequence number 0
Next attachment ID 5144
Implementation ID 16
Shadow count 0
Page buffers 2048
Next header page 0
Database dialect 3
Creation date Nov 12, 2014 0:35:20
Attributes force write

Variable header data:
Sweep interval: 20000


тестовый:
Database header page information:
Flags 0
Checksum 12345
Generation 2405
Page size 4096
ODS version 11.2
Oldest transaction 2374
Oldest active 2375
Oldest snapshot 2375
Next transaction 2396
Bumped transaction 1
Sequence number 0
Next attachment ID 36
Implementation ID 16
Shadow count 0
Page buffers 2048
Next header page 0
Database dialect 3
Creation date Nov 12, 2014 0:35:20
Attributes force write

Variable header data:
Sweep interval: 20000

Dimitry Sibiryakov,

ZARPARH (245)
Primary pointer page: 631, Index root page: 632
Average record length: 161.72, total records: 4906425
Average version length: 13.66, total versions: 1536, max versions: 19
Data pages: 248654, data page slots: 248654, average fill: 87%
Fill distribution:
0 - 19% = 1
20 - 39% = 0
40 - 59% = 2
60 - 79% = 2
80 - 99% = 248649

KADR (191)
Primary pointer page: 482, Index root page: 483
Average record length: 321.91, total records: 10622
Average version length: 14.85, total versions: 13, max versions: 3
Data pages: 983, data page slots: 983, average fill: 90%
Fill distribution:
0 - 19% = 0
20 - 39% = 1
40 - 59% = 0
60 - 79% = 0
80 - 99% = 982

SPRNU (225)
Primary pointer page: 571, Index root page: 572
Average record length: 168.20, total records: 307
Average version length: 0.00, total versions: 0, max versions: 0
Data pages: 17, data page slots: 17, average fill: 82%
Fill distribution:
0 - 19% = 1
20 - 39% = 0
40 - 59% = 0
60 - 79% = 0
80 - 99% = 16

Dimitry Sibiryakov
35 тысяч одновременно активных транзакций в БД.

Пожалуйста, объясните поподробнее, что это значит? У меня в mon$transactions 35тыс. записей не наблюдается. Если не трудно, перечислите наиболее вероятные причины по которым подобные неприятности могут возникать. С разработчиками будем работать, но это вопрос долгосрочный, может есть какие то рекомендации "на сейчас"? Спасибо.

Мимопроходящий для SS это смешно.

Посоветуйте, пожалуйста, свои параметры, исходя из вышесказанного.

Спасибо, за разъяснения.

kdvВы если администратор, то вам надо пнуть разработчика, чтобы он прочитал на ibase.ru статьи по транзакциям, мусору, версионности и прочему. И следом и вы можете почитать.
Этим сейчас и занимаюсь.

kdvВаши разработчики (сторонние или нет) не могут сказать, что вам надо Classic, а не SuperServer?

Объясните, пожалуйста, разве Classic поможет с проблемой "35 тысяч одновременно активных транзакций в БД"?