replicant

Теория про полисинг и шейпинг мне известна. Факт в том что этот код работает на 2.6.27.х ядрах и вы наверное не обратили внимания на пример с тестом, который на мой взгляд намного показательнее кода, потому что код совершенно правильный. Если бы он был неправильный, то шейпинг не работал бы на более старых ядрах. Может быть в коде и есть ошибки, но только применительно к подсистемам нового ядра, а не в принципе вообще ошибки. По поводу того что буфер должен быть больше тоже ясно. Он и так больше в 4 раза + 5500, если внимательно посмотреть код. Почему internet.yandex.ru четко показывает 4000 кбит/с по тесту, а когда скачиваешь файл допустим с mirror.yandex.ru то скорость не поднимается выше 20 кбайт!

Как раз все нормально, там возможно просто термины upload и download местами переставлены. Грубо говоря это одна и та же переменная, потому что канал симметричный. burst сделан таким образом, что на работающих системах корректно шейпит до 100 Мбит/с включительно с погрешностью около 1% в ту или иную сторону и размер burst оптимален для любых тарифов и скоростей. Меня волнует почему разница в тесте и в реальной работе и даже не почему шейпер отказал, а почему именно так странно стал работать. Оснований не доверять internet.yandex.ru пока не было.

Была печаль и были веские причины в переходе именно на это ядро именно для этого сервера. В данный момент починка старого или прикручивание другого шейпера выглядят мелочью по сравнению с проблемами, которые были. Я не сторонник самых новых ядер, но так было необходимо сделать.

Обновился до ядра 2.6.35.8. Перестал работать шейпер, но не совсем перестал, а очень странно перестал. Поясню. Ставим лимит скорости на вход-выход 4000 кбит/с, коннектимся к серверу, получаем адрес и выходим в инет. Заходим на тест internet.yandex.ru и проверяем скорость. Значения в тесте скорости соотвествуют 100%. Далее пробуем скачать большой файл с гарантированно быстрого тестового хоста во внешней сети в надежде увидеть скорость порядка 500 кбайт/с, но скорость не превышает 20-30 кбайт/с (забираю файл через браузер, отдача веб-сервером). Выключаю шейпер, пересоединяюсь к серваку, снова провожу тест. Скорость на пределе. Скачиваю файл ... прекрасно тянет до 100 Мбит/с, т.е. на полную. Основной код шейпера таков: /usr/sbin/tc qdisc del dev $interface root /usr/sbin/tc qdisc add dev $interface root tbf rate ${upload}kbit burst $[1500+$upload*10] latency 50 /usr/sbin/tc qdisc del dev $interface ingress handle ffff: /usr/sbin/tc qdisc add dev $interface ingress handle ffff: /usr/sbin/tc filter add dev $interface parent ffff: protocol ip prio 10 u32 match ip src 0.0.0.0/0 police rate ${download}kbit buffer $[7000+$download*40] drop flowid :1 Шейпер поднимается в ip-up, а все остальное обертка и к делу отношения не имеет. Вопрос в том, почему тест internet.yandex.ru выдает нормальные результаты по скорости, которые соотвествуют тарифу, а реальная скорость передачи файла никакая. И что такого надо покрутить в ядре, чтобы вернуть все в рабочее состояние. Подозреваю что это что-то находится в секциях QoS и Netfilter, но вот никак не могу понять что именно. И стоит ли по этой причине обновлять iproute2 и в нем ли могут быть проблемы? Если для постановки диагноза нужны копии секций QoS и Netfilter из конфига ядра, то могу выложить, но там особенно ничего криминального нет.

Смысл не самое новое ядро поставить, а избежать паники, которая стала появляться регулярно на тех ядрах, которые я юзаю уже бог знает сколько. Паника стала возникать после перехода на accel-pptp, но я думаю что с чем-то еще совпало, только вот отследить причины kernel panic представляется сложным, потому что одновременно с переходом на accel-pptp менялось железо и во все сервера были поставлены двухголовые Intel ET с драйвером igb-2.3.4. Что именно повлияло? У меня как минимум три причины есть. Чтобы исключить вариант влияния accel и железа было решено перейти на совершенно другое ядро одним из 11 серверов и отмониторить ситуацию. В данный момент нагрузка на машину, которую я перевел под 2.6.35.8 около 5% ... клиентов 450-500. Все остальные машины на ядрах 2.6.27.54-55 (некоторые на 2.6.27.39), но в любом случае они унифицированы по ПО и ветке ядра. Отличается только одна машина, которая зачастила падать. Возможно это реакция на структуру трафика, а может железо. Пока переходил на новое ядро попутно были проблемы с запуском на нем accel-pptp, но вроде бы это все разрулил. Шейпер подождет. Мне чем больше нагрузка - тем лучше для теста. Поэтому на пару-тройку дней машина с новым ядром открутится без шейпера. Аналогичные падения бывали и на других машинах, но значительно реже. Раз в 15-20 реже. По сути все ядра панические, вероятность выпадения не исключена и ядра, которое не упадет не существует. Оно может не упать в конкретных условиях, а это уже другой разговор. К примеру то ядро, что живет на веб-сервере не живет на vpn сервере и наоборот. Разное железо и разные задачи. Хочу найти причину конфликта возникшего в связке kernel 2.6.27.54 - igb 2.3.4 - ppp-2.4.4-5 - accel-pptp - 0.8.4-5

Нашел причину падения скорости. Под новое ядро надо шейпер нахрен переписывать полностью. Там вообще все что можно переиграли и со старым шейпером режется скорость только в путь. Однако на старых ядрах до 2.6.33.х включительно все четко работает. Блин .... ей богу достало уже все. Теперь еще шейпер толковый придется ваять. ============== Сегодня на этом серваке будет ночь безлимитного инета. Все все на полной скорости. Пойду думать как теперь шейпить.

Да причем тут звери. У меня остальные сервера нормально работают, а этот падает. И мне надо не 100 коненктов, а 700 и скорость через сервер до 500 МБит/с как на других машинах, а на новом ядре 2.6.35.8 тормоза сплошные. И желательно чтобы kernel_panic не появлялось. Паник не появляется, а скорость пропала напрочь.

Slackware 12.2 ядро 2.6.35.8 accel 0.8.5 удалось установить после танцев с бубном только в комбинации с ppp-2.4.4 в виде пакета из поставки дистра 12.2 Никак не желало работать с ppp-2.4.5, который ставил вместо родного пакета. --------------------- Не удалось пофиксить следующие ошибки, поставил прямо с ними. ошибки сборки ppp-2.4.4 ipxcp.c: In function 'setipxnode': ipxcp.c:300: warning: pointer targets in assignment differ in signedness ipxcp.c:303: warning: pointer targets in assignment differ in signedness ipxcp.c: In function 'setipxname': ipxcp.c:346: warning: pointer targets in initialization differ in signedness ipxcp.c: In function 'ipxcp_cilen': ipxcp.c:596: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness ipxcp.c: In function 'ipxcp_addci': ipxcp.c:633: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness ipxcp.c: In function 'ipxcp_ackci': ipxcp.c:739: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness ipxcp.c: In function 'ipxcp_rejci': ipxcp.c:964: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness ipxcp.c: In function 'ipxcp_script': ipxcp.c:1456: warning: pointer targets in assignment differ in signedness ipxcp.c:1457: warning: pointer targets in assignment differ in signedness ipxcp.c: In function 'ipxcp_printpkt': В итоге жопа. Скорость выше 20 кбайт/с не поднимается вообще. Такое у меня уже было и с новыми ядрами accel 0.8.5 и ppp-2.4.4 убийственная комбинация. А с ppp-2.4.5 ошибка 619. Т.е. подключиться не получается .... жесть какая-то.

Да я уже тоже думаю что не pptpd, но поскольку он вроде как ядерный, то ... хз короче. Сейчас ставлю еще одну проверку на ядре 2.6.35.8. Уже вторые сутки не сплю. А версия 1.х ставится так же make server - make server_install или надо иначе? Я не пробовал еще, но говорят что как-то по другому надо ставить ее.

Про вывод kernel_panic я понял, что нибудь попробую придумать. Я реально уже на 95% уверен в том, что сервера валит какое-то оборудование клиентов. Если учесть что между серверами и клиентами стоит L2 - L3 - L2 оборудование, то это уже совсем кажется нереальным. Остается только запрос на порт 1723, потому что кроме него вообще ничего не слушается да и коммутаторы L2 не пропускают ничего кроме этого порта и GRE. Когда до этого был обычный pptp не accel, то были проблемы с производительностью и время от времени были большие задержки в пакетах. Переход прошел на accel быстро, но на ряде машин начались траблы со стабильностью. Сервера раньше не валились по году или более, а лишь выводились на временную профилактику. Ядра откатанные и отшлифованные за время работы, поэтому гарантированно рабочие, хоть и не супер-свежие 2.6.27.54-55. Поскольку в сети несколько серверов и клиент может соединяться в любой момент времени с любой из машин для выхода в сеть, то поиск затрудняется. Я не могу опеределить в какой момент времени какой из серверов упадет, но симптопы совершенно одинаковые при падении. Иногда до паники не доходит, но интерфейс, где висит pptpd, удается оживить только ребутом. Другие интерфейсы машины работают. Убить при этом демона pptpd невозможно, консоль сразу умирает и приходится переключаться на другую. Сетевые карты двухголовые Intel запущены с параметром igb IntMode=2,2,2,2 InterruptThrottleRate=3000,3000,3000,3000 RSS=4,4,4,4 ------------------- Пробовались разные версии ОС Slackware и разные ядра. Стабильности это не добавило никак. Мониторить одновременно трафик 11 серверов в поисках того пакета, который приводит к падению нереально. К тому же неизвестно что именно искать. Вечером поток трафика 2Гбит/с. Вариации с разными драйверами igb ничего не добавили в картинку. Может упасть и на 2.3.4 и на 2.2.9 драйвере. Ошибка всегда будет такой как на скрине. Вот такая ерунда.

При сборке accel 0.8.3-5 ошибки такие, но подозреваю что они роли особой не играют. bcrelay.c: In function 'main': bcrelay.c:384: warning: comparison with string literal results in unspecified behaviour bcrelay.c:389: warning: comparison with string literal results in unspecified behaviour bcrelay.c:389: warning: comparison with string literal results in unspecified behaviour bcrelay.c: In function 'mainloop': bcrelay.c:653: warning: pointer targets in assignment differ in signedness bcrelay.c: In function 'discoverActiveInterfaces': bcrelay.c:873: warning: comparison with string literal results in unspecified behaviour

При сборке ppp-2.4.4 ошибки такие ipxcp.c: In function 'setipxnode': ipxcp.c:300: warning: pointer targets in assignment differ in signedness ipxcp.c:303: warning: pointer targets in assignment differ in signedness ipxcp.c: In function 'setipxname': ipxcp.c:346: warning: pointer targets in initialization differ in signedness ipxcp.c: In function 'ipxcp_cilen': ipxcp.c:596: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness ipxcp.c: In function 'ipxcp_addci': ipxcp.c:633: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness ipxcp.c: In function 'ipxcp_ackci': ipxcp.c:739: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness ipxcp.c: In function 'ipxcp_rejci': ipxcp.c:964: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness ipxcp.c: In function 'ipxcp_script': ipxcp.c:1456: warning: pointer targets in assignment differ in signedness ipxcp.c:1457: warning: pointer targets in assignment differ in signedness ipxcp.c: In function 'ipxcp_printpkt': При сборке ppp-2.4.5 ошибок нет, но любая версия accel с ним не работает. Сервер выдает 619 ошибку при попытке соединения. Работает только с 2.4.4, но откуда такие ошибки при сборке.

А она и не передает, что логично. Под рукой нет девайса с COM портом вообще ... вот в чем жесть. Я не вижу начала kernel_panic и могу только догадываться куда копать. Сервак держится минут 10-15, а потом падает с этим паником.

Сегодня в результате экспериментов удалось получить такое. Теперь уже сижу и вообще не знаю что и думать. SKB_PULL - это вообще сетевой буфер. Т.е. на стадии приема пакета косяк.

На голую инсталлированную ОС Slackware 13.1 и 13.0 версия 0.8.х встает и даже удается заставить его работать, но обилие ошибок при установке пугает. Пока поставил 0.8.3 на версию 12.2 с ядром 2.6.27.55 (вышло на днях) и к ним pppd 2.4.4 Чуть позже напишу все ошибки, которые были при сборке, может быть кто-то сталкивался с таким. В основном это ошибки в ipxcp и sys-linux.c в pppd. Сервак не простоял 7 часов. Слег на 300 коннекте. Загрузка pptpd под 100% и висяк. Остальные машины стоят нормально и работают. Ничерта не понимаю. Даже полный клон конфигурации другой машины на этом сервере не живет. Все больше крепнет уверенность в том, что существует какой-то способ завалить машину на accele именно коннектом в pptpd. Стоит перевести абонентов с этой машины, на другую, которая стабильна, как она тут же падает. Снифером смотреть можно до потери пульса ... там поток 50-60 тыс. пакетов в секунду и было бы известно что именно искать. На интерфейсах ошибок нет ethtool -S выдает идеальную картинку. Просто все достало. Проблема уже с месяц как есть и за этот месяц перепробовал десятки комбинаций ядер, версий и настроек. Ничего не помогает, все отваливается.

Короче сижу обновляю пакеты по одному, но чую что это неправильно. За ночь разберусь. Если что быстро вкачу Slackware-current с диска и раскидаю конфиги по местам. Настроек-то минимум. Попытаюсь поставить 0.8.3, но чтобы без ошибок, а то теперь на bcrelay ругается warning'ом, хотя и собирается. Как бы сделать в accel --without-bcrelay или что-то типа того.

Хм, но раньше такого при пересборке ядра у меня не было. У меня Slackware 13.0 за основу взята, а на нее уже наставлено разного. Всегда все до этого получалось. Сорри за тупой вопрос, а как обновить headers в /usr/include ? В исходниках ядра вроде бы есть includes и там то что надо, а как это положить в нужное место?

На ядре 2.6.35.8 ошибка сборки accel 0.8.4 и 0.8.5 In file included from /usr/include/asm/types.h:4, from /usr/src/linux/include/linux/types.h:4, from /usr/include/asm/sigcontext.h:5, from /usr/include/bits/sigcontext.h:28, from /usr/include/signal.h:333, from pptp.c:35: /usr/src/linux/include/asm-generic/int-ll64.h:11:29: error: asm/bitsperlong.h: No such file or directory make[3]: *** [pptp.lo] Error 1 make[3]: Leaving directory `/usr/src/accel-pptp-0.8.4/pppd_plugin/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/src/accel-pptp-0.8.4/pppd_plugin' make[1]: *** [all] Error 2 make[1]: Leaving directory `/usr/src/accel-pptp-0.8.4/pppd_plugin' make: *** [plugin] Error 2 Куда копать? Тупой плоский VPN без радиуса с выдачей адресов из файла chap-secret валится.

Сетевые у меня хорошие Intel E1G42ET Gigabit Adapter Dual Port с драйвером igb 2.3.4 по 2 очереди на ядро и опции драйвера при запуске IntMode=2,2,2,2 InterruptThrottleRate=3000,3000,3000,3000 RSS=4,4,4,4 Такие карты стоят во всех 11 серверах. 10 серваков работают нормально, а 11-ый никак не хочет. Опции одинаковые, железо одинаковое, даже просто с точностью до точки конфиги совпадают. Есть подозрение что при попадании определенного пакета или при подключении определнного клиентского оборудования туннель pptp так падает, что больше не поднимается даже сервак. Пробовали переводить этих клиентов на другой сервер и его валят. Не валят лишь 0.8.3 версию. Существует ли какой-то баг, при котором версия 0.8.4 и 0.8.5 сваливает сервер. Не исключено, что это какой-то роутер из дешевых и т.п., но отследить никак не получается. 0.8.3 версия стоит без проблем перед этим. Клиентов на сервере много. Вечером до 200 Мбит/с трафика с шейперами с машины ... и все бы ничего, но стабильности не стало.

На 35 ядре сервак вообще плющит. Падает часто и как наиболее стабильное выявилось ядро 2.6.27.х uptime машин на нем до года без проблем. Начиная с версии 2.6.27.39 и даже 21. С ppp_generic_smp при выводе mpstat -P ALL idle некоторых CPU 102.04% т.е. больше 100%. Это вроде бы как не нормально.

Насколько актуально в многопроцессорных системах использовать ppp_generic_smp в версии 0.8.3? Ядро у меня 2.6.27.54, pppd-2.4.4, 4 cpu, сетевки intel драйвер igb 2.3.4 привязаны по smp_affinity к ядрам. Необходимо держать около 700 сессий. Раньше держало, но после обновления pppd до 2.4.5 и accel до 0.8.5 стало вываливаться и сервак висит. В данный момент как мог сделал откат. При включении ppp_generic_smp появился [kpppd/0-1-2-3] процесс и висит в топе примерно 1-2% cpu поедая. Это нормально для такого случая?

Стояла 0.8.3 версия - все работало. Обновил до 0.8.4 - начались рандомные падения интерфейса, на котором слушает pptpd, причем сервер не падает совсем, а pptpd уходит в 100% загрузку и спасает только перезагрузка по питанию. ping до сервера проходит, а вот ssh и pptpd не откликаются. Обновил до 0.8.5 - то же самое. Немного стабильнее. Аптайм сервера увеличился, но случайным образом машина может упасть. Никакой связи с нагрузкой на сервере нет. Может упать при 200 сессиях, а может жить при 700. Откатываться обратно на 0.8.3?