Ошибка "out of memory"

[Rest_Tremor]

Доброго времени суток, уважаемые форумчане!

Очень надеюсь на вашу помощь! Постараюсь поподробнее описать суть проблемы.
Есть программа, которая работает через СМС-центр и занимается отправкой сообщений абонентам. Написана на TurboDelphi. В общем-то она работает, но проблема в следующем. Пик активности отправок СМС приходится на 3 число каждого месяца с 21 до 22 часов. В это время довольно часто вываливаются ошибки следующего плана: "Thread creation error: недостаточно памяти для обработки команды". Сначала грешили на ошибки в коде самой проги, но ведь она в другое время работает. Облазив кучу форумов, выяснил что такая ошибка вываливается когда "выедается" вся память и оперативная и виртуальная. Пошел по самому простому пути, поставил утилиту-оптимизатор RamRUSH, которая высвобождает оперативу в случае размера ОЗУ 8% от общего объема. Протестили 3 числа, ошибок нет, толька watchdod пару раз ее ребутнул. Вопросы следующие:
1. Может ли быть проблема в железе? В смысле не справляется с нагрузкой(celeron 2 GHz, 256 RAM, файл подкачки 618 Mb)
2. Имеет ли смысл увеличить файл подкачки до 1024 метров?
3. Стоит ли втыкать еще оперативку? (комп используется не как серв, а как рабочая станция)
4. Есть ли добротная утилита, которая в щадящем режиме, безопасно высвобождает оперативу и виртуальную память?
Если нужно ответить на возникающие вопросы - я готов! Спасибо!

[FaTaL]

Да поставь оперативу гига на 2 и будет тебе счастье.

[Rest_Tremor]

Сообщение от FaTaL

Да поставь оперативу гига на 2 и будет тебе счастье.

Дело в том что оперативка вся не выедается. Может ли быть ошибка в самой проге? Или все-таки это бальное забивание памяти?

[s-andriano]

Сообщение от Rest_Tremor

Есть программа, которая работает через СМС-центр и занимается отправкой сообщений абонентам. Написана на TurboDelphi. В общем-то она работает, но проблема в следующем. Пик активности отправок СМС приходится на 3 число каждого месяца с 21 до 22 часов.

Видимо, это время начисления зарплаты или пенсии.

В это время довольно часто вываливаются ошибки следующего плана: "Thread creation error: недостаточно памяти для обработки команды". Сначала грешили на ошибки в коде самой проги, но ведь она в другое время работает.

Прогу можно считать ралбочей, только если она работает всегда. Работа "иногда" о работоспособности не свидетельствует.

Облазив кучу форумов, выяснил что такая ошибка вываливается когда "выедается" вся память и оперативная и виртуальная. Пошел по самому простому пути, поставил утилиту-оптимизатор RamRUSH, которая высвобождает оперативу в случае размера ОЗУ 8% от общего объема. Протестили 3 числа, ошибок нет, толька watchdod пару раз ее ребутнул.

Предварительное замечание:
В свое время писал утилиту, выявляющую зависимость производительности от количества потоков.
Обнаружил интересный эффект:
При создании потоков средствами Delphi проблемы начинаются уже в районе 256 потоков.
При создании потоков средствами WinAPI легко (правда, с некоторой потерей производительности) удавалось создавать по 4096 потоков. Больше - не пробовал.

Это к тому, где следует искать резервы.

Вопросы следующие:
1. Может ли быть проблема в железе? В смысле не справляется с нагрузкой(celeron 2 GHz, 256 RAM, файл подкачки 618 Mb)
...

Указание этих характеристик без указания количества потоков при пиковой нагрузке и количестве выделяемой под каждый поток памяти абсолютно неинформативно.
Можно выдать оценку по ситуации "известен объем работы и известна производительность железа", но невозможно - "объем работы неизвестен, производительность железа известна".

[Sciv]

Имеет ли смысл увеличить файл подкачки до 1024 метров?

Файл подкачки имеет смысл увеличить до половины общего размера оперативы. И установить не диапазон, а фиксированный размер.

[s-andriano]

Сообщение от Sciv

Файл подкачки имеет смысл увеличить до половины общего размера оперативы.

До половины?
Раньше, вроде, считалось, что должен быть в 3-4 раза больше.

И установить не диапазон, а фиксированный размер.

Ну а фиксированный с точки зрения скорости доступа, конечно, лучше. Хотя, для NTFS, думаю, не очень актуально.

[eoln]

Самый простой способ избежать этого (или по крайней мере запустить больше потоков) уменьшить размер стека в опциях проекта. Ну и естественно слишком уменьшать не стоит, иначе локальные данные не поместятся. И конечно при создании потока надо проверять доступность памяти, если создать поток пока нельзя, то ждём-с.
Но стоит также подумать о простом ограничении количества потоков, иногда многопоточность сильно снижает скорость работы программы (особенно при частых синхронизациях).

[Sciv]

До половины?
Раньше, вроде, считалось, что должен быть в 3-4 раза больше.

Ну да, ошибся. До полутора размеров оперативы

Однако больше чем 4096 его не выставить

[Rest_Tremor]

Сообщение от eoln

Самый простой способ избежать этого (или по крайней мере запустить больше потоков) уменьшить размер стека в опциях проекта.

Подскажите, пожалуйста, как это сделать. Какой выставить размер стека?

[eoln]

В свойствах проекта, меню Project-Options - там есть что-то в виде Maximum Stack Size (в зависимости от версии IDE). Выставляем там число по-меньше, что позволяет запустить больше потоков.
Но это полумера и от очень большого кол-ва потоков не спасёт, нужно обязательно(!!!) проверять доступность памяти перед создание нового потока, пусть даже тем же самым try... except... end
Какой размер выставить не скажу, это индивидуально для каждого проекта и зависит от размера локальных переменных. Возможно, хватит 300-400 кБ