Jump to content
Калькуляторы

сервер доступа linux/debian производительность и скорость

Приветствую всех.

 

Имеем сервер доступа 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

 

Share this post


Link to post
Share on other sites

А на форуме в соседней теме пишут, что микротик загибается при 2000 абонентах, а тут тазик с работой справится не может. Как вариант - циску поставить=)

 

А если по делу - не пробовали с самого сервера во время момента, когда замечаете что скорость не поднимается, попробовать догрузить входящий канал, меняется что-то?

 

Как один из вариантов - уйти от прокси АРП, оператор с тем же успехом может смаршрутизировать вам эти адреса, а не вываливать в порт пачками.

Share this post


Link to post
Share on other sites
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

 

Share this post


Link to post
Share on other sites
1 час назад, tnega сказал:

5,96%  [kernel]            [k] tpacket_rcv

У вас что на захват пакетов работает?

Share this post


Link to post
Share on other sites

Исправил-обновил

Edited by agent2011

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
3 часа назад, tnega сказал:

В чем может быть дело?

аплинк исключили? попросите временно в ваш влан зароутить еще одну стыковочную подсеть на тесты.

 

3 часа назад, tnega сказал:

Сразу за сервером стоит DGS-3100-24TG

выкинуть каку, заменить на что-то более вменяемое, с не таким микроскопическим буфером. 768кб - это грусть-печаль и дикие дропы как только исходящий трафик на порту приближается к 600-700 мбитам. а это чудо - на агрегацию малонагруженных узлов либо на включение сотками корпоратов.

 

3 часа назад, tnega сказал:

Или на медиаконвертер который на аплинке?

маловероятно, но я бы таки советовал от медика избавиться. аплинк - в свич, порты на тазик - в агрегацию. только свич - не 3100, а что-то более адекватное (и желательно не 1210/1510 длинки а хотя бы dgs3000-28sc).

Share this post


Link to post
Share on other sites

Я бы сделал следующее. В ЧНН попросил бы кого-нибудь пульнуть вам 400-500мбит/с UDP в течение минут 15 - это такая примитивная проверка аплинка на вшивость. У вас должна быть полка по тарифу - 900мбит/с. Если не будет, то пинайте аплинка

 

Дальше - я не понял схему, вы б нарисовали чтоль. А то не понятно как это всё работает - у вас на сервере порты 10G, а линк до аплинка - 1G, где-то свитч какой-то стоит... У и не понятно, вы этот vlan можете вывести в обход сервера (до сервера) чтобы напрямую забрать один ip из этой сети и проверить

 

 судя по тому что вы показываете - на сервер пока подозрений нет.

 

ну и смотрите на статистику дропов на всех свитчах до точки включения тестового ПК

Share this post


Link to post
Share on other sites
12 часов назад, tnega сказал:

Можно поподробнее про дозагрузку? :-) и про то, чтобы уйти от прокси ARP.

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

 

Что бы уйти от прокси ARP достаточно попросить провайдера дать вам белую сеть /30, по которой вы установите связь с его оборудованием, а он уже на этот адрес смаршрутизирует вашу сеть /24.

 

Так же стоит посмотреть как сделана ваша локалка, насколько хорошо там все сегментировано и т.п.

Share this post


Link to post
Share on other sites

Друзья, товарищи, установил rtorrent на сервер, инициализировал несколько закачек, канал был загружен примерно мегабит на 550-600.

смотрел нагрузку на аплинк vnstat ом

 

Удалось подняться до 750 мегабит, больше не увидел.

В этот период

запускал на клиентской машине торрент и спидтест, скорость держалась и в торренте и в спидтесте - в районе 40 мегабит.

 

Отключил закачки на сервере - поднялась на клиентском до 80-90 мегабит. С исходящим - воде все в порядке судя по спидтесту, без пробелм 300 выжимал до разных узлов и больше.

 

То есть ситуация такая:

При небольших нагрузках 200-300 мегабит - абонент может получить и 200-300 мегабит свободно.

При нагрузках в час пик -в районе 100 мегабит. При этом мы знаем, что грубо говоря - почти половина пропускной способности канала у нас простаивает.

 

Есть у кого нибудь какие нибудь мысли еще?

Всем ответившим спасибо, прислушался, проверю.

 

Есть мысль еще один сервер доступа ввести, подключить его к аплинку. Посмотреть как два сервера будут вести себя на одном аплинке.

 

 

Переживаем за то, что кто-то захочет попросить у нас 200-300 мегабит - а мы их дать не сможем в часы пик :-)

в основном все у нас все берут 50 мегабит.

Edited by tnega

Share this post


Link to post
Share on other sites
14 минут назад, tnega сказал:

Есть у кого нибудь какие нибудь мысли еще?

проверять аплинк на вшивость. если download низкий а upload в порядке - 99% что у аплинка где-то полочка нарисовалась. сервер доступа ставить не обязательно, достаточно будет ноутбука с белым IP, iperf'ом + спидтестом.

 

ну и intel_idle.max_cstate=0 processor.max_cstate=1 - есть в параметрах ядра же?

Share this post


Link to post
Share on other sites

accel шейпер есть?

 

Share this post


Link to post
Share on other sites
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 by tnega

Share this post


Link to post
Share on other sites
17 минут назад, tnega сказал:

Вот самое интересное, что вроде как сумарно, мы доходим и поднимаемся до 750, грубо до 800 мегабит.

Но при больших нагрузках на клиентской машине не можем подняться больше 100-150 мегабит.

 

а что интересного-то? обычные дропы пакетов на путиот сервера где-то в интернетах до клиента... вероятнее всего - оконечный свич аплинка или медик.

Share this post


Link to post
Share on other sites
23 минуты назад, NiTr0 сказал:

а что интересного-то? обычные дропы пакетов на путиот сервера где-то в интернетах до клиента... вероятнее всего - оконечный свич аплинка или медик.

Вас понял, у аплинка на узле стоит еще один DGS-3100-24TG, к нему подходит другое волокно.

 

Сейчас схема такая:

Изображение 1

 

Потянет ли наша DGS-ка 2 гигабита через себя пробрасывать по разным портам?

То есть, наш головной будет связан с аплинком и внутренней сетью одновременно.

Изображение 2

 

Если мы переключим для пробы всё по второй схеме, чтобы уйти от медиаонкертера.

NONAME1.jpg

NONAME2.jpg

Share this post


Link to post
Share on other sites
3 hours ago, tnega said:

нет, шейпер на проверяемых машинах отключен, то есть правила для данных айпишниках отсутствуют.

а так испольузем ipt-ratelimit полисер

https://github.com/aabc/ipt-ratelimit/issues/13 можно что.

Share this post


Link to post
Share on other sites

5 утра нагрузка на канал 30 мегабит.

 

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

 

нормально ли, то что такой перекос в скоростях? (до других узлов ближайших такая же картина)

так было всегда. никогда не видели больше 300 по входящему, зато исходящий на высоте.

Безымянный.png

Share this post


Link to post
Share on other sites
8 минут назад, zhenya` сказал:

выбросите 3100.

Думаем об этом уже давно, поближе к доступу их переставить, а на магистрали поставить SNR-S2995G-24FX.

Share this post


Link to post
Share on other sites

Нормальное ли поведение самого верхнего процесса?

 

Цитата

   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

 

Share this post


Link to post
Share on other sites
11 часов назад, tnega сказал:

у аплинка на узле стоит еще один DGS-3100-24TG

все понятно. выкинуть каку. если кака аплинка - сменить аплинка, т.к. у него вся сеть из говна и веток.

эти поделки нормально более 500-600 мбит в порт не отдают.

 

11 часов назад, tnega сказал:

Потянет ли наша DGS-ка 2 гигабита через себя пробрасывать по разным портам?

нет. выкиньте каку.

Share this post


Link to post
Share on other sites
2 часа назад, tnega сказал:

Нормальное ли поведение самого верхнего процесса?

Обычные циклические блокировки. Подъедают одно ядро, кто конкретно - смотреть дебаггером, но в принципе с таким трафиком и таким нагромождением софта и фильтров причина врядли будет чем-то удивительным - тот же NAT создает циклические блокировки вполне штатно. 

Share this post


Link to post
Share on other sites
6 часов назад, NiTr0 сказал:

все понятно. выкинуть каку. если кака аплинка - сменить аплинка, т.к. у него вся сеть из говна и веток.

эти поделки нормально более 500-600 мбит в порт не отдают.

 

нет. выкиньте каку.

Вас понял.

Тогда жду того момента как приедут SNR и отписываюсь по теме

Share this post


Link to post
Share on other sites
4 часа назад, jffulcrum сказал:

Обычные циклические блокировки. Подъедают одно ядро, кто конкретно - смотреть дебаггером

Не только. Вполне себе может отстукиваться как работа 2-го проца(у ТС прерываняи каждой сетевки раскиданы на обе НУМЫ). Т.е. когда сетевка физически относится к 1-му процу, а юзает память и прерывания 2-го через кривенький qpi, который  всему виной. Но супермикро вроде не страдали таким. Имею в проде 2х E5649. Тащит 4,5Гб с softirq 20%. Чуть НАТа имеется. Ценник за такой HP был 300 баксов. Того и взяли.

Можно раскидать 1-ю сетевку на 1-проц, 2-ю на второй. Должно попустить поидее.

Edited by TriKS

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this