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

PPPoE и загрузка CPU, начиная с версии 2.9.3x и до 2.9.44.

PPPoE и загрузка CPU, начиная с версии 2.9.3x и до 2.9.44., RouterOS

vgs

Guest

10.08.2007 14:46:00

Привет всем. У нас всё ещё странное поведение с более чем 600 PPPoE-соединениями на нашем MT-роутере (L6 лицензия). Если одновременно переподключается больше 100-200 пользователей, CPU взлетает до 100%, PPPoE зависает, и нам приходится перезагружать. Страница списка PPPoE-сервера отображается пустой, существующие PPPoE-сессии остаются подключенными, но трафик не проходит, хотя обычная статическая маршрутизация работает нормально. Иногда требуется 3-4 перезагрузки, чтобы система стабилизировалась. Время обработки команды перезагрузки занимает около 3 минут. Нормальная загрузка CPU составляет около 30-50% при нормальной работе. Общий трафик около 15 Мбит/с. Машина – P4 3.0GHz с 1GB RAM. Проблема впервые появилась в серии 2.9.3x, не помню точно в какой версии. Сейчас мы на 2.9.44. Используем очереди (ограничение полосы пропускания через PPPoE-профили). Нет скриптов или каких-либо прочих необычных вещей. На этом сервере нет правил брандмауэра (на самом деле, у нас есть 2 MT-боксы, которые делают то же самое, оба с примерно 700 PPPoE-сессиями). Мы запускаем несколько экземпляров PPPoE-сервера из-за нескольких Ethernet-интерфейсов. Беспроводных интерфейсов нет. RAM была протестирована memtest86+. Если посмотреть changelog для 2.9.45, не похоже, чтобы эта проблема была решена. Какие-нибудь подсказки? Спасибо! -vlad P.S.: Кто-нибудь тестировал 3.0 RC1 с сотнями PPPoE-сессий?

vgs

Guest

21.11.2007 21:19:00

Мы пока не тестировали 3.0 в реальных условиях, хотя у нас есть L6 с релиз-кандидатом 3.0, просто ждем, пока он немного "выдержит"… Что касается вычислительной мощности – в часы пик загрузка процессора в текущей конфигурации составляет 50-70% (P4 3GHz). Значительно ли отличается PPPoE стек в 3.x от 2.9?

sten

Guest

25.08.2007 23:03:00

Не знаю, сильно ли это поможет, но проблема с аутентификацией мучает нас с тех пор, как есть 2.9.x (а не 2.8.x, 2.8.x был медленным, но стабильным). Она просто сильно обострилась после 2.9.25, когда они изменили способ синхронизации процедур входа. http://forum.mikrotik.com/t/heavy-loaded-pppoe-server-troubles/13065/1 Судя по моему опыту, это гонки данных (race conditions) во время настройки входа, которые происходят под высокой загрузкой процессора (кстати, аутентификация, оказывается, довольно сильно нагружает процессор в RouterOS). Я знаю, как это минимизировать, но не знаю, как полностью убрать. Служба поддержки заявила, что списки PPP secret не предназначены для этого, но я видел такие же эффекты при использовании RADIUS. Любое замедление процедуры входа только усугубит ситуацию. Я спокойно обрабатываю 700-800 одновременных входов (на 2.9.24), но каждые 3-5 месяцев, когда сервер успевает накопить достаточно памяти и, как следствие, замедлиться, один пользователь может дестабилизировать всю систему. Уверен, если бы мы заменили процессор на что-то быстрее, чем нынешний 2-гигагерцовый Xeon (P4) с 512 КБ кэша, мы бы сталкивались с этим гораздо реже, но мы выбрали совершенно другую стратегию.

uldis Guest	#4 0 27.08.2007 06:12:00 Пожалуйста, создайте файл с выводом поддержки, когда столкнетесь с этой проблемой, чтобы мы могли изучить её и попытаться исправить. Отправьте этот файл на support@mikrotik.com.

vgs

Guest

04.09.2007 02:44:00

Ну что, небольшая новость. Может, ещё рано говорить, но вот что я сделал, просто так, на интуиции: создал несколько (в моем случае, 4) экземпляров PPPoE-сервера с абсолютно одинаковыми параметрами, за исключением имени сервиса. Это позволило перезагрузиться без зависания, и загрузка процессора упала с 70% до примерно 35%. Странно… Во время PPPoE-блокировки я так и не смог вытащить файл поддержки. Но я понаблюдаю за этим пару дней и попробую этот трюк на нашем другом PPPoE-сервере и посмотрим, что получится.

ropebih Guest	#6 0 17.10.2007 15:00:00 У меня небольшая проблема.

vgs

Guest

19.10.2007 15:15:00

Обновление: По словам техподдержки Mikrotik, проблема, похоже, в количестве записей в базе данных Secrets. Мы значительно сократили количество записей, и всё стало работать намного лучше. Используем FreeRadius для аутентификации, и кажется, всё отлично работает с PPPoE-сессиями. В данный момент мы больше не сталкиваемся с 100% загрузкой CPU и блокировкой PPPoE.

vgs

Guest

20.11.2007 23:59:00

Обновление, опять… Всё равно зависает, последнее сообщение от pppoe debug было что-то вроде "нет доступных pppoe серверов". Процессор загружен на 100%, всё как прежде. P.S. в базе данных всё ещё около 40 секретных записей.

sten

Guest

21.11.2007 06:28:00

В setup (добавлении очередей и т.д.) сессии есть состояние гонки, а не в аутентификации. Эта проблема проявится как только появится большая аппаратная нагрузка и люди будут часто подключаться и отключаться. Даже если вы используете только RADIUS.

vgs

Guest

#10

21.11.2007 16:34:00

Да, это логично. Даже если я удалю все записи из секретов, когда 700+ PPPoE-устройств одновременно обрушиваются на сервер, он зависает. Потом начинается этакая порочная цепь: ругаешься-перезагружаешь-ругаешься-перезагружаешь... пока наконец не стабилизируется. Надеюсь, команда MT скоро займется этим вопросом.

hci Guest	#11 0 21.11.2007 18:57:00 Да, это имеет смысл. Даже если я удалю все записи из секретов, когда более 700 PPPoE-устройств одновременно обрушиваются на сервер, он зависает. И начинается проклятый цикл: ругань-перезагрузка-ругань-перезагрузка… пока он, наконец, не стабилизируется. Интересно, помогло бы использование Mikrotik v3.x с поддержкой двух ядер? Мы редко сталкиваемся с зависанием, но часто видим пользователей, которым, скажем, установлен лимит в 512k, но они работают на скорости более 3m. Мэтт.

Читают тему

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