miwaonlineОписать рекомендации касаемо выбора cache_size
рекомендации написаны.

! по умолчанию, если не менять firebird.conf, размер кэша классика (на процесс) составляет всего 75 страниц, что очень мало. В настоящее время рекомендуется явно устанавливать размер кэша классика равным от 512 до 2048 страниц, причем, увы, это значение придется подбирать экспериментально, потому как при большом количестве пользователей в большом кэше Classic страницы чаще становятся неактуальными, что приводит к повторам i/o (чтения измененных другими процессами страниц) и ухудшению производительности.

Для страницы 16к размер кэша в 2048 страниц будет 32 мегабайта памяти на процесс. В промышленных системах размер памяти, занимаемой процессом классика, может быть примерно от 50 до 250 мегабайт (в зависимости от выполняемых запросов, сортировок, объема метаданных, и т.п.). Следовательно, общее потребление памяти можно вычислить умножением значения для одного процесса на количество пользователей.
Например, если процесс классика занимает в памяти 150 мегабайт, и предполагается до 200 пользователей, то памяти на сервере нужно не менее 30 гигабайт.
Как выяснить заранее, сколько памяти будет занимать процесс классика? Никак, потому что это зависит от метаданных, запросов, и объема обрабатываемых данных. Нужно запустить Firebird Classic, и посмотреть на размер процесса при выполнении запросов (или работе приложения) к конкретной БД.

или мне этот текст нужно еще раз переписать так, чтобы еще больше понизить планку его понимания? :-)

miwaonline при условии что на компьютере FB является основной/приоритетной службой.
казалось бы, какая разница, приоритетной или нет. Есть объем доступной RAM, есть кол-во процессов, процессы занимают N памяти, из которых часть является page_size * cache_size. Арифметика для второго класса начальной школы.

Dimitry SibiryakovНапример, "если в статистике запросов к разогретой базе соотношение reads/fetches приближается к единице, страничный кэш можно увеличить, но только пока не полезут вверх цифры purge-exchange
муа-ха-ха. Папа, ты с кем сейчас разговаривал? :-)

Правильная последовательность
1. смотрим размер процессов
2. пялимся в page_size, cache_size
3. читаем, как это все зависит
4. меняем
5. ну и возможно, тут твой текст, чтобы вернуться к пункту 4.

Если человек не может посмотреть размер процессов, то он соответственно, не сможет понять пункты 2 и 4.
Разумеется, никому неохота "читать воду", поэтому обычно долбят сразу в пункт 4, с известным результатом.

p.s. а в отношении firebird.conf еще и не могут прочитать, что написано перед самим параметром. Как будто вместо английского там или иврит, или пустое место.

Dimitry SibiryakovИзвестный совет Влада "всегда отключать автосвип для больших баз" как раз и относится к
этой категории.
не знаю, кто имеет приоритет, но это я давно рекомендую отключать автосвип. По вполне понятным причинам.

Dimitry SibiryakovКстати, у тебя в статье нет рекомендаций по настройке параметров лок-менеджера, а он весьма сильно влияет на производительность. Пару лет назад ДЕ читал доклад на конференции на эту тему.
нету. По лок-менеджеру есть совершенно конкретная рекомендация
LockMemSize >= Cache_pages * max_connections_count * 100

т.е. опять голая арифметика, но это же не все. И более того, в данном случае я пока не вижу смысла крутить firebird.conf вообще. Ты же видишь, у человека тяга - ФБ вроде работает медленно, дайте я что-нибудь покручу в конфиге, чтобы было быстрее.
То есть, у него к жигулям белаз на прицепе, а он пытается на газ надавить посильнее, думая, что это поможет.
Первична информация по системе. firebird.conf - вторичен.

pastorесли он в пределах 1 Гб, то конфигом это не лечится. и тп. и пр.
из разряда телепатии - "тяжелый отчет" представляет собой запрос с plan sort, в результате чего io в temp пожирает ресурсы, или шедулер io блокирует альтернативные операции, в результате чего все приходит в ступор.

Собственно, имеем следующую ситуацию
- пользователь стороннего ПО
- от стороннего ПО нет нигде рекомендаций ни по оборудованию, ни по настройке ФБ (на сайте не нашел)
- рекомендация ubuntu в качестве сервера БД не объяснена. "рекомендует производитель ПО" - это на грани бреда.
- кто ставил и настраивал убунту - неизвестно
- почему старый сервер поменяли на новый - неизвестно.
- как и где что лежит на этих 128/128/500 - тоже неизвестно
- что в firebird.conf - неизвестно
- что происходит в системе (операционке) при выполнении "тяжелого отчета" и без него - неизвестно

Единственное, что известно:
- с транзакциями вроде все ок, более того, 72301 транзакций с марта - это 12 транзакций в день. Как бы, не очень верится, если работают 35 человек.
- база в no reserve, по неизвестной причине. Я знаю только один случай, когда разработчик явно объяснил причину выставления этого флага в базе. В остальных случаях "никто ничего не знает".

вроде все. Опять подчеркну, что при этих условиях крутить firebird.conf нужно в последнюю очередь (если он случайно кем-то уже не редактировался).

MaksimusAzov2 Services-DataBase Monitoring-Statements... ну и начинаем АНАЛИЗИРОВАТЬ ПОКАЗАТЕЛИ
какие еще "показатели" в ФБ 2.0.7 ???

MaksimusAzov особенно интересна КОЛОНКА NON-Index Reads(NIR) смотрим на показатель если из общего количества чтений все они NIR то это ни есть ХАРАШО, значится забыли про ИНДЕКСЫ
не могу удержаться - ахинея это. Читайте dataaccesspaths.htm на сайте. Убиваться, чтобы были одни индексные чтения, никогда не надо. Кто эту дурь придумал про "ни есть харашо", не имею понятия.
Разумеется, если поиск по индексу сократит выборку, то хорошо чтобы индекс был, и чтобы поиск шел по нему. Но эта "аксиома" верна для запросов не проще палки и веревки. В условиях сложных запросов индексы не являются прямо таки абсолютным критерием производительности.

Ну и, наконец, у людей сервер тормозит, а вы им оптимизировать запросы от ЧУЖОГО приложения советуете?