tnega Posted January 24, 2019 · Report post Приветствую всех. Имеем сервер доступа Supermicro SYS-6016-NTF E5645 - 2 шт. две планки DDR3 по 8 гб (16 гб) На борту сетевушка X520-DA2 - 2 оптических порта 10G Стоит Debian8, 64 битная, 3.16 ядро. Потребление памяти держится в районе 900 мегабайт. С вышестоящим работаем по схеме Аутсорминга, используем канал + ип адреса вышестоящего. (работает статическая маршрутизация), никаких BGP и тому подобных вещей. То есть оператор нам прописал несколько подсетей, например: 47.171.52.0/24 , где ip 47.171.52.254 - шлюз вышестоящего, мы в свою очередь поднимаем 253 айпишник и прописываем шлюз по умолчанию 254. НА коммутаторе аплинка стоит медный модуль, от него идет патчкорд в наш медиаконвертер SNR с модулем 1 gb так же от SNR на 20 км. Расстояние до аплинка ровно километр. На другой стороне модуль такой же вставлен в нашу сетевушку. Собственно конфиг: eth0 - аплинк (берем 900 мегабит) eth1 - внутренняя сеть Разрешающие правила на ИПсете, ограничение скорости - ipt-ratelimit Авторизация абонентов происходит следующим образом: 1. Выдаем ип адреса по PPPoE - используя accel-ppp + включаем proxy arp на аплинк интерфейсе. 2. Используя правила маршрутизация выдаем прямо на интерфейс абоненту нужный ип адрес так же используя proxy arp (Само собой разумеется сеть поделена на vlan) Обычно - один коммутатор доступа этой свой vlan. perf top: Цитата Samples: 13K of event 'cycles', Event count (approx.): 2180591292 5,96% [kernel] [k] tpacket_rcv 3,45% [kernel] [k] _raw_spin_unlock_irqrestore 3,39% [kernel] [k] _raw_spin_lock_irqsave 3,35% [kernel] [k] prb_fill_curr_block.isra.56 3,08% [kernel] [k] try_to_wake_up 2,51% [kernel] [k] fib_table_lookup 2,48% [kernel] [k] __sk_run_filter 2,37% [kernel] [k] _raw_spin_lock 2,22% [kernel] [k] __memcpy 2,22% [kernel] [k] task_waking_fair 2,09% [kernel] [k] ipt_do_table 2,00% [kernel] [k] irq_entries_start 1,65% [kernel] [k] __wake_up_common 1,58% [kernel] [k] sock_def_readable 1,42% [kernel] [k] ixgbe_clean_rx_irq 1,31% [kernel] [k] idle_cpu 1,29% [kernel] [k] get_nohz_timer_target 1,27% [kernel] [k] __netif_receive_skb_core 1,19% [kernel] [k] ixgbe_poll 1,07% [kernel] [k] _raw_spin_lock_bh 0,99% [kernel] [k] __x86_indirect_thunk_rax 0,98% [kernel] [k] tcp_packet 0,97% [kernel] [k] dev_queue_xmit_nit 0,94% [kernel] [k] packet_rcv 0,92% [kernel] [k] nf_iterate 0,88% [kernel] [k] __schedule 0,84% [kernel] [k] ixgbe_xmit_frame_ring 0,81% [kernel] [k] ratelimit_mt 0,77% [kernel] [k] __nf_conntrack_find_get 0,72% [kernel] [k] enqueue_task_fair 0,71% [kernel] [k] check_leaf.isra.6 0,69% [kernel] [k] __tick_nohz_idle_enter 0,67% [kernel] [k] kmem_cache_alloc 0,66% [kernel] [k] native_read_tsc 0,62% [kernel] [k] ip_route_input_noref 0,62% [kernel] [k] cpu_startup_entry 0,59% [kernel] [k] __copy_skb_header 0,57% [kernel] [k] ip_finish_output 0,57% bandwidthd [.] 0x0000000000003254 0,55% [kernel] [k] ip_forward 0,55% [kernel] [k] resched_task 0,52% [kernel] [k] kfree_skb 0,50% [kernel] [k] kmem_cache_free 0,49% [kernel] [k] ip_rcv 0,48% [kernel] [k] skb_release_head_state 0,47% [kernel] [k] skb_copy_bits 0,43% [kernel] [k] nf_conntrack_in 0,43% [kernel] [k] conntrack_mt 0,42% [kernel] [k] __dev_queue_xmit 0,42% [kernel] [k] net_rx_action 0,41% bandwidthd [.] 0x0000000000003240 0,38% [kernel] [k] __local_bh_enable_ip 0,36% [kernel] [k] timerqueue_add 0,34% [kernel] [k] rcu_eqs_enter_common 0,34% [kernel] [k] read_tsc 0,33% [kernel] [k] ns_to_timespec 0,33% [kernel] [k] pick_next_task_fair 0,32% [kernel] [k] fib_validate_source Прерывания: Цитата CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 CPU8 CPU9 CPU10 CPU11 0: 49 0 0 0 0 0 0 0 0 0 0 0 IR-IO-APIC-edge timer 1: 44 0 0 0 0 0 0 0 0 0 0 0 IR-IO-APIC-edge i8042 8: 1 0 0 0 0 0 0 0 0 0 0 0 IR-IO-APIC-edge rtc0 9: 0 0 0 0 0 0 0 0 0 0 0 0 IR-IO-APIC-fasteoi acpi 16: 0 0 0 0 0 0 0 0 0 0 0 0 IR-IO-APIC-fasteoi uhci_hcd:usb1 18: 105884 0 0 0 0 0 0 0 0 0 0 0 IR-IO-APIC-fasteoi uhci_hcd:usb6, i801_smbus, ehci_hcd:usb7 19: 0 0 0 0 0 0 0 0 0 0 0 0 IR-IO-APIC-fasteoi uhci_hcd:usb3, uhci_hcd:usb5 21: 97 0 0 0 0 0 0 0 0 0 0 0 IR-IO-APIC-fasteoi uhci_hcd:usb2 23: 0 0 0 0 0 0 0 0 0 0 0 0 IR-IO-APIC-fasteoi uhci_hcd:usb4, ehci_hcd:usb8 64: 0 0 0 0 0 0 0 0 0 0 0 0 DMAR_MSI-edge dmar0 65: 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI-edge ahci0 66: 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI-edge ahci1 67: 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI-edge ahci2 68: 9961716 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI-edge ahci3 69: 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI-edge ahci4 70: 0 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI-edge ahci5 81: 2 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI-edge ioat-msix 82: 2 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI-edge ioat-msix 83: 2 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI-edge ioat-msix 84: 2 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI-edge ioat-msix 85: 2 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI-edge ioat-msix 86: 2 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI-edge ioat-msix 87: 2 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI-edge ioat-msix 88: 2 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI-edge ioat-msix 98: 3858478732 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI-edge eth0-TxRx-0 99: 1021021 1870683371 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI-edge eth0-TxRx-1 100: 1438931 0 1864252386 0 0 0 0 0 0 0 0 0 IR-PCI-MSI-edge eth0-TxRx-2 101: 1199239 0 0 1865663611 0 0 0 0 0 0 0 0 IR-PCI-MSI-edge eth0-TxRx-3 102: 961851 0 0 0 1859422691 0 0 0 0 0 0 0 IR-PCI-MSI-edge eth0-TxRx-4 103: 1184649 0 0 0 0 1813235595 0 0 0 0 0 0 IR-PCI-MSI-edge eth0-TxRx-5 104: 52868695 0 0 0 0 0 1588721848 0 0 0 0 0 IR-PCI-MSI-edge eth0-TxRx-6 105: 1440822 50125387 0 0 0 0 0 1618957864 0 0 0 0 IR-PCI-MSI-edge eth0-TxRx-7 106: 880104 713579 47273934 0 0 0 0 0 1497158064 0 0 0 IR-PCI-MSI-edge eth0-TxRx-8 107: 1001817 0 529599 49184290 0 0 0 0 0 1512925816 0 0 IR-PCI-MSI-edge eth0-TxRx-9 108: 1643122 0 0 385590 38369953 0 0 0 0 0 1527001778 0 IR-PCI-MSI-edge eth0-TxRx-10 109: 837444 0 0 0 655614 53024024 0 0 0 0 0 1492178236 IR-PCI-MSI-edge eth0-TxRx-11 110: 23489 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI-edge eth0 111: 4256532932 0 0 0 0 0 618517 0 0 0 0 0 IR-PCI-MSI-edge eth1-TxRx-0 112: 581562 2262606794 0 0 0 0 0 481989 0 0 0 0 IR-PCI-MSI-edge eth1-TxRx-1 113: 385543 0 2278041526 0 0 0 0 0 87982 0 0 0 IR-PCI-MSI-edge eth1-TxRx-2 114: 516953 0 0 2621660894 0 0 0 0 0 138967 0 0 IR-PCI-MSI-edge eth1-TxRx-3 115: 562310 0 0 0 2235760447 0 0 0 0 0 227550 0 IR-PCI-MSI-edge eth1-TxRx-4 116: 513670 0 0 0 0 2201959736 0 0 0 0 0 223650 IR-PCI-MSI-edge eth1-TxRx-5 117: 21206914 0 0 0 0 0 1892658344 0 0 0 0 0 IR-PCI-MSI-edge eth1-TxRx-6 118: 765525 18984819 0 0 0 0 0 1921207513 0 0 0 0 IR-PCI-MSI-edge eth1-TxRx-7 119: 556751 268386 22205410 0 0 0 0 0 1785488852 0 0 0 IR-PCI-MSI-edge eth1-TxRx-8 120: 368814 0 453908 17838521 0 0 0 0 0 1809035866 0 0 IR-PCI-MSI-edge eth1-TxRx-9 121: 514247 0 0 200868 26944466 0 0 0 0 0 1822227961 0 IR-PCI-MSI-edge eth1-TxRx-10 122: 446813 0 0 0 225987 19037154 0 0 0 0 0 1787990116 IR-PCI-MSI-edge eth1-TxRx-11 123: 10046 0 0 0 0 0 0 0 0 0 0 0 IR-PCI-MSI-edge eth1 NMI: 622879 110913 105021 106648 105073 104682 91286 99563 91435 91518 92512 93895 Non-maskable interrupts LOC: 75999457 54908998 51040185 55534553 50201193 47634003 54668540 69246400 49088345 48878165 47464230 44943665 Local timer interrupts SPU: 0 0 0 0 0 0 0 0 0 0 0 0 Spurious interrupts PMI: 622879 110913 105021 106648 105073 104682 91286 99563 91435 91518 92512 93895 Performance monitoring interrupts IWI: 14713 7482 8046 7420 7315 7468 6398 14762 6229 6489 7788 6635 IRQ work interrupts RTR: 11 0 0 0 0 0 0 0 0 0 0 0 APIC ICR read retries RES: 36852014 21121957 18924858 19445329 18740817 18845529 18141078 16858517 18106808 18801529 18803493 19502448 Rescheduling interrupts CAL: 63043 184938 52303 55865 38181 28385 227286 2919997 330084 252064 222760 210574 Function call interrupts TLB: 60069 182198 49343 52989 35422 25600 23216 258670 73036 44034 30920 24589 TLB shootdowns TRM: 0 0 0 0 0 0 0 0 0 0 0 0 Thermal event interrupts THR: 0 0 0 0 0 0 0 0 0 0 0 0 Threshold APIC interrupts MCE: 0 0 0 0 0 0 0 0 0 0 0 0 Machine check exceptions MCP: 3106 3106 3106 3106 3106 3106 3106 3106 3106 3106 3106 3106 Machine check polls HYP: 0 0 0 0 0 0 0 0 0 0 0 0 Hypervisor callback interrupts ERR: 0 MIS: 0 Сетевые: Цитата ethtool -k eth0 Features for eth0: rx-checksumming: on tx-checksumming: on tx-checksum-ipv4: on tx-checksum-ip-generic: off [fixed] tx-checksum-ipv6: on tx-checksum-fcoe-crc: on [fixed] tx-checksum-sctp: on scatter-gather: on tx-scatter-gather: on tx-scatter-gather-fraglist: off [fixed] tcp-segmentation-offload: off tx-tcp-segmentation: off tx-tcp-ecn-segmentation: off [fixed] tx-tcp6-segmentation: off udp-fragmentation-offload: off [fixed] generic-segmentation-offload: off generic-receive-offload: off large-receive-offload: off rx-vlan-offload: on tx-vlan-offload: on ntuple-filters: off receive-hashing: on highdma: on [fixed] rx-vlan-filter: on vlan-challenged: off [fixed] tx-lockless: off [fixed] netns-local: off [fixed] tx-gso-robust: off [fixed] tx-fcoe-segmentation: on [fixed] tx-gre-segmentation: off [fixed] tx-ipip-segmentation: off [fixed] tx-sit-segmentation: off [fixed] tx-udp_tnl-segmentation: off [fixed] tx-mpls-segmentation: off [fixed] fcoe-mtu: off [fixed] tx-nocache-copy: off loopback: off [fixed] rx-fcs: off [fixed] rx-all: off tx-vlan-stag-hw-insert: off [fixed] rx-vlan-stag-hw-parse: off [fixed] rx-vlan-stag-filter: off [fixed] l2-fwd-offload: off busy-poll: on [fixed] Цитата ethtool -k eth1 Features for eth1: rx-checksumming: on tx-checksumming: on tx-checksum-ipv4: on tx-checksum-ip-generic: off [fixed] tx-checksum-ipv6: on tx-checksum-fcoe-crc: on [fixed] tx-checksum-sctp: on scatter-gather: on tx-scatter-gather: on tx-scatter-gather-fraglist: off [fixed] tcp-segmentation-offload: off tx-tcp-segmentation: off tx-tcp-ecn-segmentation: off [fixed] tx-tcp6-segmentation: off udp-fragmentation-offload: off [fixed] generic-segmentation-offload: off generic-receive-offload: off large-receive-offload: off rx-vlan-offload: on tx-vlan-offload: on ntuple-filters: off receive-hashing: on highdma: on [fixed] rx-vlan-filter: on vlan-challenged: off [fixed] tx-lockless: off [fixed] netns-local: off [fixed] tx-gso-robust: off [fixed] tx-fcoe-segmentation: on [fixed] tx-gre-segmentation: off [fixed] tx-ipip-segmentation: off [fixed] tx-sit-segmentation: off [fixed] tx-udp_tnl-segmentation: off [fixed] tx-mpls-segmentation: off [fixed] fcoe-mtu: off [fixed] tx-nocache-copy: off loopback: off [fixed] rx-fcs: off [fixed] rx-all: off tx-vlan-stag-hw-insert: off [fixed] rx-vlan-stag-hw-parse: off [fixed] rx-vlan-stag-filter: off [fixed] l2-fwd-offload: off busy-poll: on [fixed] sysctl: Цитата net.ipv4.neigh.default.gc_thresh1=20480 net.ipv4.neigh.default.gc_thresh2=40960 net.ipv4.neigh.default.gc_thresh3=81920 net.ipv4.netfilter.ip_conntrack_max=16777216 net.ipv4.tcp_max_syn_backlog=4096 net.netfilter.nf_conntrack_generic_timeout = 120 net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 net.ipv4.udp_mem = 8388608 12582912 16777216 net.ipv4.tcp_rmem = 4096 87380 8388608 net.ipv4.tcp_wmem = 4096 87380 8388608 net.ipv4.conf.all.rp_filter=1 net.ipv4.conf.all.accept_source_route=0 net.ipv4.conf.lo.accept_source_route=0 net.ipv4.conf.eth0.accept_source_route=0 net.ipv4.conf.eth1.accept_source_route=0 net.ipv4.conf.default.accept_source_route=0 net.ipv4.conf.all.accept_redirects=1 net.ipv4.conf.all.secure_redirects=1 net.ipv4.conf.all.send_redirects=1 net.ipv4.icmp_echo_ignore_broadcasts = 1 net.ipv4.icmp_ignore_bogus_error_responses=1 net.ipv4.tcp_max_syn_backlog=4096 net.ipv4.tcp_synack_retries=1 net.ipv4.tcp_max_orphans=65536 net.ipv4.tcp_fin_timeout=10 net.ipv4.tcp_keepalive_time=60 net.ipv4.tcp_keepalive_intvl=15 net.ipv4.tcp_keepalive_probes=5 net.core.somaxconn=15000 net.ipv4.tcp_orphan_retries=0 net.ipv4.tcp_congestion_control=htcp net.ipv4.tcp_no_metrics_save=1 net.ipv4.ip_local_port_range=1024 65535 net.ipv4.tcp_tw_reuse=1 net.ipv4.tcp_rfc1337=1 При старте делаем: Цитата sudo echo 65536 > /sys/module/nf_conntrack/parameters/hashsize sudo echo 0 > /proc/sys/net/ipv4/conf/eth1/accept_redirects sudo echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp sudo ethtool -G eth0 rx 4096 tx 4096 sudo ethtool -G eth1 rx 4096 tx 4096 sudo ethtool -K eth0 tso off gso off gro off lro off sudo ethtool -K eth1 tso off gso off gro off lro off Собственно проблема: В часы пик загрузка ЦП судя по htop не поднимается выше 15-20 % При это потребление в районе 500-600 мегабит трафика Еще раз напомню, что от вышестоящего получаем 900 мегабит. В эти моменты я ощущаю как буд-то какую-=то преграду по входящему трафику, если днем на спидтесте том же я вижу 150-200 мегабит, на торрентах естественно больше и до 300 мегабит поднимаюсь, то в часы пик скорость на тех же торрентах в два раза падает и в спидтесте тоже, держится в районе 100 мегабит. Смотрю по snmp скорость на аплинк порту, не видел чтобы она подходила до 700 мегабит, в основном держится в пределах 550-650 мегабит. и не поднимается выше. По исходящему трафику - проблем нет, в том же спдитесте до узлов вышестоящего и других близких операторов скорость может подняться и до 500 мегабит. В чем может быть дело? Сеть небольшая, 700 абонентов. Неужели мощи не хватает? Может быть мы со своей стороны что-то недоглядели? Грешу на ядровой коммутатор, его и ядровым не назовешь конечно. Сразу за сервером стоит DGS-3100-24TG, от него уже идут ответвления на 3526, 1100-06/ME, 1100-08 и еще парочка DGS-3100-24TG в других районах и от них такие же ответвления. Или на медиаконвертер который на аплинке? где-то слышал и не раз, что невозможно по меди поднять чистый гигабит, но слухи были относительно длинных кабелей медных, а там грубо говоря пол метра патч корд. До этого стоял аналогично настроенный сервер: e5440 2 шт. 4 гб ddr2 и сетевушка i350-t2 + медиаконвертер такой же как и на аплинке с модулем. (порты то медные) Нагрузка на цп в часы пик была 30-40 % в htop Новый сервер как мы видим сильно не напрягается. Посоветуйте пожалуйста что нибудь друзья товарищи. Может где-то что-то подтюнить надо или сами где-то что-то не так настроили. Цитата ifconfig eth1 eth1 Link encap:Ethernet HWaddr 90:e2:ba:22:6f:a5 inet addr:10.10.0.1 Bcast:10.10.255.255 Mask:255.255.0.0 inet6 addr: fe80::92e2:baff:fe22:6fa5/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:13820555136 errors:14 dropped:74 overruns:0 frame:14 TX packets:24924756454 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:10000 RX bytes:3630802577966 (3.3 TiB) TX bytes:32222804138512 (29.3 TiB) Цитата uptime 19:16:30 up 10 days, 19:06, 1 user, load average: 0,96, 0,78, 0,79 Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Saab95 Posted January 24, 2019 · Report post А на форуме в соседней теме пишут, что микротик загибается при 2000 абонентах, а тут тазик с работой справится не может. Как вариант - циску поставить=) А если по делу - не пробовали с самого сервера во время момента, когда замечаете что скорость не поднимается, попробовать догрузить входящий канал, меняется что-то? Как один из вариантов - уйти от прокси АРП, оператор с тем же успехом может смаршрутизировать вам эти адреса, а не вываливать в порт пачками. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
crank Posted January 24, 2019 · Report post 1 час назад, tnega сказал: Или на медиаконвертер который на аплинке? где-то слышал и не раз, что невозможно по меди поднять чистый гигабит, но слухи были относительно длинных кабелей медных, а там грубо говоря пол метра патч корд. Испытавали проблемы с мультикастом через медиаконвертор. Заменили на свич и проблема решилась. В вашем случае скорее всего проблема не в этом, но как вариант можно рассмотреть. Всё зависит от того на сколько вам удобно переделать на другой способ включения. Вы также писали 1 час назад, tnega сказал: НА коммутаторе аплинка стоит медный модуль, от него идет патчкорд в наш медиаконвертер SNR с модулем 1 gb так же от SNR на 20 км. Я правильно понимаю, что у аплинка оптический свич с медным модлуем в SFP? Если так, то зачем то вообще медиаконвертор? 1 час назад, tnega сказал: С вышестоящим работаем по схеме Аутсорминга, используем канал + ип адреса вышестоящего. (работает статическая маршрутизация), никаких BGP и тому подобных вещей. То есть оператор нам прописал несколько подсетей, например: 47.171.52.0/24 , где ip 47.171.52.254 - шлюз вышестоящего, мы в свою очередь поднимаем 253 айпишник и прописываем шлюз по умолчанию 254. Исходя из размеров предоставляемых вам сетей и того, что у вас около 700 абонентов вы используете NAT. Покажите вывод sysctl -a | grep conntrack Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
jffulcrum Posted January 24, 2019 · Report post 1 час назад, tnega сказал: 5,96% [kernel] [k] tpacket_rcv У вас что на захват пакетов работает? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
agent2011 Posted January 24, 2019 (edited) · Report post Исправил-обновил Edited January 24, 2019 by agent2011 Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
tnega Posted January 24, 2019 · Report post 59 минут назад, crank сказал: Испытавали проблемы с мультикастом через медиаконвертор. Заменили на свич и проблема решилась. В вашем случае скорее всего проблема не в этом, но как вариант можно рассмотреть. Всё зависит от того на сколько вам удобно переделать на другой способ включения. Вы также писали Я правильно понимаю, что у аплинка оптический свич с медным модлуем в SFP? Если так, то зачем то вообще медиаконвертор? Исходя из размеров предоставляемых вам сетей и того, что у вас около 700 абонентов вы используете NAT. Покажите вывод sysctl -a | grep conntrack Наш конвертер в километре от нашего центрального узла. на узле аплинка. Медный модуль у него в коммутаторе, по тех условию они нам могут дать оптикой только по двум волокнам. Они у нас есть там еще одно волокно, но не хочется его задействовать. Оператор большой, в некотором роде гибкий, но не всегда, что касается его оборудования - там есть сложности. При подключении к ним мы ждали еще недели две когда им модуль этот медный пришлют. Кстати, не так давно мы поставили у них на узле еще одну DGS-3100-24TG, для организация vlan стыка уже для нашего аплинка на базей нашей сети, для их корп. клиента. Можно попробовать как вариант из их коммутатора с модулем медным в наш коммутатор так же в медный порт. По поводу ната, я забыл указать, что есть некоторое кол-во абонентов с серыми ип адресами. Мы поднимаем доп ип на интерфейсе аплинка и маршрутизируем трафик на данный серый ип: Цитата ip addr add 47.171.52.74/24 dev eth0 - доп ип ipset -A accept 10.10.0.48 - даем абоненту доступ в интернет iptables -t nat -A POSTROUTING -s 10.10.0.48/32 -j SNAT --to-source 47.171.52.74 - нат правило sysctl -a | grep conntrack - ничего не выводит :-) 49 минут назад, jffulcrum сказал: У вас что на захват пакетов работает? это скорее всего bandwidthd, с помощью него мы смотрим потребление трафика по ip у конкретных ип адресов. Используя аутсорминг особо не заморачиваемся с нетфлоу и всем таким прочим, просто выдаём по одному статическому ип адресу внешнему на абонента. У нас три подсети ип адресов прокинуто если что /24 1 час назад, Saab95 сказал: А на форуме в соседней теме пишут, что микротик загибается при 2000 абонентах, а тут тазик с работой справится не может. Как вариант - циску поставить=) А если по делу - не пробовали с самого сервера во время момента, когда замечаете что скорость не поднимается, попробовать догрузить входящий канал, меняется что-то? Как один из вариантов - уйти от прокси АРП, оператор с тем же успехом может смаршрутизировать вам эти адреса, а не вываливать в порт пачками. Можно поподробнее про дозагрузку? :-) и про то, чтобы уйти от прокси ARP. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
NiTr0 Posted January 24, 2019 · Report post 3 часа назад, tnega сказал: В чем может быть дело? аплинк исключили? попросите временно в ваш влан зароутить еще одну стыковочную подсеть на тесты. 3 часа назад, tnega сказал: Сразу за сервером стоит DGS-3100-24TG выкинуть каку, заменить на что-то более вменяемое, с не таким микроскопическим буфером. 768кб - это грусть-печаль и дикие дропы как только исходящий трафик на порту приближается к 600-700 мбитам. а это чудо - на агрегацию малонагруженных узлов либо на включение сотками корпоратов. 3 часа назад, tnega сказал: Или на медиаконвертер который на аплинке? маловероятно, но я бы таки советовал от медика избавиться. аплинк - в свич, порты на тазик - в агрегацию. только свич - не 3100, а что-то более адекватное (и желательно не 1210/1510 длинки а хотя бы dgs3000-28sc). Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
s.lobanov Posted January 24, 2019 · Report post Я бы сделал следующее. В ЧНН попросил бы кого-нибудь пульнуть вам 400-500мбит/с UDP в течение минут 15 - это такая примитивная проверка аплинка на вшивость. У вас должна быть полка по тарифу - 900мбит/с. Если не будет, то пинайте аплинка Дальше - я не понял схему, вы б нарисовали чтоль. А то не понятно как это всё работает - у вас на сервере порты 10G, а линк до аплинка - 1G, где-то свитч какой-то стоит... У и не понятно, вы этот vlan можете вывести в обход сервера (до сервера) чтобы напрямую забрать один ip из этой сети и проверить судя по тому что вы показываете - на сервер пока подозрений нет. ну и смотрите на статистику дропов на всех свитчах до точки включения тестового ПК Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Saab95 Posted January 25, 2019 · Report post 12 часов назад, tnega сказал: Можно поподробнее про дозагрузку? :-) и про то, чтобы уйти от прокси ARP. Дозагрузка просто - скачайте что-то с интернета на сервер, либо подключите к нему компьютер и качайте с него, как вариант, воткните в сеть провайдера компьютер, установите один из свободных белых адресов и проверьте скорость там. Должны получить полную утилизацию входящего канала. Что бы уйти от прокси ARP достаточно попросить провайдера дать вам белую сеть /30, по которой вы установите связь с его оборудованием, а он уже на этот адрес смаршрутизирует вашу сеть /24. Так же стоит посмотреть как сделана ваша локалка, насколько хорошо там все сегментировано и т.п. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
tnega Posted January 25, 2019 (edited) · Report post Друзья, товарищи, установил rtorrent на сервер, инициализировал несколько закачек, канал был загружен примерно мегабит на 550-600. смотрел нагрузку на аплинк vnstat ом Удалось подняться до 750 мегабит, больше не увидел. В этот период запускал на клиентской машине торрент и спидтест, скорость держалась и в торренте и в спидтесте - в районе 40 мегабит. Отключил закачки на сервере - поднялась на клиентском до 80-90 мегабит. С исходящим - воде все в порядке судя по спидтесту, без пробелм 300 выжимал до разных узлов и больше. То есть ситуация такая: При небольших нагрузках 200-300 мегабит - абонент может получить и 200-300 мегабит свободно. При нагрузках в час пик -в районе 100 мегабит. При этом мы знаем, что грубо говоря - почти половина пропускной способности канала у нас простаивает. Есть у кого нибудь какие нибудь мысли еще? Всем ответившим спасибо, прислушался, проверю. Есть мысль еще один сервер доступа ввести, подключить его к аплинку. Посмотреть как два сервера будут вести себя на одном аплинке. Переживаем за то, что кто-то захочет попросить у нас 200-300 мегабит - а мы их дать не сможем в часы пик :-) в основном все у нас все берут 50 мегабит. Edited January 25, 2019 by tnega Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
NiTr0 Posted January 25, 2019 · Report post 14 минут назад, tnega сказал: Есть у кого нибудь какие нибудь мысли еще? проверять аплинк на вшивость. если download низкий а upload в порядке - 99% что у аплинка где-то полочка нарисовалась. сервер доступа ставить не обязательно, достаточно будет ноутбука с белым IP, iperf'ом + спидтестом. ну и intel_idle.max_cstate=0 processor.max_cstate=1 - есть в параметрах ядра же? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
h3ll1 Posted January 25, 2019 · Report post accel шейпер есть? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
tnega Posted January 25, 2019 (edited) · Report post 36 минут назад, h3ll1 сказал: accel шейпер есть? нет, шейпер на проверяемых машинах отключен, то есть правила для данных айпишниках отсутствуют. а так испольузем ipt-ratelimit полисер 42 минуты назад, NiTr0 сказал: проверять аплинк на вшивость. если download низкий а upload в порядке - 99% что у аплинка где-то полочка нарисовалась. сервер доступа ставить не обязательно, достаточно будет ноутбука с белым IP, iperf'ом + спидтестом. ну и intel_idle.max_cstate=0 processor.max_cstate=1 - есть в параметрах ядра же? GRUB_CMDLINE_LINUX_DEFAULT="quiet processor.max_cstate=1 intel_idle.max_cstate=0 - это имеете ввиду? :-) стоит сейчас в грубе. Вот самое интересное, что вроде как сумарно, мы доходим и поднимаемся до 750, грубо до 800 мегабит. Но при больших нагрузках на клиентской машине не можем подняться больше 100-150 мегабит. При маленьких нагрузках днем или ночью можем выжать и 300-400 мегабит на абоненте. Айпишники белые выдавали, snat не используя - всё тоже самое, абсолютно никак ситуация не меняется. Edited January 25, 2019 by tnega Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
NiTr0 Posted January 25, 2019 · Report post 17 минут назад, tnega сказал: Вот самое интересное, что вроде как сумарно, мы доходим и поднимаемся до 750, грубо до 800 мегабит. Но при больших нагрузках на клиентской машине не можем подняться больше 100-150 мегабит. а что интересного-то? обычные дропы пакетов на путиот сервера где-то в интернетах до клиента... вероятнее всего - оконечный свич аплинка или медик. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
tnega Posted January 25, 2019 · Report post 23 минуты назад, NiTr0 сказал: а что интересного-то? обычные дропы пакетов на путиот сервера где-то в интернетах до клиента... вероятнее всего - оконечный свич аплинка или медик. Вас понял, у аплинка на узле стоит еще один DGS-3100-24TG, к нему подходит другое волокно. Сейчас схема такая: Изображение 1 Потянет ли наша DGS-ка 2 гигабита через себя пробрасывать по разным портам? То есть, наш головной будет связан с аплинком и внутренней сетью одновременно. Изображение 2 Если мы переключим для пробы всё по второй схеме, чтобы уйти от медиаонкертера. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
h3ll1 Posted January 25, 2019 · Report post 3 hours ago, tnega said: нет, шейпер на проверяемых машинах отключен, то есть правила для данных айпишниках отсутствуют. а так испольузем ipt-ratelimit полисер https://github.com/aabc/ipt-ratelimit/issues/13 можно что. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
tnega Posted January 26, 2019 · Report post 5 утра нагрузка на канал 30 мегабит. убирали правила шейпера из конфига полностью и добавляли, результат один и тот же. сомневаюсь, что шейпер как-то влияет. нормально ли, то что такой перекос в скоростях? (до других узлов ближайших такая же картина) так было всегда. никогда не видели больше 300 по входящему, зато исходящий на высоте. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
zhenya` Posted January 26, 2019 · Report post выбросите 3100. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
tnega Posted January 26, 2019 · Report post 8 минут назад, zhenya` сказал: выбросите 3100. Думаем об этом уже давно, поближе к доступу их переставить, а на магистрали поставить SNR-S2995G-24FX. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
tnega Posted January 26, 2019 · Report post Нормальное ли поведение самого верхнего процесса? Цитата 5,28% [kernel] [k] _raw_spin_unlock_irqrestore 4,84% [kernel] [k] tpacket_rcv 3,13% [kernel] [k] _raw_spin_lock_irqsave 2,74% [kernel] [k] __sk_run_filter 2,56% [kernel] [k] prb_fill_curr_block.isra.56 2,25% [kernel] [k] _raw_spin_lock 2,16% [kernel] [k] fib_table_lookup 2,09% [kernel] [k] try_to_wake_up 1,79% [kernel] [k] __memcpy 1,75% [kernel] [k] task_waking_fair 1,73% [kernel] [k] ipt_do_table 1,60% [kernel] [k] get_nohz_timer_target 1,59% [kernel] [k] irq_entries_start 1,57% [kernel] [k] sock_def_readable 1,40% [kernel] [k] __schedule 1,32% [kernel] [k] ixgbe_clean_rx_irq 1,27% [kernel] [k] __netif_receive_skb_core 1,26% [kernel] [k] __wake_up_common 1,25% [kernel] [k] enqueue_task_fair 1,10% [kernel] [k] ixgbe_poll 1,02% [kernel] [k] idle_cpu 1,00% [kernel] [k] dev_queue_xmit_nit 0,96% [kernel] [k] __x86_indirect_thunk_rax 0,96% [kernel] [k] _raw_spin_lock_bh 0,87% [kernel] [k] nf_iterate 0,86% [kernel] [k] ratelimit_mt 0,83% bandwidthd [.] 0x0000000000003254 0,82% [kernel] [k] cpu_startup_entry 0,79% [kernel] [k] native_read_tsc 0,74% [kernel] [k] tcp_packet 0,71% [kernel] [k] ixgbe_xmit_frame_ring 0,69% [kernel] [k] packet_rcv 0,66% [kernel] [k] resched_task 0,66% [kernel] [k] kmem_cache_free 0,66% bandwidthd [.] 0x0000000000003240 0,63% [kernel] [k] check_leaf.isra.6 0,60% [kernel] [k] __switch_to 0,57% [kernel] [k] kfree_skb 0,57% [kernel] [k] kmem_cache_alloc 0,57% [kernel] [k] __nf_conntrack_find_get 0,56% [kernel] [k] ip_finish_output 0,56% [kernel] [k] poll_schedule_timeout 0,55% [kernel] [k] ip_route_input_noref 0,54% [kernel] [k] __tick_nohz_idle_enter 0,53% [kernel] [k] datagram_poll 0,53% [kernel] [k] ip_forward 0,52% [kernel] [k] __copy_skb_header 0,52% [kernel] [k] finish_task_switch 0,50% [kernel] [k] pick_next_task_fair 0,46% [kernel] [k] skb_copy_bits 0,44% [kernel] [k] conntrack_mt 0,44% [kernel] [k] __hrtimer_start_range_ns 0,43% [kernel] [k] rcu_eqs_enter_common 0,42% [kernel] [k] dequeue_task_fair 0,42% [kernel] [k] ip_rcv 0,41% [kernel] [k] nf_conntrack_in 0,41% [kernel] [k] schedule 0,37% [kernel] [k] net_rx_action Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
NiTr0 Posted January 26, 2019 · Report post 11 часов назад, tnega сказал: у аплинка на узле стоит еще один DGS-3100-24TG все понятно. выкинуть каку. если кака аплинка - сменить аплинка, т.к. у него вся сеть из говна и веток. эти поделки нормально более 500-600 мбит в порт не отдают. 11 часов назад, tnega сказал: Потянет ли наша DGS-ка 2 гигабита через себя пробрасывать по разным портам? нет. выкиньте каку. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
jffulcrum Posted January 26, 2019 · Report post 2 часа назад, tnega сказал: Нормальное ли поведение самого верхнего процесса? Обычные циклические блокировки. Подъедают одно ядро, кто конкретно - смотреть дебаггером, но в принципе с таким трафиком и таким нагромождением софта и фильтров причина врядли будет чем-то удивительным - тот же NAT создает циклические блокировки вполне штатно. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
agent2011 Posted January 26, 2019 (edited) · Report post Обновил Edited January 26, 2019 by agent2011 Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
tnega Posted January 26, 2019 · Report post 6 часов назад, NiTr0 сказал: все понятно. выкинуть каку. если кака аплинка - сменить аплинка, т.к. у него вся сеть из говна и веток. эти поделки нормально более 500-600 мбит в порт не отдают. нет. выкиньте каку. Вас понял. Тогда жду того момента как приедут SNR и отписываюсь по теме Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
TriKS Posted January 26, 2019 (edited) · Report post 4 часа назад, jffulcrum сказал: Обычные циклические блокировки. Подъедают одно ядро, кто конкретно - смотреть дебаггером Не только. Вполне себе может отстукиваться как работа 2-го проца(у ТС прерываняи каждой сетевки раскиданы на обе НУМЫ). Т.е. когда сетевка физически относится к 1-му процу, а юзает память и прерывания 2-го через кривенький qpi, который всему виной. Но супермикро вроде не страдали таким. Имею в проде 2х E5649. Тащит 4,5Гб с softirq 20%. Чуть НАТа имеется. Ценник за такой HP был 300 баксов. Того и взяли. Можно раскидать 1-ю сетевку на 1-проц, 2-ю на второй. Должно попустить поидее. Edited January 26, 2019 by TriKS Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...