Перейти к содержимому
Калькуляторы

Да, всё правильно.

 

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

 

Ещё информация:

 


ethtool -k eth0
Offload parameters for eth0:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off
receive-hashing: on

 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Поменяйте бортовые 574L на нормальную двухголовую PT/ET карточку. Были те же чудеса с потерями на БРАСах с такими же сетевками, помогла только установка нормального адаптера.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

Кстати, а что это? MTU 9198 bytes

 

Это я уже сейчас поменял, в танцах с бубном.

 

 

Поставить другую сетёвку хотел, но не смог, увы - на сервере PCI-Express нет, да и имеющийся слот расширения занят SAS-контроллером.

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

MTU точно таким не должен быть, верните взад. Насчет сетевой - замена с большой вероятностью поможет, да, но мне кажется, что тут проблему можно решить без замены. Flow control включен? Если да, то выключите.

 

net.core.netdev_max_backlog=8192

net.ipv4.tcp_max_syn_backlog=1024

 

Поставьте человеческие очереди, пакетов эдак на 300-400К. Ну и не забудьте про очередь на конкретном интерфейсе.

 

Ну и я бы откатился на 2.6.27, потому что пахнет полтергейстом. Кстати, Вы говорили, что до тюнинга потерь не было. Пробовали скидывать всё на дефолт? Проблема остается?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

# ethtool -a eth0
Pause parameters for eth0:
Autonegotiate:  on
RX:             off
TX:             off

 

 

По поводу очереди и вышеприведённых sysct-переменных, вы не могли бы более конкретно указать, где это точно?

 

Откатываться назад всё же не очень хотелось бы. На дефолт sysctl как можно скинуть?

 

 

 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Увеличил net.ipv4.tcp_max_syn_backlog до 8192, передёрнул sysctl.conf (убрав кавычки у параметра net.ipv4.tcp_rmem="4096 8388608 16777216" и net.ipv4.tcp_wmem="4096 4194394 16777216", на которые ругался sysctl -p) и о чудо - дропы исчезли.

Кстати, кому нужно мониторить interrupts per second по каждому из прерываний, рекомендую - немного переписал безымянный перловый скрипт, найденный на просторах инета:

 

 

 

 

Переменные $skip_null и $time передаются через аргументы и служат, соответственно, для пропуска прерываний с нулевыми значениями и выбора интервала времени, за которое собирается статистика.

 

Regexp тупо под четыре процессора.

 

#!/usr/bin/perl
#
#       Interrupt top
#
#       Show the interrupts per second/per IRQ per CPU

# Parse /proc/interrupts file for data
#
#            CPU0       CPU1
#   0: 3025267376 3026744388    IO-APIC-edge  timer
#   1:     833854     843315    IO-APIC-edge  i8042
#   6:         15         63    IO-APIC-edge  floppy
#   7:          0          0    IO-APIC-edge  parport0
#   8:     532620     522911    IO-APIC-edge  rtc
#   9:          1          0   IO-APIC-level  acpi
#  12:    9812189    9981980    IO-APIC-edge  i8042
#  14:   27181914   27208373    IO-APIC-edge  ide0
#  58:  249517917          0   IO-APIC-level  eth0
#  66:    1090230    1089904   IO-APIC-level  ehci_hcd:usb1, uhci_hcd:usb2
# 169:      82497      85243   IO-APIC-level  HDA Intel, uhci_hcd:usb5, i915@pci:0000:00:02.0
# 217:          0          0   IO-APIC-level  uhci_hcd:usb4
# 233:    2809674    2795397   IO-APIC-level  libata, uhci_hcd:usb3
# NMI:          0          0
# LOC: 1754237653 1754237661
# ERR:          0
# MIS:          0

use IO::File;
use Term::Cap;
use Data::Dumper;

$term = Tgetent Term::Cap;
print $term->Tputs('cl');

$fh = new IO::File;

if (!$fh->open("</proc/interrupts")) {
       die "Unable to open /proc/interrupts";
}

$top = $fh->getpos();
$first_time = 0;
$skip_null = $ARGV[0];
$interval = $ARGV[1] || 1;

while (1) {
       $fh->setpos($top);

       # Read and parse interrupts
       $header = <$fh>; # Header line
       # Count CPUs
       $cpus = () = $header =~ /CPU/g;

       my %irqs;
       while (<$fh>) {
               #if (/^\s*(\d+):(\s*(\d+)\s*)*(\S+)\s*(.*)$/) {
               # Hardcoded CPU count in regexp. Don't know how to make it other way :(
               if (/^\s*(\d+):\s*(\d+)\s+(\S+)\s+(\S+)\s+(\S+)\s+(.*)$/) {
                       # Found a IRQ line, Build an assoc array of CPU values
#                       print $1 . " " . $2 .":". $3 .":". $4 .":". $5 .":". $6 . ":" . $7 .":". $8 .":". $9 . "\n";
                       $irq = $1;
                       for ($cpu = 0; $cpu < $cpus; $cpu++) {
                               $exp = '$icount = $' . ($cpu + 2);
                               eval $exp;
                               $irqs{$irq}[$cpu] = $icount
                       }
                       eval '$desc = $' . ($cpus + 2);
                       $desc =~ /(\S+)\s+(.*)$/;
                       $irq_type{$irq} = $1;
                       $irq_device{$irq} = $2;
                       #eval '$irq_type{$irq} = $' . ($cpus + 2);
                       #print $irq_type{$irq} . "\n";
                       #eval '$irq_device{$irq} = $' . ($cpus + 3);

               }
       }

       if ($first_time != 0) {
               # Prepare sceeen
               print $term->Tputs('ho');
               # Output header
               printf("%33s%" . ($cpus + 1) * 8 . "s", "", "IRQs/Second\n");
               printf('%20s (%3s)  ', "Device", "IRQ");
               foreach ($cpu = 0; $cpu < $cpus; $cpu++) {
                       printf('%8s ', 'CPU' . $cpu);
               }
               printf("%8s\n", "TOTAL");
               foreach $irq (sort keys %irqs) {
                       my $descr_str=sprintf('%20s (%3d): ', substr($irq_device{$irq}, 0, 20), $irq);
                       my $ips_str="";
                       $total = 0;
                       for ($cpu = 0; $cpu < $cpus; $cpu++) {
                               $ips_str .= sprintf("%8d ", ($irqs{$irq}[$cpu] - $last{$irq}[$cpu])/$interval);
                               $total += ($irqs{$irq}[$cpu] - $last{$irq}[$cpu])/$interval;
                       }
                       if ($skip_null) {
                           if ((int($total) != 0) ) {
                               print $descr_str;
                               print $ips_str;
                               printf("%8d\n", $total);
                           }else {
                               next;
                           }
                       }else {
                               print $descr_str;
                               print $ips_str;
                               printf("%8d\n", $total);
                       }
               }
       }
       $first_time = 1;


       %last = %irqs;
       sleep $interval;
}

 

 

 

 

Изменено пользователем Dyr

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

2yannails: Посмотрите ошибки на порту коммутатора. Ошибки в чексуммах обычно возникают именно на стыке. Вернее сказать, я других ситуаций, когда они возникают, - и не знаю.

 

2telecom: Бурное обсуждение начинается, когда предоставляются все данные. Когда данные в расследовании проблемы приходят отрывками, помогать очень сложно, если вообще реально. Я вас попросил показать буфер _и_ состояние порта коммутатора. Вы показали ринг и всё. Ринг обсуждать нечего, показывайте коммутатор.

 

Насчет карт посмотрите в сторону 82575 еще. Это младшая модель 82576 и имеет по 4 очереди на порт ( вместо 8ми ). Стоит в 2 раза дешевле. Гиг прожует без вопросов, если CPU хватит. Я бы рекомендовал брать именно 82575, 82576. С ними сон дежурного становится гарантированно приятным и продолжительным.

 

Насчет ядер, то если не надо фичи ядер старше, я бы рекомендовал оставаться на последних версиях 2.6.27. Там всё гарантированно нормально работает, и главное, быстро. Если надо, то начинается свистопляска с отдельными боками разных версий. Где-то НАТ укладывает машину на 3х Гбитах, где-то проблемы с бондингом, где-то проблемы с шейпером. Если кто-то нашел ядро посвежее и стабильное, а главное быстрое - расскажите.

 

Поддерживаю по всем пунктам. Если о ядрах, то у меня 2.6.33.х показывают себя даже лучше чем 2.6.27.х, поднимался выше по версиям и натыкался на сплошное "Г" и множественные баги. Остановился на 33 ветке. Все работает. Правда на 2.6.35.14 гоняю 1.5 Гбит/с с натом в бондинге, нагрузка выше 30% не поднимается. CPU Intel Q9400, карта Intel 82576 quad port.

 

Возникает чисто академический вопрос, связанный с уменьшением нагрузки на CPU:

 

- есть 4 портовая сетевая

- eth0 и eth1 - bond0 (смотрит в интернет)

- eth2 и eth3 - bond1 (смотрит в лок.сеть)

- трафик in 1.5 Гбит, out 800 Мбит

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

 

Будет ли нагрузка меньше, если сколотить bond иначе?

 

А именно: Объединить все 4 сетевые в bond0, а подняв на eth0-3 влан и засунув влан в bond1 организовать второй интерфейс. Таким образом задействуются все 4 сетевые каждом bond'е.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Упадет ли нагрузка - не знаю, скорее всего нет или на уровне стат погрешности, но распределение ресурсов будет заметно лучше, т.к. если где-то резко понадобится полоса ( например ДОС снаружи ), вы не упретесь в полку бондов по 2 порта. Я уже не говорю о случаях, когда один из портов/патчей по какой-то причине ломается и одно из направлений сразу деградирует. Другой вопрос, что стоит на той стороне бондов. Если разные железки, тогда не получится. Если одна - то я не вижу ниодного аргумента не сделать 1 интерфейс вместо двух.

 

За советы по ядру спасибо, но где-то на этих ветках ( 32-34 ) были проблемы с НАТом выше 3х Гбит. Ядро паниковало раз в сутки примерно. Где-то даже была тема здесь про это. Нет у вас НАТа на 33 и чтобы больше 3х Гбит?

Изменено пользователем Dark_Angel

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Если разные железки, тогда не получится. Если одна - то я не вижу ниодного аргумента не сделать 1 интерфейс вместо двух.

 

За советы по ядру спасибо, но где-то на этих ветках ( 32-34 ) были проблемы с НАТом выше 3х Гбит. Ядро паниковало раз в сутки примерно. Где-то даже была тема здесь про это. Нет у вас НАТа на 33 и чтобы больше 3х Гбит?

НАТа такого нет. Если и могут такие проблемы вылезти, то на 34 ядре. Ему доверия как-то нет.

По железкам не вопрос. Сейчас стоит 2, но легко могу затолкать все в одну. Оно все в одной физической стойке тусуется.

 

У меня еще вопрос. Опять же чисто академического свойства.

 

Есть 4-х портовая сетевая 82576. Есть 4-ядерный камень Q9400. Есть драйвер igb.

 

Внимание! Вопрос: Сколько оптимально очередей вешать на одно ядро (RSS) и какой ставить InterruptThrottleRate при условии что планируется НАТ на 2-3 Гбит?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

replicant,

1 очередь на 1 ядро. Tx+Rx можно слепить вместе.

InterruptThrottleRate выставлять вручную экспериментально либо же на автомат (там есть что-то такое, вроде adaptive или как-то так).

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

шейпер вроде одолел, download режит четко, а вот с upload траблы, на больших пакетах не вытягивает больше 10-16Мбит, схема NAT tc ifb, может ли это быть из-за параметров ядра, в чем может быть проблема?

(xeon 2x2.13 + intel 82576)

echo "300000" > /sys/module/nf_conntrack/parameters/hashsize

ethtool -A eth0 autoneg on
ethtool -K eth0 tso off tx off sg off
ethtool -G eth0 rx 4096 tx 4096

ethtool -A eth1 autoneg on
ethtool -K eth1 tso off tx off sg off
ethtool -G eth1 rx 4096 tx 4096

ifconfig eth0 txqueuelen 10000
ifconfig eth1 txqueuelen 10000

net.netfilter.nf_conntrack_max = 1533916
net.netfilter.nf_conntrack_tcp_timeout_established=3600

net.ipv4.neigh.default.gc_thresh1=2048
net.ipv4.neigh.default.gc_thresh2=4096
net.ipv4.neigh.default.gc_thresh3=8192

net.core.wmem_max = 16777216
net.core.wmem_default = 4194394
net.ipv4.tcp_wmem="4096 4194394 16777216"
net.core.rmem_max = 16777216
net.core.rmem_default = 8388608
net.ipv4.tcp_rmem="4096 8388608 16777216"

net.core.netdev_max_backlog=8192
net.ipv4.tcp_max_syn_backlog=8192

net.netfilter.nf_conntrack_tcp_be_liberal=1
net.ipv4.tcp_sack=0

net.ipv4.tcp_no_metrics_save = 1
net.core.somaxconn = 262144

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

шейпер вроде одолел, download режит четко, а вот с upload траблы, на больших пакетах не вытягивает больше 10-16Мбит, схема NAT tc ifb, может ли это быть из-за параметров ядра, в чем может быть проблема?

(xeon 2x2.13 + intel 82576)

Если ядро старше 2.6.33.х, то сделай так ethtool -K ethX tso off gro off gso off

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Если ядро старше 2.6.33.х, то сделай так ethtool -K ethX tso off gro off gso off

CentOS 6 kernel-2.6.32

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Прочитал статью http://nag.ru/articles/article/19974/kak-my-10gigabit-na-linux-routere-marshrutizirovali.html

 

Смутила фраза:

Просмотрев последнюю версию ядра 2.6.36.1 и убедившись, что последнее узкое место в драйвере VLAN было устранено (драйвер при подключение к реальной сетевой создавал столько же виртуальных очередей, как и на реальной сетевой)

 

В рамках задачи предстоит маршрутизировать 5-6 Гб/с трафика от клиентов в ядро на картах 10G Intel 82599 2xSFP+ или Intel 82598EB 2хCX4.

 

В задаче предстоит использовать множество (до 50 штук) VLAN и не хотелось бы попасть на косяк с ядрами версий 2.6.33.х или 2.6.35.х

 

Сервер предполагает отказ от использования 2 шт. DGS-3627 как L3 и перевод их в L2 ибо достали.

 

Cisco и т.п. использовать не предлагать т.к. цена вопроса!!! В случае с PC Based мы попадаем только на стоимость карты 10Гб/с, потому что сам PC уже есть.

 

Никаких задач, кроме тупого IP Forwarding серверу решать не придется. Никакого NAT, iptables, шейперов и прочего не планируется. Просто голое перекладывание пакетов с карты на карту или с влана на влан ...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну и никаких проблем у вас быть не должно. Кстати в чем проблема использовать более старые или новые ядра? В соседней теме пишут, что 3.1 ветка ведет себя вполне сносно при больших нагрузках.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Кстати в чем проблема использовать более старые или новые ядра?

Скажем так при простом ip forward разницы действительно скорее всего нет или она мифическая, но при использовании в определенных задачах как то pptp, pppoe, tc, flow, iptables+net+conntrack иногда вылезали глюки и возникала нестабильность.

 

Именно поэтому pptp с шейперами живут у меня на 2.6.33.19-20, а иногда на 2.6.27.54-59. Вцелом для проброса трафика пофиг что использовать, поэтому скорее всего возьму постарше ядра, но опять же осадок от них остался, да и вылизанный готовый конфиг для ветки 2.6.33 и 2.6.35 никто не отменял.

 

Посмотрю по ситуации. Использовать буду Slackware и скорее всего 64 битную.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Добрый день.

Нуждаюсь в совете, в рамках этой темы.

Есть софтовый роутер: Debian с ядром 2.6.26-2-686

 

Сервер следующей конфигурации:

 

2 проца:

processor : 0

vendor_id : GenuineIntel

cpu family : 15

model : 2

model name : Intel® Xeon MP CPU 2.70GHz

stepping : 6

cpu MHz : 2694.191

cache size : 2048 KB

fdiv_bug : no

hlt_bug : no

f00f_bug : no

coma_bug : no

fpu : yes

fpu_exception : yes

cpuid level : 2

wp : yes

flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pebs bts cid xtpr

 

2-хпортовый лан:

Ethernet controller: Intel Corporation 82546EB Gigabit Ethernet Controller (Copper) (rev 01)

Subsystem: IBM PRO/1000 MT Dual Port Network Adapter

Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 29

Memory at f9fe0000 (64-bit, non-prefetchable)

I/O ports at 2540

Capabilities: [dc] Power Management version 2

Capabilities: [e4] PCI-X non-bridge device

Capabilities: [f0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-

Kernel driver in use: e1000

Kernel modules: e1000

ethtool -i eth0

driver: e1000

version: 7.3.20-k2-NAPI

firmware-version: N/A

bus-info: 0000:06:08.0

 

Задача роутера принять все вланы (а их 114 штук) и прорулить трафик между вланами. Весь трафик заворачивается на ifb интерфейсы для организации QoS, так как сеть не однородная, присутствуют и оптические и радио линки.

Никакого НАТа нет, в iptables несколько правил.

Как только через машину начинает бежать трафик больше 200мБит/40мБит и пакетов 25kpps/17kpps – load average 3.5 – 4. ksoftirqd/0 = 100%, mpstat -P ALL 1: %idle(0)=0%, %idle(1)=0%, все кушает %soft.

Может эта машина больше и не в состоянии через себя прорулить?

Изменено пользователем _random

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Весь трафик заворачивается на ifb интерфейсы для организации QoS

...

Никакого НАТа нет, в iptables несколько правил.

...

Может эта машина больше и не в состоянии через себя прорулить?

 

Что-то мне подсказывает, что львиную долю в вашем случае съедают игры с ifb.

 

В чем тайный смысл заворота на ifb в данном случае? Мне почему-то казалось, что полезность ifb выявляется только в случае использования NAT'а и QoS на одной машине. Что мешает навешивать правила QoS прямо непосредственно на физические и/vlan интерфейсы?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А почему древний pentium4 c десктопной pci карточкой должен пропускать больше? Можно попробовать поиграться с notrack в iptables, должно разгрузить раза в 2. Ну и карточки попробовать более интеллектуальные, если есть возможность.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А почему бы ему и не пропустить?

 

cpu family      : 6
model           : 15
model name      : Intel(R) Xeon(R) CPU            5110  @ 1.60GHz
stepping        : 6
cpu MHz         : 1595.932
cache size      : 4096 KB

 

вполне себе пережевывает 500М в NAT'е + еще остается место под 3-кратное увеличение нагрузки. Ну и 2-головая сетевуха для десктопа это серьезно, да.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А почему бы ему и не пропустить?

model name      : Intel(R) Xeon(R) CPU            5110  @ 1.60GHz
cpu MHz         : 1595.932
cache size      : 4096 KB

А то что у вас двухядерный core, а у автора древний одноголовый p4 не важно? Еще б e56xx описали, а чего, тоже xeon.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

До недавнего времени на этом месте стоял как раз какой-то P4 как раз с указанной сетевухой. С аналогичной нагрузкой справлялся.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

До недавнего времени на этом месте стоял как раз какой-то P4 как раз с указанной сетевухой. С аналогичной нагрузкой справлялся.

Ога, с 500м НАТа и 3ех кратным запасом. То-то люди идиоты, под 1г ната машины собирают с топовыми 4ех ядерниками и сетевками с очередями.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вот на старой машине запас был не 3-кратный, но 700-800 потянула бы.

 

И, кстати, в первоначальном вопросе как раз про отсутствие NAT и правил iptables особо упоминалось. Так что потянуть должна. Просто ее надо настроить по уму.

Изменено пользователем taf_321

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В чем тайный смысл заворота на ifb в данном случае? Мне почему-то казалось, что полезность ifb выявляется только в случае использования NAT'а и QoS на одной машине. Что мешает навешивать правила QoS прямо непосредственно на физические и/vlan интерфейсы?

если не сложно, можно реальный пример QoS для входящего и исходящего трафика

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.