Растет объем оперативной и виртуальной памяти
Растет объем оперативной и виртуальной памяти
Доброго времени суток. Использую Firebird 2.1.0.17798 super server. Есть приложение написанное на BDS 2006. Компоненты доступа InterBase.
Приложение, а точнее его часть - отдельный поток общается с базой. Т.е. подключение к базе всего одно, и одна активная транзакция с параметрами: read_committed, rec_version, nowait. Пишем в базу с помощью одного и того же IBSQL. После удачного выполнения запроса делается CommitRetaining, на except делается RollbackRetaining. После всего IBSQL.Close. Все чтения производятся в этой же транзакции с помощью динамических IBQuery. Которые после обработки закрываются и уничтожаются. Размер базы на текущий момент 6 Мб. Почему-то через сутки работы сервер Firebird "отъедает" порядка 600 Мб оперативной памяти и 800 Мб виртуальной. Понять не могу в чем дело... Подскажите куда копать...
Приложение, а точнее его часть - отдельный поток общается с базой. Т.е. подключение к базе всего одно, и одна активная транзакция с параметрами: read_committed, rec_version, nowait. Пишем в базу с помощью одного и того же IBSQL. После удачного выполнения запроса делается CommitRetaining, на except делается RollbackRetaining. После всего IBSQL.Close. Все чтения производятся в этой же транзакции с помощью динамических IBQuery. Которые после обработки закрываются и уничтожаются. Размер базы на текущий момент 6 Мб. Почему-то через сутки работы сервер Firebird "отъедает" порядка 600 Мб оперативной памяти и 800 Мб виртуальной. Понять не могу в чем дело... Подскажите куда копать...
Re: Растет объем оперативной и виртуальной памяти
В MON$STATEMENTS сколько записей ?
Re: Растет объем оперативной и виртуальной памяти
Приношу свои извинения. Оказалось проблема не в моей базе и приложении. Один умник посадил еще одну "кривую" базу на этот сервер, ничего не сказав никому...
Re: Растет объем оперативной и виртуальной памяти
тем не менее, сношать сервер завершением транзакций с retaining нехорошо. и как я вижу (про IBSQL), никакого смысла нет.
Re: Растет объем оперативной и виртуальной памяти
т.е. подтверждать транзакцию просто commit? но тогда надо будет Query вешать на отдельную транзакцию, иначе по commit они закроются, если я конечно правильно понял в чем разница commit и commitretaining
Re: Растет объем оперативной и виртуальной памяти
Добрый день участникам форума. Прошу Вашего совета.
В общем есть у нас БД (2 ГБ), диалект_1, на Firebird.1.0.3.972 - СуперСервер.
Сервер Win2003_R2, RAM - 4GB, 2 HDD 146 GB SAS в RAID-е.
Бэкап/рестор - проводятся каждую ночь.
С этой базой работают несколько приложений написанных на Делфи5,6 с использованием BDE. (старые приложения - они работают и мы их не трогаем).
Одновременно около 60-90 коннектов - к примеру один оператор запускает 3 приложения - значит с его компютера будут 3 конекта.
Эти приложения местами грешат на управление транзакциями - но повторюсь - проблем до сих пор не возникало.
И пару дней назад - началось.
процесс ibserver.exe - потихоньку пожирает оперативную память, доходит до того что за 1 час сьедая 2ГБ оперативки - база просто перестает отвечать.
При попытке подключится - выдает
Unable to complete network request to host xx.xx.xx.xx
Failed to establish a connection.
Системе не удается найти указанный параметр среды.
или
Error reading data from the connection.
Так же отмечу что до июня (3 мес. назад) - БД работала на сервере послабее - Win2000, RAM - 512MB. Обьем был может на сотню MB меньше.
И тоже не было никаких проблем.
В статистике указывается проблема что очень много активных незавершенных транзакций. С этим пытаемся сейчас разобраться - прочесываем код старых приложений.
Но как до сих пор все работало нормально (при тех же параметрах, и даже на сервере послабее) - и в один день начались проблемы?
Вот статистика (в момент когда были 73 коннекта и ibserver.exe - сьел 2ГБ оперативки )
Параметр Значение
По индексам проблем нету, блобов в базе нету.
На данный момент все это вылечивается перезапуском службы, и работа восстанавливается. А через час все по новой. (еще могу сделать бэкап/рестор за 20 мин - чтоб избавиться от активных транзакций - но это не сильно влияет на результат).
То что Active transactions 11397, 96% от ежедневных это много я знаю, но ведь все работало до сих пор без проблем.
Посоветуйте пожалуйста куда еще смотреть?
В общем есть у нас БД (2 ГБ), диалект_1, на Firebird.1.0.3.972 - СуперСервер.
Сервер Win2003_R2, RAM - 4GB, 2 HDD 146 GB SAS в RAID-е.
Бэкап/рестор - проводятся каждую ночь.
С этой базой работают несколько приложений написанных на Делфи5,6 с использованием BDE. (старые приложения - они работают и мы их не трогаем).
Одновременно около 60-90 коннектов - к примеру один оператор запускает 3 приложения - значит с его компютера будут 3 конекта.
Эти приложения местами грешат на управление транзакциями - но повторюсь - проблем до сих пор не возникало.
И пару дней назад - началось.
процесс ibserver.exe - потихоньку пожирает оперативную память, доходит до того что за 1 час сьедая 2ГБ оперативки - база просто перестает отвечать.
При попытке подключится - выдает
Unable to complete network request to host xx.xx.xx.xx
Failed to establish a connection.
Системе не удается найти указанный параметр среды.
или
Error reading data from the connection.
Так же отмечу что до июня (3 мес. назад) - БД работала на сервере послабее - Win2000, RAM - 512MB. Обьем был может на сотню MB меньше.
И тоже не было никаких проблем.
В статистике указывается проблема что очень много активных незавершенных транзакций. С этим пытаемся сейчас разобраться - прочесываем код старых приложений.
Но как до сих пор все работало нормально (при тех же параметрах, и даже на сервере послабее) - и в один день начались проблемы?
Вот статистика (в момент когда были 73 коннекта и ibserver.exe - сьел 2ГБ оперативки )
Параметр Значение
Код: Выделить всё
Информация о БД
Имя БД palata.gdb
Дата создания 23.09.2010
Дата получения статистики 23.09.2010 9:20:12
Page size 8192
Forced Write ON
Диалект 1
OnDiskStructure 10.0
Sweep interval 30000
Oldest transaction 437
Oldest snapshot 436
Oldest active 438
Next transaction 11835
Sweep gap (snapshot - oldest) -1
Размер TIP для Snapshot 11398 транзакций, 11 килобайт
Active transactions 11397, 96% от ежедневных
Транзакций в день 11835, за 1 дней
На данный момент все это вылечивается перезапуском службы, и работа восстанавливается. А через час все по новой. (еще могу сделать бэкап/рестор за 20 мин - чтоб избавиться от активных транзакций - но это не сильно влияет на результат).
То что Active transactions 11397, 96% от ежедневных это много я знаю, но ведь все работало до сих пор без проблем.
Посоветуйте пожалуйста куда еще смотреть?
-
- Заслуженный разработчик
- Сообщения: 1436
- Зарегистрирован: 15 сен 2005, 09:05
Re: Растет объем оперативной и виртуальной памяти
Вспоминать что сделали эту пару дней назад. Заменили UDF, поменяли что-то в приложениях и т.д. Рост занимаемой памяти это вероятнее всего её утечка.KSilver писал(а):И пару дней назад - началось.
Посоветуйте пожалуйста куда еще смотреть?
Re: Растет объем оперативной и виртуальной памяти
Никаких масштабных изменений не делали. UDF - вообще не трогаем пару лет уже.
Вопрос - а как то влияет на сервер то что на клиентах установлен Firebird_client более ранней версии?
К примеру на сервере Firebird_1.0.3.972, а на клиентах Firebird_client 1.0.0.ххх?
Вопрос - а как то влияет на сервер то что на клиентах установлен Firebird_client более ранней версии?
К примеру на сервере Firebird_1.0.3.972, а на клиентах Firebird_client 1.0.0.ххх?
Re: Растет объем оперативной и виртуальной памяти
клиент никак не влияет. Вам точно сказали искать, что менялось 2-3 дня назад.
-
- Заслуженный разработчик
- Сообщения: 1436
- Зарегистрирован: 15 сен 2005, 09:05
Re: Растет объем оперативной и виртуальной памяти
Значит вспоминайте немасштабные. Для того, чтобы заставить утекать память достаточно одного мелкого бага в приложении.KSilver писал(а):Никаких масштабных изменений не делали.
Re: Растет объем оперативной и виртуальной памяти
Все решилось.
Оказалось что один из програмистов (по неопытности) стал использовать функцию UDF-extractdate в запросе TQuery. То есть не в хранимой процедуре - а в коде приложения на Делфи, в том числе и как условие поиска (Query1.SQL.Text:='Select extractdate(date_in), ... where extractdate(date_in) between :data1 and :data2' ).
Убрали UDF из запросов - и все стало в порядке.
Всем спасибо за поддержку.
Оказалось что один из програмистов (по неопытности) стал использовать функцию UDF-extractdate в запросе TQuery. То есть не в хранимой процедуре - а в коде приложения на Делфи, в том числе и как условие поиска (Query1.SQL.Text:='Select extractdate(date_in), ... where extractdate(date_in) between :data1 and :data2' ).
Убрали UDF из запросов - и все стало в порядке.
Всем спасибо за поддержку.
Re: Растет объем оперативной и виртуальной памяти
Ваши слова как бы говорят о том, что функция extractdate написана криво, и приводит к утечкам памяти.
Разницы между вызовом этой функции "из Дельфи" или из процедуры нет. Утечку заметили когда функция стала использоваться часто.
Разницы между вызовом этой функции "из Дельфи" или из процедуры нет. Утечку заметили когда функция стала использоваться часто.
Re: Растет объем оперативной и виртуальной памяти
Функция extractdate написанна не нами. Мы используем набор rfunc 2.0.1.2 - последний стабильный.
В ХП функции из rfunc испльзуются часто и повсеместно (в том числе и extractdate) - и все работает без проблем.
Еще нашел по форуму
Может в rfunc действительно есть какие-то редкие баги,
или проблема кроется в использовании rfunc под Win2003,
или к утечкам памяти приводит вызов UDF из приложения,
или это может быть связанно с ипользованием BDE.
или все что выше взятое вместе - создают такую проблему.
Других обьяснений не нахожу.
В ХП функции из rfunc испльзуются часто и повсеместно (в том числе и extractdate) - и все работает без проблем.
Еще нашел по форуму
http://www.ibaseforum.ru/viewtopic.php? ... 070#p19070kdv писал(а):проверь версию rfunc. когда-то там память аллокировалась не через ib_util_malloc.
Может в rfunc действительно есть какие-то редкие баги,
или проблема кроется в использовании rfunc под Win2003,
или к утечкам памяти приводит вызов UDF из приложения,
или это может быть связанно с ипользованием BDE.
или все что выше взятое вместе - создают такую проблему.
Других обьяснений не нахожу.
Re: Растет объем оперативной и виртуальной памяти
каким образом связан BDE на клиенте и утечки памяти на сервере? Я сразу отвечу, что никаким.
И кстати, после 2.0.1.2 были обновления 2.1.2 и 2.1.3. Поскольку там есть исходники, я бы не втыкал такие функции бездумно, а хотя бы сравнил диффом (или посмотрел дифф прямо на sourceforge), что же они там поменяли.
RFUNC тоже люди писали, причем давно, если бы Вы обратили внимание, то последняя версия датирована 2003 годом. А Ваша 2.0.1.2 - вообще 2002 год. Это год выхода Firebird 1.0. Восемь (!) лет назад.Мы используем набор rfunc 2.0.1.2 - последний стабильный.
И кстати, после 2.0.1.2 были обновления 2.1.2 и 2.1.3. Поскольку там есть исходники, я бы не втыкал такие функции бездумно, а хотя бы сравнил диффом (или посмотрел дифф прямо на sourceforge), что же они там поменяли.