elias292 Опубликовано 28 сентября, 2009 · Жалоба Есть сервер. На базе какой-то серверной материнки от Intel, проц CPU Intel Core 2 Quad Q9650 На борту две гигабитные сетевухи. Одна отдельно (pci-x есессно): 00:19.0 Ethernet controller: Intel Corporation 82566DM-2 Gigabit Network Connection (rev 02) 01:00.0 Ethernet controller: Intel Corporation 82572EI Gigabit Ethernet Controller (Copper) (rev 06) 04:02.0 Ethernet controller: Intel Corporation 82541GI Gigabit Ethernet Controller (rev 05) drivers e1000e-0.5.11.2 Компилил его с бубном, помнится ставил там ограничение в 3000 (или 8000 ?) прерываний. А то он захлебывался, и падал. Щас не падает, но, временами, бывает, около часа-полутора в день, не может обеспечить скорость upload-а, хотя внешние каналы (два по 100 мбит) на аплоад свободны, на скачку в это время забиты. Если верить такой программе как munin, в это время растет колличество Resheduling interrupts Колличество прерываний на сетевухах уменьшается, до нуля. Сам VPN занимается шейпингом, и натит трафик. Последнее время переделал что трафик он отдает прямо в локальную сеть, напрямую, ибо циска не справлялась с нагрузкой. Колличество пользователей около 600-700 в это время. Не могу понять чего в нем тормозит и не справляется. Как это определить ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Valaskor Опубликовано 28 сентября, 2009 · Жалоба 1. accel используется? 2. может зависшие сессии садят проц? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
elias292 Опубликовано 28 сентября, 2009 (изменено) · Жалоба 1) accel нет. Чета не кажется, что он сильно поможет. Не в нем дело... Да и, говорят, подвисает оно. 2) Нет, за этим слежу. Не подвисают. Очень редко. Да, при этом становится еще хуже, но есть кучка скриптов, которые это все отслеживают и отстреливают. Изменено 28 сентября, 2009 пользователем elias292 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 28 сентября, 2009 · Жалоба elias292 Чета не кажется, что он сильно поможет. Не в нем дело... Да и, говорят, подвисает оно. Неправильно кажется. Совершенно очевидно, что userspace реализация PPTP ущербна "чуть более чем полностью". Каждый прилетевший пакет влечет за собой передачу данных из ядра в userspace, а потом опять из userspace в ядро. Всё "украшено" кучей системных вызовов, переключений контекстов, и копированием всех данных по три раза. Оно по определению не может быстро работать и масштабироваться. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
elias292 Опубликовано 28 сентября, 2009 (изменено) · Жалоба В принципе оно скомпиленное висит, просто мне премию дали когда оно неделю без зависания проработало, а щас оно уже 74 дня работает без больших проблем (я к тому что перегружать не хочу, а без этого неизвестно поднимется оно самостоятельно или вдруг чего забыл в стартовые скрипты написать). Тут еще вот какая проблема: Я делаю так: tc qdisc del dev eth0 root tc qdisc add dev eth0 root handle 2 htb default 1 tc class add dev eth0 parent 2: classid 2:6 htb rate 1000mbit tc qdisc del dev eth4 root tc qdisc add dev eth4 root handle 2 htb default 1 tc class add dev eth4 parent 2: classid 2:6 htb rate 1000mbit На eth4 у меня в двух vlan-ах висит уходящий трафик который шейпится примерно так: iptables -t mangle -I FORWARD -i ppp$N -j MARK --set-mark 0x1$N /sbin/tc class add dev eth4 parent 2:6 classid 2:1$N htb rate ${speed}bit burst 1k /sbin/tc qdisc add dev eth4 parent 2:1$N htb /sbin/tc filter add dev eth4 parent 2: protocol ip prio 3 handle 0x1$N fw classid 2:1$N А на eth0 у меня висит уходящий к клиентам трафик, который шейпится по простому: /sbin/tc qdisc add dev ppp$N root tbf rate ${speed}bit latency 5ms burst $BURST Вообще говоря, мне кажется, что проблемы начались, когда сумма ${speed}bit по всем пользователям перевалила за 1Г. Может стоит разбросать уходящий на клиентов трафик на большее колличество сетевых карт ? Изменено 28 сентября, 2009 пользователем elias292 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 28 сентября, 2009 · Жалоба Может стоит разбросать уходящий на клиентов трафик на большее колличество сетевых карт ?смотря какой участок перегружен, если "на клиентов" - поможет, пока не перегрузится "в мир", ну, и наоборот, есстессно. И, кстати, я что-то не понял, у Вас в -t mangle -I FORWARD вот так прямо, друг за дружкой идут последовательно MARK'и, а потом точно так же, один за другим - в tc filter'ы? Если у Вас больше 20 клиентов так делать просто нельзя, смотрите классификаторы flow, и u32 hashtable, поищите по форуму, этот вопрос часто обсуждается. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
maxxxxu Опубликовано 29 сентября, 2009 · Жалоба а что oprofile показывает в момент "истины"? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 29 сентября, 2009 · Жалоба maxxxxu да тут и без oprofile ясно если в iptables и tc последовательно проверяются 600 совпадений.... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
elias292 Опубликовано 29 сентября, 2009 · Жалоба а 600 это много ? iptables переделаю завтра, как это сделать у tc не представляю. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
elias292 Опубликовано 29 сентября, 2009 · Жалоба Хм, не... С iptables тоже не понимаю как сделать ... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 29 сентября, 2009 · Жалоба elias292 Сделайте так для tc: http://lartc.org/lartc.html#LARTC.ADV-FILTER.HASHING тогда и отпадет необходимость в iptables маркировать каждого абонента индивидуально. Сейчас, в среднем, надо сделать 300 проверок в tc и 300 проверок в iptables. После переделки будет максимум 4, в среднем - 1.5 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 29 сентября, 2009 · Жалоба Либо flow classifier :-) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
_VX Опубликовано 3 октября, 2009 (изменено) · Жалоба я так понимаю, что: - на сервере таки только NAT и нарезка скорости по IP клиента? в этом случае: - учитывай, что rate - это скорость, которую мы "гарантируем" клиенту. Сумма rate в классах пользователей не должна превышать rate корневого класса. Для того чтобы задать лимит пользователю, нужно использовать ceil. то есть, ставишь ceil - это лимит, а rate - скажем, раз в 100 меньше. - классы для пользователей должны иметь parent'ом корневой класс, а не qdisc. - уже к классам для пользователей можно прилепить например SFQ qdisc чтобы у пользователя программы друг другу меньше гадили. вообще, у меня нарезается так: - qdisc HTB для интерфейса, в нём классы: - корневой растёт из qdisc - дефолтный растёт из корневого - по классу на пользователя - растут из корневого. к каждому пользовательскому классу пришит qdisc SFQ фильтры: поскольку пользователей много (~2500 сейчас), а divisor в случае использования хэширования может быть не больше 256, то таким путём: - берём подсеть класса B, например 172.16.0.0/16 - представляем её как 256 сетей класса C - делаем хэш по 3-му октету адресов - получаем 256 "корзин" для подсетей - к каждой "корзине" пришиваем хэш по 4-му октету - получаем 256 "корзин" для пользователей в каждой подсети. - к каждой "корзине" пользователя пришиваем единственный фильтр, направляющий трафик в нужный класс. iptables в классификации не участвует вообще - используем u32 classifier. тестовый скрипт, демонтстрирующий вышеописанное, выглядит так: #!/bin/bash DEV=eth2 # root HTB qdisc tc qdisc add dev $DEV root handle 0001: htb default 00ff r2q 10000 # root class in root HTB qdisc tc class add dev $DEV parent 0001: classid 0001:0001 htb rate 1000Mbit ceil 1000Mbit quantum 32768 # default class in root HTB qdisc tc class add dev $DEV parent 0001:0001 classid 0001:00ff htb rate 32Kbit ceil 64Kbit prio 7 quantum 8192 # default class SFQ qdisc in root HTB qdisc tc qdisc add dev $DEV parent 0001:00ff handle 00ff: sfq perturb 10 # server own traffic class in root HTB qdisc tc class add dev $DEV parent 0001:0001 classid 0001:0002 htb rate 1Mbit ceil 10Mbit prio 1 quantum 16384 # server own traffic SFQ qdisc in root HTB qdisc tc qdisc add dev $DEV parent 0001:0002 handle 0002: sfq perturb 10 # client classes - 2 classes per sector == 2 clients per sector (clients IP .8, .123 in each sector) # sector id=1 tc class add dev $DEV parent 0001:0001 classid 0001:0108 htb rate 100kbit ceil 1000kbit prio 4 quantum 4096 tc class add dev $DEV parent 0001:0001 classid 0001:017b htb rate 100kbit ceil 1000kbit prio 4 quantum 4096 # sector id=2 tc class add dev $DEV parent 0001:0001 classid 0001:0208 htb rate 100kbit ceil 1000kbit prio 4 quantum 4096 tc class add dev $DEV parent 0001:0001 classid 0001:027b htb rate 100kbit ceil 1000kbit prio 4 quantum 4096 # sector id=3 tc class add dev $DEV parent 0001:0001 classid 0001:0308 htb rate 100kbit ceil 1000kbit prio 4 quantum 4096 tc class add dev $DEV parent 0001:0001 classid 0001:037b htb rate 100kbit ceil 1000kbit prio 4 quantum 4096 # ... # sector id=239 tc class add dev $DEV parent 0001:0001 classid 0001:ef08 htb rate 100kbit ceil 1000kbit prio 4 quantum 4096 tc class add dev $DEV parent 0001:0001 classid 0001:ef7b htb rate 100kbit ceil 1000kbit prio 4 quantum 4096 # SFQ qdiscs for client classes # sector id=1 tc qdisc add dev $DEV parent 0001:0108 handle 0108: sfq perturb 10 tc qdisc add dev $DEV parent 0001:017b handle 017b: sfq perturb 10 # sector id=2 tc qdisc add dev $DEV parent 0001:0208 handle 0208: sfq perturb 10 tc qdisc add dev $DEV parent 0001:027b handle 027b: sfq perturb 10 # sector id=3 tc qdisc add dev $DEV parent 0001:0308 handle 0308: sfq perturb 10 tc qdisc add dev $DEV parent 0001:037b handle 037b: sfq perturb 10 # ... # sector id=239 tc qdisc add dev $DEV parent 0001:ef08 handle ef08: sfq perturb 10 tc qdisc add dev $DEV parent 0001:ef7b handle ef7b: sfq perturb 10 # hashes for sectors # root /sbin/tc filter add dev $DEV parent 1: prio 4 protocol ip u32 /sbin/tc filter add dev $DEV parent 1: prio 4 handle 1: protocol ip u32 divisor 256 /sbin/tc filter add dev $DEV protocol ip parent 1: prio 4 u32 ht 800:: match ip dst 172.16.0.0/16 hashkey mask 0x0000ff00 at 16 link 1: # sector id=1 /sbin/tc filter add dev $DEV parent 1: prio 4 handle 0f01: protocol ip u32 divisor 256 tc filter add dev $DEV protocol ip parent 0001:0 prio 4 u32 ht 1:1: match ip dst 172.16.1.0/24 hashkey mask 0x000000ff at 16 link f01: # sector id=2 /sbin/tc filter add dev $DEV parent 1: prio 4 handle 0f02: protocol ip u32 divisor 256 tc filter add dev $DEV protocol ip parent 0001:0 prio 4 u32 ht 1:2: match ip dst 172.16.2.0/24 hashkey mask 0x000000ff at 16 link f02: # sector id=3 /sbin/tc filter add dev $DEV parent 1: prio 4 handle 0f03: protocol ip u32 divisor 256 tc filter add dev $DEV protocol ip parent 0001:0 prio 4 u32 ht 1:3: match ip dst 172.16.3.0/24 hashkey mask 0x000000ff at 16 link f03: # ... # sector id=239 /sbin/tc filter add dev $DEV parent 1: prio 4 handle 0fef: protocol ip u32 divisor 256 tc filter add dev $DEV protocol ip parent 0001:0 prio 4 u32 ht 1:ef: match ip dst 172.16.239.0/24 hashkey mask 0x000000ff at 16 link fef: # filter for server own traffic tc filter add dev $DEV parent 0001: prio 1 protocol ip u32 match ip src 192.168.254.1/32 classid 0001:0002 # filters for clients (clients IP .8, .123 in each sector) # sector id=1 tc filter add dev $DEV protocol ip parent 0001:0 handle 0f01:08:800 prio 4 u32 ht f01:8: match ip dst 172.16.1.8 flowid 0001:0108 tc filter add dev $DEV protocol ip parent 0001:0 handle 0f01:7b:800 prio 4 u32 ht f01:7b: match ip dst 172.16.1.123 flowid 0001:017b # sector id=2 tc filter add dev $DEV protocol ip parent 0001:0 handle 0f02:08:800 prio 4 u32 ht f02:8: match ip dst 172.16.2.8 flowid 0001:0208 tc filter add dev $DEV protocol ip parent 0001:0 handle 0f02:7b:800 prio 4 u32 ht f02:7b: match ip dst 172.16.2.123 flowid 0001:027b # sector id=3 tc filter add dev $DEV protocol ip parent 0001:0 handle 0f03:08:800 prio 4 u32 ht f03:8: match ip dst 172.16.3.8 flowid 0001:0308 tc filter add dev $DEV protocol ip parent 0001:0 handle 0f03:7b:800 prio 4 u32 ht f03:7b: match ip dst 172.16.3.123 flowid 0001:037b # ... # sector id=239 tc filter add dev $DEV protocol ip parent 0001:0 handle 0fef:08:800 prio 4 u32 ht fef:8: match ip dst 172.16.239.8 flowid 0001:ef08 tc filter add dev $DEV protocol ip parent 0001:0 handle 0fef:7b:800 prio 4 u32 ht fef:7b: match ip dst 172.16.239.123 flowid 0001:ef7b хэндлы фильтрам лучше задавать явно - весьма пользительно для последующего разбора скриптами, а также в сбойных ситуациях. "нулевой" подсети в данном примере быть не может - соответствующие идентификаторы используются для всяких "специальных" классов и т. д. а так - в теории, можно нарезать почти 64К пользователей. если же сервер - ещё и NAS для PPTP, то там ведь получается по отдельному интерфейсу на пользователя - в этом случае шейпим на интерфейсе pppX да и всё, не надо таких сложностей. правда, даже на очень хорошей машине в случае PPTP "узкое" место - это большое количество процессов (связка pppd+pptpd => 2 процесса на пользователя => большой load average => нестабильные задержки в прохождении пакетов). здесь важно не менее одного "честного" ядра процессора на сетевуху и тщательно курить /proc/interrupts и /proc/irq/irqN/smp_affinity хотя больше 600-700 одновременных сессий даже на хорошем сервере - проблематично. потому мы уходим от этого на контроль доступа на оконечке и шлюзу остаётся только NAT и нарезка скорости, без всяких PPTP - результат пока весьма удовлетворительный. Изменено 3 октября, 2009 пользователем _VX Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
elias292 Опубликовано 5 октября, 2009 (изменено) · Жалоба СПАСИБО! Щас почитаю вдумчиво. Кстати поставил accel-pptp-0.8.3 сервер загнулся при 800 соединениях. (Load average подскочило до 110, у меня на это скрипт написан, и сервер сам перегрузился, после чего, было около 700 соединений, и не тормозило, трафик такой же.) Уменьшил колличество правил iptables примерно в двое, он на это вообще не отреагировал. Никак. Изменено 5 октября, 2009 пользователем elias292 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
elias292 Опубликовано 5 октября, 2009 · Жалоба бугога... Вот это мне понравилось: >если же сервер - ещё и NAS для PPTP, то там ведь получается по отдельному >интерфейсу на пользователя - в этом случае шейпим на интерфейсе pppX да и всё, >не надо таких сложностей. Написано много чего _до_ потом говорится это все фигня, надо делать по другому, намного проще. Но как проще не написано... У меня сейчас сделано так: /sbin/tc qdisc add dev $PPP root tbf rate ${speed}bit latency 5ms burst $BURST tbf на htb не меняется, tbf про ceil не знает. Хотя идея понятна, буду копать... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
_VX Опубликовано 5 октября, 2009 · Жалоба я не очень понял из твоего поста - то ли у тебя NAT-PPTP-шейпинг в одном флаконе (сервере), то ли NAT+шейпинг отдельно, PPTP отдельно. потому - если нарезаешь по IP - один коленкор, если на интерфейсе - другой. вот этим ты меня смутил: "Сам VPN занимается шейпингом, и натит трафик. Последнее время переделал что трафик он отдает прямо в локальную сеть, напрямую, ибо циска не справлялась с нагрузкой." у меня есть и так (по IP), и так (по интерфейсу) - ибо переходный период: там, где контроль доступа на оконечке - нарезаю по IP (подробно описано как), там, где ещё нет - NAT+шейпинг+PPTP в одном флаконе, шейпинг - простейший: /sbin/tc qdisc add dev $1 root handle 1: htb default 20 r2q ${r2q} /sbin/tc class add dev $1 parent 1:1 classid 1:20 htb rate ${speed_lim}kbit burst ${burst_down}k prio 2 /sbin/tc qdisc add dev $1 parent 1:20 handle 20: sfq perturb 10 quantum 1500 /sbin/tc qdisc add dev $1 handle ffff: ingress /sbin/tc filter add dev $1 parent ffff: protocol ip prio 50 u32 match ip src 0.0.0.0/0 police rate ${speed_lim}kbit burst ${burst_up}k drop flowid :1 с ingress+police не очень хорошо, но уж как есть. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...