No buffer space available



  • Добрый день, уважаемые господа!

    Несколько дней назад я оптимизировал ядреные настройки так, что теперь шейпер и вообще все работает ну просто идеально. лучше и не придумать. кроме одного НО!

    dhcpd: send_packet: No buffer space available - в логах
    При отправке пинга с сервера ping: sendto: No buffer space available
    Возникает после 3-12 часов работы с момента перезагрузки и несет в себе проблему в пингах до 35000мс. Как вам:? при обычном раскладе, средний пинг 2-4, макс 7 (RRD-graphs)

    вот, какие стандартные настройки я подкрутил:
    1. выставил трубкам qlimit'ы, ибо без них торренты непобедимы. Стало все чудесно, потерь больше нет, пинги отличные, життер еденичка, трубка с торрентами всегда уступает место кому угодно. Вообщем, кулимитов мне очень давно не хватало.
    2.  /boot/loader.conf
    kern.ipc.nmbclusters="32768" - позволила получить АБСОЛЮТНО ровный результат на спидтесте. скорость не скачет ни на йоту. Такого ровного графика я не видел никогда и негде. Супер!

    Остальное было сделано дабы разрулить проблему с буффером
    net.inet.tcp.syncache.bucketlimit="100"
    net.inet.tcp.tcbhashsize="4096"
    kern.ipc.nsfbufs="10240"

    3. /etc/sysctl.conf
    kern.ipc.maxsockbuf=8388608
    kern.ipc.maxsockets=204800
    net.inet.tcp.msl=15000
    kern.ipc.somaxconn=256

    Вот что имеем по netstat'y:
    во время переполнения "буффера"
    745/3995/4740 mbufs in use (current/cache/total)
    575/3023/3598/32768 mbuf clusters in use (current/cache/total/max)
    573/2883 mbuf+clusters out of packet secondary zone in use (current/cache)
    1/673/674/12800 4k (page size) jumbo clusters in use (current/cache/total/max)
    0/0/0/6400 9k jumbo clusters in use (current/cache/total/max)
    0/0/0/3200 16k jumbo clusters in use (current/cache/total/max)
    1359K/9736K/11095K bytes allocated to network (current/cache/total)
    0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
    0/0/0 requests for jumbo clusters denied (4k/9k/16k)
    0/7/10240 sfbufs in use (current/peak/max)
    0 requests for sfbufs denied
    0 requests for sfbufs delayed
    0 requests for I/O initiated by sendfile
    0 calls to protocol drain routines

    После перезагрузки, когда все работает как в сказке:
    $ netstat -m
    399/1521/1920 mbufs in use (current/cache/total)
    387/1165/1552/32768 mbuf clusters in use (current/cache/total/max)
    385/1023 mbuf+clusters out of packet secondary zone in use (current/cache)
    0/54/54/12800 4k (page size) jumbo clusters in use (current/cache/total/max)
    0/0/0/6400 9k jumbo clusters in use (current/cache/total/max)
    0/0/0/3200 16k jumbo clusters in use (current/cache/total/max)
    873K/2926K/3800K bytes allocated to network (current/cache/total)
    0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
    0/0/0 requests for jumbo clusters denied (4k/9k/16k)
    0/6/10240 sfbufs in use (current/peak/max)
    0 requests for sfbufs denied
    0 requests for sfbufs delayed
    0 requests for I/O initiated by sendfile
    0 calls to protocol drain routines

    Предоставлю все что нужно, только , пожалуйста, идеи!
    Я прогуглил просто все уже. Ничего не выходит. Заменить сетевуху не выйдет, она встроенная. Но струдом верится, что это из-за железа, ибо до того, как я начал крутить этого не появлялось, но работало все криво, была нестабильная скорость, гребенки на графиках спидтеста и прочие непотребности.
    Могу попробовать просто понизить скорость родительских трубок на шейпере, чтобы снизить макс нагрузку. Но там все четке. Преполнений быть не должно. Пров выдает честный тариф, а трубка у меня 97% от него

    Очень жду помощи.



  • Поищите по английскому форуму.

    http://freebsd.monkey.org/freebsd-mobile/200605/msg00159.html

    Еще у меня такое было когда что-то некорректно настраивал на интерфейсе (бридж). Но давно было не помню.



  • Кажется, выцепил проблему



  • Сорри за оффтоп  ;)
    @goliy:

    …вот, какие стандартные настройки я подкрутил:
    1. выставил трубкам qlimit'ы, ибо без них торренты непобедимы. Стало все чудесно, потерь больше нет, пинги отличные, життер еденичка, трубка с торрентами всегда уступает место кому угодно. Вообщем, кулимитов мне очень давно не хватало.

    Если можно, по-подробнее - размеры qlimit для каждой трубки. Скриншотами с настройками ВСЕГО шейпера было бы идеально. Заранее очень-и-очень благодарен.

    P.s. И как решили проблему ?



  • @dvserg:

    Поищите по английскому форуму.
    http://freebsd.monkey.org/freebsd-mobile/200605/msg00159.html

    Мои значения(стандартные) net.inet.udp.maxdgram: 57344 и net.inet.udp.recvspace: 42080, и я считаю их вполне достаточными. Нет, тут что-то пожещще. Но я почти разрулил. Еще пару часов тестов и выложу результат.

    @werter:

    Сорри за оффтоп  ;)
    @goliy:

    …вот, какие стандартные настройки я подкрутил:
    1. выставил трубкам qlimit'ы, ибо без них торренты непобедимы. Стало все чудесно, потерь больше нет, пинги отличные, життер еденичка, трубка с торрентами всегда уступает место кому угодно. Вообщем, кулимитов мне очень давно не хватало.

    Если можно, по-подробнее - размеры qlimit для каждой трубки. Скриншотами с настройками ВСЕГО шейпера было бы идеально. Заранее очень-и-очень благодарен.

    Смотри в чем тут дело http://forum.pfsense.org/index.php/topic,9129.0.html
    Не понимаю, как люди столько лет шейпили торренты без этой возможности? К счастью, в ПФ 2.0 эта возможность идет из коробки, но в 1.2.3 приходится изгалятся так.
    Я сегодня-завтра напишу скрипт, который будет проверять и вбивать значения qlimit'ов по крону в файл конфигурации, не портя его. И выложу. подожди сдецл



  • Вообщем, таки трабла была описана здесь: http://kerneltrap.org/mailarchive/openbsd-misc/2008/9/14/3293054
    А про**ался я на том, что обратил внимание только на доунлоад канал(т.е. на qlanRoot), а аплоад (qwanRoot), видимо, превышал номинальным значением фактическое на какое-то незначительное кол-во килобит. Снизив его с ~18900 до 18432 Kb я совершенно избавился от проблемы!
    я вычислил я это таки по RRD графикам. Они в приложении. На котором ясно видно, как момент взлета пинга совпадает с моментом макс нагрузки канала qwanRoot.

    –-----------------------------------------------------------------------------------------------------------------------

    И да, темка с шейпингом и торрентами. Чтобы все работало чики пуки, добавьте в крон */15  *  *  *  *  (отрабатывающий каждые 15мин) скрипт, со след текстом:

    #!/bin/sh
    if grep "priority 1 hfsc" /tmp/rules.debug
    then
    sed -i "" 's/bandwidth 0% priority 2 hfsc/bandwidth 0% priority 2 qlimit 500 hfsc/g' /tmp/rules.debug
    sed -i "" 's/bandwidth 0% priority 7 hfsc/bandwidth 0% priority 7 qlimit 500 hfsc/g' /tmp/rules.debug
    sed -i "" 's/bandwidth 0% priority 1 hfsc/bandwidth 0% priority 1 qlimit 2000 hfsc/g' /tmp/rules.debug && pfctl -A -f /tmp/rules.debug
    fi

    Вообщем, повторяю, зачем увеличивать некоторые значения qlimit со стандартных 50 написано здесь:
    http://forum.pfsense.org/index.php/topic,9129.0.html

    Кратко зачем это:
    значение qlimit не поддерживается web интерфейсом, а значит, как и любое другое изменение файлов конфига не из веб интерфейса, затерается при любоми нажатии на кнопку apply. А мы сделали скрипт, который монитор файл настроек и, если необходимо (в данном случае это тогда, когда у трубки с приоритетом 1, а обычно это торренты, не назначен qlimit), ввинчивает указанные в нем значения qlimit в указанные трубки и перегружает фаервол. Если же значение присвоено - не делает ничего. Удобно, черт возьми =)

    Почему Brandwidth 0% читаем тут http://www.probsd.net/pf/index.php/Hednod's_HFSC_explained

    Ну и напоследок, мои настройки шейпинга. Они очень скудны, но мне большего и не надо =)

    queue qwanRoot bandwidth 18432Kb priority 0 hfsc { qwandef, qwanacks, qP2PUp, qGamesUp, qOthersUpH }
    queue qlanRoot bandwidth 47Mb priority 0 hfsc { qlandef, qlanacks, qP2PDown, qGamesDown, qOthersDownH }
    queue qwandef bandwidth 0% priority 2 qlimit 500 hfsc (  ecn default linkshare(0% 3000 33%) realtime(37% 3000 1Kb) )
    queue qlandef bandwidth 0% priority 2 qlimit 500 hfsc (  ecn default linkshare(0% 5000 68%) realtime(62% 10000 1%) )
    queue qwanacks bandwidth 0% priority 7 qlimit 500 hfsc (  linkshare 25% realtime 35% )
    queue qlanacks bandwidth 0% priority 7 qlimit 500 hfsc (  linkshare 15% realtime 10% )
    queue qP2PUp bandwidth 0% priority 1 qlimit 2000 hfsc (  red ecn linkshare 1Kb )
    queue qP2PDown bandwidth 0% priority 1 qlimit 2000 hfsc (  red ecn upperlimit 90% linkshare 1Kb )
    queue qGamesUp bandwidth 0% priority 4 hfsc (  linkshare 20% realtime 6% )
    queue qGamesDown bandwidth 0% priority 4 hfsc (  upperlimit 20% linkshare 12% realtime 6% )
    queue qOthersUpH bandwidth 0% priority 6 hfsc (  ecn linkshare 1% realtime 1% )
    queue qOthersDownH bandwidth 0% priority 6 hfsc (  ecn linkshare 1% realtime 1% )

    http://doc.pfsense.org/index.php/Traffic_Shaping_Guide со вкладкой Other Documentation в помощь тебе по настройке и понимании шейпинга.




  • Очень интересно.
    Можно по подробнее про qlimit (как сделал чтоб не р2р трафик вытеснял р2р)
    и про No buffer space available

    у меня постоянно такая картина

    miniupnpd[40873]: sendto(udp_notify=12, 192.168.0.1): No buffer space available
    
    dhcpd: send_packet: No buffer space available
    

    спс



  • обо всем написал выше.
    всетаки буфферы так и плачут. пока ничего с ними не решилось. Попробую еще снизить ширину Root трубок
    вот как это выглядит.

    про qlimit'ы тоже написано в после выше(гоу по ссылке). Вообще - переход на 2.0 устраняет эту проблему




  • Ув. goliy! Спасибо за объяснение. У меня pf 2.0 final. Рекомендуемые настройки в файлы /boot/loader.conf и /etc/sysctl.conf внес (для чего они , описано здесь - http://www.zeon.kiev.ua/?p=72) через Edit file. qLimit-ы выставил следующие - 500 для всех , кроме qP2p и qOthersLow - на них поставил 2000qOthersLow попадает весь неопределённый правилами трафик - так визард шейпера сформировал правила. На родительских LAN и WAN qlimit-ы не ставил, ест-но. Ребутнул pf. Ошибок нет.

    Теперь о грустном  :'(. Життер ДАЛЕКО не единица . Скачет будь здоров. Как добится стабильного пинга ?  А при попытке в дочерних очередях в Bandwidth выставить 0 % или 0 Kbit\s  идет  страшная ругань pf по-поводу того, что сумма дочерних превышает занчение родительской по linkshare , хотя я в linkshare НИЧЕГО не менял. И инета нет , хотя пишет что линк на WAN-е поднят (у меня модем в бридже (ADSL) и pf поднимает pppoe сессию).

    Подскажите, где я сплоховал ? Скрин Floating rules прилагаю.




  • покажи /tmp/rules.debug
    если ты прочитал как работает шейпер, то должен понимать, что при брандвифе 0, ты обязан поставить линкшэйр в какое-нибудь, отличное от нуля значение. Причем суммы по всем полосам линкшэйр не должна превышать 100% от канала Root (т.е. заданную ширину всего канала) как в одну так и в другую сторону. А суммы по Реалтайму 90%. при привышении фаервол ругается. и это грозит тем, что все точно ляжет.
    А где ты чекаешь життер? я, вот к примеру, находять в москве и проверяя канал на pingtest'e наблюдаю, как половина серваков вообще не хотят меня проверять, тогда как сервер istranet при проверке вообще вешает все мои браузеры, после обновления java, а сервер moskow(как ни странно), показывает ужасные результаты как по пингу так и по життеру, соответственно. и ближайший, нормально работающий, это, как ни странно, питерский. к тому же, какая у тебя уверенность, что пров выдает хороший канал? сначало убедить в этом, проведя все тесты, непосредственно через провод провайдера(без pfsense)
    если у тебя есть linux под рукой, проверяй утилитой mtr (my trace route) значение stDev и есть життер. он более точный. сейчас я провел тест на pingtest с автопоиском ближайшего сервака, и он выдал мне пинг 14, життер 7, и не смог проверить потери пакетов, тогда как mtr до я.ру(в течении пары мин) ясно показывает  средний пинг 5.8 життер 0.7 и 0.0% потерь.) счастливо живем



  • goliy попробовал выставить qlimit  в текущий мой шейпер и нифига р2р трафик не перекрывается … (иногда speedtest забирает большую часть канала, но когда я пытаюсь посмотреть ролики с ютуба всё мрёт и пинги катастрофа)

    Можешь объснить почему выставление qlimit  позволяет выгружать трубу р2р и отдавать другим трубам ? (link share само по себе не работает ,я сколько раз пробовал, и параметры m1 d  тоже мало чего делают )

    спс



  • @Tamriel:

    goliy попробовал выставить qlimit  в текущий мой шейпер и нифига р2р трафик не перекрывается … (иногда speedtest забирает большую часть канала, но когда я пытаюсь посмотреть ролики с ютуба всё мрёт и пинги катастрофа)

    Можешь объснить почему выставление qlimit  позволяет выгружать трубу р2р и отдавать другим трубам ? (link share само по себе не работает ,я сколько раз пробовал, и параметры m1 d  тоже мало чего делают )

    спс

    ЧИТАЙ ПО ССЫЛКАМ! RTFM! http://forum.pfsense.org/index.php/topic,9129.0.html - про qlimit'ы разговор. про шейпер написано ВЕЗДЕ. например тут http://www.probsd.net/pf/index.php/Hednod's_HFSC_explained . В  рамках этой темы 3й раз ссылки пишу. прочитай ты уже все, что там написано и вникни в работу шейпера



  • Quote from: goliy on Today at 06:05:51 am
    покажи /tmp/rules.debug

    И ещё, после отработки визарда шейпера реалтаймы в очередях вообще не создаются. Думаю , это стандартная конфигурация.  И в очереди для всего остального трафика визард не ставит RED. Это тоже по-дефолту.

    Мой /tmp/rules.dbg :

    altq on  pppoe1 hfsc bandwidth 512Kb queue {  qACK,  qDefault,  qP2P,  qOthersHigh,  qOthersLow  }
    queue qACK on pppoe1 bandwidth 19.6% qlimit 500 hfsc (  ecn  , linkshare 19.6%  ) 
    queue qDefault on pppoe1 bandwidth 9.8% qlimit 500 hfsc (  ecn  , default  ) 
    queue qP2P on pppoe1 bandwidth 4.9% qlimit 2000 hfsc (  ecn  , linkshare 4.9%  ) 
    queue qOthersHigh on pppoe1 bandwidth 9.8% qlimit 500 hfsc (  ecn  , linkshare 9.8%  ) 
    queue qOthersLow on pppoe1 bandwidth 2% qlimit 2000 hfsc (  ecn  , linkshare 2%  )

    altq on  em0 hfsc queue {  qLink,  qInternet  }
    queue qLink on em0 bandwidth 20% qlimit 500 hfsc (  ecn  , default  ) 
    queue qInternet on em0 bandwidth 15728.64Kb hfsc (  ecn  , linkshare 15728.64Kb  , upperlimit 15728.64Kb  )  {  qACK,  qP2P,  qOthersHigh,  qOthersLow  }
    queue qACK on em0 bandwidth 19.6% qlimit 500 hfsc (  ecn  , linkshare 19.6%  ) 
    queue qP2P on em0 bandwidth 4.9% qlimit 2000 hfsc (  ecn  , linkshare 4.9%  ) 
    queue qOthersHigh on em0 bandwidth 9.8% qlimit 500 hfsc (  ecn  , linkshare 9.8%  ) 
    queue qOthersLow on em0 bandwidth 2% qlimit 2000 hfsc (  ecn  , linkshare 2%  )



  • как ты дошел до таких значений, с десятыми процента? -) в чем проблема-то у тебя? життер? ну, тут трубки не причем, если он всегда такой. ты сделай сначало все, что я написал в предыдущем посту. (соединение без пф, с нормальной утилитой, например mtr. если там будет отличный результат - есть куда стремиться. если нет - проблема на уровень выше)
    вообще, тема про буфер спэйс.
    шейпер отлично настраивается после прочтения и пережевывания http://doc.pfsense.org/index.php/Traffic_Shaping_Guide при участии Other documentations (ссылки внизу. Если осмысленно въехать в то, что там написано, шейпер настраивается на раздва. если не понять - его никогда не настроить) если не умеете читать английский, Уважаемый dvserg перевел все на русский, даже рекомендации есть: http://forum.pfsense.org/index.php/topic,33870.0.html



  • есть еще у кого варианты? идея с увеличенным значение полосы пропускания на материнской трубке отпадает. снизил уже до немогу. До сих пор имеем потери и пинги за 20000 в некоторые странные точечные периоды. Вывожу статистику:
    netstat -s -p tcp
    tcp:
    209778697 packets sent
    97517566 data packets (4256116843 bytes)
    324488 data packets (371366906 bytes) retransmitted
    22175 data packets unnecessarily retransmitted
    0 resends initiated by MTU discovery
    100282788 ack-only packets (0 delayed)
    0 URG only packets
    279 window probe packets
    8583013 window update packets
    3409654 control packets
    149312851 packets received
    50143841 acks (for 4163762671 bytes)
    2405915 duplicate acks
    13469 acks for unsent data
    85283125 packets (433147740 bytes) received in-sequence
    457917 completely duplicate packets (289136740 bytes)
    322 old duplicate packets
    1677 packets with some dup. data (1213387 bytes duped)
    11088092 out-of-order packets (3040949322 bytes)
    120 packets (60 bytes) of data after window
    60 window probes
    764961 window update packets
    7299 packets received after close
    2927 discarded for bad checksums
    0 discarded for bad header offset fields
    0 discarded because packet too short
    793763 discarded due to memory problems
    1188550 connection requests
    1188335 connection accepts
    0 bad connection attempts
    0 listen queue overflows
    52487 ignored RSTs in the windows
    2344477 connections established (including accepts)
    2376209 connections closed (including 93302 drops)
    691567 connections updated cached RTT on close
    692651 connections updated cached RTT variance on close
    534912 connections updated cached ssthresh on close
    1554 embryonic connections dropped
    30514800 segments updated rtt (of 26003440 attempts)
    402532 retransmit timeouts
    5552 connections dropped by rexmit timeout
    1010 persist timeouts
    2 connections dropped by persist timeout
    0 Connections (fin_wait_2) dropped because of timeout
    0 keepalive timeouts
    0 keepalive probes sent
    0 connections dropped by keepalive
    7074305 correct ACK header predictions
    82392641 correct data packet header predictions
    1188908 syncache entries added
    3218 retransmitted
    3101 dupsyn
    2822 dropped
    1188335 completed
    0 bucket overflow
    0 cache overflow
    300 reset
    277 stale
    0 aborted
    0 badack
    0 unreach
    0 zone failures
    1191730 cookies sent
    4 cookies received
    46850 SACK recovery episodes
    68735 segment rexmits in SACK recovery episodes
    96526480 byte rexmits in SACK recovery episodes
    417122 SACK options (SACK blocks) received
    11346326 SACK options (SACK blocks) sent
    0 SACK scoreboard overflow

    vmstat -z
    ITEM                    SIZE    LIMIT      USED      FREE  REQUESTS  FAILURES

    UMA Kegs:                128,        0,      104,      16,      104,        0
    UMA Zones:                480,        0,      104,        0,      104,        0
    UMA Slabs:                64,        0,      869,      16,    2057,        0
    UMA RCntSlabs:            104,        0,    2501,      15,    2501,        0
    UMA Hash:                128,        0,        5,      25,        9,        0
    16 Bucket:                76,        0,      66,      34,      85,        0
    32 Bucket:                140,        0,      98,      14,      119,        0
    64 Bucket:                268,        0,      141,      13,      191,        7
    128 Bucket:              524,        0,      831,        2,    1934,      275
    VM OBJECT:                128,        0,    30765,      465, 19971621,        0
    MAP:                      140,        0,        7,      21,        7,        0
    KMAP ENTRY:                68,    57456,      23,      369,    21233,        0
    MAP ENTRY:                68,        0,    1581,      995, 43122275,        0
    DP fakepg:                72,        0,        0,        0,        0,        0
    mt_zone:                1032,        0,      293,      127,      293,        0
    16:                        16,        0,    4281,    5260, 17668570,        0
    32:                        32,        0,    2430,      395,  9284507,        0
    64:                        64,        0,    5528,    3086, 1001506570,        0
    128:                      128,        0,    1014,      426,  428472,        0
    256:                      256,        0,    2975,    6145, 22098324,        0
    512:                      512,        0,      216,      64,    54641,        0
    1024:                    1024,        0,      52,      144, 13993528,        0
    2048:                    2048,        0,      361,      357,  190179,        0
    4096:                    4096,        0,      129,      80,  1403807,        0
    Files:                    76,        0,      789,    2311, 40924628,        0
    TURNSTILE:                76,        0,      211,      77,      211,        0
    umtx pi:                  52,        0,        0,        0,        0,        0
    PROC:                    696,        0,      82,      58,  992445,        0
    THREAD:                  560,        0,      146,      64,      325,        0
    UPCALL:                    44,        0,        0,        0,        0,        0
    SLEEPQUEUE:                32,        0,      211,      241,      211,        0
    VMSPACE:                  236,        0,      41,      87,  991946,        0
    cpuset:                    40,        0,        2,      182,        2,        0
    audit_record:            856,        0,        0,        0,        0,        0
    mbuf_packet:              256,        0,      732,    3108, 598589137,        0
    mbuf:                    256,        0,        3,    1287, 1151674234,        0
    mbuf_cluster:            2048,    32768,    3842,      314, 242491157,        0
    mbuf_jumbo_pagesize:    4096,    12800,        0,      423, 21203205,        0
    mbuf_jumbo_9k:          9216,    6400,        0,        0,        0,        0
    mbuf_jumbo_16k:        16384,    3200,        0,        0,        0,        0
    mbuf_ext_refcnt:            4,        0,        0,        0,        0,        0
    ACL UMA zone:            388,        0,        0,        0,        0,        0
    NetGraph items:            36,    4134,        0,        0,        0,        0
    NetGraph data items:      36,      546,        0,        0,        0,        0
    g_bio:                    132,        0,        0,    3770, 10725147,        0
    ata_request:              192,        0,        0,      980,  2561857,        0
    ata_composite:            184,        0,        0,        0,        0,        0
    cryptop:                  60,        0,        0,        0,        0,        0
    cryptodesc:                56,        0,        0,        0,        0,        0
    VNODE:                    276,        0,    31487,      335,  597279,        0
    VNODEPOLL:                64,        0,        0,        0,        0,        0
    NAMEI:                  1024,        0,        0,      48, 125831377,        0
    S VFS Cache:              68,        0,    13437,      955,  367847,        0
    L VFS Cache:              291,        0,      23,      29,      133,        0
    DIRHASH:                1024,        0,      463,      53,      547,        0
    NFSMOUNT:                560,        0,        0,        0,        0,        0
    NFSNODE:                  452,        0,        0,        0,        0,        0
    pipe:                    396,        0,        6,      44,  541296,        0
    ksiginfo:                  80,        0,      106,      950,      108,        0
    itimer:                  220,        0,        0,      36,        1,        0
    KNOTE:                    68,        0,      611,    2301, 178998840,        0
    bridge_rtnode:            36,        0,        0,        0,        0,        0
    socket:                  416,  204804,      735,    2739,  3676524,        0
    ipq:                      32,    1130,        0,        0,        0,        0
    udpcb:                    180,  204820,      15,      95,  936745,        0
    inpcb:                    180,  204820,      954,    3182,  2378055,        0
    tcpcb:                    464,  204800,      691,    2581,  2378055,        0
    tcptw:                    52,    32256,      263,    1609,  1173516,        0
    syncache:                104,    51208,        0,      185,  1192168,        0
    hostcache:                76,    15400,    1876,    1824,    21483,        0
    tcpreass:                  20,    2197,        0,      676, 11118468,        0
    sackhole:                  20,        0,        0,      507,    65423,        0
    sctp_ep:                  816,    32770,        0,        0,        0,        0
    sctp_asoc:              1436,    40000,        0,        0,        0,        0
    sctp_laddr:                24,    80040,        0,      290,        7,        0
    sctp_raddr:              400,    80000,        0,        0,        0,        0
    sctp_chunk:                96,  400000,        0,        0,        0,        0
    sctp_readq:                76,  400000,        0,        0,        0,        0
    sctp_stream_msg_out:      64,  400020,        0,        0,        0,        0
    sctp_asconf:              24,  400055,        0,        0,        0,        0
    sctp_asconf_ack:          24,  400055,        0,        0,        0,        0
    ripcb:                    180,  204820,        1,      87,    36036,        0
    unpcb:                    168,  204815,      27,      88,  325405,        0
    rtentry:                  124,        0,      68,      149,    1888,        0
    pfsrctrpl:                124,    10013,        0,        0,        0,        0
    pfrulepl:                844,        0,    3137,    3343,    97083,        0
    pfstatepl:                284,  180012,    23740,    17280, 21127153,        0
    pfaltqpl:                224,        0,      16,      86,      720,        0
    pfpooladdrpl:              68,        0,      39,      185,      516,        0
    pfrktable:              1240,    1002,      307,      80,    1388,        0
    pfrkentry:                156,  200000,      129,      271,    4632,        0
    pfrkentry2:              156,        0,        0,        0,        0,        0
    pffrent:                  16,    5075,      140,    2499, 27808559,        0
    pffrag:                    48,        0,      140,    2512, 14106469,        0
    pffrcache:                48,    10062,        0,        0,        0,        0
    pffrcent:                  12,    50141,        0,        0,        0,        0
    pfstatescrub:              28,        0,        0,        0,        0,        0
    pfiaddrpl:                100,        0,      34,      83,      179,        0
    pfospfen:                108,        0,      696,      132,    26448,        0
    pfosfp:                    28,        0,      407,      482,    15466,        0
    SWAPMETA:                276,  121576,        0,        0,        0,        0
    Mountpoints:              720,        0,        4,        6,        4,        0
    FFS inode:                124,        0,    31360,      322,  597148,        0
    FFS1 dinode:              128,        0,        0,        0,        0,        0
    FFS2 dinode:              256,        0,    31360,      320,  597148,        0
    md0:                      512,        0,      298,      46,      298,        0

    Есть идеи что переполняется и как этого избежать? логи полностью молчат. как вызвать этот перегруз и посомтреть статистику именно во время него пока не могу, ибо непонятно что является его катализатором. Overflow пустые, ерроров нет. Я Ломаю голову, что же не так \\ пока добавил upperlimit торрентам на Up и еще понизил значение wanRoot. Таки графики намекают, что скорее всего, фэйлы во время активного аплоада.










  • вообщем, проблема так и не решена, но запилена до минимума(выставлением upperlimit'a торрентам в 90%). уже рекордное время нет взлетов пингов (хотя они просто сильно уменьшились) Например, четко отслеживается, что проблема в отсылке пакетов От сервера. чето переполняется, но хер пойми что. В последний раз было четко заметно, как при запуске ntop'a, syslogd посылал инфу на локальный сервер, а инфа, видимо, шла сразу лихой пачкой, т.к. ntop , запускаясь ну прямо Всё про себя рассказывает, syslog послал в лог предупреждение о переполнении буффера. но пинги теперь взлетают только до 30мс, так что жить как-то можно. хотя, конечно, очень не приятно. еще и потери какието, уверен, в этом же ключе\\






  • Выражаю огромную благодарность ув. goliy за помощь! Немного разобрался с шейпером.
    Теперь очередь с торрентами корректно и довольно быстро уступает очередям с более высоким приоритетом. Только вот пинг скачет все равно  :'( Меньше уже, но скачет. Буду разбираться чуть попозже.

    P.s. У ТС ,я так понял, стоит pf 1.2.3 Может стоит перейти на 2.0 и проблема с переполнением решится ?

    P.s.s. Мои /tmp/debur/rules теперь:

    altq on  pppoe1 hfsc bandwidth 512Kb queue {  qACK,  qDefault,  qP2P,  qOthersHigh,  qOthersLow  }
    queue qACK on pppoe1 qlimit 500 hfsc (  ecn  , linkshare 19.6%  ) 
    queue qDefault on pppoe1 qlimit 500 hfsc (  ecn  , default  , linkshare 9.8%  ) 
    queue qP2P on pppoe1 qlimit 2000 hfsc (  red  , ecn  , linkshare 1Kb  ) 
    queue qOthersHigh on pppoe1 qlimit 500 hfsc (  ecn  , linkshare 9.8%  ) 
    queue qOthersLow on pppoe1 qlimit 2000 hfsc (  red  , ecn  , linkshare 1Kb  )

    altq on  em0 hfsc queue {  qLink,  qInternet  }
    queue qLink on em0 qlimit 500 hfsc (  ecn  , default  , linkshare 20%  ) 
    queue qInternet on em0 bandwidth 15728.64Kb hfsc (  ecn  , linkshare 15728.64Kb  , upperlimit 15728.64Kb  )  {  qACK,  qP2P,  qOthersHigh,  qOthersLow  }
    queue qACK on em0 qlimit 500 hfsc (  ecn  , linkshare 19.6%  ) 
    queue qP2P on em0 qlimit 2000 hfsc (  red  , ecn  , linkshare 1Kb  ) 
    queue qOthersHigh on em0 qlimit 500 hfsc (  ecn  , linkshare 9.8%  ) 
    queue qOthersLow on em0 qlimit 2000 hfsc (  red  , ecn  , linkshare 1Kb  )



  • это уже вопрос, стоит ли мучатся и получить новые проблемы с переписыванием всех правил, таблицы маков (на целый диапазон сети) и много другого, если всего и так полностью хватает.. Думаю, заняться этим, когда прижмет необходимость расширять канал за счет 2го Ван, а пока еще тут покавыряюсь. Дабы даже скрипт уже пашет для qlimit'ов =)
    Буду пока криво смотреть в сторону сетевух за 300руб. А там и серв заменим и на 2.0 переедем)

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



  • Еще, на русском - http://dreamcatcher.ru/2009/11/30/Использование-hierarchical-fair-service-curve-hfsc-в-openbsd/ . Может кому и пригодится.



  • такой вопрос
    правка loader.conf  и /etc/sysctl.conf (согласно 1-му посту автора топа)
    возможна в nanobsd ?
    спс



  • @Tamriel:

    такой вопрос
    правка loader.conf  и /etc/sysctl.conf (согласно 1-му посту автора топа)
    возможна в nanobsd ?
    спс

    Можно в nanobsd, в ee, в https://pfsense/edit.php из веб-интерфейса, и даже в православном vi! это же обычный текстовый файл =)



  • @goliy:

    @Tamriel:

    такой вопрос
    правка loader.conf  и /etc/sysctl.conf (согласно 1-му посту автора топа)
    возможна в nanobsd ?
    спс

    Можно в nanobsd, в ee, в https://pfsense/edit.php из веб-интерфейса, и даже в православном vi! это же обычный текстовый файл =)

    сделал спс
    использую ee  или mcedit



  • И все же , ув. гуру, как ПРАВИЛЬНО определить размер linkshare и realtime ? По ссылкам доки прочел.
    Визард же по шейперу их как-то высчитывает. Каков алгоритм , хоть примерно ? Ткните носом. Спс.



  • @werter:

    И все же , ув. гуру, как ПРАВИЛЬНО определить размер linkshare и realtime ? По ссылкам доки прочел.

    НЕ ВЕРЮ


Log in to reply