Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

insufficient memory при большом числе обращений к БД [D6]

data © (2004-08-25 17:22:00)
Не сталкивался ли кто-нибудь со следующей проблемой:
приложение обращается к БД на чтение и добавление новых записей с частотой неск. раз в секунду. Когда общее число обращений приближается к 100 000 на очередном обращении вылетает ошибка insufficient memory to this operation, после этого такие ошибки начинают возникать при обращениях все чаще и чаще (абсолютно те же запросы до ошибки обрабатывются нормально), затем возникают при любом обращении и приложение падает. Иногда с ним падает и БДЕ. Выводила статистику (логи) по открытым-закрытым select - вроде все закрываются. Prepare - Unprepere тоже не помогает.
в http://bdn.borland.com/article/0,1410,25294,00.html написано поменять параметры в БДЕ. Да правильно, после их увеличения приложение живет дольше, но эффект все равно остается.
в http://bdn.borland.com/article/0,1410,21725,00.html вообще об утечке памяти. Все понятно, но как же побороть то :(? Может кто уже боролся?

Sergey13 (2004-08-26 10:56:00) [1]
А если это в ХП засунуть?

data (2004-08-26 10:53:00) [2]
Sergey13 ©
текст один и тот же, запрос создан в дизайн тайме с постоянным текстом и параметром.
Схема такая: назначаем параметр, открываем, смотрим необходимое, закрываем. Все из главного треда, но 5-10 раз за секунду.
Наверное какая-то память просто не успевает освободиться ИМХО. Сейчас попробую делать для Query этого Create-Free в рантайме для каждого обращения и еще c Prepare-Unprepare покручу

Sergey13 (2004-08-26 10:41:00) [3]
2[9] data © (26.08.04 10:29)
>Prepare - Unprepere тоже не помогает.
>ночной прогон показал, что дело было в постоянных селектах (раз 5-10) в секунду
А текст формируется динамически или используются параметры? Не первышается ли количество одновременно открытых курсоров на сервере (хотя это вряд ли - ошибка была бы другая вроде)?

data (2004-08-26 10:29:00) [4]
Aleksandr.
работаем с Оракл
когда приращиваю параметры в админе, то время жизни просто увеличивается пропорционально, эффект остается.

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

Aleksandr. (2004-08-25 20:41:00) [5]
ЗЫ. совет давал Rusa.

Aleksandr. (2004-08-25 20:40:00) [6]
Я тут немного ниже задавал вопрос по той же проблеме - в многопоточном приложении, где каждый поток юзает БДЕ, возникала такая трабла. И мне дали ответ, что следует прирастить параметры БДЕ-админа:
Configuration\System\INIT: MAXBUFSIZE, MAXFILEHANDLES, SHAREDMEMSIZE.
Я их прирастил - сайзы загнал по 8192, а кол-во файлов - количество потоков +1. И все заработало в ажуре.

jack128 (2004-08-25 20:20:00) [7]
data © (25.08.04 17:49) [4]
Romkin © (25.08.04 17:38) [2]
не совсем поняла вопрос:)
работаем через БДЕ.
с чем работаете? Парадокс, dbf, ib ??

data (2004-08-25 17:52:00) [8]
saNat © (25.08.04 17:41) [3]
да, вполне возможно, т.к. такое сообщение возникает при большом количестве открытых Query или курсоров. a Explorer тоже как бы что-то открывает.
Проблема в том, что я закрываю запросы, но память все равно не освобождается.

data (2004-08-25 17:49:00) [9]
Romkin © (25.08.04 17:38) [2]
не совсем поняла вопрос:)
работаем через БДЕ.
Обращения идут частые на селект всего из одной таблицы. Запрос с параметром выбирает либо одну запись, либо ничего, таблица небольшая.
Запрос на внесение новых записей идет в другую таблицу, громадную.
Еще периодически идут запросы на выборку данных не из главного треда, а из других, но там вроде все нормально сделано: отдельная сессия. Выборка там из совершенно других таблиц.

saNat (2004-08-25 17:41:00) [10]
Я сталкивался с данным сообщением при написании приложения в Delphi и запущенным SQL Explorer. После закрытия последнего можно было работать дальше без перезагрузки системы.
А SQL Explorer запускал заново
С уважением...

Romkin (2004-08-25 17:38:00) [11]
А так вы к чему обращаетесь?

data (2004-08-25 17:24:00) [12]
Да, забыла еще написать, что при работе приложения с FireBird такого эффекта нет, нормально догонялись до 2 млн. записей, все было Ок.

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »