Перейти к содержимому
Калькуляторы

VPN сервер тормозит linux pptpd пользователей больше 600

Есть сервер. На базе какой-то серверной материнки от 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 в это время.

 

Не могу понять чего в нем тормозит и не справляется.

Как это определить ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

1. accel используется?

2. может зависшие сессии садят проц?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

1) accel нет. Чета не кажется, что он сильно поможет. Не в нем дело... Да и, говорят, подвисает оно.

2) Нет, за этим слежу. Не подвисают. Очень редко. Да, при этом становится еще хуже, но есть кучка скриптов, которые это все отслеживают и отстреливают.

Изменено пользователем elias292

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

elias292

Чета не кажется, что он сильно поможет. Не в нем дело... Да и, говорят, подвисает оно.

Неправильно кажется. Совершенно очевидно, что userspace реализация PPTP ущербна "чуть более чем полностью". Каждый прилетевший пакет влечет за собой передачу данных из ядра в userspace, а потом опять из userspace в ядро. Всё "украшено" кучей системных вызовов, переключений контекстов, и копированием всех данных по три раза. Оно по определению не может быстро работать и масштабироваться.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В принципе оно скомпиленное висит, просто мне премию дали когда оно неделю без зависания проработало, а щас оно уже 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Г. Может стоит разбросать уходящий на клиентов трафик на большее колличество сетевых карт ?

Изменено пользователем elias292

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Может стоит разбросать уходящий на клиентов трафик на большее колличество сетевых карт ?
смотря какой участок перегружен, если "на клиентов" - поможет, пока не перегрузится "в мир", ну, и наоборот, есстессно.

 

И, кстати, я что-то не понял, у Вас в -t mangle -I FORWARD вот так прямо, друг за дружкой идут последовательно MARK'и, а потом точно так же, один за другим - в tc filter'ы? Если у Вас больше 20 клиентов так делать просто нельзя, смотрите классификаторы flow, и u32 hashtable, поищите по форуму, этот вопрос часто обсуждается.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

а что oprofile показывает в момент "истины"?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

maxxxxu

да тут и без oprofile ясно если в iptables и tc последовательно проверяются 600 совпадений....

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

а 600 это много ?

 

iptables переделаю завтра,

как это сделать у tc не представляю.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Хм, не...

С iptables тоже не понимаю как сделать ...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

elias292

Сделайте так для tc: http://lartc.org/lartc.html#LARTC.ADV-FILTER.HASHING тогда и отпадет необходимость в iptables маркировать каждого абонента индивидуально.

 

Сейчас, в среднем, надо сделать 300 проверок в tc и 300 проверок в iptables. После переделки будет максимум 4, в среднем - 1.5

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

я так понимаю, что:

- на сервере таки только 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 - результат пока весьма удовлетворительный.

Изменено пользователем _VX

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

СПАСИБО! Щас почитаю вдумчиво.

 

Кстати поставил accel-pptp-0.8.3 сервер загнулся при 800 соединениях. (Load average подскочило до 110, у меня на это скрипт написан, и сервер сам перегрузился, после чего, было около 700 соединений, и не тормозило, трафик такой же.)

 

Уменьшил колличество правил iptables примерно в двое, он на это вообще не отреагировал. Никак.

Изменено пользователем elias292

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

бугога... Вот это мне понравилось:

>если же сервер - ещё и NAS для PPTP, то там ведь получается по отдельному

>интерфейсу на пользователя - в этом случае шейпим на интерфейсе pppX да и всё,

>не надо таких сложностей.

 

Написано много чего _до_ потом говорится это все фигня, надо делать по другому, намного проще.

Но как проще не написано...

 

У меня сейчас сделано так:

/sbin/tc qdisc add dev $PPP root tbf rate ${speed}bit latency 5ms burst $BURST

 

tbf на htb не меняется, tbf про ceil не знает.

 

Хотя идея понятна, буду копать...

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

я не очень понял из твоего поста - то ли у тебя 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 не очень хорошо, но уж как есть.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.