--threads N support on current code
Opened this issue · 11 comments
Предлагаю для существующего кода, когда есть переменная "DEFAULT_QUEUE_NUM 537" которая подразумевает стартовый номер очереди для iptables следующие "многопоточные правила для IPTABLES/IP6TABLES, например для 4-х потоков:
*) -w 2 - опция ожидания в 2 сек, если iptables заняты (что бы правило не пропало при неудачной попытке его установки, но это только на серверах-роутерах, где "ооочень много правил iptables/ip6tables". При старте моего сервера, например, 1 секунды иногда бывает мало и правило может не примениться ;-( ).
Правила для ipv4 iptables:
iptables -w 2 -t mangle -A YOUTUBEUNBLOCK -p tcp --dport 443 -m connbytes --connbytes-dir original --connbytes-mode packets --connbytes 0:19 -m statistic --mode nth --every 4 --packet 0 -j NFQUEUE --queue-num 540 --queue-bypass
iptables -w 2 -t mangle -A YOUTUBEUNBLOCK -p udp --dport 443 -m connbytes --connbytes-dir original --connbytes-mode packets --connbytes 0:19 -m statistic --mode nth --every 4 --packet 0 -j NFQUEUE --queue-num 540 --queue-bypass
iptables -w 2 -t mangle -A YOUTUBEUNBLOCK -p tcp --dport 443 -m connbytes --connbytes-dir original --connbytes-mode packets --connbytes 0:19 -m statistic --mode nth --every 3 --packet 0 -j NFQUEUE --queue-num 539 --queue-bypass
iptables -w 2 -t mangle -A YOUTUBEUNBLOCK -p udp --dport 443 -m connbytes --connbytes-dir original --connbytes-mode packets --connbytes 0:19 -m statistic --mode nth --every 3 --packet 0 -j NFQUEUE --queue-num 539 --queue-bypass
iptables -w 2 -t mangle -A YOUTUBEUNBLOCK -p tcp --dport 443 -m connbytes --connbytes-dir original --connbytes-mode packets --connbytes 0:19 -m statistic --mode nth --every 2 --packet 0 -j NFQUEUE --queue-num 538 --queue-bypass
iptables -w 2 -t mangle -A YOUTUBEUNBLOCK -p udp --dport 443 -m connbytes --connbytes-dir original --connbytes-mode packets --connbytes 0:19 -m statistic --mode nth --every 2 --packet 0 -j NFQUEUE --queue-num 538 --queue-bypass
iptables -w 2 -t mangle -A YOUTUBEUNBLOCK -p tcp --dport 443 -m connbytes --connbytes-dir original --connbytes-mode packets --connbytes 0:19 -m statistic --mode nth --every 1 --packet 0 -j NFQUEUE --queue-num 537 --queue-bypass
iptables -w 2 -t mangle -A YOUTUBEUNBLOCK -p udp --dport 443 -m connbytes --connbytes-dir original --connbytes-mode packets --connbytes 0:19 -m statistic --mode nth --every 1 --packet 0 -j NFQUEUE --queue-num 537 --queue-bypass
правила для ipv6 ipv6tables
ip6tables -w 2 -t mangle -A YOUTUBEUNBLOCK -p tcp --dport 443 -m connbytes --connbytes-dir original --connbytes-mode packets --connbytes 0:19 -m statistic --mode nth --every 4 --packet 0 -j NFQUEUE --queue-num 540 --queue-bypass
ip6tables -w 2 -t mangle -A YOUTUBEUNBLOCK -p udp --dport 443 -m connbytes --connbytes-dir original --connbytes-mode packets --connbytes 0:19 -m statistic --mode nth --every 4 --packet 0 -j NFQUEUE --queue-num 540 --queue-bypass
ip6tables -w 2 -t mangle -A YOUTUBEUNBLOCK -p tcp --dport 443 -m connbytes --connbytes-dir original --connbytes-mode packets --connbytes 0:19 -m statistic --mode nth --every 3 --packet 0 -j NFQUEUE --queue-num 539 --queue-bypass
ip6tables -w 2 -t mangle -A YOUTUBEUNBLOCK -p udp --dport 443 -m connbytes --connbytes-dir original --connbytes-mode packets --connbytes 0:19 -m statistic --mode nth --every 3 --packet 0 -j NFQUEUE --queue-num 539 --queue-bypass
ip6tables -w 2 -t mangle -A YOUTUBEUNBLOCK -p tcp --dport 443 -m connbytes --connbytes-dir original --connbytes-mode packets --connbytes 0:19 -m statistic --mode nth --every 2 --packet 0 -j NFQUEUE --queue-num 538 --queue-bypass
ip6tables -w 2 -t mangle -A YOUTUBEUNBLOCK -p udp --dport 443 -m connbytes --connbytes-dir original --connbytes-mode packets --connbytes 0:19 -m statistic --mode nth --every 2 --packet 0 -j NFQUEUE --queue-num 538 --queue-bypass
ip6tables -w 2 -t mangle -A YOUTUBEUNBLOCK -p tcp --dport 443 -m connbytes --connbytes-dir original --connbytes-mode packets --connbytes 0:19 -m statistic --mode nth --every 1 --packet 0 -j NFQUEUE --queue-num 537 --queue-bypass
ip6tables -w 2 -t mangle -A YOUTUBEUNBLOCK -p udp --dport 443 -m connbytes --connbytes-dir original --connbytes-mode packets --connbytes 0:19 -m statistic --mode nth --every 1 --packet 0 -j NFQUEUE --queue-num 537 --queue-bypass
....
Тогда запуск демона выглядит так:
/usr/local/bin/youtubeUnblock --queue-num=537 --threads=4
...
NFTABLES не использую, но подозреваю, что синтаксис аналогичен.
Кому надо более 4-х процессов - догадаются "по аналогии" как использовать.
С такой дополнительной фильтрацией по очереди пакетов у меня на серваках загрузка стала "примерно распределенной" и ни один из 8 процов не стал упираться в 90-100%. А главное - нормально начало работать в 4К - без икоты в часы пик.
Просто замените эту кучу --queue-num 537..540 на --queue-balance 537:540
Просто замените эту кучу --queue-num 537..540 на --queue-balance 537:540
Подскажите, а в параметрах сервиса youtubeUnblock.servics в поле ExecStartPre=iptables -t mangle -A OUTPUT и Execstop тоже надо указать queue-balance как в iptables правилах или здесь оставляется queue-num 537?
Если вы не провайдер с десятками гиг трафика вам не нужен тредс. А так заменяется queue-num на queue-balance
Если вы не провайдер с десятками гиг трафика вам не нужен тредс. А так заменяется queue-num на queue-balance
Ну не десятками гбит/с, но пару сотен мбит/с есть, только если в рамках пару клиентов сервис все запускает быстро именно по загрузке видео, то стоит на этот сервер пульнуть более 100 клиентов только к подсетям ютюб на порт 443 тсп/юдп, то из 10 видео от силы грузится 1/2 видео сразу, остальные вообще в аут уходят и не грузятся, но при этом сама стр. ютюба, превью нормально грузит, ключи ставил и дефолт и то, что рекомендовали из #148 По логам сервиса неполадок не вижу. Пробовал разное количество тредов в связке с queue-balance, но эффект тот же самый, по top -sh система при от 6 до 16 тредах не особо грузится, так как сам сервер не слабый по железке и может переварить 10гбит/с. И тут вопрос возможно сам сервис не успевает обрабатывать много запросов, но когда клиентов пару шт, то в этих рамках нормально работает и шустро либо где то надо тюнить ОС(debian 11), хотя в sysctl и ethtool подкручены параметры под высокие нагрузки обработки пакетов.
А тут разве были люди, которые с десятками гбит/с пробовали и нормально работало?
Если у вас правило с connbytes, всё должно работать. Если без - может быть общая просадка по скорости из-за частых переключений контекста ядро-юзерспейс. У людей с десятками гигабит нормально работает. Проверьте ipv6/quic на клиентах
Если у вас правило с connbytes, всё должно работать. Если без - может быть общая просадка по скорости из-за частых переключений контекста ядро-юзерспейс. У людей с десятками гигабит нормально работает. Проверьте ipv6/quic на клиентах
В правилах iptables используется connbytes как у Вас указано в ридми. Подскажите, а играет ли роль, что на сетевой карте через ethtool в параметрах выкл tx/rx off, tso,lro,gso off и txqueuelen выше стандартных 1000? А лимит в 16 тредах это по умолчанию, но как понимаю его можно ставить и выше 16?
Если у вас правило с connbytes, всё должно работать. Если без - может быть общая просадка по скорости из-за частых переключений контекста ядро-юзерспейс. У людей с десятками гигабит нормально работает. Проверьте ipv6/quic на клиентах
В правилах iptables используется connbytes как у Вас указано в ридми. Подскажите, а играет ли роль, что на сетевой карте через ethtool в параметрах выкл tx/rx off, tso,lro,gso off и txqueuelen выше стандартных 1000? А лимит в 16 тредах это по умолчанию, но как понимаю его можно ставить и выше 16?
У меня стоит txqueuelen 50000. Причем я тюнил все сотальные пареметры ядра в части работы сети тоже. В частности задирал до максимума - # allow TCP with buffers up to 2GB (Max allowed in Linux is 2GB-1) net.core.rmem_max=2147483647
net.core.wmem_max=2147483647. Иначе сетевуха 2х10G нормально не работает. Но у меня программый роутер. Я могу себе позволить выделять столько памыти для сетевых нужд. И хардварные rx и tx тоже приводил к маскимально вожможным для сетевухи через ethtool.
Если у вас правило с connbytes, всё должно работать. Если без - может быть общая просадка по скорости из-за частых переключений контекста ядро-юзерспейс. У людей с десятками гигабит нормально работает. Проверьте ipv6/quic на клиентах
В правилах iptables используется connbytes как у Вас указано в ридми. Подскажите, а играет ли роль, что на сетевой карте через ethtool в параметрах выкл tx/rx off, tso,lro,gso off и txqueuelen выше стандартных 1000? А лимит в 16 тредах это по умолчанию, но как понимаю его можно ставить и выше 16?
У меня стоит txqueuelen 50000. Причем я тюнил все сотальные пареметры ядра в части работы сети тоже. В частности задирал до максимума - # allow TCP with buffers up to 2GB (Max allowed in Linux is 2GB-1) net.core.rmem_max=2147483647 net.core.wmem_max=2147483647. Иначе сетевуха 2х10G нормально не работает. Но у меня программый роутер. Я могу себе позволить выделять столько памыти для сетевых нужд. И хардварные rx и tx тоже приводил к маскимально вожможным для сетевухи через ethtool.
Понятно, а сколько у вас проходит трафика через этот роутер и какие настройки thread и ключи используете в сервисе этом? Я вчера повысил треды и баланс до 16 шт, curl запрос стал намного лучше показывать, но есть все равно видео которые не грузятся, но количество % видео которые теперь прогружает стало больше, quic/ipv6 выкл у клиентов. Я посмотрел код и ридми как понимаю можно снять лимит на тренды в config.h #define MAX_THREADS 16 поменять на большее и пересобрать сервис. Только вопрос как это повлияет на саму общую работу сервиса.
Rx/tx тоже у меня тоже выставлены на макс. Txqueuelen 20000
Настройки стоят такие, как в 1 сообщении. Я не смог по другому многпоточность запустить - в коде --queue-num=537 если не указывать отдельно при запуске - захардкорено (default). Трафик не считал, но гигов 20-30 проходит по этим правилам. Процы везде разные, но обычно стоят старые Intel(R) Xeon(R) CPU E3-1270 v3 @ 3.50GHz.
Настройки стоят такие, как в 1 сообщении. Я не смог по другому многпоточность запустить - в коде --queue-num=537 если не указывать отдельно при запуске - захардкорено (default). Трафик не считал, но гигов 20-30 проходит по этим правилам. Процы везде разные, но обычно стоят старые Intel(R) Xeon(R) CPU E3-1270 v3 @ 3.50GHz.
20-30 гигов это все ютюб ? Если да, то у клиентов без проблем все запускается на лету?
Да. Вроде все работает. Но на 4К есть только несколько странных людей.