Спасибо! Пытаемся отследить причину. У нас два провайдера — при отключении основного все проблемы пропадают (правда скорость ). Сетевые карты и драйвера абсолютно одинаковые. Может провайдер нас чем-то долбит? Как это поймать? Сами они уходят в глухую несознанку
Очень забавно — прошло само Мы сутки проработали с одним отключенным провайдером — все нормально, значит программа не виновата. Вновь его подключили и уже вторые сутки полет нормальный !
И никто память не перегружает У провайдера сменился собственник и они собирались DNS сервера обновлять, но как это может влиять на нас? Будем пока считать, что все обошлось и приглядывать. Спасибо!
DNS-сервера провайдера влиять могут, если они не работают (но тогда бы вообще ничего не работало) и если не используется встроенный в E4 DNS-сервер (он не использует провайдерский DNS).
Прошу прощения, но похоже память жрет именно acWeb! Мне не разу не удалось поймать сам момент вылета — он всегда ждет, когда я отвернусь, но приблизительный сценарий таков: Все работает, при этом память потребляется, как на первых двух картинка. Вторая — при работе с двумя провайдерами, первая — с одним. Строки отсортированы по занимаемой памяти.
Файл: описание файла 1 [3112960 bytes]
Внезапно начинает расти занимаемая acWeb память и процесс сильно жрет процессор (более 50%). Иногда при этом все приходит в норму и все работает дальше, но иногда много памяти за процессом держится долго (минуты, десятки минут) и все кончается крахом, как на каринках 3 и 4. Похоже на провайдера мы зря балон катили — просто при двух провайдерах acWeb больше памяти берет и эта бяка, исчерпание памяти просто ближе.
200-300 Мб — это для прокси нормально (жаль, на картинках нет столбца с числом потоков). При двух провайдерах в зависимости от роутинга внешние соединения могут устанавливаться дольше, тогда и требуемые ресурсы дольше висят в памяти. Вот что обязательно стоит попробовать — это отключение (лучше деинсталляция) KAV. Eserv/Eproxy всегда плохо себя чувствуют при наличии резидентных антивирусов, периодически отнимающих их рабочие файлы.
решение приватное? куда самому копать? в сторону использования памяти?
(сомневаюсь, что 15 пользователей могут "съесть" всю память на сервере только веб-серфингом). Рубрикатор не используется, что еще может влиять? реализация NTLM? Или утечка памяти при каких-то операциях, где DropBox генерирует сообщение в eproxy.log о логине/пароле None:None ?
asm пишет: сомневаюсь, что 15 пользователей могут "съесть" всю память на сервере только веб-серфингом
Я тоже сомневаюсь.
asm пишет: Или утечка памяти при каких-то операциях, где DropBox генерирует сообщение в eproxy.log о логине/пароле None:None ?
А он все еще генерирует?
Можно отключить DropBox и проверить гипотезу о том, влияет это или нет. Тем более, что это безболезненный тест: раз этот DropBox никак не может подобрать пароль к прокси , то наверное он к Сети в результате не подключен и поэтому никакой полезной работы все равно не выполняет.
вы меня спрашиваете, как будто я его разработчик в его настройках есть только 4 поля: прокси, порт, имя пользователя, пароль. Первый 2 заполнены, вторые два — нет т.е. опции использовать авторизацию или нет в настройках не предусмотрено.
P.S. сегодня опять "отвалился"... Андрей, можно попросить какую-нибудь тестовую сборку, которая при возникновении Error 8 выдало бы больше отладочной информации (может даже системной — использование памяти, количество потоков, что-то для контроля утечек, дабы локализовать проблему)
Да, я уже начал пересмотр NTLM-части с пристрастием насчет утечек, тем более что сегодня получил лог падения еще одной установки (Eproxy/5) тоже с ошибкой 8 и активным использованием NTLM.
Нет, дело все-таки не в NTLM — и по исходникам всё перепроверил, и стресс-тесты в режиме NTLM гоняю уже несколько часов, больше 100 мег не могу разогнать ему потребление памяти.
Наверное надо пробовать (у вас) отключать компоненты Eproxy, может быть какие-то правила ACL, будет ли это влиять.
Единственное, что не испытал в NTLM, так это "неправильную авторизацию" — т.к. тестовая программа для HTTP использовала функции windows, то NTLM связывался прозрачно, всегда с правильными паролями. Но не думаю, что это может влиять на утечки — процедура очистки использованных хэндлов авторизации ведётся в конце соединения в любом случае.
компоненты особо и не используюься, ни DNS, ни рубрикатор, ни TCP/UDP-MAP, статистика (SessDB отключена), только ACL, но там все просто (см. скрин), может, конечно, проверка по маскам, но думаю, что это еще в 3-ке всплыло бы..
опять за ночь "отвалилися" (теперь без Error 8, а просто перестал принимать соединения), а при попытке остановить вывалил несколько исключений. лог eproxy отравил по почте жду тестовую сборку для локализации
При увеличении загрузки (у нас это бывает в обед и в конце рабочего дня) вываливается acWeb c Error 8. Нормальное количество потоков -200-300. Прилагаю файл с скриншотом в момент аварии и кусок лога.
Файл: укажите описание файла 1 [103424 bytes]
Тогда, если возможно, пришлите фрагмент лога acWEB.log от момента запуска (строка "...started...") и до первой записи "Error:8" — на support@eserv.ru. Памяти на машине сколько? Странно, что ей (Windows) становится мало при отъёме 400М. Может подкачку увеличить попробовать...
А ситуация (в присланном логе) напоминает вашу по двум параметрам: 1) использование NTLM, 2) наличие суперактивных локальных клиентов (в этом логе — по 20 запросов в секунду; причем от заблокированных пользователей).
Вот с этим DoS'ером надо разобраться
и с pas07 c .3.97. Это точно не браузеры, пользователи не могут вводить пароли так быстро.
NTLM проверил вдоль и поперёк, утечек нет, Windows (или LAN) просто не справляется с таким напором на NTLM.
И таймаутов работы с рубрикатором (запросы по отсутствующим хостам) очень много, а это тоже тормозит потоки. (После отключения рубрикатора надо перезапускать Eserv).
Это как? Что при этом в HTTP-PROXY логе про эти сайты? Рубрикатор к WeakNtlm отношения не имеет (разве что если перестала работать авторизация вообще, и соответственно стали срабатывать иные ACL?)
Сам обалдел, но было очень некогда. Завтра с утра все аккуратно подчищу (логи) и повторю. А то сегодня налетели юзвери, а были другие тяжелые проблемы.
У меня с вашим OnStartup запустился. Вы запускаете "acWEB/4.31, build 31579, 25.02.2012", а надо запускать именно вчерашнюю сборку acWEB4 (по ссылке выше (06.02.2013 13:54)).
Сайты блокируются по категории БИЗНЕС, а мы не запрещаем бизнеса
И еще одно наблюдение — резко меньше жрет памяти и процессора acWEB, но заметно больше — acFilter
Зело велик, потому вопрос: какие именно (например) сайты из лога неправильно блокируются новым acWEB'ом и правильно не-блокируются старым. Может, наоборот, новый точнее выполняет указания ACL, надо разобраться...
2013-02-07 12:46:47; 192.168.3.78;21939;0;1;297;PW23@lenmetro.ru (0,196,lmgt_users/PAPR,[],_55(0)) ADV_BLOCK/200 463 GET http://vts.com/ DIRECT/ text/html; charset=windows-1251 0 21939 21939 Basic(PW23) 1558;1538;0;0 0;Business: Telecommunications: Location and Tracking: Vehicle;(PW23@lenmetro.ru,16995941);Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.57 Safari/537.17
и еще:
2013-02-07 12:47:00; 192.168.3.190;22066;0;1;31;PW05@lenmetro.ru (0,103,lmgt_users/PAPR,[],_55(0)) ADV_BLOCK/200 676 GET http://www1.systemair.com/ DIRECT/ text/html; charset=windows-1251 0 22066 22066 Basic(PW05) 42250;51625;0;0 0;World: Deutsch: Wirtschaft: Bauwesen: Bauausfuhrung und Installation: Technische Gebaudeausrustung: Heizungs- und Klimatechnik; Regional: Europe: United Kingdom: Business and Economy: Construction and Maintenance: Materials and Supplies: Me;(PW05@lenmetro.ru,293221803);Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.57 Safari/537.17
55 правило — запрет для роли PAPR всех ресурсов (*) с 20:00 до 6:00
для старой программы лог:
2013-02-07 15:30:08; 192.168.3.78;8012;0;6;93;PW23@lenmetro.ru (0,196,lmgt_users/PAPR,[],) TCP_MISS/404 1646 GET http://www1.systemair.com/favicon.ico DIRECT/217.114.80.121 text/html; 0 77.232.61.72 8012 8012 Basic(PW23) 17698;46032;41451;774763 0;World: Deutsch: Wirtschaft: Bauwesen: Bauausfuhrung und Installation: Technische Gebaudeausrustung: Heizungs- und Klimatechnik; Regional: Europe: United Kingdom: Business and Economy: Construction and Maintenance: Materials and Supplies: Me;(PW23@lenmetro.ru,18669141);Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.57 Safari/537.17
Значит дело в изменениях обработки ACL между версиями... Можно также получить на support@ ваши CONF\lists\directory*.* (архивом)? Пароли там не хранятся, только хэши, поэтому пересылка не опасна.
Возник один интересный вопрос.
Модуль acFilter осуществляет проверку на вирусы только почты или и http-траффика тоже?
Судя по логам log\antivirus там происходит активное копание в data\cache. И при этом acFilter отъедает около 50% ресурсов ЦП.
А надо ли оно вообще при условии, что на каждой рабочей станции функционирует веб-антивирус?
Да, антивирус проверяет и почту, и трафик прокси. Если на всех клиентских машинах есть антивирус, которому вы доверяете, то на сервере антивирус можно отключить.
Нет, при таком количестве потоков — не нормально. Если используется одна из последних сборок acWEB (по теме выше), то в acWEB.log должна быть диагностика по потреблению памяти, пришлите его на support@eserv.ru пожалуйста (вырезка с момента последнего запуска, архивом; или при следующем перезапуске удалите предварительно старый лог, а потом пришлите, что накопилось).
Не безнадежно, но долго, менеджер памяти и потоков перерабатываю — это нужно еще для EAS и для TCPMAP, поэтому неизбежно... Но текучка отвлекает сильно. Позавчера у одного клиента обнаружилась проблема с безопасностью в E4, исправили срочной заплаткой, так что теперь требуется внеочередное обновление выпустить (проблема не воспроизвелась больше ни на одной машине, но на всякий случай надо всем залатать), а для этого еще и кэш переработать.