+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Прозрачный веб-прокси и загрузка ЦП.

Прозрачный веб-прокси и загрузка ЦП., RouterOS

hci

Guest

07.04.2006 16:47:00

Кто-нибудь использует прозрачный веб-прокси с большим количеством пользователей? У меня есть Mikrotik 2.9.x с 3 (скоро 4) картами Cyclades T1 для подключения к интернету, и он также работает как прозрачный веб-прокси-кэш. Ещё там идёт контроль p2p и файрволлинг. Загрузка ЦП огромная. Это 2.6Ghz P4 с гигабайтом ОЗУ. Как только я отключаю правило DST-NAT для кэша, загрузка ЦП падает почти до нуля. Я уменьшил размер кэша, но это мало что дало. На самом деле, я установил его в 0, и загрузка осталась очень высокой. Так что я предполагаю, что перенаправление всех HTTP-запросов даёт высокую загрузку ЦП? Кто-нибудь здесь использовал wpad.dat, чтобы принудительно использовать кэш? Как заставить всех пользователей изменить настройку в своих веб-браузерах, чтобы они использовали его? Буду рад любым советам. Matthew

onowojemma Guest	#2 0 15.04.2006 15:40:00 Привет, спасибо за твой пост! Подскажи, пожалуйста, как настроить прокси-сервер и какая нужна конфигурация? Заранее благодарен.

savage

Guest

07.04.2006 16:52:00

Ещё не сталкивался с этим сам, но прекрасно понимаю, что к чему. MT использует Squid для прокси. При таком объеме трафика/пользователей, Squid требует очень оптимизированной конфигурации. Как минимум, это касается его кэш-хранилищ (которые, в вашем случае, должны быть ОЧЕНЬ большими), списков доступа и прочих вещей. Но MT, к сожалению, не позволяет использовать такие обширные опции конфигурации, чтобы не усложнять настройку для новичков. Поэтому ваше решение — завести выделенный прокси-сервер на Squid, настроить и оптимизировать его под ваши требования к пропускной способности и количеству пользователей, а затем изменить правило dst-nat, чтобы прозрачно перенаправлять веб-трафик на выделенный прокси-сервер для кэширования. – C

hci

Guest

07.04.2006 17:08:00

Я не думаю, что это поможет. Сейчас у меня кэш настроен на 0 для максимального размера диска, оперативной памяти и объектов, а загрузка ЦП все равно высокая. Как только я отключаю правило перенаправления DST-NAT, загрузка ЦП через несколько минут падает почти до нуля. Так что сейчас кэш пуст и вообще ничем не кэширует. Не вижу, как добавление родительского кэша может помочь. Поможет ли? Мэтью.

savage

Guest

07.04.2006 17:13:00

Размер кэша — 0 или 10 триллионов — не имеет значения. Запрос все равно проходит через squid (поэтому аномалия исчезает, когда вы ОТКЛЮЧАЕТЕ правило dst-nat, потому что запрос тогда не проходит через squid). И родительский прокси тоже здесь не причем… Вообще не используйте пакет прокси в MT, так как конфигурация не оптимизирована. Добавьте chain=dstnat in-interface="My Network" protocol=tcp dst-port=80 \
src-address-list="All Clients" dst-address-list=!noHTTPProxy \
action=dst-nat to-addresses=x.x.x.x to-ports=3128 comment="" \
disabled=yes Как видите, в этом dst-nat правиле я просто перенаправляю трафик напрямую от MT к выделенному прокси-серверу на отдельной машине… Я на 200% уверен, что ваша проблема в том, что конфигурация squid в пакете прокси просто не справляется с объемом трафика, который ей нужно обрабатывать. Неважно, кэширует она его или нет, ей все равно приходится обрабатывать пакет. – C

hci

Guest

07.04.2006 17:32:00

Понимаю, к чему ты клонишь. Попробую твой метод. Интересная штука с добавлением IP-адресов в белый список, чтобы их не кэшировали. Сколько клиентов работают на твоем сервере и какой у тебя пропускная способность? Всё равно думаю, что DST-NAT такого количества трафика может сильно загрузить систему. Но, может, дело совсем не в этом.
Мэттью

savage Guest	#7 0 07.04.2006 18:24:00 Натинг (natting) проблем не должно вызвать. Помни, ядро Linux и файрволы (iptables, на чём, полагаю, основан MT) уже оптимизированы – для этого никаких настроек не требуется. Уверен, что любая более-менее приличная MT-машина без труда сможет обрабатывать пару миллионов пакетов в секунду… Просто погугли немного и потрать время на squid-cache.org. Там полно статей и формул для расчёта размера, требований к железу и производительности кэшей по мере их построения. Если отрываться от темы, то, пожалуй, SCSI-диски (<9GB), больше одной директории кэша, процессы diskd для чтения/записи кэш-хранилища и т.д. и т.д…. При грамотной настройке, я почти гарантирую, ты увидишь значительное улучшение производительности. У меня пара пользователей, но я использую внешний прокси просто на всякий случай. MT — это маршрутизатор, а не движок кэширования. В любом случае, у меня всего 3ГБ кэша, и я получаю от 40% до 60% попаданий в кэш с полностью заполненным кэшем… – C

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры