littlesavage Опубликовано 12 апреля, 2012 (изменено) · Жалоба Правда, говорят что "via ng*" может быть даже хуже по производительности, чем отсутствия указания - как-то там "не так" ipfw проходит по списку интерфейсов. Полная чушь. Никакого прохода ни по какому списку интерфейсов в этом случае не выполняется (да и не за чем). Буквально выполняется сравнение первых двух символов имени интерфейса пакета с 'n' и 'g'. Возможно, путают с использованием me/not me, которых действительно лучше избегать. Изменено 13 апреля, 2012 пользователем littlesavage Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaN5300 Опубликовано 16 апреля, 2012 (изменено) · Жалоба Настало время отметиться здесь. На всех трех серверах паники не было, но впервые столкнулись с невиданным ранее сбоем mpd-5.6. Закончилась вся память, SWAP-раздел мы не организовываем на маррутизаторах с SSD-дисками. MPD оставил все туннели как есть а сам вылетел с криками о попытках проникнуть в своп, котрого нет. 450 ng интерфейсов так и остались висеть, но траф по ним уже не шел. При рестарте mpd эти мёртвые ng-шки так и оставались в вистеме. Пришлось отправить ось в ребут. Сразу добавили графики RAM-а в cacti (не на всех серверах они были добавлены в свое время). И теперь наблюдаем такую картину. На всех серверах с 7.4-STABLE и 9.0-STABLE горизонтальная планка 24/7: Uploaded with ImageShack.us И на одном серваке вот такая картина: Uploaded with ImageShack.us Сам mpd жрёт < 300 Mb. В top ничего подозрительного не замечено. Куда девается память? С другой стороны если считать mem+buf+free=free то никуда она не девается судя по графику. Изменено 16 апреля, 2012 пользователем kaN5300 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
littlesavage Опубликовано 16 апреля, 2012 · Жалоба И на одном серваке вот такая картина: Сам mpd жрёт < 300 Mb. Много. В top ничего подозрительного не замечено. Куда девается память? С другой стороны если считать mem+buf+free=free то никуда она не девается судя по графику. vmstat -m. Графики мне напомнили давным давно пофикшенный kern/145865. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaN5300 Опубликовано 16 апреля, 2012 · Жалоба Type InUse MemUse HighUse Requests Size(s) sigio 1 1K - 1 64 filedesc 48 49K - 336446 16,32,64,128,512,1024,2048,4096 kenv 90 11K - 101 16,32,64,128 kqueue 0 0K - 3422 256,2048 proc-args 26 2K - 159407 16,32,64,128,256 hhook 2 1K - 2 128 acpitask 1 2K - 1 2048 ithread 134 21K - 134 32,128,256 CAM dev queue 5 1K - 5 128 CAM queue 17 1K - 86 16,32 KTRACE 100 13K - 100 128 acpisem 18 3K - 18 128 linker 223 122K - 282 16,32,64,128,256,512,1024,2048,4096 lockf 26 3K - 478 64,128 loginclass 1 1K - 1043 64 CAM SIM 5 2K - 5 256 temp 1609 66K - 21859887 16,32,64,128,256,512,1024,2048,4096 devbuf 722 6957K - 738 16,32,64,128,256,512,1024,2048,4096 module 275 35K - 275 128 mtx_pool 2 16K - 2 ata_pci 2 1K - 2 64 CAM periph 4 1K - 20 16,32,64,128,256 subproc 286 290K - 335305 512,4096 proc 2 16K - 2 session 23 3K - 1079 128 pgrp 24 3K - 1124 128 cred 38 6K - 2955072 64,256 uidinfo 5 3K - 124845 128,2048 plimit 13 4K - 182753 256 CAM XPT 39 22K - 139 32,64,128,1024,2048 sysctltmp 0 0K - 1739034 16,32,64,128,256,4096 sysctloid 6321 317K - 6447 16,32,64,128 sysctl 0 0K - 399196 16,32,64 tidhash 1 16K - 1 callout 5 2560K - 5 umtx 1716 215K - 1716 128 p1003.1b 1 1K - 1 16 bus-sc 101 100K - 3590 16,32,128,256,512,1024,2048,4096 bus 869 87K - 39975 16,32,64,128,256,1024,2048 devstat 8 17K - 8 32,4096 eventhandler 76 6K - 76 64,128 kbdmux 6 18K - 6 16,512,1024,2048 kobj 176 704K - 271 4096 Per-cpu 1 1K - 1 32 LED 8 1K - 8 16,128 rman 266 31K - 666 16,32,128 sbuf 1 1K - 56033 16,32,64,128,256,512,1024,2048,4096 stack 0 0K - 2 256 taskqueue 47 4K - 47 16,32,128 Unitno 15 1K - 1780545 32,64 iov 0 0K - 15558 16,64,128,256,512 select 760 95K - 760 128 ioctlops 0 0K - 39179996 16,32,64,128,256,512,1024 msg 4 30K - 4 2048,4096 sem 4 106K - 4 2048,4096 shm 1 20K - 1 tty 20 20K - 27 1024,2048 pts 1 1K - 6 256 mbuf_tag 105 4K - 3686550832 32,64 shmfd 1 8K - 1 DEVFS1 83 42K - 104 512 pcb 34 158K - 1727443 16,32,64,128,1024,2048,4096 soname 4 1K - 56304997 16,32,128 acl 0 0K - 1561 4096 vfscache 1 1024K - 1 cl_savebuf 0 0K - 27 64 vfs_hash 1 512K - 1 DEVFS3 99 25K - 133 256 vnodes 2 1K - 2 256 vnodemarker 0 0K - 48773 512 mount 61 3K - 131 16,32,64,128,256 BPF 788 99K - 8853 128 ether_multi 1576 62K - 16546 16,64 ifaddr 2393 817K - 26007 32,512,4096 ifnet 789 1584K - 8860 128,256,512,1024,2048,4096 clone 5 20K - 5 4096 arpcom 5 1K - 5 16 lltable 1229 505K - 10443 256,512 DEVFS 15 1K - 16 16,128 routetbl 934 165K - 230081 32,64,128,256,512 netflow_hash 1 3072K - 1 netflow_general 1 1K - 1 256 netgraph_msg 0 0K - 24217550 64,128,256,512,1024 netgraph_node 7130 1783K - 144452 256 netgraph_hook 20112 2514K - 330418 128 netgraph 5611 11213K - 91792 64,128,256,512,1024,4096 netgraph_iface 782 98K - 8847 128 netgraph_ksock 784 98K - 13928 128 netgraph_sock 4 1K - 43306 128 netgraph_path 0 0K - 12390542 16,32 igmp 788 197K - 8853 256 in_multi 785 197K - 8269 256 IpFw/IpAcct 18 3K - 32 16,32,64,128 ipfw_tbl 5250 1313K - 10748 256 sctp_iter 0 0K - 3 256 sctp_ifn 3 1K - 3 128 sctp_ifa 4 1K - 4 128 sctp_vrf 1 1K - 1 64 sctp_a_it 0 0K - 3 16 hostcache 1 28K - 1 syncache 1 96K - 1 libalias 482503 60441K - 244360384 128 sctpnat 6 80K - 6 rpc 2 1K - 2 256 audit_evclass 179 6K - 218 32 jblocks 8 2K - 8 128,256 savedino 0 0K - 291 256 sbdep 0 0K - 2266 64 jsegdep 0 0K - 21436 64 jseg 0 0K - 5304 128 jfreefrag 0 0K - 159 128 jnewblk 0 0K - 15739 128 jremref 0 0K - 2765 128 jaddref 0 0K - 2773 128 freedep 0 0K - 35 64 freework 1 2K - 606 128,2048 newdirblk 0 0K - 6 64 dirrem 0 0K - 2753 128 mkdir 0 0K - 12 128 diradd 0 0K - 2761 128 freefile 0 0K - 472 64 freeblks 0 0K - 471 128 freefrag 0 0K - 159 128 indirdep 0 0K - 2097 128 newblk 1 128K - 15740 256 bmsafemap 2 9K - 2327 256 inodedep 2 513K - 5176 512 pagedep 2 129K - 422 256 ufs_dirhash 858 183K - 864 16,32,64,128,256,512 ufs_mount 12 50K - 12 512,4096 vm_pgdata 1 128K - 1 UMAHash 3 13K - 10 512,1024,2048,4096 memdesc 1 4K - 1 4096 atkbddev 2 1K - 2 64 pfs_nodes 21 6K - 21 256 GEOM 59 11K - 782 16,32,64,128,256,512,1024 acpidev 52 4K - 52 64 pci_link 16 2K - 16 64,128 apmdev 1 1K - 1 128 acpi_perf 6 3K - 6 512 acpiintr 1 1K - 1 64 isadev 5 1K - 5 128 qpidrv 1 1K - 1 16 io_apic 1 2K - 1 2048 entropy 1024 64K - 1024 64 MCA 7 1K - 7 64,128 msi 20 3K - 20 128 nexusdev 4 1K - 4 16 cdev 7 2K - 7 256 acpica 4954 536K - 76964 16,32,64,128,256,512,1024,2048,4096 UART 6 4K - 6 16,512,1024 netgraph_mppc 0 0K - 1 1024 netgraph_ppp 782 9384K - 8847 netgraph_bpf 8772 1097K - 123364 128 Перешел по ссылке, глянул сисктл, hw.bus.devctl_disable: 0 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bird_of_Luck Опубликовано 16 апреля, 2012 · Жалоба Возможно, путают с использованием me/not me, которых действительно лучше избегать. Вообще говоря, там тоже все не сказать чтобы страшно - сейчас там хеш вместо прохода всего списка. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 17 апреля, 2012 · Жалоба По идее можно написать скриптик который будет убивать ноды через ngctl в случае вылета mpd5. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaN5300 Опубликовано 18 апреля, 2012 · Жалоба По идее можно написать скриптик который будет убивать ноды через ngctl в случае вылета mpd5. Это понятно, но хотелось бы обнаружить причину всех бед, т.к. аналогичный сервак (по софту и нагрузке) работает стабильно. Вчера ночью перезагрузили mpd (первый скачек на графике) и потом еще крон видимо что-то делал, прибавился еще cached. Ждём когда free опустится до нуля и будем смотреть, повторится ли замеченный ранее симптом. Uploaded with ImageShack.us Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaN5300 Опубликовано 20 апреля, 2012 · Жалоба Обнаружил кое-какое расхождение в конфиге с другими NAS-серверами на 9.0, подправил и обновил через portupgrade кваггу и все required порты. Заодно подтянул новые исходники через cvsup и пересобрал мир с ядром. Осталось ребутнуть. Во время этих мероприятий Memory free резко подскочило, а Cache соответственно уменьшился Uploaded with ImageShack.us Теперь стало заметно что утекает память относительно своего исходного размера. 24 назад было 1610, сейчас на 300 мегов меньше. Есть подозрение, что mpd зависнет когда абсолютно вся память таким образом исчезнет. Но дожидаться мы этого не будем, произведем ребут. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
roysbike Опубликовано 21 апреля, 2012 · Жалоба Обнаружил кое-какое расхождение в конфиге с другими NAS-серверами на 9.0, подправил и обновил через portupgrade кваггу и все required порты. Заодно подтянул новые исходники через cvsup и пересобрал мир с ядром. Осталось ребутнуть. Во время этих мероприятий Memory free резко подскочило, а Cache соответственно уменьшился Uploaded with ImageShack.us Теперь стало заметно что утекает память относительно своего исходного размера. 24 назад было 1610, сейчас на 300 мегов меньше. Есть подозрение, что mpd зависнет когда абсолютно вся память таким образом исчезнет. Но дожидаться мы этого не будем, произведем ребут. у вас память переходит в Inactive?? Дело в том , что у меня почти на всех насах так. И по 2 месяца уже пашут. freemem 150 мб обычно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaN5300 Опубликовано 24 апреля, 2012 · Жалоба Перезагрузили: Uploaded with ImageShack.us Всё равно тенденция не здоровая. Будем смотреть за состоянием mpd теперь. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Vitalij K Опубликовано 21 ноября, 2012 · Жалоба Илья ну что решил свою проблему? Короче у меня проблема аналогичная и вот какая: Есть Роутер софтовый на FreeBSD 9.0R i386, netgraph через tee генерит netflow, NAT через PF (очень мало), шейпит IPFW (dummynet), IPv6 в ядре включен Сетевая карточка i350 - Quad PORT ядро: options NETGRAPH options IPFIREWALL options IPDIVERT options IPSTEALTH options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=100 options IPFIREWALL_FORWARD options DUMMYNET options HZ=1000 # pf device pf device pflog device pfsync Также настроен Quagga OSPF отдает маршрут по умолчанию и получает порядка 1к маршрутов Вообщем железо все проверил, сеть.карточки менял. Суть в том что роутер перегружается произвольно после (1-40 минут) добавления в ospfd.conf default-information originate always metric 1 metric-type 1 (т.е. чтобы роутер анонсил себя в качестве шлюза) как только побежал трафик сервак произвольно перегружается. Кернел Дампы не пишет. Из того что мне удалось выяснить: отключил модули kldload ng_ipfw kldload ng_ether kldload ng_tee kldload ng_netflow Ессено трафик пока не считается, пока полет нормальный, нужно ждать. Так вот что то подсказывает мне, что изменения относительно netflow v9 в FreeBSD 9.0 некорректно работают с IPv6 У кого какие идеи? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaN5300 Опубликовано 21 ноября, 2012 · Жалоба Привет, Виталий! У нас ребуты пропали после перехода на архитектуру AMD64 и выкидывания из ядра IPV6. <kan5300@nas1>uptime 3:48PM up 112 days, 15:29, 2 users, load averages: 2.63, 2.20, 2.05 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dyr Опубликовано 30 ноября, 2012 · Жалоба У меня два сервера с 9.0 в продакшене работают с лета без единой проблемы. Тоже сетёвка i350 с lagg, NAT + dummynet + ng_netflow. IPv6 включен (и на одном даже используется), архитектура amd64. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
polmax Опубликовано 30 ноября, 2012 · Жалоба У меня два сервера с 9.0 в продакшене работают с лета без единой проблемы. Тоже сетёвка i350 с lagg, NAT + dummynet + ng_netflow. IPv6 включен (и на одном даже используется), архитектура amd64. У нас тоже работает нормально, но IPv6 пришло отключить, так как наблюдаются проблемы: mpd5 + quagga. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kirush Опубликовано 23 декабря, 2012 (изменено) · Жалоба Помогите разобраться что за чудева творятся, 2 NASa на freebsd 9.1 amd64 Первый: 2 x XEONA 6 ядерных с 2портовой intel (igb) сетевухой: Функционал: radius, mpd5, netgraph (шейпер) при нагрузке: # netstat -w1 -h -Iigb0 input (igb0) output packets errs idrops bytes packets errs bytes colls 15k 0 0 14M 14k 0 6.8M 0 14k 0 0 12M 13k 0 6.4M 0 16k 0 0 15M 15k 0 6.6M 0 13k 0 0 11M 14k 0 6.9M 0 ---- last pid: 71625; load averages: 6.33, 7.94, 8.85 up 0+11:43:08 13:45:39 289 processes: 29 running, 198 sleeping, 2 zombie, 60 waiting CPU 0: 0.0% user, 0.0% nice, 2.3% system, 22.1% interrupt, 75.6% idle CPU 1: 0.8% user, 0.0% nice, 2.3% system, 29.8% interrupt, 67.2% idle CPU 2: 0.0% user, 0.0% nice, 4.6% system, 27.5% interrupt, 67.9% idle CPU 3: 0.0% user, 0.0% nice, 1.5% system, 24.4% interrupt, 74.0% idle CPU 4: 0.0% user, 0.0% nice, 2.3% system, 13.0% interrupt, 84.7% idle CPU 5: 0.0% user, 0.0% nice, 0.0% system, 22.1% interrupt, 77.9% idle CPU 6: 0.0% user, 0.0% nice, 2.3% system, 23.7% interrupt, 74.0% idle CPU 7: 0.0% user, 0.0% nice, 0.0% system, 23.7% interrupt, 76.3% idle CPU 8: 0.0% user, 0.0% nice, 4.6% system, 6.1% interrupt, 89.3% idle CPU 9: 0.0% user, 0.0% nice, 9.2% system, 0.0% interrupt, 90.8% idle CPU 10: 0.0% user, 0.0% nice, 10.7% system, 0.0% interrupt, 89.3% idle CPU 11: 0.0% user, 0.0% nice, 17.6% system, 0.0% interrupt, 82.4% idle CPU 12: 0.0% user, 0.0% nice, 13.0% system, 0.0% interrupt, 87.0% idle CPU 13: 0.0% user, 0.0% nice, 20.6% system, 0.0% interrupt, 79.4% idle CPU 14: 0.0% user, 0.0% nice, 16.8% system, 0.0% interrupt, 83.2% idle CPU 15: 0.8% user, 0.0% nice, 22.1% system, 0.0% interrupt, 77.1% idle CPU 16: 0.0% user, 0.0% nice, 19.8% system, 0.0% interrupt, 80.2% idle CPU 17: 0.0% user, 0.0% nice, 18.3% system, 0.0% interrupt, 81.7% idle CPU 18: 0.0% user, 0.0% nice, 18.3% system, 0.0% interrupt, 81.7% idle CPU 19: 0.0% user, 0.0% nice, 18.3% system, 0.0% interrupt, 81.7% idle CPU 20: 3.1% user, 0.0% nice, 16.8% system, 0.0% interrupt, 80.2% idle CPU 21: 0.8% user, 0.0% nice, 23.7% system, 0.0% interrupt, 75.6% idle CPU 22: 0.0% user, 0.0% nice, 21.4% system, 0.0% interrupt, 78.6% idle CPU 23: 0.0% user, 0.0% nice, 20.6% system, 0.0% interrupt, 79.4% idle Mem: 130M Active, 705M Inact, 955M Wired, 417M Buf, 2130M Free Swap: 4096M Total, 4096M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 155 ki31 0K 384K CPU10 10 665:48 93.36% idle{idle: cpu10} 11 root 155 ki31 0K 384K CPU9 9 672:06 89.89% idle{idle: cpu9} 11 root 155 ki31 0K 384K RUN 8 661:47 88.57% idle{idle: cpu8} 11 root 155 ki31 0K 384K CPU11 11 664:58 88.28% idle{idle: cpu11} 11 root 155 ki31 0K 384K RUN 15 624:01 81.98% idle{idle: cpu15} 11 root 155 ki31 0K 384K CPU19 19 622:58 80.57% idle{idle: cpu19} 11 root 155 ki31 0K 384K CPU22 22 623:50 79.59% idle{idle: cpu22} 11 root 155 ki31 0K 384K CPU0 0 588:43 79.39% idle{idle: cpu0} 11 root 155 ki31 0K 384K CPU16 16 624:53 79.30% idle{idle: cpu16} 11 root 155 ki31 0K 384K CPU12 12 626:01 78.47% idle{idle: cpu12} 11 root 155 ki31 0K 384K CPU13 13 624:44 77.49% idle{idle: cpu13} 11 root 155 ki31 0K 384K CPU21 21 622:56 77.10% idle{idle: cpu21} 11 root 155 ki31 0K 384K CPU4 4 593:10 77.10% idle{idle: cpu4} 11 root 155 ki31 0K 384K CPU14 14 625:34 76.76% idle{idle: cpu14} 11 root 155 ki31 0K 384K CPU18 18 624:14 76.46% idle{idle: cpu18} 11 root 155 ki31 0K 384K CPU23 23 622:01 75.39% idle{idle: cpu23} 11 root 155 ki31 0K 384K RUN 20 624:02 74.85% idle{idle: cpu20} 11 root 155 ki31 0K 384K RUN 17 623:24 74.56% idle{idle: cpu17} 11 root 155 ki31 0K 384K CPU5 5 596:37 74.17% idle{idle: cpu5} 11 root 155 ki31 0K 384K CPU2 2 599:30 69.48% idle{idle: cpu2} 11 root 155 ki31 0K 384K CPU3 3 572:30 66.99% idle{idle: cpu3} 11 root 155 ki31 0K 384K CPU7 7 581:33 66.80% idle{idle: cpu7} 11 root 155 ki31 0K 384K CPU1 1 594:19 62.79% idle{idle: cpu1} 11 root 155 ki31 0K 384K CPU6 6 599:50 62.60% idle{idle: cpu6} 12 root -92 - 0K 960K WAIT 1 85:58 37.79% intr{irq257: igb0:que} 12 root -92 - 0K 960K WAIT 6 85:29 37.35% intr{irq262: igb0:que} 12 root -92 - 0K 960K WAIT 2 86:38 29.20% intr{irq258: igb0:que} 12 root -92 - 0K 960K WAIT 7 101:38 29.05% intr{irq263: igb0:que} В то же время есть второй NAS на i3 c em драйверами: last pid: 98036; load averages: 1.39, 1.49, 1.54 up 0+13:05:00 13:51:13 111 processes: 6 running, 87 sleeping, 18 waiting CPU 0: 0.0% user, 0.0% nice, 54.8% system, 0.0% interrupt, 45.2% idle CPU 1: 0.0% user, 0.0% nice, 16.1% system, 6.5% interrupt, 77.4% idle CPU 2: 0.0% user, 0.0% nice, 32.3% system, 0.0% interrupt, 67.7% idle CPU 3: 0.0% user, 0.0% nice, 35.5% system, 0.0% interrupt, 64.5% idle Mem: 34M Active, 777M Inact, 495M Wired, 6080K Cache, 209M Buf, 616M Free Swap: 4096M Total, 4096M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 155 ki31 0K 64K RUN 1 683:14 77.39% idle{idle: cpu1} 11 root 155 ki31 0K 64K RUN 3 645:47 71.78% idle{idle: cpu3} 11 root 155 ki31 0K 64K CPU2 2 642:18 67.77% idle{idle: cpu2} 11 root 155 ki31 0K 64K RUN 0 570:15 51.46% idle{idle: cpu0} 0 root -92 0 0K 224K CPU0 0 192:43 44.97% kernel{em0 que} 13 root -16 - 0K 64K sleep 2 84:00 23.00% ng_queue{ng_queue1} 13 root -16 - 0K 64K sleep 1 84:08 22.75% ng_queue{ng_queue0} 13 root -16 - 0K 64K sleep 2 83:57 22.36% ng_queue{ng_queue2} 13 root -16 - 0K 64K sleep 1 83:59 21.19% ng_queue{ng_queue3} 12 root -92 - 0K 288K WAIT 2 36:13 9.47% intr{irq265: em1:rx 0} 12 root -92 - 0K 288K WAIT 2 7:31 1.66% intr{irq266: em1:tx 0} 927 root 20 0 202M 41504K select 1 5:22 0.49% mpd5{mpd5} 995 root 20 0 31668K 4420K select 3 0:13 0.10% zebra 12 root -60 - 0K 288K WAIT 1 3:57 0.00% intr{swi4: clock} 0 root -92 0 0K 224K - 1 2:14 0.00% kernel{dummynet} 1101 root 20 0 37996K 9240K uwait 0 1:25 0.00% utm5_radius{utm5_radius} 15 root -16 - 0K 16K - 1 1:18 0.00% yarrow при нагрузке: # netstat -w1 -h -Iem0 input (em0) output packets errs idrops bytes packets errs bytes colls 20k 0 0 21M 16k 0 6.7M 0 21k 0 0 23M 16k 0 7.1M 0 22k 0 0 24M 17k 0 7.7M 0 После увиденного начал крутить тюнинг, но нагрузки смешные. В часы пик (до 300-400Мбит/с на роутер) нагрузка на мощном сервере возрастает до 20 average и все заваливается очередями. Накрутил до такого: # less /boot/loader.conf netgraph_load="YES" ng_ipfw_load="YES" ng_car_load="YES" ng_nat_load="YES" autoboot_delay="1" kern.ipc.maxpipekva="32000000" hw.igb.rxd=4096 hw.igb.txd=4096 hw.igb.max_interrupt_rate=32000 # less /etc/sysctl.conf # $FreeBSD: src/etc/sysctl.conf,v 1.8.38.1 2010/12/21 17:10:29 kensmith Exp $ # # This file is read when going to multi-user and its contents piped thru # ``sysctl'' to adjust kernel values. ``man 5 sysctl.conf'' for details. # # Uncomment this to prevent users from seeing information about processes that # are being run under another UID. #security.bsd.see_other_uids=0 net.inet.ip.forwarding=1 net.inet.ip.fastforwarding=1 net.inet.ip.redirect=0 net.inet.ip.intr_queue_maxlen=10240 net.inet.tcp.delayed_ack=0 net.inet.tcp.sendspace=3217968 net.inet.tcp.recvspace=3217968 net.inet.tcp.blackhole=2 net.inet.tcp.drop_synfin=1 net.inet.udp.recvspace=65535 net.inet.udp.maxdgram=57344 net.inet.udp.blackhole=1 net.inet.icmp.drop_redirect=1 net.inet.icmp.icmplim=200 net.inet.icmp.drop_redirect=1 kern.ipc.nmbclusters=400000 kern.ipc.somaxconn=8192 kern.ipc.maxsockbuf=83886080 kern.ipc.maxsockets=204800 kern.ipc.shmall=8388608 net.local.stream.recvspace=65535 net.local.stream.sendspace=65535 net.link.ether.inet.proxyall=1 net.inet.tcp.tso=0 net.graph.maxdgram=8388608 net.graph.recvspace=8388608 dev.igb.0.rx_processing_limit=-1 dev.igb.1.rx_processing_limit=-1 но и это не спасло. Правила ipfw: # ipfw show 00010 181884 16382428 deny ip from any to table(50) dst-port 135-139,445 00010 187498 17600048 deny ip from table(50) to any dst-port 135-139,445 00030 6 264 deny ip from any to table(20) dst-port 22 00060 20178202 5843214445 allow ip from 172.16.0.0/16 to 10.0.0.0/8 00060 4935741 349274219 allow ip from 10.0.0.0/8 to 172.16.0.0/16 00099 4601461 549651491 allow ip from any to any via lo0 00180 919184129 425389336692 allow ip from 10.0.0.0/8 to 10.0.0.0/8 in recv igb1 00180 1196334153 1065094085564 allow ip from 10.0.0.0/8 to 10.0.0.0/8 out xmit igb1 00210 6833708 685236677 allow ip from 172.16.0.0/16 to 172.16.0.0/16 00240 1495928 399786619 allow ip from any to me 00250 2149835 230655428 allow ip from me to any 01000 34531407 30906027365 allow ip from any to table(30) 01000 30950224 14061136330 allow ip from table(30) to any 03000 280389 135646215 netgraph tablearg ip from table(105) to any in recv ng* 03000 301370 289195850 netgraph tablearg ip from any to table(110) out xmit ng* 03500 849038581 374112825085 allow ip from table(100) to any 03500 1057548376 1046505656451 allow ip from any to table(100) 04000 1385327 1911201279 allow ip from table(99) to any 04000 731285 51537058 allow ip from any to table(99) 04100 33872 2621244 allow ip from 192.168.0.254 to any 04100 4 200 allow ip from any to 192.168.0.254 65535 34711897 5723493059 deny ip from any to any Отключил netgraph (шейпер) на проблемном сервере и нагрузка нормализовалась: Посоветуйте Изменено 23 декабря, 2012 пользователем kirush Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaN5300 Опубликовано 23 декабря, 2012 · Жалоба 1) На проблемном сервере после резкого увеличения lavg выполнить "vmstat -z|grep items" 2) Шейпирование реализовано через shape или rate-limit? 3) hyper-threading я бы отключил Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kirush Опубликовано 23 декабря, 2012 (изменено) · Жалоба 1) На проблемном сервере после резкого увеличения lavg выполнить "vmstat -z|grep items" 2) Шейпирование реализовано через shape или rate-limit? 3) hyper-threading я бы отключил 1) Проблемный: # vmstat -z|grep items NetGraph items: 104, 4118, 39, 3354,932282611, 0, 0 NetGraph data items: 104, 522, 1, 521,3937276999,5336084, 0 Нормальный: # vmstat -z|grep items NetGraph items: 72, 4118, 52, 441,1108945697, 0, 0 NetGraph data items: 72, 522, 0, 522,3870054604,20029, 0 Очень станно, что на проблемном в 2 раза больше items, сервера идентичны на 100% 2) через ng_car :) 3) не мешал на 7.2 (была до этого). Изменено 23 декабря, 2012 пользователем kirush Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
roysbike Опубликовано 23 декабря, 2012 · Жалоба 1) На проблемном сервере после резкого увеличения lavg выполнить "vmstat -z|grep items" 2) Шейпирование реализовано через shape или rate-limit? 2) через ng_car :) имелось ввиду mpd-limit all shape или mpd-limit rate-limit? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaN5300 Опубликовано 24 декабря, 2012 · Жалоба Подозреваю что rate-limit меньше требователен к ресурсам в отличие от shape. Мы применяли shape во времена тарифов по 128k. Потом перешли на limit. На самом последнем насе у нас по всем счётчикам vmstat только в одном месте есть отклонение счетчика фейлов (128 Bucket: 22135). Остальные все нули. Попробуй по библии dadv'а сделать: net.graph.maxdata=65536 net.graph.maxalloc=65536 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 24 декабря, 2012 · Жалоба А как вы думаете, что происходит с системой, когда пакет передаётся между ядрами разных процов? Простой=блокировка выполнения потока. При этом шедулер ОС считает что время простоя=время работы. И сравнение не корректное из за настроек и различий железа: у ем одно прерывание, а у игб их больше, при ваших настройках вся (до нетграфа) обработка пакетов происходит в обработчике прерывания. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaN5300 Опубликовано 24 декабря, 2012 · Жалоба Отказаться от планировщика выключив гипер-трединг и прибив процессы к ядрам как вариант. Но с другой стороны у нас насы с сервисами all-in-one тащат по 40-50 kpps в ЧНН с дефолтным шедулером из 9.0 и четырьмя ядрами. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kirush Опубликовано 24 декабря, 2012 · Жалоба процессы к ядрам прибиты Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kirush Опубликовано 25 декабря, 2012 (изменено) · Жалоба А не в том ли смысл, что на "24 ядерном" пиковая нагрузка при 100% будет 24 lavg А на слабенькой машине i3 пик будет 4lavg? и тогда получается что с картинками все ок? Изменено 25 декабря, 2012 пользователем kirush Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaN5300 Опубликовано 25 декабря, 2012 · Жалоба А не в том ли смысл, что на "24 ядерном" пиковая нагрузка при 100% будет 24 lavg А на слабенькой машине i3 пик будет 4lavg? и тогда получается что с картинками все ок? Невозможно будет каждый процессор забить на 100%. К тому же lavg это такой абстрактный параметр, с единой интерпретацией которого даже гуру не могут определиться: http://www.teamquest.com/pdfs/whitepaper/ldavg1.pdf Экспериментальным путём я выяснил что при увеличении значения load average 15m больше 3.0 на многопроцессорном (многоядерном) сервер доступа начинаются явные проблемы. По этому стараюсь выводить такие сервера из DNS до восстановления этих значений в норму. Еще заметил что порой может рандомно на каком-то из насов lavg резко взлететь до 40 например и в таком состоянии сервер будет находиться минут 20. Такое бывает очень редко. Раз в месяц примерно. Возможно связано с нетипичным трафиком с зараженного компа. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kaN5300 Опубликовано 26 декабря, 2012 · Жалоба Kirush, проблема больше не проявляется? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...