[Иванов Денис]

Коллеги, может кто интересовался/сталкивался и поможет разъяснить некоторые моменты. :)

 

Например, я увеличиваю значения параметров nf_conntrack CONNTRACK_MAX и HASHSIZE

echo 14588928 > /proc/sys/net/ipv4/netfilter/ip_conntrack_max
echo 14588928 > /sys/module/nf_conntrack/parameters/hashsize

Правильно ли я понял, что в таком случае под хеш-таблицу и записи CONNTRACK должно быть выделено от 2.7 до 5.0 ГБ памяти?

 

Методика расчёта:

http://wiki.khnet.info/index.php/Conntrack_tuning

The size of kernel memory used by netfilter connection tracking is:

size_of_mem_used_by_conntrack (in bytes) = CONNTRACK_MAX * sizeof(struct ip_conntrack) + HASHSIZE * sizeof(struct list_head)

where:

sizeof(struct ip_conntrack) can vary quite much, depending on architecture, kernel version and compile-time configuration. To know its size, see the kernel log message at ip_conntrack initialization time.

sizeof(struct ip_conntrack) is around 300 bytes on i386 for 2.6.5, but heavy development around 2.6.10 make it vary between 352 and 192 bytes!

sizeof(struct list_head) = 2 * size_of_a_pointer On i386, size_of_a_pointer is 4 bytes.

14588928 * 352 + 14588928 * 2 * 8 = 5368725504 (5.0 ГБ)

14588928 * 192 + 14588928 * 2 * 8 = 3034497024 (2.7 ГБ)

(размер указателя для x86_64 равен 8 байтам)

 

Правильно ли я понял, что хеш-таблица CONNTRACK - это статическая структура фиксированного размера, поэтому после существенного увеличения HASHSIZE, сразу же должен существенно уменьшится объём свободной памяти?

[vitalyb]

Правильно ли я понял, что в таком случае под хеш-таблицу и записи CONNTRACK должно быть выделено от 2.7 до 5.0 ГБ памяти?

не "должно", а "может".

 

Правильно ли я понял, что хеш-таблица CONNTRACK - это статическая структура фиксированного размера, поэтому после существенного увеличения HASHSIZE, сразу же должен существенно уменьшится объём свободной памяти?

14588928 * 2 * 8 выделится сразу. 14588928 * 352 - при наличии 14588928 состояний.

 

Но это довольно грубый расчет.

[Иванов Денис]

Благодарю! :)

[d10r]

Иванов Денис, как Вам удалось увеличить значение hashsize до такой величины?

Система с 16 гигабайт оперативной памяти, Linux 3.4.9 x86_64. При попытке выставить значение /sys/module/nf_conntrack/parameters/hashsize выше 524288 получаю ошибку "nf_conntrack: falling back to vmalloc." nf_conntrack version 0.5.0

cat /proc/meminfo:

 

 

MemTotal: 16508876 kB

MemFree: 16344284 kB

Buffers: 6836 kB

Cached: 41572 kB

SwapCached: 0 kB

Active: 31272 kB

Inactive: 33184 kB

Active(anon): 16064 kB

Inactive(anon): 128 kB

Active(file): 15208 kB

Inactive(file): 33056 kB

Unevictable: 0 kB

Mlocked: 0 kB

SwapTotal: 8189944 kB

SwapFree: 8189944 kB

Dirty: 0 kB

Writeback: 0 kB

AnonPages: 16084 kB

Mapped: 8060 kB

Shmem: 148 kB

Slab: 34820 kB

SReclaimable: 7620 kB

SUnreclaim: 27200 kB

KernelStack: 1216 kB

PageTables: 1736 kB

NFS_Unstable: 0 kB

Bounce: 0 kB

WritebackTmp: 0 kB

CommitLimit: 16444380 kB

Committed_AS: 61540 kB

VmallocTotal: 34359738367 kB

VmallocUsed: 308572 kB

VmallocChunk: 34359429011 kB

HardwareCorrupted: 0 kB

AnonHugePages: 0 kB

HugePages_Total: 0

HugePages_Free: 0

HugePages_Rsvd: 0

HugePages_Surp: 0

Hugepagesize: 2048 kB

DirectMap4k: 7848 kB

DirectMap2M: 2060288 kB

DirectMap1G: 14680064 kB

 

 

На стандартном ядре CentOS 6.3 2.6.32-279.14.1.el6.x86_64 та же ситуация.

Перерыл все параметры в .config, не могу понять, где же проблема.

Единственное, что удалось найти, это обсуждение патча на lkml.org.

[Soltik]

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

[pppoetest]

cat /sys/module/nf_conntrack/parameters/hashsize
1048576

uname -sr
Linux 2.6.32-5-686

dmesg | grep vers | grep conn
[   13.785050] nf_conntrack version 0.5.0

grep Mem /proc/meminfo
MemTotal:        3585816 kB
MemFree:         1711652 kB

Edited November 22, 2012 by pppoetest

[d10r]

Soltik, в том то и дело, что нужен для nat`а

проблема где-то в параметрах конфигурации ядра, либо в системных переменных, но не могу понять, где именно.

sysctl.txt

.config.txt

Edited November 22, 2012 by d10r

[Soltik]

Сколько же народу за этим одним натом сидит? Может тогда подрезать им количество одновременных сессий, а то же торренты, например, совершенно ненасытны.

Кроме того, имеет смысл обратить внимание на таймауты tcp и udp сессий (net.ipv4.netfilter.ip_conntrack_***), нынче инет не на диалапе чтоб счет вести на десятки минут, а то и на часы. Можно поанализировать файл /proc/net/ip_conntrack, там третье поле - длительность висящей сессии, если там большое количество записей с сильно большими числами - надо сокращать таймауты.

Вот что-то такое например:

cut /proc/net/ip_conntrack -d" " -f8 | sort -n | uniq -c

если разбивать по пробелам, у меня это поле восьмым вышло, поэтому -f8

[Ilya Evseev]

При попытке выставить значение /sys/module/nf_conntrack/parameters/hashsize выше 524288 получаю ошибку "nf_conntrack: falling back to vmalloc." nf_conntrack version 0.5.0

Это не ошибка, а некритичное предупреждение.

[d10r]

Да, хоть ругается, но память ест.

 

cat /proc/meminfo

MemTotal: 16485308 kB

MemFree: 4548888 kB

 

net.netfilter.nf_conntrack_count = 24535304

[vitalyb]

Можно поанализировать файл /proc/net/ip_conntrack

Лучше не надо, особенно при таком количестве состояний - при его чтении таблица блокируется (или раньше блокировалась) и трафик перестает ходить. conntrack-tools используйте.

[Soltik]

24млн соединений??? нее, что-то там не так. Пусть будет 10тыс юзеров, получается по 2400 соединений на каждого, это анриал какой-то. Хотя сомневаюсь, что одна линуксовая машина столько народу тянет.

[replicant]

24 млн. это же какой должен быть трафик через машину? Точно какой-то анрил. Надо смотреть что не так с трафиком. Явно соединения висят мертвым грузом.

 

У меня при входящем 180 Мбайт/с и исходящем около 80 Мбайт/с получается так:

 

MemTotal: 4005256 kB

MemFree: 2897692 kB

 

conntrack_count = 381287

 

Нагрузка на Intel Xeon X3470 2.93GHz около 25-30% в этот момент времени.

Edited November 24, 2012 by replicant

[flow]

Доброго времени суток. Может у кого появятся идеи по поводу подземного стука. Есть две одинаковых машинки c i7 и сетевушками Intel X520-DA2 с дровами 3.10.16, сетевушки включены в PCI-E 16x. Трафика на обеих машинках практически одинаково - около 4 гигабит. На обоих работает нат.

На одной

cat /sys/module/nf_conntrack/parameters/hashsize
131072
cat /etc/sysctl.conf 
net.nf_conntrack_max = 1048576

На другой

cat /sys/module/nf_conntrack/parameters/hashsize
3145728
cat /etc/sysctl.conf 
net.nf_conntrack_max = 3145728

Соответственно количество трансляций на второй машинке раз в 8 превышает количество на первой и составляет около 800-900K записей. При этом CPU хватает обоим машинкам. Ну а теперь к проблеме. На втором компе при приближении трафика к 4 гигабитам, ну и соотв. с ростом трансляций начинают капать missed_errors, причем хорошо так капать

ethtool -S eth1 |grep error
    rx_missed_errors: 5733715

при этом если смотреть на buffers там все ок

ethtool -S eth1 |grep buff
    rx_no_buffer_count: 0
    alloc_rx_buff_failed: 0

Куда в итоге смотреть уже непонятно )

Edited November 28, 2012 by flow

[s.lobanov]

Покажите ethtool -k eth1 и ethtool -g eth1 на проблемном сервере. и ещё sysctl -a | grep nf_conntrack | grep timeout тоже посмотреть интересно

[flow]

Покажите ethtool -k eth1 и ethtool -g eth1 на проблемном сервере. и ещё sysctl -a | grep nf_conntrack | grep timeout тоже посмотреть интересно

 

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

 

 

ethtool -g eth1
Ring parameters for eth1:
Pre-set maximums:
RX:             4096
RX Mini:        0
RX Jumbo:       0
TX:             4096
Current hardware settings:
RX:             4096
RX Mini:        0
RX Jumbo:       0
TX:             4096

 

sysctl -a | grep nf_conntrack | grep timeout 
net.netfilter.nf_conntrack_generic_timeout = 600
net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 30
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 15
net.netfilter.nf_conntrack_tcp_timeout_established = 18000
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 30
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60
net.netfilter.nf_conntrack_tcp_timeout_last_ack = 30
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_close = 10
net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300
net.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 300
net.netfilter.nf_conntrack_udp_timeout = 30
net.netfilter.nf_conntrack_udp_timeout_stream = 60
net.netfilter.nf_conntrack_icmp_timeout = 20
net.netfilter.nf_conntrack_events_retry_timeout = 15

[s.lobanov]

А что говорит ethtool -a eth1? и какой размер netdev_max_backlog установлен?

[Alex/AT]

Скорее всего поллинг не поспевает.

 

Навскидку - сразу:

net.core.dev_weight = 16
net.core.netdev_budget = 256
net.core.netdev_max_backlog = 16000
net.core.netdev_tstamp_prequeue = 0

После применения последить за ситуацией - в какую сторону изменится, и изменится ли.

 

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

Edited November 28, 2012 by Alex/AT

[flow]

А что говорит ethtool -a eth1? и какой размер netdev_max_backlog установлен?

ethtool -a eth1                  
Pause parameters for eth1:
Autonegotiate:  off
RX:             off
TX:             off

 

 sysctl net.core.netdev_max_backlog
net.core.netdev_max_backlog = 10000

[flow]

Скорее всего поллинг не поспевает.

 

Навскидку - сразу:

net.core.dev_weight = 16
net.core.netdev_budget = 256
net.core.netdev_max_backlog = 16000
net.core.netdev_tstamp_prequeue = 0

После применения последить за ситуацией - в какую сторону изменится, и изменится ли.

 

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

Выкрутил

net.core.dev_weight = 16
net.core.netdev_budget = 256
net.core.netdev_max_backlog = 16000

Про net.core.netdev_tstamp_prequeue упоминания нет вообще. К сожалению ничего не изменилось - rx_missed_errors капают судя по графику приблизительно с той же скоростью. С хэшами - стояло вообще 131072, это уже я ковырялся пытаясь понять, что происходит.

Edited November 28, 2012 by flow

[d10r]

replicant,Soltik, прошу прощения что не указал сразу, это тестовая машинка с малой долей реального трафика, подавляющее количество записей в таблице трассировщика генерируется с помощью hping.

[Alex/AT]

Про net.core.netdev_tstamp_prequeue упоминания нет вообще.

А ядрышко какое у Вас? Вообще интересны

uname -a

и

cat /proc/interrupts

Edited November 29, 2012 by Alex/AT

[flow]

Про net.core.netdev_tstamp_prequeue упоминания нет вообще.

А ядрышко какое у Вас? Вообще интересны

uname -a

и

cat /proc/interrupts

Пардон, думал сразу написал, ядрышко старое 2.6.32-5-amd64.

 

cat /proc/interrupts
          CPU0       CPU1       CPU2       CPU3       
 0:         78          0          0          0   IO-APIC-edge      timer
 1:          8          0          0          0   IO-APIC-edge      i8042
 8:          1          0          0          0   IO-APIC-edge      rtc0
 9:          0          0          0          0   IO-APIC-fasteoi   acpi
16:          0          0          0          0   IO-APIC-fasteoi   uhci_hcd:usb2
18:          0          0          0          0   IO-APIC-fasteoi   ehci_hcd:usb1, uhci_hcd:usb8
19:          0          0          0          0   IO-APIC-fasteoi   uhci_hcd:usb5, uhci_hcd:usb7
20:       2468          0          0          0   IO-APIC-fasteoi   ata_piix, ata_piix
21:          0          0          0          0   IO-APIC-fasteoi   uhci_hcd:usb4
23:          0          0          0          0   IO-APIC-fasteoi   ehci_hcd:usb3, uhci_hcd:usb6
24:          3          0          0          0   IO-APIC-fasteoi   nouveau
53:  177666178          0          0          0   PCI-MSI-edge      eth1-rx-0
54:       4914  177182141          0          0   PCI-MSI-edge      eth1-rx-1
55:       4933          0  171629860          0   PCI-MSI-edge      eth1-rx-2
56:       4641          0          0  174198299   PCI-MSI-edge      eth1-rx-3
57:  171895373          0          0          0   PCI-MSI-edge      eth1-tx-0
58:         10  171625997          0          0   PCI-MSI-edge      eth1-tx-1
59:          8          0  166330464          0   PCI-MSI-edge      eth1-tx-2
60:          8          0          0  167255591   PCI-MSI-edge      eth1-tx-3
61:        838          0          0          0   PCI-MSI-edge      eth1:lsc
71:          0          0          0          0   PCI-MSI-edge      eth0
NMI:          0          0          0          0   Non-maskable interrupts
LOC:    1843298    2190505    2255786    2314688   Local timer interrupts
SPU:          0          0          0          0   Spurious interrupts
PMI:          0          0          0          0   Performance monitoring interrupts
PND:          0          0          0          0   Performance pending work
RES:        159        164        140        121   Rescheduling interrupts
CAL:          1         29         29         28   Function call interrupts
TLB:        158        907        474        246   TLB shootdowns
TRM:          0          0          0          0   Thermal event interrupts
THR:          0          0          0          0   Threshold APIC interrupts
MCE:          0          0          0          0   Machine check exceptions
MCP:         38         38         38         38   Machine check polls
ERR:          0
MIS:          0

[Alex/AT]

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

Потому что вообще rx_missed_errors означает, что забивается FIFO на карте - не успевает передать данные по шине / не опрашивают карту.

А слот PCI-E "честный" x16, или обрезок типа x4/x8 / разделяемый со вторым слотом, где видеоадаптер? Память одно- двух- или трех- канальная?

Вообще конечно еще информация по железу нужна - может быть и проблема с платформой.

Edited November 29, 2012 by Alex/AT

[flow]

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

Потому что вообще rx_missed_errors означает, что забивается FIFO на карте - не успевает передать данные по шине / не опрашивают карту.

А слот PCI-E "честный" x16, или обрезок типа x4/x8 / разделяемый со вторым слотом, где видеоадаптер? Память одно- двух- или трех- канальная?

Вообще конечно еще информация по железу нужна - может быть и проблема с платформой.

Там стоит Asus P6T, слот там судя по виду честный, память трехканальная, 3x1g работающие на 1066. Собственно первая машинка, где проблем нет, абсолютно идентична по железу и по трафику, отличается только количество трансляций, ну и профиль трафика. Мысль от том, что при наличии rx_missed_errors, нет buffers loss, в принципе достаточно явно указывает на проблемы с шиной, вот только непонятно на какие - по имеющимся на руках данным ресурса хватает ).

Edited November 29, 2012 by flow