foreverok

аплинк на брас можно и в бондинге, а вот абонам при рррое лучше отдать парой портов с задублироваными вланами на портах. А почему в сторону абонентов отдавать pppoe не в LACP а дублировать вланы в разных портах? В таком случае, скорее всего будет та же проблема с балансировкой между физическими интерфейсами. Хотя тут уже от алгоритмов агрегации зависит.

1. под linux советуем собирать из исходников, так как не всегда все модули freeradius есть в бинарных сборках. 2. конфигурация freeradius 3 аналогична конфигурации 2 версией. 3. лучший способ быстро и качественно установить это воспользоваться Ainstall Спасибо. Будем пробовать.

Переходим на CentOS 7. Выяснилось что в стандартных репозиториях нет freeradius2, а в документации abills ничего не удалось найти по поводу настройки freeradius3. Кто то пробовал запустить? Вариант описанный в доке (сборка freeradius2 из src ) рассматривается как резервный. Хотелось бы запустить на freeradius3.

4ms, вы шутите? А вообще, одна трассировка не показатель. Начните хотя бы с MTR в 1000 повторов. По теме, у вас на втором хопе подскочил пинг. что бы хоть что то предположить, надо знать схему сети. Мучайте своего провайдера. P.S. Хотя, думаю вас пошлют далеко и на долго.

поправить можно с помощью mysqlcheck если используется myisam. Вот только кажется мне, что в бекап попадает не та БД которая нужна. Т.е. исходя из первого поста, делается бекап пустой БД.

Больше всего доставляет пункт №8

2. Например, для высокочастотного трейдинга. По радиорелейке сигнал идёт быстрее, чем по оптоволокну - скорость света в воздухе больше и сигнал идёт по прямой.1. Бюджет для трейдеров неважен. Если канал будет на несколько миллисекунд быстрее, чем у конкурентов, стоимость "отобъётся" очень быстро. Это же как нужно тянуть оптику, что бы на расстоянии 37 км получить разницу в 2мс по сравнению с РРЛ?

такие варианты не рассматривали? http://deps.ua/katalog/ru-shassi.html

raid, хотя бы software. Если проблем с заменой диска нет, то думаю не проблема поставить и 2 диска.

2.2 млн???? грн.? В размерах государства это копейки.

Какая версия прошивки микротика? 6.35.4

У меня pptp сервер без шифрования на RB450G имею вот такую картину

Индексы, движки - это конечно все возможно и даст небольшой прирост. Судя по самому запросу и размеру БД, проблема в том, что создается временная таблица на диске (диски наверное не ssd?), причем не маленькая. Посмотрите размер временной таблицы которая создается при выполнении запроса, возможно удастся засунуть её в tmpfs.

Само по себе точно не сбросилось бы. Что делали на сервере? Я такое наблюдал при sevice iptables restart на Centos 6. Потому нужно делать service iptables reload

Может и так. Вопрос в том, куда? ( Риторический вопрос )))

loglevel Debug пробовали? Может его в логах видно?

Брать надо на те длинны волн на которых вы работаете. Обычная физика и к точности измерений не имеет отношения. Запросто может быть ситуация когда через один и тот же кабель 1310 проходит замечательно, 1550 с затуханиями, а 1625 с еще большими затуханиями. При использовании CWDM столкнулись именно с такой проблемой.

На loopback интерфейсе запускайте tcpdump.

Почему не использовать например заббикс?

Просто DHCP-Relay добавляет информацию в пакет, в частности информацию о том, с какого интерфейса пришел пакет, что бы DHCP понимал какой IP нужно выдать. Поэтому на клиентском влане где висит relay нужен IP адрес. Во всяком случае у меня так: dhcpd: DHCPDISCOVER from 94:de:80:da:54:79 via 10.10.10.2 dhcpd: DHCPOFFER on 10.10.10.44 to 94:de:80:da:54:79 via 10.10.10.2 dhcpd: DHCPREQUEST for 10.10.10.44 (10.36.0.1) from 94:de:80:da:54:79 via 10.10.10.2 dhcpd: DHCPACK on 10.10.10.44 to 94:de:80:da:54:79 via 10.10.10.2 Где 10.10.10.2 IP адрес relay агента который смотрит в клиентский влан

IP адрес на этом влане настроен?

Еще раз говорю, с RX все ок ethtool -S igb0 | grep rx | grep packets rx_packets: 330764836530 rx_queue_0_packets: 41641938982 rx_queue_1_packets: 41324756652 rx_queue_2_packets: 41284168751 rx_queue_3_packets: 41376661849 rx_queue_4_packets: 41290403953 rx_queue_5_packets: 41482067750 rx_queue_6_packets: 41332238092 rx_queue_7_packets: 41032589069 А вот Tx : ethtool -S igb0 | grep tx | grep packets tx_packets: 239368064948 tx_queue_0_packets: 1354117513 tx_queue_1_packets: 231581877249 tx_queue_2_packets: 1148038306 t

PPPoE/PPTP проблема наблюдалась как на внутреннем интерфейсе так и на внешнем только с TX . C RX очередями все ровно. Что то не нашел тут ничего про TX. https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/network-rps.html удалось разрулить как писал выше через tc multiq

Оно. Добавил график в заббикс. Что бы визуально видеть изменения. Данные снимаются через ethtool В итоге получил следующую картину: Не идеально конечно. Но уже лучше.

Там счетчики еще с того момента, когда они свободно гуляли по ядрам. В общем похоже проблема в стандартной дисциплине mq. tc -s -d class show dev igb0 class mq :1 root Sent 4248819500 bytes 32806685 pkt (dropped 0, overlimits 0 requeues 1785) backlog 0b 0p requeues 1785 class mq :2 root Sent 70099802402310 bytes 1550251209 pkt (dropped 19391, overlimits 0 requeues 10021965) backlog 0b 0p requeues 10021965 class mq :3 root Sent 4784327130 bytes 37032812 pkt (dropped 0, overlimits 0 requeues 1988) backlog 0b 0p requeues 1988 class mq :4 root Sent 4690785532 bytes 35456978 pkt (dropp