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

Хотспот, HTTPS и производительность процессора

Хотспот, HTTPS и производительность процессора, RouterOS

gammy69er

Guest

02.11.2014 23:38:00

Прежде чем начнёте просить у меня Supouts... Я понимаю, что могу их отправить, и моя проблема решится... Однако мне хочется провести ещё пару проверок перед этим.

Проблема: процесс www в профиле /tools съедает весь доступный процессор.

Причина: система входа в Hotspot через HTTPS (/ip hotspot profile set login-by=https).

Решение: отключение HTTPS как способа входа.

Новая проблема: у многих пользователей HTTPS-страницы по умолчанию (спасибо, Google), из-за чего при отключении HTTPS ломается редирект на страницу входа.

Временный выход: просить клиента зайти на страницу без HTTPS — не самый лучший вариант, учитывая, что приходится обслуживать до 100 клиентов в день на радио, и у нас больше 90 hotspot-систем.

Вопрос: известны ли причины, почему HTTPS так нагружает процессор? Может, есть несколько вариантов, которые можно попробовать и потом отчитаться с решениями, или же это баг (судя по всему, уже был, его несколько раз исправляли и он снова появлялся).

Для информации: у нас стоят полностью сертифицированные SSL-сертификаты. Некоторые Hotspot’ы вообще не страдают от этой проблемы — даже более крупные. У других всё начинает «падать» при 50-90+ клиентах, у некоторых это происходит уже при 5+ клиентах. Я не использую веб-кэш, но применяю DNS-кэш. На некоторых точках несколько Hotspot’ов, на других — по одному.

Отключение HTTPS снижает нагрузку www с максимальной (где-то от 30% до 70%) до нуля — 0%.

Отключение — это временное решение, но оно не подходит из-за ошибок редиректа.

И ещё: прежде чем ругать меня за то, что я не добавляю комментарии к другим постам — я реально максимально старался найти решения в них, но все только требуют supouts, а потом никаких обновлений.

Я просто прошу список возможных причин... Иногда такие эксперименты помогают лучше понять систему.

gammy69er

Guest

11.12.2014 21:22:00

Тем, кто следит за этим — вот обновление. Наконец-то! Но я хотел убедиться. Итак... Провёл живое тестирование на объекте 2. Обновился до 6.21.1. Дал поработать. Через день… Уф, он снова начал глючить. Отключил HTTPS и ждал, пока смогу попасть на объект. К тому моменту (через два дня) вышла версия 6.22. Обновился снова (думал откатиться, но для теста решил оставить новую). В этой прошивке явных обновлений HS не было, поэтому сделал то, что планировал — удалил скриптовую версию Hotspot и настроил вручную через Winbox. Прошло уже 3 недели — никаких проблем. За это время также обновил связь между 5 узлами, висящими на нём, и теперь никто не жалуется на интернет (а жалобы — это наличие проблем).

Итак… Рекомендация: если у вас есть скрипт, который годами работал стабильно, самое время построить радио вручную и натянуть свежий скрипт. Как я уже говорил, в наших старых скриптах было много кавычек "", а текущие экспорты из версии 6+ их не содержат. Теоретически, раз это строковые значения, это не должно влиять вообще никак... Но у меня, судя по всему, повлияло.

Я проверил на другом объекте с устаревшим RB450, где была другая проблема — тоже на старой прошивке. Там проблемы были не связаны с этим, и переход на 450g решил их. Там одновременно онлайн от 40 до 100 человек — нагрузка достаточная, чтобы баг проявлялся быстро, и, насколько я понимаю, поскольку я собрал роутер вручную (без скриптов), сейчас дважды в неделю всё работает без сбоев.

Обновлю вас, если снова появится та же ошибка — буду рад доказать, что ошибался, ради прогресса. И ещё раз спасибо SystemErrorMessage за то, что использовал форум по назначению — вы дали много полезных советов и помогли, спасибо!

awacenter Guest	#3 0 24.02.2015 08:07:00 Твой пост был очень полезен, gammy69er. Я замечал такое поведение несколько раз на своих устройствах. Может быть, дело в том, что мы используем не те (или недостаточно мощные) устройства для наших нужд?

gammy69er

Guest

15.03.2015 20:47:00

Спасибо, Awa — рад, что люди получают полезную информацию из этого. На самом деле я ответил в другом посте, потому что недавно сделал несколько открытий. Вот ссылка на пост: http://forum.mikrotik.com/t/32mb-ram-devices-and-ros-6/81580/1

Я выяснил, что, похоже, проблема связана с RoS v6 и оборудованием RouterOS с 32 Мб ОЗУ или меньше (по моим обычным навыкам аппаратной диагностики ПК — я знаю, что здесь всё немного иначе, но не полностью). Я заметил, что устройства с меньшим объемом памяти хуже справляются с HS-клиентами — каждый следующий подключенный проходит всё медленнее и медленнее, пока в итоге устройство просто не перезагружается из-за watchdog. Это проверялось и сейчас подтверждается на двух rb751U: один с 64 Мб — стабилен уже несколько месяцев, другой с 32 Мб — в другом месте, при примерно одинаковом трафике и той же конфигурации (кроме названий, т.к. это две разные библиотеки с бесплатным Wi-Fi). 32 Мб версия может падать до пяти раз в день, хотя иногда бывает удаётся проработать 4-5 дней без сбоев, но редко. Устройства с большим объемом RAM справляются с этим намного лучше. Это просто факт.

Мои рекомендации, исходя из неофициального опыта: если вам нужно обновиться до RoS 6 — обновляйте железо (RB951U сейчас дешевле, чем RB751U был, когда я писал впервые, и у него 128 Мб и 600 МГц, он меня хорошо выручает). Если безопасность решается где-то ещё, то ваш роутер, скорее всего, особо ничего не делает, так что RoS 5 вполне подходит. Но я техник, и поэтому советую перейти на свежие версии ради новых функций и безопасности.

gammy69er

Guest

09.04.2015 06:08:00

Обновление… Наконец-то зашёл в библиотеку и обновил железо — поставил 951G (обычно беру 951U, но его не было в наличии). В любом случае — прошло уже 7 дней, и ни одной проблемы, на удивление (постучим по дереву). Правда, пару дней назад заметил падение ppp, но быстро всё восстановилось. По состоянию на вечер четверга, в 18:00, при входе CPU висел примерно на 20%, а свободной оперативки было около 90,1 Мб (ну теперь 89,8) — это явно больше, чем 32 Мб. В общем, как вспомню проверить снова — напишу здесь про время работы и прочее. Всем здоровья и берегите себя!

gammy69er

Guest

22.05.2015 00:26:00

Возможно, это последнее обновление по этому поводу — если кто-то использует Toss, сейчас 25 дней без перезагрузок (смотрел логи, была перезагрузка какое-то время назад — почему именно, непонятно, возможно, отключение питания). С момента обновления не было ни одного звонка в поддержку (раньше приходилось отвечать на 3+ в неделю). Только что зашёл проверить его перед этим обновлением.

Что заметил по Hotspot’ам: при входе загружался процессор на 100%, но быстро справлялся и начинал пропускать гостей (100% загрузка — это WWW, видимо, RB говорит компьютеру показывать Splash Page). После этого нагрузка резко падала до менее 20% в целом (~10 пользователей — нагрузка совсем небольшая).

В любом случае — для меня это победа. Если есть вопросы или комментарии, не стесняйтесь оставлять их здесь — буду время от времени заходить и читать.

awacenter

Guest

04.08.2015 12:45:00

Подтверждаю ваши предположения. При использовании дешёвого оборудования (32 МБ ОЗУ) и ROS v6 поведение действительно очень плохое. А с RB951G процессор поднимается до 100% на несколько секунд (4-5 секунд, по-моему, это уж слишком долго), а потом падает до 10-15%. В любом случае нужно проверить реализацию службы хотспота при использовании метода входа через https в профиле хотспота. Думаю, это баг.

awacenter Guest	#8 0 27.08.2015 10:27:00 Есть новости о том, почему загрузка процессора поднимается до 100%, когда аутентификация хотспота происходит через https?

gammy69er Guest	#9 0 27.08.2015 22:47:00 У меня нет идей... Такое происходит с каждой версией железа, которую я использовал для Hotspot (Cloud Core ещё не пробовал — но это всё равно что приехать на монстр-траке на гонки на гокартах). Придётся обратиться к тем, кто разбирается в коде и понимает, что именно HTTPS-вызовы пытаются сделать с роутером, чтобы нагрузить CPU до 100%. Всё, что я знаю — чем лучше железо, тем меньше CPU висит на 100%, и это либо снижает, либо почти полностью устраняет проблему (на RB850Gx2 её почти не замечаешь). Мои наблюдения: RB751U или аналог — 400 МГц, 32 МБ ОЗУ, Mipsbe — 5–20 секунд работы CPU на 100% (если не падает) RB751U или аналог — 400 МГц, 64 МБ ОЗУ, Mipsbe — 5–20 секунд CPU (редко падает) RB532A — 399 МГц (разгон), 64 МБ ОЗУ, Mipsle — 5–20 секунд CPU (редко падает) RB951U или аналог — 600 МГц, 128 МБ ОЗУ, Mipsbe — 1–5 секунд CPU, никаких падений из-за Hotspot RB450G — 680 МГц, 256 МБ ОЗУ, Mipsbe — 1–5 секунд CPU, никаких падений из-за HS RB600 — 400 МГц, 128 МБ ОЗУ, PPC — 5–20 секунд CPU, редко падает, только при множественных логинах RB850Gx2 — 533 МГц, двухъядерный, 512 МБ ОЗУ, PPC — практически незаметная нагрузка, пока ни разу не падал из-за Hotspot. То есть, судя по моим наблюдениям, с железом самый большой геморрой у чипов Mipsbe, но Mipsle почти на одном уровне. Большинство моих бюджетных “LE” устройств отправились на свалку, как только я понял, как всё работает. С другой стороны, варианты с частотой 600 МГц и выше — достаточно крепкие, справляются нормально. Правда, RB600 на PPC не намного лучше. Мне пришлось отключить HTTPS, чтобы роутер нормально работал после обновления до версии 6.xx. При этом на нём было 2 Hotspot и больше 10 клиентов (некоторые через Hotspot, большинство — просто NAT с приватными IP и своим Hotspot). Что касается RB850Gx2 — это зверь! 200+ логинов в день (в основном с 17 до 20 часов) — и ни разу не “проглючил”. Для большого, но не гигантского сайта — однозначно рекомендую. Когда летом снова наступит в Южном полушарии, я хочу перепроапгрейдить свой RB600 до RB850Gx2 с Ubnt BH. Для больших площадок (1000+ пользователей) скорее всего понадобятся несколько Hotspot или CCR. Хотя RB1100 тоже отлично подойдёт, но лишь до некоторого предела.

Читают тему

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