[Ivan_83]

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

[s.lobanov]

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

 

на той страничке по тюнингу, на которую вы дали ссылку есть расчёт по соединениям. для x86(32) в 512M RAM влезет всего 32К трансляций, ну т.е. тут всё равно никак в кеш не вписаться

 

я бы начал с того, что покрутил nat timeout'ы, по умолчанию они какие-то запредельные(какой-то вообще 3 дня)

[DVM-Avgoor]

На сетке с 2к активными пользователями и 750мбит/с in+out я только ip_conntrack_max увеличивал, хэши не трогал. Все работало как часы. Может не там ищете?

[NiTr0]

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

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

 

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

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

 

на той страничке по тюнингу, на которую вы дали ссылку есть расчёт по соединениям. для x86(32) в 512M RAM влезет всего 32К трансляций, ну т.е. тут всё равно никак в кеш не вписаться

Нет там расчета по соединениям. Там есть формула вычисления дефолтного значения ядром. А это - разные вещи.

[DVM-Avgoor]

Чтобы получать от кэша профит надо во-первых убрать все левое с процессора, что вымывает кэш. Во-вторых использовать кэш-ориентированные массивы, подобные judy array.

В реальном NAT-сервере этого добиться очень сложно. Так что вы рано о кэше думаете - надо сначала топором поработать, а потом уже надфилем.

[DVM-Avgoor]

Зачем вам столько правил ната? Там одного бы хватило. Зачем -m state в FORWARD? В целом я не вижу никакого смысла в ваших правилах вообще. Заведите на пробу простой набор правил, без всякой ерунды, с однострочным натом. И пробуйте. Если проблема лежит в iptables то это даст эффект, если же нет (может у вас там irq-штормы летают по компу), будете искать дальше. Но путь "потюнить жиклеры карбюратора часовой отверточкой" когда у вас в двигателе пары поршней не хватает, я считаю не верным.

[NiTr0]

Чтобы получать от кэша профит надо во-первых убрать все левое с процессора, что вымывает кэш. Во-вторых использовать кэш-ориентированные массивы, подобные judy array.

В реальном NAT-сервере этого добиться очень сложно. Так что вы рано о кэше думаете - надо сначала топором поработать, а потом уже надфилем.

Ну а смысл лепить хеш на 1М записей если столько трансляций-то в жизни на тазике не будет? Для 2к абонов - в среднем 256к трансляций случается. Итого - при хеше в 64к записей имеем аж 4 операции сравнения на каждую трансляцию. Зачем раздувать служебные структуры? :)

[Wheely]

1) hashsize conntrack'a можно сменить двумя путями - на лету и постоянно.

на лету: echo $hashsize > /sys/module/nf_conntrack/parameters/hashsize

постоянно: создать любой файл с расширением .conf в папке /etc/modprobe.d/ с содержимым options nf_conntrack hashsize=$hashsize, после чего перезагрузить модуль или ребутнуть сервер.

2) conntrack_buckets по умолчанию равен conntrack_max. так что особой нужды крутить первый параметр нет, гораздо юзабельнее покрутить второй и первый автоматически станет ему равным.

 

ну а теперь несколько рекомендаций собственно по увеличению производительности nat-сервера.

- NAT = conntrack, conntrack = зло. но раз уже от этого зла никуда не деться, то нужно его минимизировать:

в -j NOTRACK *все*, что не будет натиться.

- conntrack_max = conntrack_hashsize = 983040, как для начала.

- net.netfilter.nf_conntrack_tcp_loose = 0

- очередей карты выставьте сколько у вас ядер процессора, например 4 ядра - 4 очереди и должно быть, на примере драйверов от intel: RSS=4,4

- irq развесьте вручную по ядрам одного процессора, не двух а одного, поскольку карту прибивают к единому процессору. если система мультипроцессорная, желательно вывести для NIC отдельный проц, а на второй закинуть остальные задачи (taskset, default_affinity)

- tx/rx queue выставьте на максимум, txqueuelen = tx queue

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

[DVM-Avgoor]

Ну а смысл лепить хеш на 1М записей если столько трансляций-то в жизни на тазике не будет? Для 2к абонов - в среднем 256к трансляций случается. Итого - при хеше в 64к записей имеем аж 4 операции сравнения на каждую трансляцию. Зачем раздувать служебные структуры? :)

 

 

Размер кэш линии L2 у x86 - 128байт, L1 - 64, так что большой разницы 64к у вас записей или 256к нет, оно все равно не помещается в кэш целиком, только фрагментированно. А там очень очень и очень сильно зависит от самого алгоритма хэширования. Допускает ли он блокировки уровней или блокируется только целиком (а это наиболее часто встречающаяся реализация, например тот же radix tree в простом виде). Но и это не важно, потому что каждое прерывание, каждое переключение контекста вымывает кэш почище чем неоптимальный хэш-алгоритм. А любая из запущенных задач удачно брошенная планировщиком на ядро, занимавшееся трафиком, делает это еще красочней. Но и это тоже не важно. Потому что даже правильный механизм и вычистка ядра цпу от "левых" занятий пока еще на практике не дают ощутимо превосходного результата, хотя есть определенное улучшение при очень высоких нагрузках, предельных нагрузках, доказанное экспериментальным путем переноса всех задач на другие ядра, но это совсем не наш случай: там речь идет о нагрузках в Mpps, а не kpps.

 

Ну и еще раз, ни разу в линуксе не тюнил хэш ната (у меня был сервер 1.1 Mpps in+out, 8 сетевух с кучей очередей), только увеличивал таблицы коннтрака. Как бы я не не любил линукс, но все же там все с НАТом очень даже хорошо. Поэтому я считаю, что ТС просто не совсем на верном пути. Ему надо а) профилить и глядеть что в моменты "залипания" занимает процессор, б) прибраться в iptables потому что там фигня а не правила. Увы в мире есть еще куча железа со странностями. Взять те же intel-материнки у которых не редкость штормящий usb-контроллер. Или supermicro с залипающим sata(ahci)-контроллером, который раз в 2-3 минуты просто перестает работать на 5 секунд и ОС рапортует о таймаутах на всех дисках...

[NiTr0]

Размер кэш линии L2 у x86 - 128байт, L1 - 64, так что большой разницы 64к у вас записей или 256к нет, оно все равно не помещается в кэш целиком, только фрагментированно.

Да какбы если активны все соединения (идет частое обращение к хешу) - как минимум из л3 он не вымоется.

 

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

Кто сказал? L3 кэш на современных камнях большой, была бы воля вендоров - линь мог бы работать целиком в кеше без рамы на каких-то зионах с 16=24 метрами кеша...

 

Ну и еще раз, ни разу в линуксе не тюнил хэш ната (у меня был сервер 1.1 Mpps in+out, 8 сетевух с кучей очередей), только увеличивал таблицы коннтрака.

Но это еще не повод ставить ненормальный размер хэша ;)

 

Ему надо а) профилить и глядеть что в моменты "залипания" занимает процессор, б) прибраться в iptables потому что там фигня а не правила

Да скорее всего залипает из-за переполнения коннтрака... Тогда интересные вещи могут случаться.

[s.lobanov]

NiTr0

почему вы считаете только указатели? сами данные xlat(записи таблицы замен) типа не нужны и не вымывают кеш?

[DVM-Avgoor]

Да какбы если активны все соединения (идет частое обращение к хешу) - как минимум из л3 он не вымоется.

 

Кто сказал? L3 кэш на современных камнях большой, была бы воля вендоров - линь мог бы работать целиком в кеше без рамы на каких-то зионах с 16=24 метрами кеша...

 

 

L3 != L2 != L1. L3 кэш медленней двух младших, и чуть быстрее обычной памяти, он скорее просто буфер между памятью и нормальными кэшами. Это дает небольшие преимущества, но часто не заметные, ибо он shared по природе. А значит страдает теми же проблемами доступа в SMP (non-NUMA) системах что и обычная память.

 

Но это еще не повод ставить ненормальный размер хэша ;)

 

Ну дак и я говорю не надо его трогать, зачем?

 

Да скорее всего залипает из-за переполнения коннтрака... Тогда интересные вещи могут случаться.

 

 

В мои времена conntrack активно гадил в системный лог-буффер, dmesg. Но ТС сказал что там чисто.

 

Прочитал шапку еще раз, ТС сказал что перезагруз правил спасает. Делаю ставку на его -m state натыканый в обилии там где нафиг не надо.

[alibek]

Для диагностики:

 

> ethtool -S eth0 (и другие интерфейсы) - есть ли дропы или нет

Дропов нет. Есть некоторое число ошибок, незначительное по сравнению с общим трафиком (на три порядка меньше)

 

> tc -s -d qdisc - тоже дропы

Аналогично.

 

> mpstat -P ALL - упирается ли какое-то из ядер в потолок?

Понаблюдал минут 5, выше 10% загрузки одного из ядер не видел, в среднем загрузка — проценты и доли процента.

Понаблюдаю еще в момент, когда трафик большой.

 

> Есть ли сетевки на шине PCI?

Нет.

 

> Есть ли hyperthreading? Тогда загрузка в 50% может быть на самом деле 100%. "Ненастоящие" ядра можно _ОСТОРОЖНО_ отключать, через sysfs

Даже 50% нагрузки у меня нет.

 

> Есть ли на тазике шейперы? Если да - отключать offloading. Учитывая что используется ПК - там могут быть сетевки, которые при нагрузке глючат на этой части - лучше отключать в любом случае.

Нет, скорость режется непосредственно на хотспоте.

 

> sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

> net.netfilter.nf_conntrack_count = 389005

> net.netfilter.nf_conntrack_max = 1000000

# sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

net.netfilter.nf_conntrack_count = 307

net.netfilter.nf_conntrack_max = 104857600

 

> grep "Hz" /proc/cpuinfo

> Является ли частота номинальной или "плавает".

# grep "Hz" /proc/cpuinfo
model name      : Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
cpu MHz         : 830.875
model name      : Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
cpu MHz         : 830.875
model name      : Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
cpu MHz         : 830.875
model name      : Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
cpu MHz         : 830.875
model name      : Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
cpu MHz         : 830.875
model name      : Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
cpu MHz         : 830.875
model name      : Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
cpu MHz         : 937.125
model name      : Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
cpu MHz         : 830.875

 

Зачем вам столько правил ната?

Сколько? У меня их четыре, два для tcp/udp и два для echo-request/echo-reply.

Можно конечно и одно оставить, если это сильно на работу влияет.

 

в -j NOTRACK *все*, что не будет натиться.

После этого я не смогу использовать -m state?

Мне не придется в этом случае отказаться от $FW -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT, а вместо него определять зеркальные (относительно OUTPUT) правила?

[DVM-Avgoor]

model name      : Intel® Core™ i7-4770 CPU @ 3.40GHz

cpu MHz         : 830.875

 

Ггг.

https://wiki.archlinux.org/index.php/CPU_frequency_scaling#Scaling_governors

# echo performance | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor >/dev/null

 

Сколько? У меня их четыре, два для tcp/udp и два для echo-request/echo-reply.

Можно конечно и одно оставить, если это сильно на работу влияет.

 

А зачем? -s x.x.x.x/x -j SNAT --to-source и достаточно.

[alibek]

Ггг.

Да уж, забыл я про такое.

 

А зачем?

Ну чтобы не натить лишнее. Вдруг найдутся пионеры, которые попытаются в ICMP туннель сделать.

Кроме того, вдруг какой-нибудь экзотический протокол найдется — среди клиентов есть устройства Apple, у них бывают всякие странности, типа ATP.

[Antares]

hyperthreading тоже отрубайте, это зло

[alibek]

> mpstat -P ALL - упирается ли какое-то из ядер в потолок?

Понаблюдал минут 5, выше 10% загрузки одного из ядер не видел, в среднем загрузка — проценты и доли процента.

Понаблюдаю еще в момент, когда трафик большой.

Иногда загрузка ядра доходит до 30%.

Выше пока не видел.

[DVM-Avgoor]

Частоту ЦПУ то восстановили?

 

http://h10025.www1.hp.com/ewfrf/wc/document?cc=ru&lc=ru&dlc=ru&docname=c03132537

и вот это на всякий пожарный тоже

[alibek]

Да, частоту восстановил.

Возможно дело было в этом, т.к. подвисаний пока не было.

Нагрузка на ядре обычно несколько процентов, выше 10% бывает только изредка, выше 30% пока не видел.

[DVM-Avgoor]

Да, попадалась такая ерунда. Отключение intel_pstate / intel_idle, установка performance governor это для линукс-сервера всегда must have :D

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

[NiTr0]

почему вы считаете только указатели? сами данные xlat(записи таблицы замен) типа не нужны и не вымывают кеш?

Может потому, что вымывание хеш-аблицы наиболее ощутимо?

 

L3 != L2 != L1. L3 кэш медленней двух младших, и чуть быстрее обычной памяти

Ну латентность его существенно ниже латентности памяти...

 

Ну дак и я говорю не надо его трогать, зачем?

Увеличить в пределах разумного можно. Несколько снизит нагрузку. Но только в пределах разумного.

 

Вдруг найдутся пионеры, которые попытаются в ICMP туннель сделать

А чем вам туннель в ICMP не нравится? Вернее, чем он хуже туннеля в tcp/udp?

[alibek]

А чем вам туннель в ICMP не нравится?

Приоритетами и дефолтным поведением на разных железках.

Проще его запретить, чем учитывать нюансы.

[vitalyb]

Проще его запретить, чем учитывать нюансы.

Как раз проще его оставить, чем учитывать нюансы.

 

http://en.wikipedia.org/wiki/Path_MTU_Discovery

[Wheely]

После этого я не смогу использовать -m state?

Мне не придется в этом случае отказаться от $FW -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT, а вместо него определять зеркальные (относительно OUTPUT) правила?

 

Да, после этого у вас будет недоступен стейт. Я сделал лично у себя вот как:

-A PREROUTING -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j CT --notrack

-A PREROUTING -p udp -m udp -j CT --notrack

-A PREROUTING -p icmp -m icmp --icmp-type any -j CT --notrack

И затем:

-A INPUT -p tcp -m state --state RELATED,ESTABLISHED -j ACCEPT

[alibek]

Возможно дело было в этом, т.к. подвисаний пока не было.

Все-таки что-то другое, подвисает по прежнему.

Буду смотреть дальше.