Добрый день.

Имеется:
FB 2.5
OC – Ubuntu 10.04 LTS
проц - 16 ядер
ОЗУ - 48 Гб

Проблема:
Резко падает производительность (медленно выполняются запросы, очень медленно проходит коннект к базе) при наличии более 200 открытых соединений (в mon$attachments). При этом аппаратных проблем не видно — загрузка процессоров < 25%, свободной памяти > 30Гб, винт практически не нагружен.
При закрытии, или ручном отключении пары десятков соединений все приходит в норму.

Сборка мусора — раз в сутки.

Firebird.conf:

#RootDirectory =
#DatabaseAccess = Full
#ExternalFileAccess = None
#UdfAccess = Restrict UDF
#TempDirectories =
#LegacyHash = 1
#Authentication = native
#AuditTraceConfigFile =
#MaxUserTraceLogSize = 10
#512
DefaultDbCachePages = 8192
#DatabaseGrowthIncrement = 134217728
#FileSystemCacheThreshold = 65536
#FileSystemCacheSize = 0
#RemoteFileOpenAbility = 0
TempBlockSize = 2048576
#67108864/4
TempCacheLimit = 1073741824
#CompleteBooleanEvaluation = 0
DeadlockTimeout = 10
#MaxUnflushedWrites = 100
#MaxUnflushedWriteTime = 5
#BugcheckAbort = 0
#OldColumnNaming = 0
#OldSetClauseSemantics = 0
#RelaxedAliasChecking = 0
ConnectionTimeout = 10 #180
#DummyPacketInterval = 0
#RemoteServiceName = gds_db
#RemoteServicePort = 3050
#RemoteAuxPort = 0
#TcpRemoteBufferSize = 8192
#TcpNoNagle = 1
#RemoteBindAddress =
LockMemSize = 5048576
#LockGrantOrder = 1
#LockAcquireSpins = 0
LockHashSlots = 30011
#EventMemSize = 65536
#CpuAffinityMask = 1
#UsePriorityScheduler = 1
#PrioritySwitchDelay = 100
#PriorityBoost = 5
#GCPolicy = combined
#GuardianOption = 1
#ProcessPriorityLevel = 0
#IpcName = FIREBIRD
#RemotePipeName = interbas
#Redirection = 0

Может это быть из-за каких-то настроек в ОС? Или ФБ виноват? Кто сталкивался? Куда хоть копать?
Переход на 3.0 не рассматривается.

размер страницы - 4096
buffer pages - 8192
buffer KB - 32768

Размер БД - 40Гб

архитектура - SuperClassic

Database header page information:
Flags 0
Checksum 12345
Generation 5355474
Page size 4096
ODS version 11.2
Oldest transaction 4284802
Oldest active 4536285
Oldest snapshot 4536285
Next transaction 4718559
Bumped transaction 1
Sequence number 0
Next attachment ID 636903
Implementation ID 24
Shadow count 0
Page buffers 8192
Next header page 0
Database dialect 3
Creation date Feb 24, 2018 0:26:57
Attributes force write

Variable header data:
Sweep interval: 0

использует не более 15% от общей (48Гб)
размер свопа - 50 Мб и не меняется

rdb_dev,

релиз
firebird2.5-superclassic 2.5.2.26540.ds4-8ubuntu11

hvlad,
сдержимое трейса FB не меняется, но ночинает тормозить вместе со всем остальным. А в линуксе не силен.


Ivan_Pisarevsky
метрики собраны из htop и iotop
что за диски физически - неизвестно, это ВМ, скорость копирования 80-120Мб/с

по поводу статистики - сейчас делал новую (старой больше 2-х недель):
Database header page information:
Flags 0
Checksum 12345
Generation 13215754
Page size 4096
ODS version 11.2
Oldest transaction 10409382
Oldest active 10409383
Oldest snapshot 10409383
Next transaction 11775740
Bumped transaction 1
Sequence number 0
Next attachment ID 1439999
Implementation ID 24
Shadow count 0
Page buffers 8192
Next header page 0
Database dialect 3
Creation date Feb 24, 2018 0:26:57
Attributes force write

Variable header data:
Sweep interval: 0


что не так с цифрами? БД довольно большая, приложений масса, пользователей тоже хватает

Dimitry Sibiryakov,
а есть методы определения при работе с какими таблицами это происходит?

rdb_dev,
ну... некоторые знают, а некоторые давно уже тютю

Dimitry Sibiryakov,
select * from mon$statements where mon$state = 0
это оно?

тут таких много