Сегодня перед работой поднял DefaultDbCachePages до 1536.

Получилось следующее:Обращения к диску/с
Среднее: 115
Максимальное: 1170

Обращений чтения с диска/с
Среднее: 2.3
Максимальное: 58

Обращений записи с диска/с
Среднее: 114
Максимальное: 1164

Средняя длина очереди диска
Среднее: 0.047
Максимальное: 0.303

% загруженности процессора
Минимум: 5.6
Среднее: 22
Максимальное: 68

Ранее средняя загрузка процессора была 46%.

Памяти стало чуть больше занимать - 7 Гб вместо 5Гб.

Если недорогой RAID 1 (увеличение скорости не нужно, увеличение надежности нужно) рассматривать на 2 SSD, то что лучше в плане надежности:
1) аппаратный Adaptec/Intel + 2 SATA/SAS/U.2 - диска или
2) программный RAID на 2 PCi (у них скорость чтения/записи лучше чем у SATA/SAS/U.2 , но аппаратных рейдов для таких плат не видел)?

Dimitry SibiryakovА теперь покажи результат fb_lock_print.

Ivan_Pisarevskypastor производительность не беспокоит .Первый пост в топике говорит немного об обратном.

Сформулирую свою мысль более развернуто. Мне необходима достаточная производительность всего сервера в целом. Так же мне необходима и достаточная для моего случая надежность (ниже опишу что я под этим понимаю)

Для себя из всего обсуждения наметил следующий порядок действий (в порядке приоритета):
1) Более плотно подойти к оптимизации БД. Провести оценку структуры, индексов (избыточность), триггеров (расчет агрегаций), запросов. Цель: уменьшить количество обращений к диску, снизить нагрузку на процессор.
2) Увеличить память до 64Гб. После этого посмотреть еще раз на производительность. Возможно, процессор станет справляться с нагрузкой.
3) Поменять 1 SSD на RAID из SSD.

И тут 3 пункт для меня пока не очень понятен. С одной стороны в Firebird_Hardware_Guide говорится, что FB достаточно критичен к скорости хранилища БД. С другой стороны скорости 1 SSD вроде бы (?) достаточно, но его надежность под большим сомнением.
Поэтому оставив ту же производительность хочу поставить RAID 1, который даст некую уверенность. Относительно разумных денег будут стоить 2 SSD на PCI, которые дадут еще бОльшую производительность относительно SATA/SAS/U.2 SSD дисков, но для них нет аппаратных контроллеров. Либо, выбрав на хороших SATA/SAS/U.2 SSD дисках аппаратный RAID-контроллер даже с батарейкой, при выходе его из строя - я теряю всю БД (восстановление бэкапа рассматриваем как крайний случай - это дополнительное время и потеря новых данных с последнего бэкапа).
Если при выходе из строя железа сервера с программным RAID-ом есть надежда, что подоткнув один из SSD дисков в резервный сервер можно быстро запустить работу, то с аппаратным контроллером это будет значительно сложнее. Держать в резерве еще один контроллер я не готов.

Питание сервера сейчас такое: здание подключено по 2й категории, время переключения на 2й кабель (от другого трансформатора) 10 минут, ИБП Eaton Powerware с двойным преобразованием выдерживает 40 минут. В принципе, можно подсоединить еще 1-2 доп.батареи и увеличить время работы от ИБП часов до 2-3.

ДаниилDimitry SibiryakovА теперь покажи результат fb_lock_print.
Никогда не пользовался этим инструментом. Подскажите, на какие цифры смотреть?

Подниму свою старую тему по поводу попытки увеличения производительности.

На данный момент настраиваю сервер FB на новом железе.
Решил, что экспериментировать с переходом с 2.5 на 3.0 пока рано, поставил последнюю версию сервера ветки 2.5 (2.5.9.27139).
С целью экономии остановился на варианте быстродействующего персонального компьютера вместо серверной платформы. Цена вопроса: 200 тыс.руб. (на i9) вместо 1200 тыс. (на Xeon Gold).
Пока что провел тестирование только дисковой подсистемы с помощью backup'а. БД размером 57 Гб бэкапится в 35 Гб за 12 минут (50 Мб/с). Судя по статье ( http://www.ibase.ru/backupspeed3/) - это хорошие показатели.
К сообщению приложил скриншот тестов дисков для DB и backup-а CrystalDiskMark'ом.

Сейчас хочу оптимально выставить настройки сервера для максимальной производительности.
Подскажите, правильно ли я подобрал параметры?

Исходные данные такие:
Размер БД: 57 Гб. Из них оперативные данные - это не более 5-10 Гб. Все остальные - архивные данные, которые редко читаются и практически никогда не изменяются.
Firebird 2.5.9.27139 Classic. OC WIndows 2016std.
Объем ОЗУ: 64 Гб (с возможностью нарастить до 128Гб, но пока не понятна целесообразность, пусть будет 64).
Количество одновременно работающих пользователей: 120-140.
БД расположена на отдельном от системного диска SSD. Так же в firebird.conf выделен отдельный HDD для TempDirectories (тот, что для используется для ежедневных бэкапов). Использую один и тот же диск исходя из логики, что таблицы сортировки серверу будут не нужны, когда все пользователи отключены и запущен gbak. А затем файл с бэкапом потихоньку забирается с этого быстрого но небольшого диска (запас диска от текущего размера бекапа - шестикратный) на большой медленный диск и далее на сетевые хранилища.
Исходя из статей по оптимизации настроек и размера ОЗУ, прописал в firebird.conf (для Page size 16384) следующее:


DefaultDbCachePages = 1536
# Пока поставил немного менее 2048

FileSystemCacheThreshold = 8192
# Должен быть больше CachePages. На сколько больше? Достаточно ли ограничения в 128Гб?

LockMemSize = 23040000
# LockMemSize >= Cache_pages * max_connections_count * 100 (Посчитал для 150 пользователей)

FileSystemCacheSize = 25
# Отдаем 16 Гб памяти под кэш ОС. Или не надо это явно ограничивать?

TempCacheLimit = 8192M
# Отдаем 8Гб памяти для сортировок

TempBlockSize = 64M
# По совету dimitr (TempBlockSize я бы советовал выставлять не более 5% от TempCacheLimit и не менее 1МБ (дефолтное значение))

LockHashSlots = 30011
# Из оптимизированного конфига с ibase.ru

Симонов ДенисДаниилFileSystemCacheThreshold = 8192
# Должен быть больше CachePages. На сколько больше? Достаточно ли ограничения в 128Гб?
эту настройку можно было вообще не трогать. Там и так большое значение по умолчанию Для классика полюбас подойдёт.
Как гигабайты насчитал?


Как я понял из https://ib-aid.com/download/webinar/memory_usage_in_firebird1.pdf
8192 - это максимальный размер кэша ОС, который может использовать FB при необходимости, измеряется в количестве страниц
Поэтому 8192*16384=134217728=128Гб

Симонов ДенисДаниилTempCacheLimit = 8192M
# Отдаем 8Гб памяти для сортировок
для классика многовато будет. Этот параметр общий в SS и SC, но не в классике. Надеюсь буковку M не оставил. Это работает начиная с 3.0.
Вообще-то оставил, но пока на обсуждаемом конфиге не запускал. Комп сейчас свободный стоит, пока все хотя бы первоначально не настрою. Про ошибку свою понял.
Про память для сортировок читал http://www.ibase.ru/files/firebird/Firebird_Hardware_Guide_2015_rus.pdf и https://ib-aid.com/download/webinar/memory_usage_in_firebird1.pdf но в итоге посчитал кэш общим для всех процессов (как в FB 3.0).
Скачанный с www.ibsurgeon.com конфиг для Firebird 2.5 64-bit Classic содержит значение для TempCacheLimit = 77108864 и TempBlockSize = 2048576. Сделаю их такими.

Basil A. SidorovДаниилРазмер БД: 57 Гб. Из них оперативные данные - это не более 5-10 Гб. Все остальные - архивные данные, которые редко читаются и практически никогда не изменяются.
Firebird 2.5.9.27139 Classic. OC WIndows 2016std.
Объем ОЗУ: 64 Гб (с возможностью нарастить до 128Гб, но пока не понятна целесообразность, пусть будет 64).
Количество одновременно работающих пользователей: 120-140.
БД расположена на отдельном от системного диска SSD. Так же в firebird.conf выделен отдельный HDD для TempDirectories (тот, что для используется для ежедневных бэкапов).Плохая идея.
В C:\ProgramData\firebird расположены lock-файлы, для которых (тоже) нужен быстрый доступ. И для сортировок.
В вашем раскладе легко получить 100% загрузки системного диска с огромной очередью и огрестись тормозами "вообще всего".
Если не хотите размещать систему на SSD целиком, то "откусите" от SSD диска несколько гигабайт, создайте отдельный раздел и подмонтируйте его к пустому C:\ProgramData\firebird.
Всё это можно проделать "онлайн" и остановка FB потребуется только для того, чтобы очистить ProgramData/firebird и смонтировать туда подготовленный раздел.
Чтобы переместить на SSD fb_table, fb_sort и прочие временные файлы FB, установите глобальную переменную FIREBIRD_TMP (setx /m или аплет sysdm.cpl) в отдельный (существующий) каталог SSD-диска.
Firebird 2.0 Administrators ManualUse the TempDirectories parameter to specify where the server will create temporary sort files.
Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ Борри ХеленПеременная окружения FIREBIRD_TMP (В версии 1.0.x - INTERBASE TMP) задает пользовательское размещение для файлов сортировки Firebird. Доступны также другие способы определения размещения этих файлов. Конфигурирование параметра TempDirectories Зачем мне тогда указывать FIREBIRD_TMP? Или параметр TempDirectories в конфиге задает место для сортировок, а системная переменная FIREBIRD_TMP не только сортировки, но еще и другие файлы? Не нашел этого в инструкциях.
Диск для ОС у меня на самом деле точно такой же модели как для файла сортировок и еженочных оперативных бэкапов - SSD SAMSUNG 970 EVO Plus MZ-V7S250BW 250Гб, M.2 2280, PCI-E x4, NVMe. Это достаточно быстрый диск. Тормозов "вообще всего" быть не должно.
А файл базы лежит на еще более быстром диске - зеркале из двух SSD INTEL Optane 900P SSDPED1D280GASX 280Гб, PCI-E AIC (add-in-card), PCI-E x4, NVMe
Их скорости я выкладывал вчера.