IzOt Опубликовано 14 января, 2016 · Жалоба Добрый день всем! Имеется бордер на 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. Кто их использовал? Есть ли нюансы и явные проблемы при работе с ними? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pppoetest Опубликовано 14 января, 2016 · Жалоба i7 Какой? Если чо-нить типа 4770 и старше, то явно не железо. У нас на таком же ~1,5Г летает. С такими же функциями. Нагрузка примерно 25%. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
GrandPr1de Опубликовано 14 января, 2016 · Жалоба дамминет прибит к 0 ядру?)) или на 9.х уже не актуально? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rdc Опубликовано 14 января, 2016 · Жалоба можно попробовать прибить, попытка не пытка /usr/bin/cpuset -l 0 -t $(procstat -t 0 | awk '/dummynet/ {print $2}') Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 15 января, 2016 · Жалоба Обновиться до 9.3. Тюнинговать сетевой стек. Тюнинг Нетграфа и переход на шейпер ng_car. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Azamat Опубликовано 15 января, 2016 · Жалоба Лучше всего разделить - на одну машину мост, на другую - НАТ, цена сейчас всего то +600 долл. Зато на паре таких машин сможете шейпить/натить порядка 4Гбит/с (от ппс зависит) У нас мост на i7-3770 CPU @ 3.40GHz, FreeBSD 8.4-RELEASE шейпит 5+1,5 Гбит на 75 проц загрузки ЦПУ Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vurd Опубликовано 15 января, 2016 · Жалоба Давным-давно когда я шейпил на фре, такая проблема появлялась от работы dummynet на нескольких ядрах. Решается прибиванием к одному из. Неужто ничего не изменилось до сих пор. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Liner's Опубликовано 15 января, 2016 · Жалоба студентов, попросил написать, и тут не сделали полностью))) фри 9.3 проц 4790к мать не понмню но не серверная сетевая x520-sr памяти 8 гигов поднято бгп фул вью, 2 аплинка приходят на одну десятку, на второй отдаём клиентам натим pf диманет прибит к 0 ядру при потоке от 800 метров его начинает колбасить, пробовали снять ограничение шейпера в исходящий трафик, на пару раз помогло, поднялись до 1,6 гига, вчера не помогло даже это утонули на 900 метрах. в планах вынести оттуда биллинг и зебру с натом вынести, но то не быстро, поэтому хотелось бы помощи в разборе ситуёвины. где то писалось что можно увеличить количество очередей на порт, не нашёл где это можно сделать. разнос аплинка и клиентов по разным портам сделали после нг когда начала появляется проблема, предполагалось что не хватает прерываний Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Azamat Опубликовано 15 января, 2016 · Жалоба У нас НАТ начинал затыкаться когда vmstat -m | grep alias | tr -s ' ' | cut -d ' ' -f 4 становился больше 450Мбайт, причем очень резко. Видимо нарастали накладные расходы на lookup по таблицам нат. До 100Мбайт i7-4930K CPU @ 3.40GHz может натить 6 + 1 Гбит/с Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rdc Опубликовано 15 января, 2016 · Жалоба Резкий рост таблиц ната возникает из-за того, что какой-то нехороший юзер начинает сканить интернет. Чтобы это не могло происходить, нужно ставить лимиты. Ниже - простая реализация лимита: /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; } Циферки правим по вкусу. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Liner's Опубликовано 15 января, 2016 · Жалоба сейчас трафик 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} сделали небольшой тюнинг, вечером посмотрим Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 15 января, 2016 · Жалоба сделали небольшой тюнинг, вечером посмотрим FD_SETSIZE увеличили ? И покажите вывод netstat -m Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Liner's Опубликовано 15 января, 2016 · Жалоба $ 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, его крутить не к этому Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 15 января, 2016 · Жалоба FD_SETSIZE увеличили ? он больше влияет на запись на винт, нам он зачем? интерфейсов у нас около 50, его крутить не к этому О! он во многих местах используется :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Liner's Опубликовано 15 января, 2016 · Жалоба хорошо, с другой стороны как нам поможет кол-во открытых дескрипторов? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Azamat Опубликовано 16 января, 2016 · Жалоба HT бы выключить ? а то нет картины реальной нагрузки на физические ядра Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Liner's Опубликовано 16 января, 2016 · Жалоба 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? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
GrandPr1de Опубликовано 16 января, 2016 · Жалоба странно, у меня около гигабитных нагрузках дамминет вообще в процессах не светится как pipe конфигурятся? в фаерволе конструкции tablearg используются? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Liner's Опубликовано 17 января, 2016 · Жалоба нет не используеья tablearg. используеьтся pipe tablearg)) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Mechanic Опубликовано 17 января, 2016 · Жалоба покажите кусок кода ipfw шейпера Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Liner's Опубликовано 18 января, 2016 · Жалоба 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, если у кого по МО есть, я бы взял на тест Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Liner's Опубликовано 19 января, 2016 · Жалоба была кстати идея, о том чтобы ip с которого все выходят вынести с интерфейсов и повесить его алиасом на lo. ребята что смотрели исходники pf на 9 ветке, описывали что там может блокироваться айпи интерфейса с которого идёт выход, отчего растёт очередь Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
GrandPr1de Опубликовано 19 января, 2016 · Жалоба видимо как пайп конфигурится никто и не увидит хотя раза три уже спросили Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Liner's Опубликовано 19 января, 2016 · Жалоба Если один глаз оторвать от стакана хоть на секунду и прочитать полтора сообщения назад, то в двух строчках можно найти искомое, как конфигурится пайп Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
GrandPr1de Опубликовано 19 января, 2016 · Жалоба для особенных "как конфигурится пайп?" это не кусок фаера с tablearg ip from table я хотел бы видеть ipfw pipe 100 config ... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...