iBase.ru Forum

Использую FB embedded 1.5.3.4870.
При чтении blob растет занимаемый приложением объем RAM, величина прироста по объему примерно соответствует объему вычитываемых из blob данных.
Если вместо использования embedded сервера коннектиться к Classic серверу (той же версии) то сжирания памяти как сервером так и моим приложением не наблюдается.

Как быть в данной ситуации? Отказаться от embedded версии я не могу.

Память жрёт не embedded, а приложение

Embeded - это же динамическая библиотека вроде бы, работающая в контексте вызывающего процесса. Да, в итоге память потребляет процесс, но это не значит, что библиотека не может являться причиной утечки памяти...
Или я ошибаюсь?
С другой стороны, если приложение читает BLOB, то где-то оно должно подготовить буфер для этого блоба, вот и расход памяти. Функции типа malloc/free, даже при правильном использовании, могут увеличивать занимаемую приложением память (особенности работы менеджера памяти, фрагментация).

hvlad писал(а):Память жрёт не embedded, а приложение

Если бы память жрало приложение то оно бы его продолжало жрать и при работе с Classic сервером. Это было второе, что я проверил (в исходном посте описано). Остается вариант с кэшированием, но это в любом случае дела FB.

простейшим test case повторяется?

3m писал(а):Если бы память жрало приложение то оно бы его продолжало жрать и при работе с Classic сервером.

Чем читаешь блобы?

Dimitry Sibiryakov писал(а):

3m писал(а):Если бы память жрало приложение то оно бы его продолжало жрать и при работе с Classic сервером.

Чем читаешь блобы?

Читаю самопально доработанным IBPP-2.5.2.2 с поддержкой потоковых blob и позиционированием http://c5r.narod.ru/ibpp-with-stream-blobs.html

Я еще потестировал и получается что память жрет агрессивное кэширование блобов Embedded версией. У меня сложилось впечатление что стратегия кэширования у embedded и classic server в корне различна: embedded как при чтении так и при записи blob старается по максимуму использовать ОЗУ (держит в ОЗУ сразу несколько многомегабайтных blob не выгружая их после закрытия), обмен с HDD сведен к минимуму минимален; classic server поступает прямо наоборот - использование ОЗУ минимально, а обмен с HDD очень интенсивен.

3m писал(а):Я еще потестировал и получается что память жрет агрессивное кэширование блобов Embedded версией. У меня сложилось впечатление что стратегия кэширования у embedded и classic server в корне различна: embedded как при чтении так и при записи blob старается по максимуму использовать ОЗУ (держит в ОЗУ сразу несколько многомегабайтных blob не выгружая их после закрытия), обмен с HDD сведен к минимуму минимален; classic server поступает прямо наоборот - использование ОЗУ минимально, а обмен с HDD очень интенсивен.

Код супера\классика\embedded для блобов не отличается.

Сколько памяти отъедает приложение с embedded ?
Чему равно DefaultDbCachePages в firebird.conf в корне приложения ?

hvlad писал(а): Сколько памяти отъедает приложение с embedded ?
Чему равно DefaultDbCachePages в firebird.conf в корне приложения ?

Это оно.
Используется дефолтный firebird.conf из дистибутива. Наблюдения за использованием ram показали что embedded версия по умолчанию использует DefaultDbCachePages=2048, в то время как classic server - 75.
Это примерно объясняет (+-2-3Мб) потребление памяти моим приложением.

3m писал(а):

hvlad писал(а): Сколько памяти отъедает приложение с embedded ?
Чему равно DefaultDbCachePages в firebird.conf в корне приложения ?

Это оно.
Используется дефолтный firebird.conf из дистибутива. Наблюдения за использованием ram показали что embedded версия по умолчанию использует DefaultDbCachePages=2048, в то время как classic server - 75.
Это примерно объясняет (+-2-3Мб) потребление памяти моим приложением.

И это называется "отжирает" ?

hvlad писал(а):...
И это называется "отжирает" ?

Если реальный расход памяти в 4 раза превышает расчетное значение, то стоит задуматься.