[Saab95]

Покажи сколько памяти используется у тебя на аналогичном насе ? На х86 с ROS у меня раз в десять меньше памяти используется, в отличии от CCR.

 

Около 600 мегабит вместе с 5000 маршрутами OSPF.

[kosmich7]

600 мегабит памяти ? :-)

[Saab95]

Мегабайт. Там, где еще есть и BGP, занято чуть больше гига.

[kosmich7]

Шейпы и NAT на этом же девайсе, PPPoE ?

[nuclearcat]

Детишки с CCR, брысь назад в песочницу, лепите дальше себе куличики из говнапеска с аптаймом в неделю и рассказывайте дальше басни про ваши 36 ядер.

Бывает нужда использовать Микротик, я согласен, но крайне неразумно советовать его как silver bullet другим.

1.5G, до 10к юзеров. На графике процессора рисуется idle time, из-за включенного энергосбережения - главное, чтобы ни одно ядро уползало в красную зону.

Один проц (выпущен в 2012, так что старенький), E5-2620, т.е. всего-лишь 6 честных ядер 2.1Ghz, памяти с избытком, но кушается около 6 гиг максимум вроде (но всего в системе 98.920.496 kB).

Набортные сетевухи не использую, поставил две четырехпортовых (кажется) i350.

Перейду на 10G свитч - думаю еще лучше будут результаты. NAT уже перевел, производительность технически и по субьективным ощущениям возросла значительно.

[kosmich7]

Детишки с CCR, брысь назад в песочницу, лепите дальше себе куличики из говнапеска с аптаймом в неделю и рассказывайте дальше басни про ваши 36 ядер.

Мальчик - брысь отсюда (с) :-)

На других ОСях у нас тоже есть дивные цифры.

Обьясните почему один тик работает как часы, а его брат болеет не ведомо чем ?

ИМХО дело в конкретном экземпляре железа.

[nuclearcat]

Покажите ваши дивные цифры, с железом, интересно, к чему стремится :)

Не в железе. В ядре есть вполне конкретные баги, которыми особо никто заниматься не хочет, и реверс патчей тоже не хотят (в vanilla).

Данный баг вызывается похоже только определенными CPE. Шанс выловить и тем более пофиксить этот баг у пользователей Микротика - близок к нулю, можно только приносить жертвы на алтарь, в надежде, что боги соизволят обратить внимание на них. На Линуксе, хотя и не без матов, в течении пары дней я выяснил причины ребутов раз в 1-2 дня на большом количестве юзеров.

[kosmich7]

Покажите ваши дивные цифры, с железом, интересно, к чему стремится :)

Стремимся к солнцу :)

Наши цифры меркнут по сравнению с вашими, тем не менее они в разы выше текущих цифр по онлайну и трафику.

Будут цифры достойные внимания, покажу.

 

Не в железе.

Два идентичных CCRа, один ребутится второй нет, ОСь одинаковая, железо тоже, стоят в одной стойке, от одного ИБП - в чем проблема ?

Есть мысль поменять их местами и понаблюдать.

В других местах такие же ССRы и тазики на ROS живут месяцами.

 

Данный баг вызывается похоже только определенными CPE.

Вероятно, хотелось бы его отловить, хоть это и неблагодарное занятие.

 

Перейду на 10G свитч - думаю еще лучше будут результаты. NAT уже перевел, производительность технически и по субьективным ощущениям возросла значительно.

64 очереди на порт туда и обратно, гораздо веселей чем, 4 на порт туда и 4 обратно на i350 и ее предшественницах/аналогах.

[nuclearcat]

Два идентичных CCRа, один ребутится второй нет, ОСь одинаковая, железо тоже, стоят в одной стойке, от одного ИБП - в чем проблема ?

Есть мысль поменять их местами и понаблюдать.

В других местах такие же ССRы и тазики на ROS живут месяцами.

Траффик(нагрузка) те же самые или клиенты разные?

 

Вероятно, хотелось бы его отловить, хоть это и неблагодарное занятие.

На Микротике - нереально. Хотя, возможно если включить максимальный debug и syslog over udp - можно.

[kosmich7]

Траффик(нагрузка) те же самые или клиенты разные?

Клиенты разные, условия практически идентичные.

Перекину клиентов на второй который не ребутится, точно узнаем в чем дело.

[Saab95]

CCR используют не потому, что не могут себе позволить тазик собрать, а потому, что так удобнее - меньше места в стойке занимает и меньше потребление.

[nuclearcat]

Ну и сколько места займут в стойке CCR-ы на 10k юзеров? :) При том, что от 1k микротику уже плохеет.

[kosmich7]

Штук 15 справятся с 10k юзеров :) Дело не в 1k а больше в количестве трафа, pps и в самой сети. :)

[Yuraner]

Два идентичных CCRа, один ребутится второй нет,

Подцепись на COM порт, зайди в загрузчик и запусти тест памяти.

[nuclearcat]

Saab95, так каким образом они занимают в стойке меньше места? у меня с полным резервированием 4U, а тут каждый микротик 1U, итого 15U без резервирования. Вранье?

По питанию кстати тоже больше выходит.

[Saab95]

Saab95, так каким образом они занимают в стойке меньше места? у меня с полным резервированием 4U, а тут каждый микротик 1U, итого 15U без резервирования. Вранье?

По питанию кстати тоже больше выходит.

 

В стойке столько юнитов, что даже 30 микротиков влезет в любую. Кроме всего, микротики короткие по длине и их реально ставить в один юнит с двух сторон.

[BF-Systems]

Если заменить и поставить CCR1036-8G-2S+EM как думайте результат лучше будет? Есть ли у кого опыт и что посоветуете?

 

routeros x86 - не умеет видеть больше 2 гиг оперативной памяти.

 

по поводу производительности - у нас прокачивает 980 мегабит в пике, на устройстве нашего производства, через НАТ и леер 7 фаервол с кучей сигнатур, при нагрузке на проце не более 35%.

 

Спеки девайса и подробности могу озвучить в личку, насколько я понял тут реклама платная (?)

 

З.Ы. девайс 1U с глубиной 26см, никаких больших гробов, 2015 год на дворе.

Изменено 11 сентября, 2015 пользователем BF-Systems

[sfstudio]

Какие всё знакомые тараканы-то. Даже непонятно чем там всё это время микротики занимались если такие вещи не зафикшены и ушли в продакшн.

 

В ядре начиная с появления RPS/XPS без которых нет возможности распараллелить по человечески сеть на SMP жил баг именно с route cache приводивший к глухим висам и ребутам. В 3.5.х из ядра вообще вынесли route cache и проблема решилась, но производительность не на SMP системах рухнула почти вдвое. Далее почесав репу народ таки реализовал route cache для conntrack отдельно и избавился от общей блокировки в контраке порезав её на стопку мелких независимых блокировок. Это позволило подтянуть производительность на SMP к "докризисному" уровню, но на не SMP всё ещё сильно проигрывает 3.4 и более ранним ядрам. Ессно что Microtik не может пойти по тому же пути ибо и без того дохлые младшие модели на одноведерных MIPS превратятся в ещё более убогие тормоза. А если не решить проблему то будут вот такие вот глюки на SMP. Мы уже прошли через это и проблему таки удалось решить без выковыривания route cache (где-то месяца 3 назад).

 

Это первая трабла.

 

Вторая трабла при массовом дисконнекте pppoe клиентов залечена в апстримных ядрах совсем недавно (и требует небольшой правки и в юзерспэйсном pppd).

Смотрим https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/?id=refs%2Ftags%2Fnext-20150911&qt=grep&q=pppoe%3A надеюсь понятно какие именно.

 

Так же в ядре в штатном отсутствуют проверки DST маков в PADT пакетах, отсутствует проверка типа пакета в recive path и ещё пара тараканов которые на сетях с дупами или даже мелким флудом могут привести к срыву головы в любой момент.

 

Ждите когда поправят, симптоматика описанная в теме красноречиво говорит именно об этих глюках. А будут они проявляются или не будут зависит от кучи в т.ч. внешних факторов. Как бы можно было бы легко и самим всё это зафиксить, но вот жешь бяда сырцы недоступны =))) Так что привет x86 и никаких гвоздей. Ну и как выше сказали 2015год на дворе, компактных решений на x86 хватает. И энергоэффективность в расчёте производительность на ватт у x86 на данный момент мипсам, армам и прочим уж точно не уступает если рассматривать с точки зрения сети.

[nuclearcat]

Вторая трабла при массовом дисконнекте pppoe клиентов залечена в апстримных ядрах совсем недавно (и требует небольшой правки и в юзерспэйсном pppd).

Смотрим https://git.kernel.o...grep&q=pppoe%3A надеюсь понятно какие именно.

 

У меня этот фикс вызывает стабильную панику на pppoe сервере :)

[sfstudio]

Ну дык трэйс надо видеть, сомнительно это дело. pppd тоже подправлено? У меня ни на сервере ни на клиентах проблем не замечено. Что-то мне подсказывает что не в фиксе дело, точнее не только в нём. Да и если натягивать руками там ещё в ppp_generic надо кой чего затянуть иначе будет падать. Короче там стопка патчей один за другой цепляется.

 

Так же бы неплохо было бы поправить в skbuff+ppp_generic+pppoe на тему realloc`а рамы для skb_head, это ещё в +20% производительности примерно. В апстриме нет.

 

Можно ещё time critical функции ещё вместе в одну секцию собрать, ещё чуток подтянется производительность). В общем было бы желание.

 

В случае с ROS хоть желай хоть не желай, но не пофиксить ни оптимизнуть не моги. Кроме как жертвоприношениями заниматься что бы быстрее пофиксили ничего и не остаётся.