Ежедневно на пиковой нагрузке получаю OutOfMemory
процесс Firebird вырастает до 60 Гб
Помогите найти причину. Даже при наличии кеша на подключение, а не на процесс 522*50Мб - 26Гб

Максимальное количество пользователей 522

Виртуальный сервер (Xenon Platinum 8160 (2.1GHz) 2 процессора, память 64 Gb, ОС WinSrv20

База
Page Size 16384
ODS Version 12.0
Oldest Tr. 6576715
Oldest Active Tr. 6576716
Oldest Snapshot Tr. 6576716
Next Tr. 6625664
Page Buffers 65536
SQL Dialect 3
Shutdown Mode Online
Sweep Interval 20000
Read Only No
Forced Writes Yes
Reserve Space No
Created At 20.05.2018 10:49
Pages 1520344
Size, KB 24325504
Size, MB 23755,38
Backup State Normal
Non-indexed Reads 110509853
Indexed Reads 291856415
Records Inserted 170457
Records Updated 234478
Records Deleted 27895
Records Backed Out 15489
Records Purged 110627
Records Expunged 116110
Page Reads 7929658
Page Writes 299662
Page Fetches 867207569
Page Marks 4309822

Конфигурация
#########################################
#
# Firebird version 3.0 configuration file
#

# ----------------------------
# Database Paths/Directories
#
# DatabaseAccess = None
# DatabaseAccess = Restrict C:\DataBase
# DatabaseAccess = Restrict C:\DataBase;D:\Mirror
# DatabaseAccess = Restrict /db
# DatabaseAccess = Restrict /db;/mnt/mirrordb
# DatabaseAccess = Full
#
#DatabaseAccess = Full

#RemoteAccess = true

#ExternalFileAccess = None

#UdfAccess = Restrict UDF

#TempDirectories =

#AuditTraceConfigFile =

#MaxUserTraceLogSize = 10


#DefaultDbCachePages = 2048
#FNV
DefaultDbCachePages = 64K

#DatabaseGrowthIncrement = 128M

#FileSystemCacheThreshold = 64K
#FNV
FileSystemCacheThreshold = 129K

#FileSystemCacheSize = 0

#RemoteFileOpenAbility = 0

#TempBlockSize = 1M
#FNV
TempBlockSize = 2M

TempCacheLimit = 64M
#FNV - кэш сортировок - один на процесс
#TempCacheLimit = 2G

#AuthServer = Srp
AuthServer = Legacy_Auth, Srp, Win_Sspi

#AuthClient = Srp, Win_Sspi, Legacy_Auth
AuthClient = Legacy_Auth, Srp, Win_Sspi

#UserManager = Srp
UserManager = Legacy_UserManager, Srp

#TracePlugin = fbtrace

#WireCryptPlugin = Arc4

#KeyHolderPlugin =

#AllowEncryptedSecurityDatabase = false

#Providers = Remote,Engine12,Loopback

#DeadlockTimeout = 10

#MaxUnflushedWrites = 100

#MaxUnflushedWriteTime = 5

#BugcheckAbort = 0


#RelaxedAliasChecking = 0

#ConnectionTimeout = 180

#WireCrypt = Enabled (for client) / Required (for server)
#FNV
WireCrypt = disabled

#WireCompression = false

#DummyPacketInterval = 0


#RemoteServiceName = gds_db
#RemoteServicePort = 3050
#FNV
#RemoteServiceName = gds_db_64
#RemoteServicePort = 3051

#RemoteAuxPort = 0

#TcpRemoteBufferSize = 8192

#TcpNoNagle = 1

#IPv6V6Only = 0

#RemoteBindAddress =

#LockMemSize = 1M

#LockAcquireSpins = 0

#LockHashSlots = 8191

#EventMemSize = 64K

#CpuAffinityMask = 0

#GCPolicy = combined

#SecurityDatabase = $(dir_secDb)/security3.fdb

#GuardianOption = 1

#ProcessPriorityLevel = 0

#IpcName = FIREBIRD

#RemotePipeName = interbas

#Redirection = 0

ServerMode = Super


вот показатели VMMap при 380 продключений

Симонов Денис, на 3.0.3 не перешли - непонравилось распределение нагрузки между процессорами
у 3.0.2 более равномерная

dimitr,

fnvhope,

dimitr,

dimitr,

dimitr,

Симонов Денис
https://cloud.mail.ru/public/6UHM/hJBFfAeam

dimitrмного коннектов по 100-200 мегабайт каждый, причем юзерских запросов там единицы. Либо есть какая-то утечка памяти в ФБ, либо это все отжирается под кеш метаданных. Причем под кешированные процедуры/триггера.

Восстановление базы из бэкапа с признаком - только метаданные даёт базу размером менее 66 МБ (66 994 176 байт)
Т.е. коннект с использованной памятью 261831504 байт вмещает 4 (3,9) копии метаданных (и таких коннектов действительно пара сотен). Зачем столько копий (если это копии)?

dimitr Насколько "развесистые" запросы с т.з. вызываемых PSQL-модулей? Типа внутри одной ХП вызов еще десятка, внутри которых тоже самое.

Очень развеститые. Многие ХП - рекурсивные, вызываются с разными параметрами, вложенность рекурсии может доходить до 7(из того что написано мной), анализ по прочим не делала. Триггеры, конечно, вызывают ХП и рекурсивные в том числе, часто текст запроса генерируется в run-time ХП.

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

ищи кривые UDF/UDR
ну и обновится желательно до 3.0.3. Там были исправлены некоторые утечки памяти

Симонов Денис, Вам удалось посмотреть тесты? Тесты корректны, показательны (таблица содержит около 55 тыс. записей)? Можете предоставить ссылку на информацию об утечке?

Симонов Денисвот почему некоторые думают, что метаданные на диске и в памяти (кеш метаданных) одно и тоже? Это совсем не так.


метаданные на диске - это хоть какая-то отправная точка

http://www.sql.ru/forum/784504/uznat-tekushhiy-razmer-kesha-metadannyh

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

http://tracker.firebirdsql.org/browse/CORE-5416

Не смогла повторить - нет содержимого файлов, и описания теста не нашла (не исключаю своей незрелости)
@call run_test_w64_local2_d3.bat
@call run_test_w32_local2_d3.bat

Симонов Денисdimitrв 2.5 можно попробовать снять размер памяти для объекта database, вычесть из него память, занимаемую всеми объектами attachment оной database, вычесть размер страничного кеша. Остаток в первом приближении будет размером кеша метаданных.

где тут про размер метаданных на диске? Речь о том как приближённо вычислить через MON$

Предварительно как-то инициировать загрузку в кэш 500 ХП, 400 триггеров, 150 таблиц, 100 доменов, 600 индексов, и всё это надо было сделать до перехода на 3.0. :о( Увы, не сообразила, минус мне.

kdvfnvhope,

к слову. ничего гигантского в количестве ваших процедур, триггеров и таблиц нет. Промышленные БД обычно содержат тысячи триггеров и процедур, т.е. в 10 и более раз чем у вас. Другое дело, что в основном они на классике, но много переехали на суперклассик, и часть уже переехало на суперсервер 3.0. И пока такой проблемы (с пожиранием памяти) не наблюдается.

Отсутствие проблем у других и вызвало эту тему на форуме. До этого мы работали на superserver 2.5 x32 и не знали горя, кроме производительности. Если размер кэша метаданых м.б. в два раза больше размера на диске, то это объяснило бы использование памяти. Пока просто добавили серверу ещё 12 Гб памяти, уменьшили размер кэша страниц с 4 Гб до 1Гб.

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

Как заставить сервер загрузить метаданые в кэш? Если ХП рекурсивная сколько копий объектов представления её в памяти будет? Одна.? Столько, сколько вызовов? Столько сколько уровней рекурсии?

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 - малоактивные.

За время с последнего поста, увеличили память до 138Г. И, конечно же, наступил момент, когда и её стало мало.
"Гонку вооружений" удалось приостановить, надеюсь "протянем" ещё несколько лет на этом объёме.

Было.
Каждое клиентское приложение создавало и удерживало активным (сколько это возможно) своё подключение к базе, которое разрушалось при закрытии приложения.
В рамках этого подключения выполнялись все запросы: служебные, читающие, пишущие.

Стало.
Сделали несколько подключений на одного клиента:
один для служебных запросов (которые могут быть очень развесистыми, но только читающими и только очень ограниченный набор записей, так чтобы их можно было получить полностью и отключить датасет от транзакции);
второй для запросов, читающих данные из ограниченного набора таблиц ("реестр документов"), но порциями (спасибо разработчикам), и требующих открытого датасета на сервере данных;
третий для запросов "без ограничений" при чтении, и запросов изменяющих данные.
Первое (служебное) подключение (очень затратное по использованию памяти) переподключаем по OnIdle на клиенте.
Второе и третье по таймеру и наличию возможности на сервере.
Как показали наблюдения второе подключение большинства клиентов держится в рамках 500Кб.
Самое затратное - третье. Но поскольку оно выполняет конечный набор запросов, многие из которых не читающие (пакет insert/update/execute), его удается каждые, в среднем минут 10, переподключать.
В итоге получили (в среднем)
из 2200 подключений
600-700 по 0Кб (первый коннект переподключается по OnIdle),
150-160 от 350М до 450М (второй и третий)
остальные - от 4К до 40М (первый (ещё в запросе) и второй).

Использование памяти сократилось до 60-70Гб
Благодарю всех за участие.

hvlad,

Доброго дня, hvlad. Это будет сделано, обязательно, и здесь отчитаюсь, но не в ближ. 3 месяца. Приношу извинения, за задержку.

hvlad,
Удалось сделать раньше.

Система правда другая (на рабочем сервере нет возможности пока)

Название ОС: Майкрософт Windows Server 2019 Datacenter
Версия ОС: 10.0.17763 Н/Д построение 17763
Изготовитель ОС: Microsoft Corporation
Параметры ОС: Рядовой сервер
Сборка ОС: Multiprocessor Free
Модель системы: Virtual Machine
Тип системы: x64-based PC
Процессор(ы): Число процессоров - 2.
[01]: Intel64 Family 6 Model 85 Stepping 7 GenuineIntel ~2893 МГц
[02]: Intel64 Family 6 Model 85 Stepping 7 GenuineIntel ~2893 МГц
Язык системы: ru;Русский
Язык ввода: en-us;Английский (США)
Часовой пояс: (UTC+03:00) Москва, Санкт-Петербург, Волгоград
Полный объем физической памяти: 8 191 МБ
Доступная физическая память: 5 493 МБ
Виртуальная память: Макс. размер: 10 111 МБ
Виртуальная память: Доступна: 7 466 МБ
Виртуальная память: Используется: 2 645 МБ
Расположение файла подкачки: C:\pagefile.sys
Сетевые адаптеры: Число сетевых адаптеров - 1.
[01]: Microsoft Hyper-V Network Adapter
Имя подключения: Ethernet
DHCP включен: Нет
IP-адрес
[01]: 172.16.10.42
Требования Hyper-V: Обнаружена низкоуровневая оболочка. Функции, необходимые для Hyper-V, отображены не будут.


Один бэкап базы восстановлен в для каждой версии Firebird.
Проведено: перекомпиляция объектов БД для Firebird 3.0.7.33374, Firebird 4.0.0.2353

FB3MON$ATTACHMENT_IDMON$USERMON$REMOTE_PROCESSMON$TRANSACTION_IDMON$STAT_IDMON$STAT_GROUPMON$MEMORY_USEDMON$MEMORY_ALLOCATEDMON$MAX_MEMORY_USEDMON$MAX_MEMORY_ALLOCATED1038 554 04839 436 28839 733 34440 689 66435SYSDBAC:\Program Files (x86)\HK-Software\IBExpert\IBExpert.exe2212 847 7602 777 0884 025 6644 030 46433Cache Writer48111 584011 584034Garbage Collector491234 6720234 6720
FB4MON$ATTACHMENT_IDMON$USERMON$REMOTE_PROCESSMON$TRANSACTION_IDMON$STAT_IDMON$STAT_GROUPMON$MEMORY_USEDMON$MEMORY_ALLOCATEDMON$MAX_MEMORY_USEDMON$MAX_MEMORY_ALLOCATED1037 962 59238 928 38439 249 12040 247 29641SYSDBAC:\Program Files (x86)\HK-Software\IBExpert\IBExpert.exe2412 086 0002 183 1683 369 1043 502 08042Cache Writer54112 096012 096043Garbage Collector551211 9200211 9200
Приращение (Кб)MON$ATTACHMENT_IDMON$USERMON$REMOTE_PROCESSMON$TRANSACTION_IDMON$STAT_IDMON$STAT_GROUPMON$MEMORY_USEDMON$MEMORY_ALLOCATEDMON$MAX_MEMORY_USEDMON$MAX_MEMORY_ALLOCATED-577.5938-496.0000-472.8750-432.000041SYSDBAC:\Program Files (x86)\HK-Software\IBExpert\IBExpert.exe-743.9063-580.0000-641.1719-516.000042Cache Writer00.50000.00000.50000.000043Garbage Collector0-22.21880.0000-22.21880.0000
Перекомпиляция всех объектов
FB3MON$ATTACHMENT_IDMON$USERMON$REMOTE_PROCESSMON$TRANSACTION_IDMON$STAT_IDMON$STAT_GROUPMON$MEMORY_USEDMON$MEMORY_ALLOCATEDMON$MAX_MEMORY_USEDMON$MAX_MEMORY_ALLOCATED10642 886 256770 994 176644 071 824771 977 21635SYSDBAC:\Program Files (x86)\HK-Software\IBExpert\IBExpert.exe291604 783 616649 596 928605 894 336650 711 04033Cache Writer28111 584011 584034Garbage Collector6011 094 65665 5361 100 88065 536
FB4MON$ATTACHMENT_IDMON$USERMON$REMOTE_PROCESSMON$TRANSACTION_IDMON$STAT_IDMON$STAT_GROUPMON$MEMORY_USEDMON$MEMORY_ALLOCATEDMON$MAX_MEMORY_USEDMON$MAX_MEMORY_ALLOCATED10333 007 104444 874 752333 607 648445 399 04041SYSDBAC:\Program Files (x86)\HK-Software\IBExpert\IBExpert.exe301291 616 080357 699 584292 146 592358 289 40842Cache Writer29112 096012 096043Garbage Collector631977 93665 536979 45665 536
Приращение (Кб)MON$ATTACHMENT_IDMON$USERMON$REMOTE_PROCESSMON$TRANSACTION_IDMON$STAT_IDMON$STAT_GROUPMON$MEMORY_USEDMON$MEMORY_ALLOCATEDMON$MAX_MEMORY_USEDMON$MAX_MEMORY_ALLOCATED-302 616.3594-318 476.0000-303 187.6719-318 924.000041SYSDBAC:\Program Files (x86)\HK-Software\IBExpert\IBExpert.exe-305 827.6719-285 056.0000-306 394.2813-285 568.000042Cache Writer00.50000.00000.50000.000043Garbage Collector0-113.98440.0000-118.57810.0000

hvlad,
Каждая последующая перекомпиляция, объектов, прибавляет вес подключению, первая почти в 1.5 раза, последующие меньше. На всех версиях 302, 307, 400. Для рабочей базы, в которой компиляция происходит при работе пользователей (знаю это плохо), это объяснимо (накапливаются версии объектов, так как они used). А вот, почему так происходит для базы, в которой я единственный пользователь? Или это особенность реализации IBExpert? Через командную строку попыток не делалось.

Здравствуйте, hvlad.
авторЧто имеется в виду ? ALTER каждой процедуры\триггера\что_ещё ?
Последовательный вызов команд "перекомпилировать все ..." в IBExpert.
авторДаже если так (я позже проверю) - а какие проблемы это приносит в реальной жизни ?
Поскольку, такие действия производятся крайне редко, реальной проблемы нет. Это просто "тень утечки памяти", которая думаю, щимит всем разработчикам.