//
// MessageId: ERROR_NO_SYSTEM_RESOURCES
//
// MessageText:
//
// Insufficient system resources exist to complete the requested service.
//
#define ERROR_NO_SYSTEM_RESOURCES 1450L
Это код ошибки Windows. Поскольку перезагрузка не спасает, я бы посоветовал посетить http://helpme.virusinfo.info/ — не исключено, что завёлся зверь. Впрочем, мешать может и резидентный антивирус.
Ещё, конечно, можно в порядке бреда открыть CommonPlugins\log.str.txt и посмотреть, в каком там состоянии строка с кодом 701. Потому что, например, друая форматная строка лога нормально отработала.
1450 = "Недостаточно системных ресурсов для завершения операции."
Жаль, что не говорится, каких именно ресурсов... Памяти в системе хватает? Еще можно посмотреть, не поврежден ли CommonPlugins\log.str.txt — если повреждены шаблоны, то Eserv может ошибочно запросить у системы столько памяти, что ни у кого не хватит.
Было 86 файлов — 4 ГБ, убирал часть — не помогало. Убрал текущий лог — 200808log.txt (804Mb) — ошибка пропала, новый лог 200808log.txt начал заполняться данными, письма, вроде, начали ходить.
Неужели размер лога может оказать влияние на работу?
Сейчас SMTP потребляет около 15Мб, порядка 30 потоков, письма ходят нормально, в логе ошибок нет.
Спасибо за то, что оперативно наставили на путь истинный.
alex1124 пишет: Неужели размер лога может оказать влияние на работу?
Стресс-тест на предмет максимального размера лога мне пока не приходило в голову запустить. Запустил (для чистоты эксперимента цикл по тем же "701 LOG" в отдельном потоке acSMTP). Пока что он успел заполнить 14Мб, так что результата ждать еще долго.
Чисто теоретически лимит должен быть никак не раньше 2Gb (и то если это fat), а никак не 804Mb. Все манипуляции с размером файла внутри функций по записи в лог вообще 64-битные (FILE-SIZE и REPOSITION-SIZE), т.е. там и 4Gb лимит (32бита) не преграда.
По данным http://support.microsoft.com/kb/304101 эта ошибка о нехватке Paged kernel memory, т.е. глубоко системные вещи, которые можно пытаться настраивать через реестр.
Диск под NTFS, с Microsoft-ом буду сейчас смотреть. Но, до вчерашнего вечера все работало как надо. Правда и лог не достигал такого размера (если быть точным, то 804 437 502).
Отчитываюсь: многопоточный стресс-тест по записи лога DATA\log\smtp\200808log.txt через 701 LOG успешно миновал магическую отметку 804 437 502 и сейчас находится в районе 869 694 520. Никаких ошибок в acSMTP.log не появилось, в отчетах taskmgr по памяти ядра тоже без заметных изменений. В общем, дело не в размере файла, а в какой-то конкретной комбинации условий. Может это зависит и от версии ОС. Я сейчас тестировал под Vista.
Кто нибудь решил эту проблему?В третий раз за последние полгода с этим сталкиваюсь. Размер папки 966.881.380 в 9 файлах,лог mail 772mb(помогает только удаление).Видимо это проблема в файловой системы NTFS W2K.Может кто подскажет,где поправить в реестре.Очень похоже(типа) на ограничения открывания окон в висте(http://weblogs.asp.net/israelio/archive/2007/02/07/max-num-of-open-windows-under-xp-2003-vista-resolved.aspx),а здесь резмера txt файлов ,даже не знаю ,как правильно запрос составить но проблема в w2k c размером логов eserv3 реально есть.IMHO.
Файловую систему на ошибки проверять не пробовали? Сколько оперативной памяти на машине? Можно по Диспетчеру задач посмотреть (на закладке Быстродействие), сколько там какой памяти занято, вдруг наведёт на мысль.
2xeon,4г памяти,смотрел память "procexp",все ok!
Единнственно возникает мысль,может из-за того что включил плагины mlogs,cashe_log_str и mstat.Как вы думаете?
Хотя вряд-ли,эта тема уже старенькая,а тогда еще включение этих плагинов не обсуждалась.
И еще файл log.txt,извините за не точность.
cache_log_str точно ни при чём. mlogc влияет однозначно — это он разбрасывает вывод по разным файлам, что инициирует постоянное дёргание последовательности открытие-позиционирование-запись-закрытие. mstat может влиять, а может и не влиять. Скорее, всё же, не влияет: протокольный лог через MStat не идёт.
На каких кодах строк падает?
Это код ошибки Windows. Поскольку перезагрузка не спасает, я бы посоветовал посетить http://helpme.virusinfo.info/ — не исключено, что завёлся зверь. Впрочем, мешать может и резидентный антивирус.
Ещё, конечно, можно в порядке бреда открыть CommonPlugins\log.str.txt и посмотреть, в каком там состоянии строка с кодом 701. Потому что, например, друая форматная строка лога нормально отработала.
Log.Str.txt
А какое у вас значение MaxConnections в секции [SMTP]?
Жаль, что не говорится, каких именно ресурсов... Памяти в системе хватает? Еще можно посмотреть, не поврежден ли CommonPlugins\log.str.txt — если повреждены шаблоны, то Eserv может ошибочно запросить у системы столько памяти, что ни у кого не хватит.
Неужели размер лога может оказать влияние на работу?
Спасибо за то, что оперативно наставили на путь истинный.
Чисто теоретически лимит должен быть никак не раньше 2Gb (и то если это fat), а никак не 804Mb. Все манипуляции с размером файла внутри функций по записи в лог вообще 64-битные (FILE-SIZE и REPOSITION-SIZE), т.е. там и 4Gb лимит (32бита) не преграда.
Размер лога 882 024 292, тест прекращаю.
Единнственно возникает мысль,может из-за того что включил плагины mlogs,cashe_log_str и mstat.Как вы думаете?
Хотя вряд-ли,эта тема уже старенькая,а тогда еще включение этих плагинов не обсуждалась.
И еще файл log.txt,извините за не точность.
На каких кодах строк падает?