По сравнению с Е2 скорость меньше раза в 2 (по разным спидометрам интернета) на одной машине. И в соединениях прокси HTTP(S) все время увеличивается кол-во "CLOSE_WAIT". После перезапуска acWeb на некоторое время все налаживается. А скорость, измеренная на самом прокси раза в 1,5-2 больше, чем в сети.
За темой буду следить. У нас как раз полетел 3COM switch, заменили на другой. Но я и не вспомнила об этом, пока не прочитала. По времени замедление примерно совпадает с заменой. Сейчас тоже туда покопаю...
Для Eproxy эта ситуация невидима — он уже давно закрыл сокет и завершил обслуживающий поток, а CLOSE_WAIT может так и висеть. Их количество можно уменьшить, если закрывать сокет "ускоренно" (без опции so_linger и без socket shutdown), но тогда нет гарантии, что все данные получены до закрытия.
Пока никак не могу определить IP адрес нового свитча. Хотела в его управление залезть и не могу.
У меня тоже нет. Это я из MS KB цитирую http://support.microsoft.com/kb/319502. Да, добавить и перезапустить.
Управляемый свич? Можно WireShark'ом посмотреть, эти штуки часто выдают себя через всякие advertisment'ы
Да, чем сложнее железка, тем больше к ней подозрений... Пора нам собственное сетевое железо выпускать, чтобы не было повода списывать проблемы на кривые железки
ред: 27.01.2011 18:41
Кстати, похоже, что этот смарт свитч никакой и не смарт и не управляется извне.
У вас тоже появился повод не брать его с собой в новую жизнь. Как и E4, впрочем (до выяснения...).
Мне тоже непонятно — что работает шустренько? Исчезла разница между E2 и E4?
Вы с NPtest'ом из той темы про Eproxy/3 поэкспериментируйте тоже — его показатели ближе к E2 или E4?
Проблемы начались в январе, или в декабре тоже было заметно? (версия E4 не менялась это время, значит ищем изменения конфига)
Номер плана 1
Название ourusers
Включено? да
С 2010-09-21 19:01:55
По 1970-01-01 03:00:00
Приоритет 100
Проект ourusers
Исключения adsl,192.168.16.*
В день 100000000
Номер плана 2
Название administrator
Включено? да
С 2010-09-21 19:04:18
По 1970-01-01 03:00:00
Приоритет 10
Роль administrator
Исключения adsl
В день 0
В неделю 0
В месяц 0
Нет
Обычно бывало много (200-300).Трудно сказать. Но напрямую не могу это связать, т.к. бывала, что и нормально работал при таком же количестве.
Уже сейчас не могу точно вспомнить, но, по-моему, в конце декабря, еще до НГ.
Это при попытке просмотра детализации сессий? Попробуйте при очередном перезапуске остановить не только acWEB, а все службы Eserv'а, потом убрать/переименовать файл DATA\log\stat\stats.db3 и запустить службы.
ред: 02.02.2011 16:49
Сделала
Нормально, у нас на сервере размер этого файла несколько гиг.
Скорее здесь дело в том, что SQLite с некоторыми типами запросов не справляется, точнее справляется пропорционально размеру базы (= пропорционально производительности диска), и индексация по соотв.полям не спасает
А проблемы с прокси сохранились?
Просмотрел переписку с вами за эти месяцы — там вопросы по каскаду, ACL и т.д., а про производительность ничего. Давайте разберемся и с вашим случаем.
ОК, раз есть такая проблема, придётся ротировать и эту базу. Или вообще опционально отключать возможность детализации для экономии дисковых операций. На суммарную статистику и тар.планы эта база никак не влияет, т.к. скорострельность sqlite не соответствовала задаче изначально, и всё это хранится в самодельных спец.БД.
Со вчерашнего дня никаких тормозов нет.
В управлении HTTP(S) соединений ~4000. Перезапуск acWeb помог. Ранее, в борьбе с тормозами, задала параметр HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters TcpTimedWaitDelay = 0xF0 (240 десятичное). Но по наблюдениям, количество соединений нарастает, и почти все CLOSE_WAIT. Перезапуск acWeb уменьшает кол-во соединений до примерно 50. Кстати, сейчас перезапуск acWeb удался только со второго раза, т.к. первый раз:
http://www.eserv.ru/download/acWEB4_2011-02-05.rar
В планировщике можно добавить задание с ком.строкой
Если это не приведет к побочным эффектам, описанным в последнем абзаце 27.01.2011 12:47 выше, то можно будет вернуться к быстрому закрытию соединений.
Да, если при перезапуске службы Eserv'а WinSock еще не успел очистить таблицу соединений, то возникают проблемы с запуском — порты "не биндятся", т.к. считаются еще занятыми. Это не зависит от CLOSE_WAIT, может быть и с ESTABLISHED, и с любыми другими состояниями.
Может, сделать для них спец. журнал, а то теряются важные события среди такого потока?
Значит к-во CLOSE_WAIT тут не причем. Тогда давайте снова по опциям TCP гадать. Например MaxUserPort: http://support.microsoft.com/kb/q196271/
ред: 11.02.2011 10:21
Это на всех лок. компах надо будет использовать? Интернет переставал работать у всех с этой ошибкой. Посмотрю в след. раз.
Нет, проблема-то на машине с Eserv, клиенты просто ответ в браузер получают.
Хоть там название debug в имени, это обычные (полезные логи. Вот Игорь в PigProxy довёл до ума то, что в E3 только планировалось — декодированную запись передаваемых в POST'ах данных. Полезно для анализа активности пользователей на предмет "утечек". POST'ы редки, поэтому для производительности не критичны.
ред: 14.02.2011 15:31
Через некоторое время получил... перестал отдавать почту Imap, перестал работать портал и интернет acWeb.
сервис — Дескр — потоки
acWeb — 7020 — 224
acImap — 205 — 23
acSmtp — 224 — 19
acFiltr — 128 — 12
Перезапустил сервисы и все заработало.
Файл: лог [34936 bytes]
По к-ву используемых ресурсов всё в норме.
Да, страшная. Причем каждый поток успевает сбойнуть по нескольку раз. У вас UsePool не включен случайно?
ред: 14.02.2011 15:53
Сам компьютер в это время работоспособен, доступен из сети, можно перегружать только сервисы, при этом в логах ничего подозрительного не появляется. Логи прикреплены в прошлом сообщении.
Если вы про OnStartup.rules.txt acWeb — то нет, закомментирован.
MaxUserPort давно сделан, как перешел на e4 proxy
ред: 14.02.2011 20:59
Файл: acWeb-log.txt [37692 bytes]
Скорее всего это та же проблема, связанная с включаемыми CGI, о которой вы ранее сообщали на support. Т.е. с прокси не связано. С этой ошибкой пока разобраться не смог, надо больше данных собрать в этом exception, вышлю вам спец.версию.
Перешел с Е2 на Е4. Теперь через день (а вот сегодня уже и каждый день) имею
An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full.
Если нужно сделать еще одну попытку, нажмите "Обновить" в браузере.
Ошибка 10055. Полагаю из-за того, что в соединениях накапливается просто огромное количество со статусом CLOSE_WAIT. Иногда помогает перезапуск acWEB, иногда приходится перезагружать весь сервер (даже выждав какое-то время после остановки до запуска), что весьма печально для предприятия. Только что попробовал добавить в задания (Generic) Ком.строка: Internal: CloseWaitingConnections с интервалом в час (всё правильно?), посмотрим что будет дальше. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters TcpTimedWaitDelay пока не прописывал, имеет смысл? Если да то с каим приблизительно значением? А заменить acWEB на http://www.eserv.ru/download/acWEB4_2011-02-05.rar имеет смысл?
Только если версия Eproxy эта новая февральская. Но, как мы тут выше убедились, избавление от CLOSE_WAIT проблему не снимает... Если хаки реестра не помогут, то наверное придётся число локальных, а не внешних, соединений уменьшать. Для этого попробуем уменьшить таймаут Keep-Alive (ожидание дополнительных запросов от браузера в тех же соединениях). В E2 логика эта была попроще (ближе к HTTP/1.0, чем к 1.1), соединения были более короткоживущими.
CloseWaitingConnections с интервалом по умолчанию мне, по крайней мере, помогают не наблюдать такую ошибку в прокси
Помог только перезапуск сервиса
Придётся в выходные выпускать промежуточное (до офиц.4.27) обновление.
Забыла написать, что обновлялась сегодня утром.
Вот и меня достала медленная работа Е4.
Остановил все сервисы удалил папку с DNS_cache. Запустил заного все сервера.
Чудо , смог наконец то написать на форум.
У меня стоит в запущенном состоянии проксик Е3 и часть конторы (80%) всё ещё работают на нём. Вот думаю если всех переведу на Е4 вообще повешусь.
Честно говоря не знаю что присылать и где капать.
Всё что нешёл:
22.3.2011 (1941581 virus records)
1081 :127.0.0.1 0
1081 :192.168.хх.хх 0
3122 :127.0.0.1 0
3122 :192.168.хх.хх 0
3129 :127.0.0.1 0
3129 :192.168.хх.хх 0 dom=img-kazan.ru&host=proxy.vbkzn.ru&smtp=25&хххх=хххх
http://www.eserv.ru/e4a/network.e dom=img-kazan.ru&host=proxy.vbkzn.ru&smtp=25&хххх=хххх
http://www.eserv.ru/e4a/network.e
Couldn't resolve host name
OnDnsReq err=-2 DNS reply format error (type)
1394
58EA4A4 00 01 01 00 00 01 00 00 00 00 00 00 00 05 72 61 ..............ra
58EA4B4 64 61 72 08 69 6D 67 73 6D 61 69 6C 02 72 75 00 dar.imgsmail.ru.
58EA4C4 00 0D 00 01 00 00 00 00 00 00 00 00 00 00 00 00 ................
OnDnsReq err=-2 DNS reply format error (type)
1394
57EA4A4 00 01 01 00 00 01 00 00 00 00 00 00 00 05 72 61 ..............ra
57EA4B4 64 61 72 08 69 6D 67 73 6D 61 69 6C 02 72 75 00 dar.imgsmail.ru.
57EA4C4 00 0D 00 01 00 00 00 00 00 00 00 00 00 00 00 00 ................
OnDnsReq err=-2 DNS reply format error (type)
1394
58EA4A4 00 01 01 00 00 01 00 00 00 00 00 00 00 05 72 61 ..............ra
58EA4B4 64 61 72 08 69 6D 67 73 6D 61 69 6C 02 72 75 00 dar.imgsmail.ru.
58EA4C4 00 0D 00 01 00 00 00 00 00 00 00 00 00 00 00 00 ................
OnDnsReq err=-2 DNS reply format error (type)
1394
57EA4A4 00 01 01 00 00 01 00 00 00 00 00 00 00 05 72 61 ..............ra
57EA4B4 64 61 72 08 69 6D 67 73 6D 61 69 6C 02 72 75 00 dar.imgsmail.ru.
57EA4C4 00 0D 00 01 00 00 00 00 00 00 00 00 00 00 00 00 ................
OnDnsReq err=-2 DNS reply format error (type)
1394
58EA4A4 00 01 01 00 00 01 00 00 00 00 00 00 00 05 72 61 ..............ra
58EA4B4 64 61 72 08 69 6D 67 73 6D 61 69 6C 02 72 75 00 dar.imgsmail.ru.
58EA4C4 00 0D 00 01 00 00 00 00 00 00 00 00 00 00 00 00 ................
OnDnsReq err=-2 DNS reply format error (type)
1394
57EA4A4 00 01 01 00 00 01 00 00 00 00 00 00 00 05 72 61 ..............ra
57EA4B4 64 61 72 08 69 6D 67 73 6D 61 69 6C 02 72 75 00 dar.imgsmail.ru.
57EA4C4 00 0D 00 01 00 00 00 00 00 00 00 00 00 00 00 00 ................
Couldn't connect to server
MAPTO: ххххххххх хххх
MAPTO: ххххххххх хххх
<25>TCPMAP, Can't get IP for connection — ххххххххх хххх
DHCP -нет
Использывать рубрикатор в прокси, стоит — да.
Е3 на той же машине. на порту 3128.
Доктер стоит только на Е4.
В Е3 нет ничего.
Перезагрузка серверов помогает на 1- 2 минуты. потом полный висяк.
Eproxy не каскадом включен случайно?
Это сделал в первую очередь но не помогло. Тем более, что база была всего 250 мегов.
Доктера и рубрикатор помогли хотя не знаю точно кто из них.
Не каскадом.
Вот новые ошибки в логе
<30>
Буду смотреть. Но точно быстро стало работать.
ред: 24.07.2012 13:15
Да, запускала NPTest на прокси и клиенте, получила 11 ... ... байт в секунду — это же 88 Мб? Вроде, нормально.
Спасибо.
Уточните, 100 мегабит или гигабит?
Мегабайт или мегабит?
Какая скорость получения файлов с локального Eserv'а по FTP?
Если на машине с Eproxy разница через прокси и без прокси небольшая (до 5-15%, с учетом обработки ACL, записи кэша и лога — это нормально), то в ЛС всё будет зависеть от первых двух параметров в acWEB\conf\OnStartup.rules.txt
Их можно покрутить. Особенно первый — иногда скорость меняется в разы. Попробуйте вместо 65000 поставить 16000 или 24000.
ред: 24.07.2012 17:06
100 мегабит
мегабит (я стараюсь в одних единицах писать )
У меня как раз эти настройки стоят. Сейчас попробую. А надо перезапускать acWeb?
ред: 24.07.2012 17:25
Да. На всяк. случай еще раз попробовала. 65000 — показывает 5,43 Мб/с; 64000 — 58,29Мб/с.
Спасибо!
А на 72000 — 62,65 Мб/с. Может, и больше можно увеличить? Это на что еще влияет?
А размер буфера влияет в зависимости от соотношения размеров буферов eproxy, windows, драйвера, сетевой карты, свича и роутера. Заранее не угадать, оптимальное значение в конкретной ситуации подбирается методом тыка У меня в одной сети оптимально 24000, в другой 65000, потому такие значения и привожу.
Спасибо!