No buffer space available
-
Ув. goliy! Спасибо за объяснение. У меня pf 2.0 final. Рекомендуемые настройки в файлы /boot/loader.conf и /etc/sysctl.conf внес (для чего они , описано здесь - http://www.zeon.kiev.ua/?p=72) через Edit file. qLimit-ы выставил следующие - 500 для всех , кроме qP2p и qOthersLow - на них поставил 2000 (в qOthersLow попадает весь неопределённый правилами трафик - так визард шейпера сформировал правила. На родительских 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 тоже мало чего делают )
спс
-
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%27s_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 overflowvmstat -z
ITEM SIZE LIMIT USED FREE REQUESTS FAILURESUMA 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 ?
спс -
такой вопрос
правка loader.conf и /etc/sysctl.conf (согласно 1-му посту автора топа)
возможна в nanobsd ?
спсМожно в nanobsd, в ee, в https://pfsense/edit.php из веб-интерфейса, и даже в православном vi! это же обычный текстовый файл =)
-
-
И все же , ув. гуру, как ПРАВИЛЬНО определить размер linkshare и realtime ? По ссылкам доки прочел.
Визард же по шейперу их как-то высчитывает. Каков алгоритм , хоть примерно ? Ткните носом. Спс. -
И все же , ув. гуру, как ПРАВИЛЬНО определить размер linkshare и realtime ? По ссылкам доки прочел.
НЕ ВЕРЮ
