Столкнулся с проблемой. что есть: eserv 2.99 (3517), win2k sp4.
Что происходит: за сутки виртуальная память занимаемая eserv возрастает на 45 Mb, за две недели она заканчивается.
Вопрос: Где искать?
|
Столкнулся с проблемой. что есть: eserv 2.99 (3517), win2k sp4.
Что происходит: за сутки виртуальная память занимаемая eserv возрастает на 45 Mb, за две недели она заканчивается. Вопрос: Где искать?  
| ||||
Имеется ввиду это:
Я думаю Eserv не закрывает порты. Т.к например ночью активности нет. При работе Eserv, outpost выключен всегда.
С уважением жду ответа.
Это чистое. Или просто свежезапущенный?
Если нет зависших потоков, то и порты дожны быть закрыты. Может, Outpost, даром что выключен (резидент-то продолжает болтаться), удерживает их?
С списке процессов outposta нет. Для чистоты эксперимента удалить outpost?
С уважением.
У меня была (и есть) аналогичная ситуация ...
Разобраться не удалось.
Пришлось в планировщик задач винды прописать ежедневное задание на ночной перезапуск есерв.
Но вылезла другая проблема: если кто-то получает почту по медленному каналу (gprs, dialup) и в это время происходит перезапуск ЕСЕРВа, то сообщения в ящике этого пользователя теряются (в логах комманд клиента на удаление писем тоже нет).
Вот по этому я и перестал, перезапускать Eserv.
ОФФ: Наблюдаю за Eserv, после удаления outpost. через 3 дня сообщу.
Да вроде в килобайтах.
А как его написать, чтобы обязательно помогли?
Ведь тема в форуме уже поднималась ранее.
В противном случае зачем беспокоить товарищей у них и без меня забот хватает.
Включу планировщик и все будет как последние 3 года.
136мег при всего 16 потоках — это, конечно, много. Надо разобраться.
"Чтобы обязательно помогли" нужно прислать для начала Eserv.ini, список plugin'ов (если есть), текущий log\*eserv.log. Информацию о "внештатных" (не-MS) резидентах — firewall'ах, антивирусах.
Отчет по портам надо делать netstat'ом, а не аутпостом. И желательно не скриншотить netstat, а переправлять в файл (тогда над отчетом можно делать действия, в частности сортировать и фильтровать). А вот отчет по памяти, потокам и хэндлам — лучше скриншот taskmgr чем отчет pslist (в pslist баги). У Руссиновича есть другой полезный инструмент — ProcessExplorer, он в частности может рассказать, куда уходят хэндлы (но не надо его скриншотить, он в файл умеет сохранять).
Куда писать?
- антивирус КАВ
- незакрытые порты
Подробнее:КАВ, проверяя почту периодически валит есерв.При этом пишется e.log c упоминанием оного...Для локализации трабла почтовую часть Есерва заглушил (временно).
После 2-3 дней работы http-прокси процесс есерва начинает весить около 200МБайт...Кол-во хендлов увеличивается до 2500-3000.Болтается множество незакрытых TCP соединений в состоянии TIME_WAIT (очень много с s1.mail.ru).Пронаблюдал еще онин интересный момент: когда я поднял приоритет процесса eserv.exe с 10 до 13 (process explorer-ом) количество отъедаемой памяти резко снизилось (с 197 до 103Мб).
Если у кого наблюдается что-то схожее, плз, опишите!На скриншоте, который вы support прислали — с s1.mail.ru не TIME_WAIT, а CLOSE_WAIT, описанный выше.
Почему потверждения на закрытия фильтруются firewall'ом?
Они же приходят на порты открытые ЕСЕРВОМ... А ЕСЕРВ.ЕКЗЕ файерволом не прикрывается СОВСЕМ (стоит в исключениях).
Есть IMHO только один вариант — есерв сам закрывает эти порты раньше времени (или закрывает совсем не те порты, что должен
И тогда ответы, идущие в никуда, фильтруются FW.
Потому что вы его так настроили, судя по логу firewall'а.
Впрочем, в этом случае более вероятны ошибки 10060 (таймаут), а не 10054.
> Они же приходят на порты открытые ЕСЕРВОМ... А ЕСЕРВ.ЕКЗЕ
> файерволом не прикрывается СОВСЕМ (стоит в исключениях).
Лог, который вы привели — от встроенного в Windows пакетного фильтра, он не обращает внимания на исключения EXE, которые появились только в прикладном Windows Firewall в SP2.
> Есть IMHO только один вариант — есерв сам закрывает эти порты
>раньше времени (или закрывает совсем не те порты, что должен,
> что объясняет 10054 в логах).
Если Eserv сам закрывает сокет, то никаких 10054 в логе никак не появится, т.к. уже несуществуюший сокет может дать только ошибку "6" — "нет такого хэндла". 10054 обозначает буквально следующее "Удаленный хост принудительно разорвал существующее подключение" (из официальной расшифровки, выдаваемой Windows).
Это не так чтобы реальная проблема (любой из сторон) — это означает, что не было взаимосогласованного чистого закрытия (graceful close в терминологии сокетов), а было "ускоренное" закрытие (в данной случае не Eserv'ом, а второй стороной или firewall'ом).
А вот тут вы ошибаетесь.
Лог от Windows Firewall, встроенного в Windows Server 2003 SP2 и исключения он отрабатывает нормально...
И Есерв опять упал, переев памяти...
При запуске test_proxy.exe по умолчанию работает через прокси localhost 3128 и обращается к URL
Можно менять опциями ком.строки:
-s имя_машины_с_прокси_сервером
-p порт_прокси_сервера
-url
Запустите, пожалуйста, и сообщите, какие числа тест выведет в конце выполнения (последние пару строк) и приведите скриншоты taskmgr про потребление ресурсов Eserv до и после теста (в taskmgr в меню 'выбор столбцов' выберите счетчики хэндлов, потоков, памяти).
Да, лог в нем такой же. Но значит исключения на тот момент не обрабатывались. Ведь в приведенном вами логе информация о блокировке доступа к сайтам.
Выдал:
Скриншот диспетчера задач в суппорте.
Тест не отработал из-за включенной авторизации.
Результат второго прогона:
Есерв во время прогона заткнулся...
Его работа восстановилась после закрытия окна программы test_proxy
Тут нужно искать-читать доку к process explorer-у... В хелпе подробности понятия Virtual Size не расписан.
И что такое Page Faults и Page Fault Delta?
Извиняюсь да пропал.
Все таки интересно чем это закончится.
При отключении кэширования "рост" виртуальной памяти прекращается и Eserv не "слетает".
Их нет.
При включенном кэшировании и росте потребления памяти — растет ли число потоков и хэндлов процесса Eserv (посмотреть можно в taskmgr) и число активных соединений (посмотреть можно в netstat).
Ясно. Помониторю недельку. Доложу.
Память: 8200 кб
Вирт. память: 7552 кб
Дескрипторы: 1209
Потоки: 17
После включения кэширования:
Память: 6500 кб
Вирт. память: 5800 кб
Дескрипторы: 150
Потоки: 19
через сутки
Память: 80900 кб
Вирт. память: 82900 кб
Дескрипторы: 1100
Потоки: 18
через двое суток Eserv вылетает. далее через 2 суток:
Память: 73844 кб
Вирт. память: 94500 кб
Дескрипторы: 6236
Потоки: 22
Вот такая ситуация.
Добавлю: через 13 суток без кэширования:
Память: 20600 кб
Вирт. память: 21500 кб
Дескрипторы: 18500
Потоки: 62
Притом что в Eserv/2 allocate- редкое явление. Надо будет потрассировать немного, выдам тестовую версию.
Плз, напишите номер билда, в котором будете бороться с обсуждаемой бедой.
Готов проделать test_proxy.
Но лучше и проще запустить тестовый комплект, который я сейчас подготовил: