Ivan_83 Опубликовано 21 июня, 2014 · Жалоба Проц сам рулит кешем, и даже 1 мегабайт из него будет периодически выкидываться. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 21 июня, 2014 · Жалоба и это только указатели, а ещё есть сами данные, которых куда больше, поэтому кеш всё равно будет вымываться на приличном кол-ве соединений, даже если подгадывать hashsize на той страничке по тюнингу, на которую вы дали ссылку есть расчёт по соединениям. для x86(32) в 512M RAM влезет всего 32К трансляций, ну т.е. тут всё равно никак в кеш не вписаться я бы начал с того, что покрутил nat timeout'ы, по умолчанию они какие-то запредельные(какой-то вообще 3 дня) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 21 июня, 2014 · Жалоба На сетке с 2к активными пользователями и 750мбит/с in+out я только ip_conntrack_max увеличивал, хэши не трогал. Все работало как часы. Может не там ищете? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 22 июня, 2014 · Жалоба Проц сам рулит кешем, и даже 1 мегабайт из него будет периодически выкидываться. Да понятно что сам рулит. Но одно дело когда хеш-таблица и код целиком влазят в кэш, другое - когда хеш-таблица будет вымывать код. и это только указатели, а ещё есть сами данные, которых куда больше, поэтому кеш всё равно будет вымываться на приличном кол-ве соединений, даже если подгадывать hashsize А если не подгадывать - каждый раз надо будет лезть в медленную память.. на той страничке по тюнингу, на которую вы дали ссылку есть расчёт по соединениям. для x86(32) в 512M RAM влезет всего 32К трансляций, ну т.е. тут всё равно никак в кеш не вписаться Нет там расчета по соединениям. Там есть формула вычисления дефолтного значения ядром. А это - разные вещи. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 22 июня, 2014 · Жалоба Чтобы получать от кэша профит надо во-первых убрать все левое с процессора, что вымывает кэш. Во-вторых использовать кэш-ориентированные массивы, подобные judy array. В реальном NAT-сервере этого добиться очень сложно. Так что вы рано о кэше думаете - надо сначала топором поработать, а потом уже надфилем. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 22 июня, 2014 · Жалоба Зачем вам столько правил ната? Там одного бы хватило. Зачем -m state в FORWARD? В целом я не вижу никакого смысла в ваших правилах вообще. Заведите на пробу простой набор правил, без всякой ерунды, с однострочным натом. И пробуйте. Если проблема лежит в iptables то это даст эффект, если же нет (может у вас там irq-штормы летают по компу), будете искать дальше. Но путь "потюнить жиклеры карбюратора часовой отверточкой" когда у вас в двигателе пары поршней не хватает, я считаю не верным. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 22 июня, 2014 · Жалоба Чтобы получать от кэша профит надо во-первых убрать все левое с процессора, что вымывает кэш. Во-вторых использовать кэш-ориентированные массивы, подобные judy array. В реальном NAT-сервере этого добиться очень сложно. Так что вы рано о кэше думаете - надо сначала топором поработать, а потом уже надфилем. Ну а смысл лепить хеш на 1М записей если столько трансляций-то в жизни на тазике не будет? Для 2к абонов - в среднем 256к трансляций случается. Итого - при хеше в 64к записей имеем аж 4 операции сравнения на каждую трансляцию. Зачем раздувать служебные структуры? :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Wheely Опубликовано 22 июня, 2014 · Жалоба 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, все что вам не особо нужно лучше удалить, и оставшуюся часть оптимизировать, если вам это сложно я могу в этом помочь. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 22 июня, 2014 · Жалоба Ну а смысл лепить хеш на 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 секунд и ОС рапортует о таймаутах на всех дисках... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 22 июня, 2014 · Жалоба Размер кэш линии L2 у x86 - 128байт, L1 - 64, так что большой разницы 64к у вас записей или 256к нет, оно все равно не помещается в кэш целиком, только фрагментированно. Да какбы если активны все соединения (идет частое обращение к хешу) - как минимум из л3 он не вымоется. Но и это не важно, потому что каждое прерывание, каждое переключение контекста вымывает кэш почище чем неоптимальный хэш-алгоритм. Кто сказал? L3 кэш на современных камнях большой, была бы воля вендоров - линь мог бы работать целиком в кеше без рамы на каких-то зионах с 16=24 метрами кеша... Ну и еще раз, ни разу в линуксе не тюнил хэш ната (у меня был сервер 1.1 Mpps in+out, 8 сетевух с кучей очередей), только увеличивал таблицы коннтрака. Но это еще не повод ставить ненормальный размер хэша ;) Ему надо а) профилить и глядеть что в моменты "залипания" занимает процессор, б) прибраться в iptables потому что там фигня а не правила Да скорее всего залипает из-за переполнения коннтрака... Тогда интересные вещи могут случаться. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 22 июня, 2014 · Жалоба NiTr0 почему вы считаете только указатели? сами данные xlat(записи таблицы замен) типа не нужны и не вымывают кеш? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 22 июня, 2014 · Жалоба Да какбы если активны все соединения (идет частое обращение к хешу) - как минимум из л3 он не вымоется. Кто сказал? L3 кэш на современных камнях большой, была бы воля вендоров - линь мог бы работать целиком в кеше без рамы на каких-то зионах с 16=24 метрами кеша... L3 != L2 != L1. L3 кэш медленней двух младших, и чуть быстрее обычной памяти, он скорее просто буфер между памятью и нормальными кэшами. Это дает небольшие преимущества, но часто не заметные, ибо он shared по природе. А значит страдает теми же проблемами доступа в SMP (non-NUMA) системах что и обычная память. Но это еще не повод ставить ненормальный размер хэша ;) Ну дак и я говорю не надо его трогать, зачем? Да скорее всего залипает из-за переполнения коннтрака... Тогда интересные вещи могут случаться. В мои времена conntrack активно гадил в системный лог-буффер, dmesg. Но ТС сказал что там чисто. Прочитал шапку еще раз, ТС сказал что перезагруз правил спасает. Делаю ставку на его -m state натыканый в обилии там где нафиг не надо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 23 июня, 2014 · Жалоба Для диагностики: > 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) правила? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 23 июня, 2014 · Жалоба 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 и достаточно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 23 июня, 2014 · Жалоба Ггг. Да уж, забыл я про такое. А зачем? Ну чтобы не натить лишнее. Вдруг найдутся пионеры, которые попытаются в ICMP туннель сделать. Кроме того, вдруг какой-нибудь экзотический протокол найдется — среди клиентов есть устройства Apple, у них бывают всякие странности, типа ATP. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Antares Опубликовано 23 июня, 2014 · Жалоба hyperthreading тоже отрубайте, это зло Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 23 июня, 2014 · Жалоба > mpstat -P ALL - упирается ли какое-то из ядер в потолок? Понаблюдал минут 5, выше 10% загрузки одного из ядер не видел, в среднем загрузка — проценты и доли процента. Понаблюдаю еще в момент, когда трафик большой. Иногда загрузка ядра доходит до 30%. Выше пока не видел. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 23 июня, 2014 · Жалоба Частоту ЦПУ то восстановили? http://h10025.www1.hp.com/ewfrf/wc/document?cc=ru&lc=ru&dlc=ru&docname=c03132537 и вот это на всякий пожарный тоже Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 23 июня, 2014 · Жалоба Да, частоту восстановил. Возможно дело было в этом, т.к. подвисаний пока не было. Нагрузка на ядре обычно несколько процентов, выше 10% бывает только изредка, выше 30% пока не видел. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DVM-Avgoor Опубликовано 23 июня, 2014 · Жалоба Да, попадалась такая ерунда. Отключение intel_pstate / intel_idle, установка performance governor это для линукс-сервера всегда must have :D Только проблема как обычно в том, что Линусу порой на стабильность семантики накласть, поэтому в разных ядрах конфигурируется по-разному. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 23 июня, 2014 · Жалоба почему вы считаете только указатели? сами данные xlat(записи таблицы замен) типа не нужны и не вымывают кеш? Может потому, что вымывание хеш-аблицы наиболее ощутимо? L3 != L2 != L1. L3 кэш медленней двух младших, и чуть быстрее обычной памяти Ну латентность его существенно ниже латентности памяти... Ну дак и я говорю не надо его трогать, зачем? Увеличить в пределах разумного можно. Несколько снизит нагрузку. Но только в пределах разумного. Вдруг найдутся пионеры, которые попытаются в ICMP туннель сделать А чем вам туннель в ICMP не нравится? Вернее, чем он хуже туннеля в tcp/udp? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 23 июня, 2014 · Жалоба А чем вам туннель в ICMP не нравится? Приоритетами и дефолтным поведением на разных железках. Проще его запретить, чем учитывать нюансы. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 23 июня, 2014 · Жалоба Проще его запретить, чем учитывать нюансы. Как раз проще его оставить, чем учитывать нюансы. http://en.wikipedia.org/wiki/Path_MTU_Discovery Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Wheely Опубликовано 23 июня, 2014 · Жалоба После этого я не смогу использовать -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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 23 июня, 2014 · Жалоба Возможно дело было в этом, т.к. подвисаний пока не было. Все-таки что-то другое, подвисает по прежнему. Буду смотреть дальше. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...