Здравствуйте господа.
Столкнулся с проблемой, которую не могу решить.

Перевел базу с FB 2.5 (SuperClassic) на FB 3.0.4 (SuperServer).
База: ~35Гб, Кол-во пользователей: ~200, Сервер: 2 х E5-2630, 32 Гб, win server 2012 (64)
FB 3.0.4.33054 (64), конфигурационный файл - по умолчанию, автоматическая сборка мусора отключена, ежедневный (-ночный) backup/restore.

До перевода средняя загрузка процессоров составляла порядка 10-20%
После перевода на FB3 и установки SuperServer загруженность увеличилась до 30-40% с периодическими (раз в несколько часов) выходами на 90-100% загрузку. При которой пользователи вообще работать не могут, приходилось перезапускать FB.

Если переключить с FB 3.0.4 (SuperServer) на FB 3.0.4 (SuperClassic) - все проблемы снимаются. Загрузка те же 10% что были на FB 2.5. Никаких зависаний.

Буду благодарен за совет в какую сторону рыть.

Dimitry Sibiryakov,
Это да, мысль хорошая. Но в данной истории все таки интересно почему SuperClassic (c настройками по-умолчанию) работает, SuperServer (опять же по-умолчанию) зовет сисадмина :)

Симонов Денис,
Полностью с Вами согласен, Денис. Понятно, что параметры по умолчанию неоптимальны. Просто мне казалось, что значения по-умолчанию могут приводить к снижению эффективности. Но не к полной же неработоспособности. И опять же почему "по-умолчанию" у SS - это 100% загрузка именно процов. А "по-умолчанию" у SC - полностью работоспособная система (возможно не оптимальная). Пока роюсь в документации, но ответа не нашел.

kdv,
Честно признаться, приложение на BDE. И с явным управлением транзакциями там ээээ... не очень.
Простите мое невежество, я еще только начинаю разбираться во всем этом: а что у SuperServer-a сборка мусора работает как то по другому чем у SuperClassic-а? Просто у нас sweep interval установлен в 0 и сборка мусора выполняется один раз в день (ночью) - во всяком случае я так это понимал.

Господа, спасибо за рекомендации. Проверяю все что можно.
К сожалению в данный момент вариант с заменой настроек по умолчанию на другие не помогает.

Установил в конфиге:
ServerMode = Super
DefaultDbCachePages = 50000
TempBlockSize = 2M
TempCacheLimit = 2G

Результат тот же:
Через примерно час работы выход всех процессоров на загрузку от 50% и вверх до упора. Все тормозят, новые пользователи не подключаются. До перезапуска FB.
Переключение на СуперКлассик - полет нормальный, все работает.

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

Симонов Денис,
Что "делает неработоспособной" это сказал я. Потому что действительно работать невозможно :).
Запросы могут быть конечно плохими, но вряд ли причина в этом. Потому что под FB2.5 SC - все ОК. Под FB 3.0 SC - все ОК. А вообще эта программа (ну в более старой версии) и под IB работала. Все проблемы - при использовании FB 3.0 SS. По моему это с запросами связано быть не может.
UDF - есть. Но опять же в SC они работают нормально. Или здесь есть какая то принципиальная разница.
Статистика:

Gstat execution time Mon May 06 11:49:26 2019
Database header page information:
Flags 0
Generation 1117081
System Change Number 0
Page size 4096
ODS version 12.0
Oldest transaction 2113
Oldest active 933798
Oldest snapshot 933798
Next transaction 1125724
Sequence number 0
Next attachment ID 2371
Implementation HW=AMD/Intel/x64 little-endian OS=Windows CC=MSVC
Shadow count 0
Page buffers 1024
Next header page 0
Database dialect 1
Creation date May 6, 2019 4:28:31
Attributes force write, no reserve

Variable header data:
Sweep interval: 0
*END*

Пишу чтобы завершить тему. Перепробовал различные варианты настройки.
Database header page information:
Flags 0
Generation 1195600
System Change Number 0
Page size 16384
ODS version 12.0
Oldest transaction 15833
Oldest active 1130310
Oldest snapshot 1130310
Next transaction 1208964
Sequence number 0
Next attachment ID 3118
Implementation HW=AMD/Intel/x64 little-endian OS=Windows CC=MSVC
Shadow count 0
Page buffers 50000
Next header page 0
Database dialect 1
Creation date May 8, 2019 4:31:08
Attributes force write
Variable header data:
Sweep interval: 0

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

Возвращаюсь на SuperClassic - в нем, как писал выше, ни одной из описанных проблем не возникает даже на базовых настройках. Следующий заход в SuperServer - либо когда найду какую то существенно новую информацию по этим чудесам, либо (что скорее) - ждем FB4.

Всем спасибо за помощь и комментарии.

Мимопроходящий, спасибо.
Но sweep не хочу - у нас ночью происходит backup/restore. А в течении дня sweep для нашей базы - только лишние тормоза.
А вот насчет буферов - вы считаете, что это принципиально? Здесь есть какая то выгода?

Симонов ДенисТы вместо анализа того что именно происходит просто перебираешь различные варианты конфигов
Я исхожу из того, что архитектура приложения и выбранный вариант конфигурации сервера - это малопересекающиеся сущности. Может быть я не прав. Но эта база и связанные с ней приложения нормально работали в вариантах IB7.5+BDE (SS), IB2009+BDE (SS), FB2.5+BDE (SC - потому что не было многопроцессорного SS) и теперь FB3+BDE (SC). А в FB3+BDE (SS) - не работают.
Из этого я делаю вывод, что в реализации SS в FB3 есть какие то серьезные отличия от него же в IB и что под SS наши программы работают не так как под SC.
Как диагностировать эту проблему со стороны приложения мы придумать не можем - потому, что проблемы возникают не при выполнении каких то действий программы, а через некоторое время стандартной работы программ при стандартной нагрузке. При этом под SS - проблемы есть. Под SC - нет.
С тем, что программы для использования с FB (SS) и c FB (SC) должны чем то серьезно отличаться я ранее не сталкивался.