Jump to content
Калькуляторы

производительность xxbt полка по кол-вы пиров

господа , стоит ретрекер на базе xxbt, есть подозрение что уперся в производительность. не поднимается выше 500к пиров/сек.

 

загрузка процессора не поднимается выше 5% памяти тоже достаточно, единственное что смущает это то, что вывод netstat -n -t | wc -l колеблется в пределах 55к-60к.

 

естественно, что основное количество сокетов в состоянии TIME_WAIT.

может кто-нить посоветовать как можно найти в чем затык и как вылечить

 

на серваке кроме ретрекера крутится только нода speedtest.net но там не много коннектов.

 

P.S. система debian linux 2.6.32-3-686-bigmem.

 

eef9be55aed68d427c463a0932d04cd8.png

 

 

Edited by orlik

Share this post


Link to post
Share on other sites

Лечится так:

 

net.ipv4.tcp_fin_timeout = 15

net.ipv4.tcp_keepalive_time = 1800

fs.aio-max-nr = 262144

 

Самое главное fs.aio-max-nr

Share this post


Link to post
Share on other sites
Лечится так:

 

net.ipv4.tcp_fin_timeout = 15

net.ipv4.tcp_keepalive_time = 1800

fs.aio-max-nr = 262144

 

Самое главное fs.aio-max-nr

угу спасибо , про fin_timeout уже сам нашел , а вот остальное не успел

Share this post


Link to post
Share on other sites

Да финтаймаут это ерунда, просто осталось от экспериментов(но лишней эта опция не будет, конечно), а вот fs.aio-max-nr 100% надо увеличивать, начиная от 300К торрентов. Чтобы убедиться в этом надо посмотреть что лежит в fs.aio-nr до того, как увеличили fs.aio-max-nr

Share this post


Link to post
Share on other sites
Да финтаймаут это ерунда, просто осталось от экспериментов(но лишней эта опция не будет, конечно), а вот fs.aio-max-nr 100% надо увеличивать, начиная от 300К торрентов. Чтобы убедиться в этом надо посмотреть что лежит в fs.aio-nr до того, как увеличили fs.aio-max-nr

уменьшил fs.aio-max-nr , помониторил , там все время 0.

Share this post


Link to post
Share on other sites

Уменьшите ещё сильнее и понаблюдайте за fs.aio-nr, когда начнёт колбасить ретрекер(медленно отвечать)

Share this post


Link to post
Share on other sites
Уменьшите ещё сильнее и понаблюдайте за fs.aio-nr, когда начнёт колбасить ретрекер(медленно отвечать)

самое обидное что все это ни на грамм не помогло, и по прежнему при достижении 500к пиров сервак временами перестает отвечать

сейчас в sysctl.conf :

net.ipv4.tcp_max_tw_buckets = 262144

net.ipv4.tcp_tw_reuse = 1

net.ipv4.tcp_tw_recycle = 1

net.core.somaxconn = 32768

net.core.netdev_max_backlog = 32768

net.ipv4.tcp_fin_timeout = 3

net.ipv4.tcp_keepalive_time = 1800

fs.aio-max-nr = 262144

 

 

 

 

 

Share this post


Link to post
Share on other sites

интересная статистика получается... накатал небольшой скрипт , который считает кол-во син и син-ак пакетов, итого

syn:303710 synack:103016 200694

syn:342522 synack:89281 253241

syn:411162 synack:103285 307877

syn:447426 synack:101550 345876

syn:421509 synack:102966 318543

syn:408326 synack:100073 308253

syn:424191 synack:98355 325836

syn:357757 synack:101669 256088

syn:344651 synack:100304 244347

 

 

получается что кол-во входящих синов в 2-3 раза больше чем кол-во исходящих син-ак пакетов.

Share this post


Link to post
Share on other sites

Не работает это скрипт... Имя устройства для дампа трафика поставил нужное

 

 

# perl 1.pl

syn:0 synack:0 0 0

syn:0 synack:0 0 0

syn:0 synack:0 0 0

syn:0 synack:0 0 0

^C

# perl -v

 

This is perl, v5.10.0 built for i486-linux-gnu-thread-multi

....

Share this post


Link to post
Share on other sites
Не работает это скрипт... Имя устройства для дампа трафика поставил нужное

 

 

# perl 1.pl

syn:0 synack:0 0 0

syn:0 synack:0 0 0

syn:0 synack:0 0 0

syn:0 synack:0 0 0

^C

# perl -v

 

This is perl, v5.10.0 built for i486-linux-gnu-thread-multi

....

хз , у меня работает. у вас надо дебажить

Share this post


Link to post
Share on other sites
Не работает это скрипт... Имя устройства для дампа трафика поставил нужное

 

 

# perl 1.pl

syn:0 synack:0 0 0

syn:0 synack:0 0 0

syn:0 synack:0 0 0

syn:0 synack:0 0 0

^C

# perl -v

 

This is perl, v5.10.0 built for i486-linux-gnu-thread-multi

....

там кстати фильтр стоит на порт 80 , может поэтому а вас и не работает ?

Share this post


Link to post
Share on other sites

ну вроде наметился некоторый прогресс

после выставления в sysctl

net.ipv4.tcp_max_tw_buckets = 512288

net.ipv4.tcp_tw_reuse = 1

net.ipv4.tcp_tw_recycle = 1

net.core.somaxconn = 32768

net.core.netdev_max_backlog = 32768

net.ipv4.tcp_fin_timeout = 5

net.ipv4.tcp_keepalive_time = 1800

net.ipv4.tcp_rfc1337 = 1

net.ipv4.tcp_timestamps = 0

net.ipv4.tcp_keepalive_intvl = 15

net.ipv4.tcp_keepalive_probes = 5

net.ipv4.tcp_rmem = 4096 131072 262144

net.ipv4.tcp_wmem = 4096 131072 262144

net.core.rmem_max = 262144

net.core.wmem_max = 262144

net.ipv4.tcp_syncookies = 1

net.ipv4.tcp_sack = 0

net.ipv4.tcp_window_scaling = 0

net.ipv4.tcp_no_metrics_save = 0

net.ipv4.tcp_moderate_rcvbuf = 1

сервер стал работать намного стабильнее , сейчас 570к и растет .

Share this post


Link to post
Share on other sites
попробуй ocelot вместо XBTT

спасибо за совет , но на данный момент сервер работает стабильно и с xbtt

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this