Добрый день!

Есть FB 2.5.5 x64 (SC\SS), Windows Server 2012 R2 16Gb ОЗУ, SSD под систему и 1Тб под базу. База 150Гб и растет. Требуется добиться максимальной производительности сервера при работе приложения. Запускается одно клиентское приложение (x32) на этой же машине либо по сети и выполняется длительная процедура над 1-1.5 мл записей. Параметры firebird.conf значительно увеличены по сравнению с оптимизированными конфигами от ibsurgeon. FB в ОЗУ в любом режиме (SS/SC) занимает до 1.5Гб. А вот кеш системы файла базы не растет выше 1.5-2Гб. Свободно еще 12-13Гб ОЗУ.
Как заставить систему или FB использовать всю оперативную память?

Database "D:\RGB\RGB_DATA.FDB"
Database header page information:
Flags 0
Checksum 12345
Generation 5505
Page size 16384
ODS version 11.2
Oldest transaction 3827
Oldest active 4115
Oldest snapshot 4113
Next transaction 4252
Bumped transaction 1
Sequence number 0
Next attachment ID 1604
Implementation ID 26
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 1
Creation date Dec 2, 2015 17:28:24
Attributes force write

Variable header data:
Sweep interval: 0
*END*

kdv,
В программе последовательно выполняется
start
select - 300 записей
execute procedure - 300 раз
commit

Из файла базы (монитор ресурсов) идет постоянное чтение до 1 мб/сек и такая же, поменьше примерно запись.
FB сервер (SC) привязал к одному ядру процессора, приложение к другому.
При запуске второго, третьего приложения, что локально, что по сети нагрузка на FB сервер растет, чтение/запись файла базы растет (до 3Мб\сек), вот кеш файла больше 2Гб не бывает. Простаивает память, обидно.
В это же время при копировании большого файла или при бэкапе базы кеш Windows заполняется полностью.

Цифры в firebird.conf увеличивал многократно...

TempCacheLimit = 167108864
TempBlockSize = 18048576
TempCacheLimit = 1127108864
LockMemSize = 110048576
LockHashSlots = 130011
CpuAffinityMask = 128

Симонов Денис,
темр файлов нет. Под них выделена отдельная директория c:\temp и она всегда пуста.

Симонов Денис,

TempCacheLimit вытаскивал блокнотом и зацепил закомментированное.
Все остальные параметры закомментированы.
Сейчас стоит SC. Но картина с кешем базы одинакова и на SS. Для него также увеличивал на порядок параметры из "оптимизированного" конфига для SS.

DefaultDbCachePages = 20000 (не заметил, он тоже активен)
#FileSystemCacheThreshold = 65536
#FileSystemCacheSize = 0

hvlad,
это машина для теста. Но могу и снести...

Dimitry Sibiryakov,
А это следующий вопрос...
После обработки 150000-200000 строк FB сервер начинал занимать 100% ядра и обработка падала с 600 строк в минуту вначале до 50 через несколько часов. Я думал, мешает уборка мусора. Оказалось , что нет. Но 0 оставил.
У меня задача - максимально ускорить обработку кусков по 1-2 млн строк.
В начале: select - 7-10 сек, execute proc 0.01-0.02 сек, commit - 1-2 сек
Через несколько часов времена пропорционально увеличиваются.

kdv,
Раскомментировал FileSystemCacheThreshold = 65536 по совету Симонова Дениса.
Win кеш остановился вообще на 300К. Возвращаю назад, а пока картинку прикладываю.
Стер 8-ку. Время обработки первого запуска 8 мин и второго после перезапуска приложения тоже 8 минут. Кеш выключился.

Вот весь конфиг:
#RootDirectory =
#DatabaseAccess = Full
#ExternalFileAccess = None
#UdfAccess = Restrict UDF
#TempDirectories =
#LegacyHash = 1
#Authentication = native
#AuditTraceConfigFile =
#MaxUserTraceLogSize = 10
#DefaultDbCachePages = 512
DefaultDbCachePages = 20000
#DatabaseGrowthIncrement = 134217728
FileSystemCacheThreshold = 65536
#FileSystemCacheSize = 0
#RemoteFileOpenAbility = 0
#TempBlockSize = 2048576
TempBlockSize = 18048576
TempCacheLimit = 1127108864
#CompleteBooleanEvaluation = 0
#DeadlockTimeout = 10
#MaxUnflushedWrites = 100
#MaxUnflushedWriteTime = 5
#BugcheckAbort = 0
#OldColumnNaming = 0
#OldSetClauseSemantics = 0
#RelaxedAliasChecking = 0
#ConnectionTimeout = 180
#DummyPacketInterval = 0
#RemoteServiceName = gds_db
#RemoteServicePort = 3050
#RemoteAuxPort = 0
#TcpRemoteBufferSize = 8192
#TcpNoNagle = 1
#RemoteBindAddress =
#LockMemSize = 5048576
LockMemSize = 110048576
#LockGrantOrder = 1
#LockAcquireSpins = 0
LockHashSlots = 130011
#EventMemSize = 65536
CpuAffinityMask = 128
#UsePriorityScheduler = 1
#PrioritySwitchDelay = 100
#PriorityBoost = 5
#GCPolicy = combined
#GuardianOption = 1
#ProcessPriorityLevel = 0
#IpcName = FIREBIRD
#RemotePipeName = interbas
#Redirection = 0

Ivan_Pisarevsky,
Мало того САТА, что даже на 5400... Потому и хочу ее кешировать.
Но очередь не поднимается до 0.2, время ответа 1-2 мс. А у приятеля 2 ССД на ПО и базу. Результаты почти аналогичны, ~20% побыстрее (скорее всего за большей частоты процессора 3.6 против 2.2). А машина свободна!!!

Вот данные с закомментированным параметром #FileSystemCacheThreshold = 65536
По мере обработки кеш ОС вырастает не спеша до 1.5-2 гб.
Наверное вернусь к SS. Там сразу и памяти FB берет под 2ГБ и кеш побольше. И проводок он обрабатывает сначала под 800 в минуту

Симонов Денис,

Ты мне сказал, что FileSystemCacheThreshold (65536) параметр должен быть больше DefaultDbCachePages (20000). Я его и включил, он оказался больше, значит кеш ОС должен точно работать. А он не работает.
>>>>Это важно. Если DefaultDbCachePages > FileSystemCacheThreshold, то файловый кеш будет отключен <<<

А увеличиваю я только те параметры, которые есть в "оптимизированных" конфигах для SC иSS и смотрю на скорость обработки в программе.

Зимаргл,

По мере работы программы растет время выполнения процедуры. Придется обращаться к разработчикам.
Наверное все ускорение там и лежит. А в таком режиме обработку даже на выходные не оставить, она умирает. Приходится через несколько часов перезапускать ПО.

kdv,

Разница между Oldest и Next transaction увеличивается.
Это и есть накапливание версий (мусора)?

Database "D:\RGB\RGB_DATA.FDB"
Database header page information:
Flags 0
Checksum 12345
Generation 14539
Page size 16384
ODS version 11.2
Oldest transaction 3827
Oldest active 9003
Oldest snapshot 8998
Next transaction 9067

kdv,
Поговорил с программистами про накапливание мусора и версионности. Сказал, что после перезапуска приложения все сначала работает быстро. Они не вдаваясь в подробности, после обработки 20000 записей сделали дисконнект и реконнект к базе. Накапливающиеся тормоза пропали, скорость обработки к 3-м часам, я думаю что за счет кеша ОС выросла с 560 до 640 записей в минуту и на этом остановилась, остановился и рост кеша ОС. Вот картинка 4-х часов обработки. FB в режиме SS с задранными параметрами в памяти занимает 1-1.3 Гб

kdv,
Теперь можно и в ночную, да несколько экземпляров ПО

kdv,
Попробовал наше ПО на FB 3.0. Длинные операции работают быстрее! (причем файла базы данных в кеше Windows RamMap не видит вообще!). А вот как вернуть базу обратно для 2.5.5, если что не заладится?

kdv,
FB 3.0 использовать для глобальных импортов и обработки, например в выходные. Выигрыш в скорости примерно на треть на каждое подключение (вместо 500-550 сделок в минуту - 750-800). А затем конвертироваться в 2.5 и работать с данными в ПО до следующего большого импорта. ПО достаточно универсальное, работает c SQL FB, MS, Oracle, есть контакт с разработчиками. Попробую gbak'ом в понедельник.