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

dummynet ест 100% CPU бордера ищем решение

Добрый день всем!

 

Имеется бордер на FreeBSD 9.x (тазик) который шейпит и натит.

Характеристики тазика:

Проц i7 4гц

Память 8гб

Сетевая Intel x520 с 2умя 10Gb портами.

 

В первый 10Gb порт приходят 2 аплинка, с общим размером канала в 2 гигабита.

 

Второй порт 10Gb смотрит на абонентов.

 

Начались проблемы со скоростью у абонентов по вечерам.

 

Причина - 100.00% kernel{dummynet}

 

Проц уходит в 100.00% при загрузке канала в 1.2гб/с.

При этом трафик по аплинкам делится равномерно.

 

Что в данном случае является решением такой проблемы?

Из вариантов пока:

Апгрейд проца

Замена сетевой карты на более производительную

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

 

Кто что может посоветовать в данной ситуации?

И еще вопрос по карточкам Intel x710 или х720. Кто их использовал? Есть ли нюансы и явные проблемы при работе с ними?

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


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

i7 Какой? Если чо-нить типа 4770 и старше, то явно не железо. У нас на таком же ~1,5Г летает. С такими же функциями. Нагрузка примерно 25%.

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


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

дамминет прибит к 0 ядру?))

или на 9.х уже не актуально?

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


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

можно попробовать прибить, попытка не пытка

/usr/bin/cpuset -l 0 -t $(procstat -t 0 | awk '/dummynet/ {print $2}')

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


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

Обновиться до 9.3.

Тюнинговать сетевой стек.

Тюнинг Нетграфа и переход на шейпер ng_car.

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


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

Лучше всего разделить - на одну машину мост, на другую - НАТ, цена сейчас всего то +600 долл. Зато на паре таких машин сможете шейпить/натить порядка 4Гбит/с (от ппс зависит)

 

У нас мост на i7-3770 CPU @ 3.40GHz, FreeBSD 8.4-RELEASE шейпит 5+1,5 Гбит на 75 проц загрузки ЦПУ

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


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

Давным-давно когда я шейпил на фре, такая проблема появлялась от работы dummynet на нескольких ядрах. Решается прибиванием к одному из. Неужто ничего не изменилось до сих пор.

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


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

студентов, попросил написать, и тут не сделали полностью)))

фри 9.3

проц 4790к

мать не понмню но не серверная

сетевая x520-sr

памяти 8 гигов

 

поднято

бгп фул вью,

2 аплинка приходят на одну десятку, на второй отдаём клиентам

натим pf

диманет прибит к 0 ядру

 

при потоке от 800 метров его начинает колбасить, пробовали снять ограничение шейпера в исходящий трафик, на пару раз помогло, поднялись до 1,6 гига, вчера не помогло даже это утонули на 900 метрах.

 

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

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


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

У нас НАТ начинал затыкаться когда

 

vmstat -m | grep alias | tr -s ' ' | cut -d ' ' -f 4

 

становился больше 450Мбайт, причем очень резко. Видимо нарастали накладные расходы на lookup по таблицам нат. До 100Мбайт

i7-4930K CPU @ 3.40GHz может натить 6 + 1 Гбит/с

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


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

Резкий рост таблиц ната возникает из-за того, что какой-то нехороший юзер начинает сканить интернет.

Чтобы это не могло происходить, нужно ставить лимиты. Ниже - простая реализация лимита:

 

/usr/src/sys/netinet/libalias/alias_db.c

AddLink()

 

добавляем

 

switch (link_type) {
case LINK_ICMP:
       if(la->icmpLinkCount > 100) return (NULL);
       break;
case LINK_UDP:
       if(la->udpLinkCount > 2000) return (NULL);
       break;
case LINK_TCP:
       if(la->tcpLinkCount > 2000) return (NULL);
       break;
default:
       if(la->protoLinkCount > 100) return (NULL);
       break;
}

 

Циферки правим по вкусу.

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


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

сейчас трафик 711 на 170

 

last pid: 50743;  load averages:  1.81,  1.80,  1.71                                                                                            up 0+06:52:29  15:14:33
255 processes: 12 running, 204 sleeping, 39 waiting
CPU 0:  0.0% user,  0.0% nice, 57.9% system,  0.0% interrupt, 42.1% idle
CPU 1:  0.4% user,  0.0% nice,  0.4% system,  9.8% interrupt, 89.4% idle
CPU 2:  0.4% user,  0.0% nice,  0.0% system, 15.4% interrupt, 84.3% idle
CPU 3:  1.6% user,  0.0% nice,  0.0% system, 16.1% interrupt, 82.3% idle
CPU 4:  0.8% user,  0.0% nice,  0.0% system,  9.4% interrupt, 89.8% idle
CPU 5:  0.4% user,  0.0% nice,  0.0% system, 17.3% interrupt, 82.3% idle
CPU 6:  0.8% user,  0.0% nice,  0.0% system,  7.9% interrupt, 91.3% idle
CPU 7:  1.2% user,  0.0% nice,  0.0% system, 11.0% interrupt, 87.8% idle
Mem: 1014M Active, 322M Inact, 1291M Wired, 1629M Buf, 5158M Free
Swap: 4096M Total, 4096M Free

 PID USERNAME   PRI NICE   SIZE    RES STATE   C   TIME    WCPU COMMAND
  11 root       155 ki31     0K   128K CPU4    4 373:44  91.75% idle{idle: cpu4}
  11 root       155 ki31     0K   128K RUN     6 371:35  91.02% idle{idle: cpu6}
  11 root       155 ki31     0K   128K CPU7    7 372:09  90.48% idle{idle: cpu7}
  11 root       155 ki31     0K   128K CPU1    1 380:30  90.28% idle{idle: cpu1}
  11 root       155 ki31     0K   128K RUN     2 360:55  87.01% idle{idle: cpu2}
  11 root       155 ki31     0K   128K RUN     5 366:22  86.08% idle{idle: cpu5}
  11 root       155 ki31     0K   128K CPU3    3 360:03  84.62% idle{idle: cpu3}
   0 root       -92    0     0K   448K CPU0    0 155:51  52.54% kernel{dummynet}
  11 root       155 ki31     0K   128K RUN     0 272:01  52.44% idle{idle: cpu0}
  12 root       -92    -     0K   656K WAIT    3  16:02   7.71% intr{irq267: ix0:que }
  12 root       -92    -     0K   656K WAIT    3  14:54   6.79% intr{irq265: ix0:que }
  12 root       -92    -     0K   656K WAIT    5  14:57   6.64% intr{irq269: ix0:que }
  12 root       -92    -     0K   656K CPU2    2  15:57   5.47% intr{irq268: ix0:que }
  12 root       -92    -     0K   656K WAIT    5  12:22   4.98% intr{irq278: ix1:que }
  12 root       -92    -     0K   656K WAIT    2  15:30   4.74% intr{irq264: ix0:que }
  12 root       -92    -     0K   656K WAIT    3  14:16   4.69% intr{irq266: ix0:que }
  12 root       -92    -     0K   656K WAIT    3  16:18   4.59% intr{irq270: ix0:que }
  12 root       -92    -     0K   656K WAIT    2  16:29   4.49% intr{irq271: ix0:que }
  12 root       -92    -     0K   656K WAIT    5  12:42   4.49% intr{irq275: ix1:que }
  12 root       -92    -     0K   656K WAIT    5  12:18   4.49% intr{irq273: ix1:que }
  12 root       -92    -     0K   656K WAIT    4  12:18   4.39% intr{irq277: ix1:que }
  12 root       -92    -     0K   656K WAIT    7  11:14   4.39% intr{irq280: ix1:que }
  12 root       -92    -     0K   656K WAIT    4  12:36   4.10% intr{irq276: ix1:que }
  12 root       -92    -     0K   656K CPU5    5  11:43   4.00% intr{irq274: ix1:que }
  12 root       -92    -     0K   656K WAIT    4  12:37   3.66% intr{irq279: ix1:que }
2920 root        20    0   203M   146M select  6   8:53   2.78% snmpd
1939 root        20    0   348M   331M select  2   5:14   1.07% bgpd
3537 root        20  -15   217M   166M nanslp  2   5:41   0.88% perl5.16.3
5866 root        20    0 59988K 11692K nanslp  4   2:44   0.34% perl5.16.3
3333 mysql       20    0   835M   359M sbwait  3   1:37   0.24% mysqld{mysqld}

 

сделали небольшой тюнинг, вечером посмотрим

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


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

 

сделали небольшой тюнинг, вечером посмотрим

 

FD_SETSIZE увеличили ?

 

И покажите вывод netstat -m

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


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

$ netstat -m
33468/6732/40200 mbufs in use (current/cache/total)
33263/3111/36374/498328 mbuf clusters in use (current/cache/total/max)
33263/2449 mbuf+clusters out of packet secondary zone in use (current/cache)
0/503/503/249164 4k (page size) jumbo clusters in use (current/cache/total/max)
0/0/0/73826 9k jumbo clusters in use (current/cache/total/max)
0/0/0/41527 16k jumbo clusters in use (current/cache/total/max)
75083K/9917K/85000K bytes allocated to network (current/cache/total)
0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters delayed (4k/9k/16k)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0/0/0 sfbufs in use (current/peak/max)
0 requests for sfbufs denied
0 requests for sfbufs delayed
1 requests for I/O initiated by sendfile
0 calls to protocol drain routines

 

FD_SETSIZE увеличили ?

он больше влияет на запись на винт, нам он зачем?

интерфейсов у нас около 50, его крутить не к этому

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


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

FD_SETSIZE увеличили ?

он больше влияет на запись на винт, нам он зачем?

интерфейсов у нас около 50, его крутить не к этому

 

О! он во многих местах используется :)

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


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

хорошо, с другой стороны как нам поможет кол-во открытых дескрипторов?

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


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

HT бы выключить ? а то нет картины реальной нагрузки на физические ядра

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


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

last pid: 29014;  load averages: 12.79, 10.34,  8.52                                                                                            up 0+07:41:32  20:03:51
242 processes: 20 running, 191 sleeping, 31 waiting
CPU 0:  3.9% user,  0.0% nice,  1.2% system, 55.9% interrupt, 39.0% idle
CPU 1:  0.0% user,  0.0% nice,  0.0% system, 85.4% interrupt, 14.6% idle
CPU 2:  1.2% user,  0.0% nice,  1.6% system, 71.3% interrupt, 26.0% idle
CPU 3:  0.0% user,  0.0% nice,  0.0% system, 99.6% interrupt,  0.4% idle
CPU 4:  1.6% user,  0.0% nice,  0.8% system, 79.1% interrupt, 18.5% idle
CPU 5:  1.2% user,  0.0% nice,  0.4% system, 76.0% interrupt, 22.4% idle
CPU 6:  1.6% user,  0.0% nice,  1.6% system, 76.4% interrupt, 20.5% idle
CPU 7:  0.0% user,  0.0% nice,  100% system,  0.0% interrupt,  0.0% idle
Mem: 920M Active, 245M Inact, 1458M Wired, 1629M Buf, 5162M Free
Swap: 4096M Total, 4096M Free

 PID USERNAME   PRI NICE   SIZE    RES STATE   C   TIME    WCPU COMMAND
   0 root       -92    0     0K   448K CPU7    7 270:21 100.00% kernel{dummynet}
  12 root       -92    -     0K   656K WAIT    2  78:10  53.47% intr{irq265: ix0:que }
  12 root       -92    -     0K   656K RUN     5  72:20  49.37% intr{irq268: ix0:que }
  12 root       -92    -     0K   656K WAIT    4  70:17  44.09% intr{irq267: ix0:que }
  12 root       -92    -     0K   656K CPU6    6  64:02  43.85% intr{irq269: ix0:que }
  11 root       155 ki31     0K   128K RUN     0 338:10  42.19% idle{idle: cpu0}
  12 root       -92    -     0K   656K RUN     3  77:00  38.13% intr{irq266: ix0:que }
  12 root       -92    -     0K   656K WAIT    4  46:09  37.50% intr{irq274: ix1:que }
  12 root       -92    -     0K   656K WAIT    1  61:43  33.98% intr{irq264: ix0:que }
  12 root       -92    -     0K   656K CPU3    3  45:21  32.08% intr{irq280: ix1:que }
  12 root       -92    -     0K   656K RUN     6  46:09  31.10% intr{irq276: ix1:que }
  12 root       -92    -     0K   656K RUN     3  47:12  30.96% intr{irq273: ix1:que }
  12 root       -92    -     0K   656K CPU0    0  66:07  28.42% intr{irq270: ix0:que }
  12 root       -92    -     0K   656K CPU5    5  45:56  28.03% intr{irq275: ix1:que }
  11 root       155 ki31     0K   128K RUN     6 340:52  27.54% idle{idle: cpu6}
  12 root       -92    -     0K   656K WAIT    1  64:03  27.39% intr{irq271: ix0:que }
  12 root       -92    -     0K   656K CPU2    2  49:41  26.76% intr{irq279: ix1:que }
  12 root       -92    -     0K   656K WAIT    0  42:25  24.66% intr{irq277: ix1:que }
  12 root       -92    -     0K   656K RUN     1  41:46  24.22% intr{irq278: ix1:que }
  11 root       155 ki31     0K   128K RUN     5 332:06  23.68% idle{idle: cpu5}
  11 root       155 ki31     0K   128K RUN     4 333:52  21.24% idle{idle: cpu4}
  11 root       155 ki31     0K   128K RUN     2 324:02  18.85% idle{idle: cpu2}
  11 root       155 ki31     0K   128K CPU1    1 286:25  14.31% idle{idle: cpu1}
   0 root       -92    0     0K   448K -       5   0:08   2.10% kernel{ix1 que}
3369 root        20  -15 66164K 17544K nanslp  1   5:53   1.46% perl5.16.3
3370 root        20  -15   217M   166M nanslp  5   9:38   1.22% perl5.16.3
  11 root       155 ki31     0K   128K RUN     3 284:22   1.17% idle{idle: cpu3}
   0 root       -92    0     0K   448K -       5   0:06   1.17% kernel{ix1 que}
1935 root        20    0   316M   300M select  0   6:38   0.78% bgpd
3178 mysql       20    0   814M   376M sbwait  5   3:08   0.05% mysqld{mysqld}

тюнинг не помог, нагрузка 900-1000 ччн

будем разносить шейпер, и нат с бгп. нехватает прерываний. крутилок по тюнингу на карте немного.

есть что нибудь ещё производительное на 10G?

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


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

странно, у меня около гигабитных нагрузках дамминет вообще в процессах не светится

как pipe конфигурятся?

в фаерволе конструкции tablearg используются?

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


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

нет не используеья tablearg.

используеьтся pipe tablearg))

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


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

покажите кусок кода ipfw шейпера

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


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

net.inet.ip.dummynet.io_pkt_drop: 4505538

net.inet.ip.dummynet.io_pkt_fast: 31035971

и растут дропы

 

нарезка

pipe tablearg ip from таблица to any

pipe tablearg ip from any to таблица

 

из последнего махнули мать посвежее, разгнали чуть чуть проц.

не помогло, на гиге трафа уходит в полку диммунет.

в качестве теста на днях соберём систему на 10.2 фре, 16 гигов оперативы, и проц E5-2683v3. в 10 фре pf вроде как многопоточный, интересно будет посмотреть что выйдет. никто не отписался по поводу x710, если у кого по МО есть, я бы взял на тест

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


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

была кстати идея, о том чтобы ip с которого все выходят вынести с интерфейсов и повесить его алиасом на lo. ребята что смотрели исходники pf на 9 ветке, описывали что там может блокироваться айпи интерфейса с которого идёт выход, отчего растёт очередь

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


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

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

хотя раза три уже спросили

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


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

Если один глаз оторвать от стакана хоть на секунду и прочитать полтора сообщения назад, то в двух строчках можно найти искомое, как конфигурится пайп

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


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

для особенных

"как конфигурится пайп?" это не кусок фаера с tablearg ip from table

я хотел бы видеть

ipfw pipe 100 config ...

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


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

Join the conversation

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

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

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

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

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

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

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