kdvfnvhope,

к слову, а вот это откуда в свойствах БД взялось?
Reserve Space No
кто его сделал, и зачем? У вас же база не read-only.
Нет ,не только для чтения. При восстановлении включили галочку "использовать все доступное пространство", видимо.

kdvу супера 2.5 кэш метаданных общий, у 3.0 - как у классика, отдельный на каждый коннект.
Об этом известно, речь идёт о размере кэша на коннект

kdvfnvhope,

к слову, а вот это откуда в свойствах БД взялось?
Reserve Space No
кто его сделал, и зачем? У вас же база не read-only.

Благодарю, за указание - это явная ошибка и серьёзная. Исправить можно только через новое восстановление или можно так gfix -use reserve ?

hvladОбратиться к соотв. объекту. Обращение может быть косвенным, не обязательно прямым.

Т.е. select null from SP (null, ....) -

hvladНа каждом уровне рекурсии или ином вложенном вызове создаётся новый экземпляр.

т.е. я не получу 100% картины, но хотя бы одноуровневый кэш получу

hvladдерево выполнения не клонируется - оно одинаково и не меняется,

дерево остаётся в кэше?

И так, добавили серверу пямяти до 72Гб, теперь коннекты стали расти до 380Мб каждый, процесс сервера тоже вырастает до 70Гб, пользователей даже не 500 (последнее максимальное кол-во было 522), а всего 401. Работает на пределе. Ещё десяток пользователей и сервер умрёт. Давайте вместе справимся с ситуацией.

Дабавлю, что после получения сообщения о нехватке памяти, служба firebird "зависает", перезапустить не возможно. Приходится перегружать сервер.

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

на фига? Пока нет никаких подтверждений что это кеш метаданных столько отожрал.
Надо сделать ровно один коннект и следить как на нём растёт память, и смотреть что делали когда память существенно выросла.

Если много памяти хапается при коннекте, значит надо смотреть триггеры ON CONNECT и на старт, коммит транзакции.

А нагрузочное тестирование перед переходом на новую версию это обязательно надо делать.
Сделан один коннект, выполнена перекомпиляция всех процедур и триггеров - получичли размер памяти у соединения
MON$STAT_IDMON$STAT_GROUPMON$MEMORY_USEDMON$MEMORY_ALLOCATEDMON$MAX_MEMORY_USEDMON$MAX_MEMORY_ALLOCATEDMON$ATTACHMENT_IDMON$SERVER_PIDMON$STATEMON$ATTACHMENT_NAMEMON$USERMON$ROLEMON$REMOTE_PROTOCOLMON$REMOTE_ADDRESSMON$REMOTE_PIDMON$CHARACTER_SET_IDMON$TIMESTAMPMON$GARBAGE_COLLECTIONMON$REMOTE_PROCESSMON$CLIENT_VERSIONMON$REMOTE_VERSIONMON$REMOTE_HOSTMON$REMOTE_OS_USERMON$AUTH_METHODMON$SYSTEM_FLAG501302 202 768312 934 400304 386 064 316 940 672 1 52658 1241E:\CISDATA302\PP01.FDBSYSDBANONETCPv4172.16.97.228/3138795 6685212.09.2018 11:451C:\Program Files (x86)\HK-Software\IBExpert\IBExpert.exeWI-V3.0.2.32703 Firebird 3.0P15asz1310014059Srp0
можно ли говорить, что размер кэша около 300 Мб?

Ivan_PisarevskyfnvhopeДавайте вместе справимся с ситуацией.В смысле скинуться еще на полдюжины планок памяти?

Мы на полторы сотни юзеров поставили 256 гб, правда рассчитываем удвоить нагрузку. потребление памяти стабилизировалось на отметке 210-220 гб.

70 гиг тупо мало для нагруженного сервера, у меня в десктопе 32.

Помочь, определиться с размером кэша, и, соот-но, с минимальным объёмом необходимой памяти.

Благодарю всех за потраченное время. Пойду скрести по закромам родины. Надеюсь, в будущих версиях всё-таки Firebird вернётся к общему кэшу.

kdv,
Нет не пропустили, ранее было указание на эту ошибку и её исправили при первой же возможности.

Симонов Денис
Симонов Денисfnvhope,
ты когда про кеш говоришь уточняй какой именно кеш.
Да, приношу извинения.

Симонов ДенисfnvhopeДо этого мы работали на superserver 2.5 x32 и не знали горя, кроме производительности.

Я вообще с трудом представляю как можно 500 коннектов запустить на 2.5 x32 SS, даже несмотря на общий кеш метаданных.

А что, по Вашему мнению, должно было мешать серверу 2.5 х32?

О бездеятельности. Активная работа осуществляется (и осуществлялась), в среднем, 270 пользователями (один пользователь - один коннект). Ещё около 100 пользователей - средняя активность, и около 150 - малоактивные.