Иванов Денис Опубликовано 15 ноября, 2012 · Жалоба Коллеги, может кто интересовался/сталкивался и поможет разъяснить некоторые моменты. :) Например, я увеличиваю значения параметров 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, сразу же должен существенно уменьшится объём свободной памяти? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 16 ноября, 2012 · Жалоба Правильно ли я понял, что в таком случае под хеш-таблицу и записи CONNTRACK должно быть выделено от 2.7 до 5.0 ГБ памяти? не "должно", а "может". Правильно ли я понял, что хеш-таблица CONNTRACK - это статическая структура фиксированного размера, поэтому после существенного увеличения HASHSIZE, сразу же должен существенно уменьшится объём свободной памяти? 14588928 * 2 * 8 выделится сразу. 14588928 * 352 - при наличии 14588928 состояний. Но это довольно грубый расчет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Иванов Денис Опубликовано 16 ноября, 2012 · Жалоба Благодарю! :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
d10r Опубликовано 22 ноября, 2012 · Жалоба Иванов Денис, как Вам удалось увеличить значение 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. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Soltik Опубликовано 22 ноября, 2012 · Жалоба в некоторых случаях, когда не нужен трекинг соединений, имеет смысл не раздувать эти таблицы, а добавить пару правил в iptables, исключающих лишние записи. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pppoetest Опубликовано 22 ноября, 2012 (изменено) · Жалоба 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 Изменено 22 ноября, 2012 пользователем pppoetest Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
d10r Опубликовано 22 ноября, 2012 (изменено) · Жалоба Soltik, в том то и дело, что нужен для nat`а проблема где-то в параметрах конфигурации ядра, либо в системных переменных, но не могу понять, где именно. sysctl.txt .config.txt Изменено 22 ноября, 2012 пользователем d10r Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Soltik Опубликовано 22 ноября, 2012 · Жалоба Сколько же народу за этим одним натом сидит? Может тогда подрезать им количество одновременных сессий, а то же торренты, например, совершенно ненасытны. Кроме того, имеет смысл обратить внимание на таймауты tcp и udp сессий (net.ipv4.netfilter.ip_conntrack_***), нынче инет не на диалапе чтоб счет вести на десятки минут, а то и на часы. Можно поанализировать файл /proc/net/ip_conntrack, там третье поле - длительность висящей сессии, если там большое количество записей с сильно большими числами - надо сокращать таймауты. Вот что-то такое например: cut /proc/net/ip_conntrack -d" " -f8 | sort -n | uniq -c если разбивать по пробелам, у меня это поле восьмым вышло, поэтому -f8 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 23 ноября, 2012 · Жалоба При попытке выставить значение /sys/module/nf_conntrack/parameters/hashsize выше 524288 получаю ошибку "nf_conntrack: falling back to vmalloc." nf_conntrack version 0.5.0 Это не ошибка, а некритичное предупреждение. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
d10r Опубликовано 23 ноября, 2012 · Жалоба Да, хоть ругается, но память ест. cat /proc/meminfo MemTotal: 16485308 kB MemFree: 4548888 kB net.netfilter.nf_conntrack_count = 24535304 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 23 ноября, 2012 · Жалоба Можно поанализировать файл /proc/net/ip_conntrack Лучше не надо, особенно при таком количестве состояний - при его чтении таблица блокируется (или раньше блокировалась) и трафик перестает ходить. conntrack-tools используйте. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Soltik Опубликовано 23 ноября, 2012 · Жалоба 24млн соединений??? нее, что-то там не так. Пусть будет 10тыс юзеров, получается по 2400 соединений на каждого, это анриал какой-то. Хотя сомневаюсь, что одна линуксовая машина столько народу тянет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 24 ноября, 2012 (изменено) · Жалоба 24 млн. это же какой должен быть трафик через машину? Точно какой-то анрил. Надо смотреть что не так с трафиком. Явно соединения висят мертвым грузом. У меня при входящем 180 Мбайт/с и исходящем около 80 Мбайт/с получается так: MemTotal: 4005256 kB MemFree: 2897692 kB conntrack_count = 381287 Нагрузка на Intel Xeon X3470 2.93GHz около 25-30% в этот момент времени. Изменено 24 ноября, 2012 пользователем replicant Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
flow Опубликовано 28 ноября, 2012 (изменено) · Жалоба Доброго времени суток. Может у кого появятся идеи по поводу подземного стука. Есть две одинаковых машинки 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 Куда в итоге смотреть уже непонятно ) Изменено 28 ноября, 2012 пользователем flow Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 28 ноября, 2012 · Жалоба Покажите ethtool -k eth1 и ethtool -g eth1 на проблемном сервере. и ещё sysctl -a | grep nf_conntrack | grep timeout тоже посмотреть интересно Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
flow Опубликовано 28 ноября, 2012 · Жалоба Покажите 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 28 ноября, 2012 · Жалоба А что говорит ethtool -a eth1? и какой размер netdev_max_backlog установлен? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 28 ноября, 2012 (изменено) · Жалоба Скорее всего поллинг не поспевает. Навскидку - сразу: net.core.dev_weight = 16 net.core.netdev_budget = 256 net.core.netdev_max_backlog = 16000 net.core.netdev_tstamp_prequeue = 0 После применения последить за ситуацией - в какую сторону изменится, и изменится ли. А еще стоит на второй машинке уменьшить размер хэш-таблицы также до 1048576 - вполне возможно, что уже не влезает в кэши. Изменено 28 ноября, 2012 пользователем Alex/AT Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
flow Опубликовано 28 ноября, 2012 · Жалоба А что говорит 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
flow Опубликовано 28 ноября, 2012 (изменено) · Жалоба Скорее всего поллинг не поспевает. Навскидку - сразу: 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, это уже я ковырялся пытаясь понять, что происходит. Изменено 28 ноября, 2012 пользователем flow Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
d10r Опубликовано 29 ноября, 2012 · Жалоба replicant,Soltik, прошу прощения что не указал сразу, это тестовая машинка с малой долей реального трафика, подавляющее количество записей в таблице трассировщика генерируется с помощью hping. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 29 ноября, 2012 (изменено) · Жалоба Про net.core.netdev_tstamp_prequeue упоминания нет вообще. А ядрышко какое у Вас? Вообще интересны uname -a и cat /proc/interrupts Изменено 29 ноября, 2012 пользователем Alex/AT Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
flow Опубликовано 29 ноября, 2012 · Жалоба Про 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 29 ноября, 2012 (изменено) · Жалоба Вероятна проблема именно с передачей данных от карты в память, поскольку изменение параметров поллинга не помогло... Потому что вообще rx_missed_errors означает, что забивается FIFO на карте - не успевает передать данные по шине / не опрашивают карту. А слот PCI-E "честный" x16, или обрезок типа x4/x8 / разделяемый со вторым слотом, где видеоадаптер? Память одно- двух- или трех- канальная? Вообще конечно еще информация по железу нужна - может быть и проблема с платформой. Изменено 29 ноября, 2012 пользователем Alex/AT Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
flow Опубликовано 29 ноября, 2012 (изменено) · Жалоба Вероятна проблема именно с передачей данных от карты в память, поскольку изменение параметров поллинга не помогло... Потому что вообще rx_missed_errors означает, что забивается FIFO на карте - не успевает передать данные по шине / не опрашивают карту. А слот PCI-E "честный" x16, или обрезок типа x4/x8 / разделяемый со вторым слотом, где видеоадаптер? Память одно- двух- или трех- канальная? Вообще конечно еще информация по железу нужна - может быть и проблема с платформой. Там стоит Asus P6T, слот там судя по виду честный, память трехканальная, 3x1g работающие на 1066. Собственно первая машинка, где проблем нет, абсолютно идентична по железу и по трафику, отличается только количество трансляций, ну и профиль трафика. Мысль от том, что при наличии rx_missed_errors, нет buffers loss, в принципе достаточно явно указывает на проблемы с шиной, вот только непонятно на какие - по имеющимся на руках данным ресурса хватает ). Изменено 29 ноября, 2012 пользователем flow Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...