make.kernel Опубликовано 11 ноября, 2009 (изменено) · Жалоба /sbin/ipfw -q pipe 1 config bw 590Mbit/s queue 1000KBytes /sbin/ipfw -q pipe 2 config bw 590Mbit/s queue 1000KBytes /sbin/ipfw -q queue 11 config pipe 1 weight 10 mask src-ip 0xffffffff queue 1000KBytes buckets 8192 noerror /sbin/ipfw -q queue 14 config pipe 1 weight 40 mask src-ip 0xffffffff queue 1000KBytes buckets 8192 noerror /sbin/ipfw -q queue 19 config pipe 1 weight 90 mask src-ip 0xffffffff queue 1000KBytes buckets 8192 noerror /sbin/ipfw -q queue 21 config pipe 2 weight 10 mask dst-ip 0xffffffff queue 1000KBytes buckets 8192 noerror /sbin/ipfw -q queue 24 config pipe 2 weight 40 mask dst-ip 0xffffffff queue 1000KBytes buckets 8192 noerror /sbin/ipfw -q queue 29 config pipe 2 weight 90 mask dst-ip 0xffffffff queue 1000KBytes buckets 8192 noerror /sbin/ipfw -q pipe 3 config bw 590Mbit/s queue 1000KBytes /sbin/ipfw -q pipe 4 config bw 590Mbit/s queue 1000KBytes /sbin/ipfw -q queue 31 config pipe 3 weight 10 mask src-ip 0xffffffff queue 1000KBytes buckets 8192 noerror /sbin/ipfw -q queue 34 config pipe 3 weight 40 mask src-ip 0xffffffff queue 1000KBytes buckets 8192 noerror /sbin/ipfw -q queue 39 config pipe 3 weight 90 mask src-ip 0xffffffff queue 1000KBytes buckets 8192 noerror /sbin/ipfw -q queue 41 config pipe 4 weight 10 mask dst-ip 0xffffffff queue 1000KBytes buckets 8192 noerror /sbin/ipfw -q queue 44 config pipe 4 weight 40 mask dst-ip 0xffffffff queue 1000KBytes buckets 8192 noerror /sbin/ipfw -q queue 49 config pipe 4 weight 90 mask dst-ip 0xffffffff queue 1000KBytes buckets 8192 noerror /sbin/ipfw -q add queue 21 all from any to table(1) out xmit em0 /sbin/ipfw -q add queue 11 all from table(1) to any in recv em0 /sbin/ipfw -q add queue 24 all from any to table(4) out xmit em0 /sbin/ipfw -q add queue 14 all from table(4) to any in recv em0 /sbin/ipfw -q add queue 29 all from any to table(9) out xmit em0 /sbin/ipfw -q add queue 19 all from table(9) to any in recv em0 /sbin/ipfw -q add queue 41 all from any to table(1) out xmit em1 /sbin/ipfw -q add queue 31 all from table(1) to any in recv em1 /sbin/ipfw -q add queue 44 all from any to table(4) out xmit em1 /sbin/ipfw -q add queue 34 all from table(4) to any in recv em1 /sbin/ipfw -q add queue 49 all from any to table(9) out xmit em1 /sbin/ipfw -q add queue 39 all from table(9) to any in recv em1 /sbin/sysctl net.inet.ip.fw.one_pass=1 Есть 2 аплинка по 600 мбит, нагрузка текущая 800-900 мбит, один аплинк получает препенд и трафик ложится примерно 50-50, все хорошо. Если отваливается 1 из аплинков нужно отдать випам випово, физикам физиково, юрикам - что осталось, причем это "что осталось" нужно поделить, чтобы 20 киноманов торентом не сожрали все. Вообщем есть 2 трубы и динамические очереди с тремя приоритетами и маской по ip клиента. Очередей тыщ 8 в каждую сторону, dummynet жрет под 60% процессора, трафик чуть больше 100 кппс, правил фаервола 10 штук, в таблицах подсети по сервису. Может я не то и не тем решаю? Или на таком количестве очередей это нормально? Поиск использовал, особо нагрузка не поменялась. Изменено 11 ноября, 2009 пользователем make.kernel Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 11 ноября, 2009 · Жалоба Есть 2 аплинка по 600 мбит, нагрузка текущая 800-900 мбит, один аплинк получает препенд и трафик ложится примерно 50-50, все хорошо. Если отваливается 1 из аплинков нужно отдать випам випово, физикам физиково, юрикам - что осталось, причем это "что осталось" нужно поделить, чтобы 20 киноманов торентом не сожрали все. Вообщем есть 2 трубы и динамические очереди с тремя приоритетами и маской по ip клиента. Очередей тыщ 8 в каждую сторону, dummynet жрет под 60% процессора, трафик чуть больше 100 кппс, правил фаервола 10 штук, в таблицах подсети по сервису. Может я не то и не тем решаю? Или на таком количестве очередей это нормально? Поиск использовал, особо нагрузка не поменялась. Составьте список киноманов, и в момент аварии засуньте их всех в мелкую трубу. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 11 ноября, 2009 (изменено) · Жалоба Размеры родительских очередей (pipe) такой же, как и у дочерних (queue), а должен быть таким, чтобы помещались все дочерние, и еще оставался запас, около 4000KBytes. Кроме того, надо бы размеры даминетовских хэшей в sysctl подкрутить. Изменено 11 ноября, 2009 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
make.kernel Опубликовано 11 ноября, 2009 · Жалоба Составьте список киноманов, и в момент аварии засуньте их всех в мелкую трубу.Не тру-вей в трубу ложить, если авария в 4 утра и недогруз даже на одном аплинке ;) Размеры родительских очередей (pipe) такой же, как и у дочерних (queue), а должен быть таким, чтобы помещались все дочерние, и еще оставался запас, около 4000KBytes.Тут не понятно, пакеты должны скирдоваться в буферах queue, pipe их только вынимает оттуда и отдает на пересылку, вынимает со своей скоростью в очередности заданой приоритетами. Я чего-то думал, что queue для pipe задается чтобы он не тупо дропал что выше скорости а складывал в неявную очередь если трафик именно в pipe заворачивается. Я же очереди явно создал и трафик в них явно положил. И откуда цифра в 4 мб? Она рассчитывается как-то? Если я создаю динамически 16 тыщ очередей по например 100кбайт это на 1.6 гб, значит на pipe нада еще 2 гб ставить, итого 3.6 гб буферов - да там данных ляжет еще на 20 минут качать после отвала обоих аплинков.... border# sysctl net.inet.ip.dummynet.hash_size net.inet.ip.dummynet.hash_size: 32768 border# Или какие хеши имелось ввиду? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 11 ноября, 2009 · Жалоба По идее, родительская очередь должна быть больше дочерних, чтобы пакеты не терялись. Хотя для динамических очередей dummynet может быть это и не нужно. По крайней мере будет лучше уменьшить длину очереди в queue до 50--80KByte. net.inet.ip.dummynet.hash_size = 32768 вы фактически затираете параметром buckets 8192. Если этого числа достаточно, то ничего менять не нужно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 11 ноября, 2009 · Жалоба Не тру-вей в трубу ложить, если авария в 4 утра и недогруз даже на одном аплинке ;) :-) Про тру-вей поговорим после этой самой аварии. Я почему-то думаю, что она будет в ЧНН. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Giga-Byte Опубликовано 11 ноября, 2009 · Жалоба .... /sbin/ipfw -q add queue 21 all from any to table(1) out xmit em0 /sbin/ipfw -q add queue 11 all from table(1) to any in recv em0 .... попробуйте не шейпить входящие пакеты, а именно: /sbin/ipfw -q add queue 21 all from any to table(1) [b]out recv em1 xmit em0[/b] /sbin/ipfw -q add queue 11 all from table(1) to any [b]out recv em0 xmit em1[/b] это даст небольшой выигрыш (снизит нагрузку) также можно минимизировать кол-во правил (чтобы глаза не мазолили): pipe config... queue config... ipfw add queue tablearg all from any to table(100) out recv em1 xmit em0 ipfw add queue tablearg all from table(100) to any out recv em0 xmit em1 про остальное (значения очередей и хешей) не скажу Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
networks Опубликовано 12 ноября, 2009 · Жалоба Немного оффтоп, но все же - я так понял из описания алгоритма w2fq, что не важно, какие именно значения приоритетов писать при задании queue, важно отношение между ними? Т.е. в данном случае 90-40-10, т.е. первый приоритет получит 90/(90+40+10) - 64% проп. способности, второй - 40/(90+40+10) - 28% проп. способности, третий - 10/(90+40+10) - 7% проп. способности. Я прав? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 12 ноября, 2009 (изменено) · Жалоба Немного оффтоп, но все же - я так понял из описания алгоритма w2fq, что не важно, какие именно значения приоритетов писать при задании queue, важно отношение между ними? Т.е. в данном случае 90-40-10, т.е. первый приоритет получит 90/(90+40+10) - 64% проп. способности, второй - 40/(90+40+10) - 28% проп. способности, третий - 10/(90+40+10) - 7% проп. способности. Это же не шейпинг, а fair queueing, поэтому такое распределение будет выполняться при 100% использовании канала. Если канал не загружен, низкоприоритетные классы могут занять неиспользуемую полосу. Кроме того, нужно учитывать, что трафик имеет большую пачечность, поэтому выравнивание распределений будет происходить не мгновенно. Изменено 12 ноября, 2009 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
