OKyHb

Кто может подсказать, softirq: Let ksoftirqd do its job из kernel 4.9 - есть ли от него польза софт роутеру?

А как обычно делается: 1. раскрашивать по DSCP и дальше доверять этой раскраске (смотреть только на значение DSCP) 2. раскрашивать DSCP, на порту коммутатора мапить DSCP в 802.1p CoS vlan-тега, и дальше на транзитных коммутаторах проверять только этот L2 приоритет? То есть, что выбрать - trust-CoS или trust-DSCP?

Забирать плейлисты по http - можно, работает. Но из-за нашей специфики возникли и другие сложности. Наверно, эти вопросы стоит задавать разработчикам, но мало ли... 1. В описании dpdk-ans говорится следующее: "The listen sockets of APP processes are created on each lcore averagely. For example: ans(with -c 0x3) run on two lcore, shall run two nginx(only run master ), one nginx listens on lcore0, another nginx listens on lcore1.". То есть, если я хочу задействовать 4 CPU, то надо запускать 4 отдельных независимых процесса nginx? (c reuseport и одинаковым конфигом, но разными pid/log файлами). При этом одинаковый proxy_cache_path использовать чревато? 2. С "master_process off" nginx не чистит proxy_cache. Файлы складывает, но ничего не удаляет. Чистить его по крону - как-то жёстко. Но других вариантов ж нет? И самое непонятное - почему-то при просмотре через VLC мой тестовый поток заикался. Параллельно запущенный wireshark в такие моменты показывал заметное к-во потерь/ретрансмитов при получении чанка. Вроде ж должен быть буффер в VLC, пофиг на потери - но тем не менее, реально заметно. И вот не знаю, это из-за proxy_pass или где-то в dpdk буферы настраивать?

Тест на Go - та же картина. Ну и, похоже, unix сокеты дейсвительно не поддерживаются. Хоть и не смертельно, но огорчает.

Сорри за портянки текста, но чтобы ничего не упустить... Мой конфиг: - создание тестового сокета: - конфиг nginx - консоль c запущенным nginx Вроде как nginx к тестовому сокету обращается: [~]: /usr/local/bin/node /var/node/unix.js METHOD: GET URL: /test HEADERS: { "host": "socket_live", "connection": "close", "user-agent": "curl/7.49.1", "accept": "*/*" } Но на запрос nginx ничего не возвращает, и в консоль пишет: skip linux fd 7 2016/06/10 13:06:38 [info] 10796#0: *2 client prematurely closed connection, so upstream connection is closed too while sending request to upstream, client: 10.10.50.13, server: localhost, request: "GET /test HTTP/1.1", upstream: "http://unix:/run/test.socket:/test/1.html", host: "10.10.90.109" Собственно, это сообщение ("skip linux fd 7") пишется для любых запросов, для которых надо обращаться к unix-сокету. P.S. crossdomain.xml, status.txt, *.ts отдаются.

По dpdk-nginx - действительно, оказалось не всё так легко. Хоть инструкция чертовски простая, но тем не менее... И так, пробую простейший вариант с одной 40G сетевой картой/одним CPU/одним ip адресом и одним nginx процессом. dpdk - скомпилил. Забиндил одну i40e сетевую карту на драйвер igb_uio, включил huge_pages на 2GB dpdk-ans - скомпилил, запустил [./build/ans -c 0x1 -n 1 -- -p 0x1 --config=(0,0,0)]. Во второй консоли с помощью anscli поменял ip адрес с дефолтного 2.2.2.2 на наш. ip адрес пингуется. dpdk-nginx - взял их конфиг (с "worker_processes 1" и "master_process off"), добавил location для m3u8 и ts файлов. Просто файлы из html - раздаёт. Возникшие проблемы: если nginx запускать без конфига, просто "./objs/nginx -V" - получаю segfault (это из-за дефолтных опций master_process/..?) запускаю с конфигом - работает, статические файлы с диска раздаёт, но тоже с особенностями: если включить sendfile, то ничерта не работает, в консоли на мои curl-запросы пишет "skip linux fd 5" не заработал proxy_pass на unix сокет (m3u8 файлы). Для http:// proxy_pass работает, а вот с сокетом - почему-то нет. В консоли - тот же "skip linux fd 5". Может наш backend (nodejs) как-то править надо, чтобы через socket'ы заработало? Это я что-то недопонял и неправильно сделал, или есть какие-то особенности?

Переписать на go - заманчиво, но некому и некогда. Проще сервер купить :) Блин, а у keepalive_requests дефолтное значение 100 - реально надо было поднимать. Провтык. 10 секунд на чанки - нам почему-то так показалось оптимальным. Ну и чтобы каналы у клиентов включались быстрее. Да и когда на популярной передаче начинается реклама - чтобы поменьше трафика вытягивали при переключении каналов. /mnt/live - да, tmpfs. proxy_temp - сегодня как раз обратил внимание, когда систему перенёс на флешку. По остальным параметрам - буду проверять, спасибо :)

Упс, про 12 пакетов на m3u8 - это я погорячился. Такая фигня только при присмотре через VLC. Если смотреть через браузер, то keepalive работает, все запросы в пределах одного tcp connection. Но за консультации реально спасибо, теперь больше понимания :)

Второй сервер - можно. Но мне все утверждают, что nginx легко выдаёт 20Gbps статики на десктопном Core i7. А тут серверный Xeon - и CPU в полке при 25Gbps. То есть, что-то неправильно настроил.

Да, сервер для экспериментов есть, это не проблема. Из-за того, что закончились идеи, уже даже думали взять на тест новый сервер (двухпроцессорный с E5-2620 v4). Но не хочется заморачиваться с NUMA. По соотношению пакетов - чёрт его знает, может что-то и не так. Но тут есть дополнительные факторы: 1. для части клиентов трафик отдаётся по https 2. кроме видео чанка каждые 10 секунд запрашивается мелкий плейлист (*.m3u8 файл). Смотрел wireshark'ом со своего компьютера, во время проигрывания видео получение одного m3u8 файла по http - это 6 пакетов от клиента + 6 пакетов от сервера. На всякий случай сделал ещё один график: И вот используемые настройки: - sysctl - nginx Буду признателен за конструктивную критику :)

Да, памяти на сервере - 64GB, почти вся свободна (при "vm.swappiness=1" использование swap стабильно нулевое). dpdk-nginx - фигасе, не знал, что такое есть. Будем пробовать, реально интересно. Спасибо :)

По Hyper-threading - попробуем. sendfile, tmpfs - есть. TSO, GSO - используем. Единственное, что выключено - это RPS/RFS и ntuple filters. Результаты "perf record -a -g sleep 10" и "perf report" - под спойлером. "Server thread" - это авторизация/ограничение доступа на nodejs (вызывается через proxy_pass в nginx). Привёл только первый экран. Можно по нему делать какие-то выводы?

А какой рекомендуемый подход для трафика, который мы отдаем в интернет? Стоит ли заморачиваться и обнулять DSCP для трафика ОТ наших клиентов?

hls - так вроде удобнее абонентам, меньше проблем с android девайсами. perf top - затупил, не собрал :( Прийдётся уже вечерней нагрузки ждать.

Приветствую. Интересует опыт и мнение коллег по настройке линуксового сервера с nginx. Отказываемся от мультикаста, переводим абонентов на OTT. Для этого используется nginx, который раздаёт hls-видео чанки по 10 секунд/2MB. Железо сервера: один процессор Xeon E3-1270 (с hyper-threading - 8 ядер) сетевая - intel X710 (4x10G) По сетевой: на каждой сетевой по 8 очередей - прибиты set_irq_affinity на отдельные cpu rx/tx ring (-G) - по 4096 rx-usecs/tx-usecs (-C) - 1000, adaptive off ntuple, flow-director - отключены Запущено 8 воркеров nginx, крутили sysctl... Но всё равно при 1Mpps входящего + 2Mpps исходящего получается загрузка CPU в ~100% (~25Gbps трафика к абонентам). Собственно, вопрос - нормально ли это? Насколько больше можно выжать из такого железа?