Mon, 28 Jan 2008 08:54:14 +0800 MaxThreads reached (server)!
Mon, 28 Jan 2008 08:54:15 +0800 MaxThreads reached (server)!
Mon, 28 Jan 2008 08:54:15 +0800 MaxThreads reached (server)!
Mon, 28 Jan 2008 08:54:16 +0800 MaxThreads reached (server)!
Mon, 28 Jan 2008 08:54:16 +0800 MaxThreads reached (server)!
Mon, 28 Jan 2008 08:54:17 +0800 MaxThreads reached (server)!
Mon, 28 Jan 2008 08:54:17 +0800 MaxThreads reached (server)!
Mon, 28 Jan 2008 08:54:18 +0800 MaxThreads reached (server)!
Mon, 28 Jan 2008 08:54:19 +0800 MaxThreads reached (server)!
Mon, 28 Jan 2008 08:54:19 +0800 MaxThreads reached (server)!
Mon, 28 Jan 2008 08:54:20 +0800 MaxThreads reached (server)!
Mon, 28 Jan 2008 08:54:20 +0800 MaxThreads reached (server)!
Mon, 28 Jan 2008 08:54:21 +0800 MaxThreads reached (server)!
Mon, 28 Jan 2008 08:54:21 +0800 MaxThreads reached (server)!
Mon, 28 Jan 2008 08:54:22 +0800 MaxThreads reached (server)!
Mon, 28 Jan 2008 08:54:22 +0800 MaxThreads reached (server)!
Mon, 28 Jan 2008 08:54:23 +0800 MaxThreads reached (server)!
Mon, 28 Jan 2008 08:54:23 +0800 MaxThreads reached (server)!
Вот... При этом процесс acSMTP грузит процессор на 100% . Почта при этом не идет.
Такая петрушка продолжается до рестарта сервиса acSMTP вручную.
Началось все пятницу вечером, когда меня уже не было на работе, я в понедельник утром рестартил службу, посмотрел в лог acSMTP.log, а там такие строки каждую секнуду, если не чаще.
Это превышение количества подключений к серверу? Лимит был 100, сделал 500, то же самое. Если это редиски мучают сервер то как их отловить с целью сунуть IP в файревол?
P.S. до пятницы сервер работал без вмешательств уже с пол года как...
MaxConnectionsFromIP=3
MaxConnections=30
теперь такого в логе нет... просто тупо 100% процессора занято процессом acSMTP
однако сервис иногда все же "западает" со 100% загрузкой процессора
Версия Есерва обновлена до последней... может глюк разработчиков ?
В любом случае хзотелось бы как то решить проблему...
Файрволы — используются стандартный Микрософтовский, про есерв он знает и ему велено есерв пропускать без вопросов...
Используется NAT32, НО он успешно использовался до этого более полугода и при этом никаких проблем не вызывал...
Настройки не меняли соответственно непонятно с чег бы это вдруг вопрос может быть в файрволах и НАТе...
Это типа принятые письма ждут обработку... вопрос в том что совпадает время начала проблем и время когда начались копиться письма в спуле... т.е. проблема ЯВНО не в файрволе\НАТе...
Какая то херь происходит в самом Есерве...
И хотелось бы наконец услышать хоть что нибудь от разработчиков... хоть какие то коментарии...
эххх.... говорил шефу, надо ставить на почту линукс
Что за NAT32?
В NAT/firewall дело может быть "с чего-то вдруг", если просто нагрузка на сервер больше обычной. И в firewall'е не хватило размеров таблиц, или я не знаю что там у них переполняется, но что Outpost, ZoneAlarm и другие fw могут вызывать проблемы — выявлялось неоднократно за последние годы.
Еще проверьте, что никакой резидентный антивирус не сидит на папках Eserv (надо их исключить из проверок, и вообще антивирус в таком режиме на сервере — зло).
у меня такой бяки там отродясь не было
symbols качать долго... да и за 240 мег трафика шеф не похвалит
P.S. eserv 333 windows 2003srv std sp1
Загляните в acSMTP.log. Если там есть записи про EXCEPTION, то это херь в Eserv'е (лог в студию, точнее на support@eserv.ru). А вот если там записи про невозможность удалить файлы в спуле или еще что-то в этом роде, то причины явно внешние. Антивирусы очень любят так хулиганить.
spool — каталог, в котором лежат те файлы, которые _в данный момент_ принимаются сервером. Т.е. их в норме не больше, чем потоков в acSMTP. Если больше — ищем проблемы в логе, что-то мешает обработке.
NAT32 это собственно программка такая... обеспечивает использование NAT на конкретном компе... у меня используется для шлюзования банк-клиента из локальной сети наружу...
Больше она ничего делать не может...
Антивирус на сервере резидентом не сидит.
в любом случае все вышенаписанное не объясняет почему в папке SPOOL начинают скапливаться письма...
Фишка в том, что в acSMTP.log сечас вообще ничего нового не отображается — типа стартовал учпешно, все замечательно... и тишина...
Значит, явных ошибок нет. Надо смотреть другие логи, которые в DATA\log\smtp
Антивирус объяснил бы легко
Собственно размножение файлов в спуле не создает нагрузочной проблемы для Eserv/3 (в отличие от Eserv/2), т.к. он их там никогда не перебирает. Т.е. в момент приема письма поток создает там файл с гарантировано уникальным именем, пишет туда письмо, а после обработки удаляет, и всё.
Эти файлы в spool'е можно пробовать удалять без останова acSMTP. Те, что он сейчас принимает, он удалить не даст. А остальные удалять безопасно — если они остались в спуле, значит сессия прервалась на стадии DATA или сразу после приема — еще до того момента, когда Eserv ответил отправителю "ОК, письмо принято". Значит письмо осталось у отправителя, и он будет продолжать попытки.
Так. Если в acSMTP.log пусто, то давайте заглянем в DATA\log\smtp\200801log.txt — на чем останавливаются сессии?
БД-архивирование (новая опция UseDbArc) включено или выключено? Какие включены другие plugin'ы, отключенные в штатном конфиге?
Еще посмотрите по логу DATA\log\smtp\200801mail.txt и в loop — не зацикливается ли у вас какая почта? (неверной настройкой алиасов, форвардинга) Eserv считает хопы и прерывает зацикливание, но если писем много, и каждое из них крутится до MaxReceivedCnt, то это тоже может создавать лишнюю нагрузку.
штуки четыре
я вот подумал... а не доктор ли веб ли это? открыл... проверил... но не закрыл?
- отключил доктора, жду*
P.S. из spool файлы удалились сразу после убийства тредаВсе замечательно в этом файле ошибок нет...
БД-архивирование = 0
Используется POPFile как антиспам.
И RBL-ы используются...
О ! нашел: в файле 200801smtpsend.txt
...
Какие ответы дает Eserv на команду DATA?
Какие?
Это не может блокировать почтовик. Это исходящая очередь, которую даже не acSMTP обрабатывает, а smtpsend4. Если в mail/out писем не много, то и нагрузки заметной это не создаст. Письмо <479EF547.9090704@bpmes.debryansk.ru> либо удалите, либо исправьте там (в For
250-AUTH PLAIN LOGIN
250-AUTH=LOGIN
250-STARTTLS
250-SIZE 45000000
250-ETRN
250-8bitmime
250-BINARYMIME
250 HELP
UseOrdbRbl = 1
UseMapsRbl = 1
UseRBLList = 1
Maps и Ordb отключите, они давно не работают!
Этот лог сделан до конца файла — ниже ничего нет...
Мапс и ОрДБ отключил...
Теперь наверное уже есть. Поищите по IP.
Да. После получения письма SMTP-сервером он выполняет антивирусные и антиспам-проверки, прочие обработки контента (DbArc, если включен, и т.д.), потом говорит "принято", и отправитель отключается. Вот что-то где-то у вас на этом этапе затыкается. PopFile отрабатывает нормально?
А попробуйте все-таки отключить временно свой NAT32. Если он только "для шлюзования банк-клиента", то наверное без него можно пережить час-другой?
Вроде да — вполне себе отбивает спам... в логах вроде ошибок нет...
2008/1/28 11:42:20 1864: bayes: 708: Attempting to connect to dbi:SQLite:Dbname=./popfile.db (1)
2008/1/28 11:42:20 1864: bayes: 714: Using SQLite library version 2.8.5
2008/1/28 11:42:22 1864: WARNING: Couldn't open POPFile packing list (./popfile.pck) so cannot check configuration[0a]
что бы это могло быть ?
По поводу DNS — а встречаются ли в логе отлупы по причине несуществующих доменов?
Отследить задержки в DNS можно, включив (раскомментировав) команду "DnsDebug ON" в acSMTP\conf\OnStartup.rules.txt и перезапустив acSMTP.
И с отключением NAT32 надо попробовать — хотя бы после рабочего дня. Влияет ли это на зависание процессов отправки по SMTP.
Включил ДНС дебаг...
НАТ32 отключил...
Завтра с утра проверю что получится...
P.S. вчера вечером отключил доктора веба... утром прихожу... а сервер не висит
DATA\mail\spool\ теперь пуст, не засоряется
по моему предположению он (доктор веб) после проверки файлы писем не отпускал, Eserv же такое очень сильно не любит?
После отключения всего чего только можно включая NAT32 — повисания прекратились... НО Спул вчерась засирался до 17:05... после чего засирания прекратились...
Сечас все нормально несмотря на то что NAT32 с утра включен...
Подозрительно выглядит расхождение статистики ПроксиИнспектора по SMTP и провайдерской статистики за день...
Провайдер утверждает что за день прошло чуть меньше 800 мегов, а Прокси Инспектор — ~500... видимо разница за счет не до конца принятых писем...
И еще — я тут вчерась сделал подмену плугина DrWebа обычным, новым (4.44) файлом и базой — все работает
таки не поленился я снести там винду
объясняю:
Стоял к Есерву плагин др-веба с лицензионным ключом. т.к. плагин версии 4.33, мне захотелось проверить (раз уж всеравно ковыряюсь с есервом) что будет если заменить базы антивируса-плагина и файл "drweb32w.exe" (все это в каталоге eserv3\antivirus\drweb\) файлами от версии DrWeb 4.44 т.е. я взял файлы с другой машины где стоял дрвеб 4.44 и переписал их вместо плагина. Так понятно ?
Что самое прикольно антивирь в таком варианте — работает
А вообще плагин (то есть, не плагин, а рантайм антивируса с настроенным обновлением) лежит отдельно:
NAT32 — включен. Все настройки вернул взад. Работает.
Вобщем не понимаю нихрена — все настройки как и были, но при этом три дня глючило, а сечас — все Ок.
Хотя с другой стороны до этого вообще пару лет без глюков работало...
Ага. Щазззз.
Хрен там — в последней сборке Есерва плагин drWeb-а был 4.33
Я когда качал\ставил = убедился...
Может и лежит... только с веб страницы есерва он недоступен — там по прежнему ссылка на 4.33...
В Eserv/3.33 Dr.WEB/4.44, сейчас проверил.
Ссылку поправил.
Вот что сделал:
Поставил:
TarpitDelay 1000
MaxConnections 350
ListenQLen: 2000 в OnStartup.rules.txt(по совету ac) убрал firewall zonealarm
Больше месяца без проблем.
Очень правильное слово, firewall'ы надо убивать. Деинсталлировать. А то они даже в отключенном (не фильтрующем) состоянии умудряются сидеть на канале и мешать нормальной работе.
DrWebPromptOn4 DrWebPromptOn4 DrWebPromptOn4 DrWebPromptOn4
Thu, 13 Mar 2008 00:27:21 +0300 MaxThreads reached (server)!
Треады прут до бесконечности...
Спул засран...
Настройки не менялись — все как обычно — глюк вылезает с периодичностью раз в 2 недели...
в data\log\antivirus\200803av-r.txt:
Еще по поводу "MaxThreads reached (server)!" — убедитесь, что у вас из RBL включен только CBL, т.к. все остальные, которые когда-либо были включены в Eserv по умолчанию, уже не функционируют.
У ClamAV, к сожалению, своих проблем больше, чем у DrWEB.
Я так и понял, что ДрВеб чсто то пытается сказать... но ЧТО и ПОЧЕМУ ?
RBL проверил — был включен CWHOIS (combined-hib.dnsiplists.completewhois.com) — отключил.
Все остальное — отключено...
DrWeb сечас отключил — вроде все работает... но я ж говорю проблема всплывает раз в две недели... причем проходит тоже сама... как правило на след. день...