6yktonox

Возможна такая ситуация, что у одного ip будет несколько url (lurkmore.to), в таком случае было бы логично иметь основной id у ips, а не у urls.

Хм. Кому-нибудь удалось корректно подружить tproxy и nginx(не в freebsd)?

возможно поможет http://forum.nag.ru/forum/index.php?showtopic=55025. в кратце, всему виной udp

спасибо автору http://forum.nag.ru/forum/index.php?showtopic=72625 получил ответ на все интересующие вопросы

железо подбирается, не хочется промахнуться Экспериментально замечено, что нагрузка на процессор при демультиплексировании и последующем транскодировании 1 канала из потока содержащего 15 тв-каналов - выше, чем того-же тв-канала присутствующего в потоке из 2-3. Странно получается, на макоси 2-а четырехядерных ксеона тянут 20 каналов, при том что остается запас по процессорному времени. Учитывая, что макось правленый фри - можно проводить некоторую параллель и делать некоторые выводы, питая надежды к 2-ум шестиядерникам..

Хорошо, допустим. Серверу на базе двухпроцессорного xeon e5649 какую нагрузку ожидать при транскодировании 10 каналов (1 udp поток = 2-3 тв канала)

Ребят, пользовался поиском, гуглом, кучу всего перечитал. Такой вопрос. Необходимо транскодировать около 10 каналов, с запасом 16-18 (udp to http) для этих целей выбран ?vlc?? Исходный канал mpeg-2(~5Mbit, на один канал), на выходе необходим mpeg-4(h264,vb=500,ab=128,w=720,h=576). Все это планируется осуществить на centos|fedora|rhel, какие процессоры рекомендуете? Xeon (X,E)? В транскодировании играет роль гипетрединг(сколько процентов при мультипоточности выигрывается?)?

Хотелось бы поблагодарить @nuclearcat Вопрос решен.

# tc qdisc add dev eth0.10 root pfifo limit 10000 # tc -s -d qdisc show dev eth0.10 qdisc pfifo 800a: root refcnt 2 limit 10000p Sent 357587609 bytes 385271 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 # tc qdisc add dev eth0.10 root htb r2q 1500 # tc -s -d qdisc show dev eth0.10 qdisc htb 800e: root refcnt 2 r2q 1500 default 0 direct_packets_stat 381296 ver 3.17 Sent 317206549 bytes 381296 pkt (dropped 4958, overlimits 0 requeues 0) backlog 0b 0p requeues 0 Мне крайне необходим htb с его классами

перешли на 2.6.39.3 картина следующая. пакеты дропаются с нереальной скоростью при добавлении любого qdisc # tc qdisc add dev eth0.10 root handle 1: pfifo через 10 секунд # tc -s qdisc show dev eth0.10 qdisc pfifo 1: root refcnt 2 limit 1p Sent 394574230 bytes 382266 pkt (dropped 966, overlimits 0 requeues 0) backlog 0b 0p requeues 0 имеем порядка 996 dropped из 382266 pkt Меняю очередь на htb # tc qdisc add dev eth0.10 root handle 1: htb так-же снимаем данные через 10 секунд # tc -s qdisc show dev eth0.10 qdisc htb 1: root refcnt 2 r2q 10 default 0 direct_packets_stat 384368 Sent 372025931 bytes 384368 pkt (dropped 3796, overlimits 0 requeues 0) backlog 0b 0p requeues 0 соответственно с htb, 3796 dropped из 384368 pkt С hfsc # tc qdisc add dev eth0.10 root handle 1: hfsc аналогично, 10 секунд # tc -s qdisc show dev eth0.10 qdisc hfsc 1: root refcnt 2 Sent 372734185 bytes 386391 pkt (dropped 14283, overlimits 0 requeues 0) backlog 0b 0p requeues 0 14283 dropped из 386391 pkt Параметры очередей не указывал специально, что в принципе не важно, с ними ситуация не меняется. На 2.6.30 и 2.6.35 такого количества dropped pkt не наблюдается (практически равно нулю). Хочется все-таки докопаться до причины

в том то и дело, при добавлении очереди tc qdisc add dev eth0.10 root handle 1: htb или tc qdisc add dev eth0.10 root handle 1: pfifo и любой другой, начинаются проблемы. Напомню, по умолчанию у меня такие очереди для физ.интерфейсов # tc qdisc show qdisc mq 0: dev eth0 root qdisc mq 0: dev eth1 root Смена очереди на физ.интерфейсах, не дает результатов также. UPD Я понимаю, что проблема не наблюдается на 2.6.30 и 2.6.35, а это значит, что либо 38-е ядро кривое, либо в нем появились какие-то новые параметры, на которые я не обращаю внимания. Не припомните, что-то новое в 38-м появилось касательно шейпинга? Если совсем будет глухо, попробую перейти на 39-е

updd. при присоединении к VLAN-интерфейсу любой дисциплины очереди (htb, pfifo, hfsc, tbf..) пакеты на данном интерфейсе начинают дико дропаться вне зависимости от конфигурации очереди

# cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 0: 126 0 1 0 IO-APIC-edge timer 1: 0 2 0 0 IO-APIC-edge i8042 8: 0 0 0 0 IO-APIC-edge rtc0 9: 0 0 0 0 IO-APIC-fasteoi acpi 12: 0 1 1 2 IO-APIC-edge i8042 14: 257171 246715 240383 233445 IO-APIC-edge ata_piix 15: 25 25 24 23 IO-APIC-edge ata_piix 16: 67 71 66 70 IO-APIC-fasteoi uhci_hcd:usb2 19: 0 0 0 0 IO-APIC-fasteoi uhci_hcd:usb3 23: 0 0 1 1 IO-APIC-fasteoi ehci_hcd:usb1 66: 0 0 0 1 PCI-MSI-edge eth0 67: 919271050 28651 26148 26410 PCI-MSI-edge eth0-TxRx-0 68: 27895 929404291 517825 29225 PCI-MSI-edge eth0-TxRx-1 69: 0 1 0 0 PCI-MSI-edge eth1 70: 565595 32176 982915375 30595 PCI-MSI-edge eth1-TxRx-0 71: 29936 30076 542977 973183604 PCI-MSI-edge eth1-TxRx-1 NMI: 0 0 0 0 Non-maskable interrupts LOC: 82658677 82661592 106820224 106847889 Local timer interrupts SPU: 0 0 0 0 Spurious interrupts PMI: 0 0 0 0 Performance monitoring interrupts IWI: 0 0 0 0 IRQ work interrupts RES: 14649 19405 29739 25351 Rescheduling interrupts CAL: 152174 118661 24550 22571 Function call interrupts TLB: 10202 8371 34320 35276 TLB shootdowns TRM: 0 0 0 0 Thermal event interrupts THR: 0 0 0 0 Threshold APIC interrupts MCE: 0 0 0 0 Machine check exceptions MCP: 529 529 529 529 Machine check polls ERR: 0 MIS: 0 # cat /proc/cpuinfo processor : 0/1/2/3 vendor_id : GenuineIntel cpu family : 15 model : 4 model name : Intel(R) Xeon(TM) CPU 3.00GHz stepping : 3 cpu MHz : 2992.803 cache size : 2048 KB physical id : 0/3/0/3 siblings : 2 core id : 0 cpu cores : 1 apicid : 0/6/1/7 initial apicid : 0/6/1/7 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm constant_tsc pebs bts pni dtes64 monitor ds_cpl cid cx16 xtpr bogomips : 5983.82 clflush size : 64 cache_alignment : 128 address sizes : 36 bits physical, 48 bits virtual # tc -s qdisc qdisc mq 0: dev eth0 root Sent 257597591524 bytes 287932088 pkt (dropped 0, overlimits 0 requeues 232) backlog 0b 0p requeues 232 qdisc mq 0: dev eth1 root Sent 127122172198 bytes 263637164 pkt (dropped 0, overlimits 0 requeues 308) backlog 0b 0p requeues 308 16 классов по умолчанию для eth0 # tc -s class show dev eth0 class mq :1 root Sent 130730502047 bytes 146647806 pkt (dropped 0, overlimits 0 requeues 138) backlog 0b 0p requeues 138 class mq :2 root Sent 129697216820 bytes 144420824 pkt (dropped 0, overlimits 0 requeues 96) в следующие классы :3,:4 и т.д. пакеты не попадают т.е. class mq :3 root Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 и т.д. такая же картина с eth1 # tc -s class show dev eth1 class mq :1 root Sent 67825856405 bytes 139419999 pkt (dropped 0, overlimits 0 requeues 168) backlog 0b 0p requeues 168 class mq :2 root Sent 63489604709 bytes 132177418 pkt (dropped 0, overlimits 0 requeues 145) backlog 0b 0p requeues 145 class mq :3 root Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 и т.д. повторюсь. Но стОит добавить хоть один корневой класс к VLAN-интерфейсу, допустим: tc qdisc add dev eth0.10 root handle 1: htb как сразу же число обрабатываемых пакетов снижается

[РЕШЕНО] ответ в конце сообщения Софтроутер, Fedora 14, 2.6.38.8-35, NIC Intel 82576, драйвер не ядерный igb eth0 и eth1 tso off tx on sg on gro off lro off gso off Драйвер загружается с параметрами options igb IntMode=2,2 InterruptThrottleRate=3,3 RSS=2,2 sysctl.conf net.ipv4.ip_forward = 1 net.ipv4.conf.default.rp_filter = 0 net.ipv4.conf.all.rp_filter = 0 net.ipv4.conf.default.accept_source_route = 1 kernel.sysrq = 1 kernel.panic = 30 kernel.core_uses_pid = 1 net.ipv4.tcp_syncookies = 1 kernel.msgmnb = 65536 kernel.msgmax = 65536 net.ipv4.neigh.default.gc_thresh3 = 4096 net.ipv4.neigh.default.gc_thresh2 = 2048 net.ipv4.neigh.default.gc_thresh1 = 1024 net.core.wmem_max = 16777216 net.ipv4.tcp_rmem = 4096 8388608 16777216 net.ipv4.tcp_wmem = 4096 4194394 16777216 net.core.wmem_default = 4194394 net.core.rmem_default = 8388608 net.core.netdev_max_backlog = 2000 net.ipv4.tcp_max_syn_backlog = 1024 net.core.somaxconn = 262144 net.ipv4.tcp_timestamps = 1 net.ipv4.tcp_no_metrics_save = 0 net.netfilter.nf_conntrack_tcp_timeout_established = 3600 net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120 net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120 net.netfilter.nf_conntrack_generic_timeout = 300 net.netfilter.nf_conntrack_max = 824288 net.netfilter.nf_conntrack_udp_timeout = 30 net.netfilter.nf_conntrack_udp_timeout_stream = 180 net.nf_conntrack_max = 824288 net.ipv4.tcp_max_tw_buckets = 262144 vm.swappiness=5 eth0 поделен на eth0.10/100/552 eth1 поделен на eth1.87/217 По умолчанию бесклассовая дисциплина на физ.интерфейсах выглядит: # tc qdisc show qdisc mq 0: dev eth0 root qdisc mq 0: dev eth1 root С такой конфигурацией шейпера (вернее его "отсутствии") машина показывает хорошие результаты роутинга пакетов в районе 120kpps. Но стОит добавить хоть одину дисциплину очереди(любую) к VLAN-интерфейсу, допустим: tc qdisc add dev eth0.10 root handle 1: htb как сразу же число обрабатываемых пакетов снижается до уровня ~80-90kpps, абоненты начинают кричать, что всё тормозит. Появляются 1-2% потери по пингу. CPU utilization снижается вместе с pps, до уровня среднего при 80-90kpps. При нагрузке - ДО 80kpps, аналогичного падения pps не замечено. То есть до 80kpps всё роутится+шейпится отлично, если выше - начинаются тормоза. Предпринимал попытки заменить очередь на физических интерфейсах c mq на pfifo (стандартная для большинства linux систем), но проблема остается абсолютно такой-же. Пробовал менять ядра на 2.6.30 и 2.6.35, там подобных проблем не наблюдается, но мне нужно 38-е ядро. upd. на сервере используется NAT updd. при присоединении к VLAN-интерфейсу любой дисциплины очереди (htb, pfifo, hfsc, tbf..) пакеты на данном интерфейсе начинают дико дропаться вне зависимости от конфигурации очереди Ребят, помогите? Проблемы бы могло и не быть, если бы я в правилах шейпера не опустил строки, отвечающие за подкласс общего класса для всех кто не попадает в фильтры :) Опишу наглядно с примером в пределах одного интерфейса. /sbin/tc qdisc del dev eth0.10 root /sbin/tc qdisc add dev eth0.10 root handle 1: htb default 10 /sbin/tc class add dev eth0.10 parent 1: classid 1:1 htb rate 1000Mbit burst 1280k cburst 1280k /sbin/tc class add dev eth0.10 parent 1:1 classid 1:10 htb rate 100Mbit ceil 1000Mbit burst 1280k cburst 1280k /sbin/tc class add dev eth0.10 parent 1:1 classid 1:11 htb rate 1Mbit ceil 25Mbit burst 64k cburst 64k quantum 9000 #elcom /sbin/tc class add dev eth0.10 parent 1:1 classid 1:13 htb rate 100Kbit ceil 2Mbit burst 4k cburst 4k #privb10 /sbin/tc class add dev eth0.10 parent 1:1 classid 1:14 htb rate 100Kbit ceil 2Mbit burst 4k cburst 4k #privb /sbin/tc class add dev eth0.10 parent 1:1 classid 1:15 htb rate 100Kbit ceil 2Mbit burst 4k cburst 4k #kspz /sbin/tc qdisc add dev eth0.10 parent 1:10 handle 10: sfq perturb 10 /sbin/tc qdisc add dev eth0.10 parent 1:11 handle 11: sfq perturb 10 /sbin/tc qdisc add dev eth0.10 parent 1:13 handle 13: sfq perturb 10 /sbin/tc qdisc add dev eth0.10 parent 1:14 handle 14: sfq perturb 10 /sbin/tc qdisc add dev eth0.10 parent 1:15 handle 15: sfq perturb 10 #Создаем корневой фильтр /sbin/tc filter add dev eth0.10 parent 1: protocol ip u32 #Создаем хеш таблицу для 10.230.109.0/24 /sbin/tc filter add dev eth0.10 parent 1:0 handle 63: protocol ip u32 divisor 256 #Добавляем правило в хеш таблицу, если ip dst входит в 10.230.109.0.24, то оправляем пакет в 63 хеш таблицу /sbin/tc filter add dev eth0.10 parent 1:0 protocol ip prio 1 u32 ht 800:: match ip dst 10.230.109.0/24 hashkey mask 0xff at 16 link 63: /sbin/tc filter add dev eth0.10 parent 1:0 protocol ip prio 1 u32 ht 63:61: match ip dst 10.230.109.97/32 flowid 1:13 #privb10 /sbin/tc filter add dev eth0.10 parent 1:0 protocol ip prio 1 u32 ht 63:63: match ip dst 10.230.109.99/32 flowid 1:14 #privb /sbin/tc filter add dev eth0.10 parent 1:0 protocol ip prio 1 u32 ht 63:1b: match ip dst 10.230.109.27/32 flowid 1:15 #kspz #если пакет из этой подсети не входит в указанную выше маску, отправляется в 10 класс /sbin/tc filter add dev eth0.10 parent 1:0 protocol ip prio 2 u32 ht 63:: match ip dst 10.230.109.0/24 flowid 1:10 #all #ну и еще разные правила #24.53.192.0/18 /sbin/tc filter add dev eth0.10 parent 1:0 protocol ip prio 14 u32 match ip src 24.53.192.0/18 flowid 1:11 #86.34.96.0/19 /sbin/tc filter add dev eth0.10 parent 1:0 protocol ip prio 14 u32 match ip src 86.34.96.0/19 flowid 1:11 #53.167.192.0/19 /sbin/tc filter add dev eth0.10 parent 1:0 protocol ip prio 14 u32 match ip src 53.167.192.0/19 flowid 1:11 #159.236.192.0/18 /sbin/tc filter add dev eth0.10 parent 1:0 protocol ip prio 14 u32 match ip src 159.236.192.0/18 flowid 1:11 #56.27.48.0/20 /sbin/tc filter add dev eth0.10 parent 1:0 protocol ip prio 14 u32 match ip src 56.27.48.0/20 flowid 1:11 #78.28.192.0/19 /sbin/tc filter add dev eth0.10 parent 1:0 protocol ip prio 14 u32 match ip src 78.28.192.0/19 flowid 1:11 Так вот, в ранних ядрах 2.6.30 и 2.6.35 я мог опустить 10 подкласс с конечной дисциплиной этого класса и отправлять пакеты не прошедшие фильтры сразу в 1 класс. В версиях 2.6.38 2.6.39, по какой-то причине пакеты отправленные в default 1 дропались с огромной скоростью. Спасибо @nuclearcat, за подсказку.