Не справляется nginx?

Question

[andrei_pro]

Всем привет.

Сервер cloud: 4 cpu, 8 ram. Стоит nginx как прокси на другие сервера и rabbitmq в контейнерах докера, логи включены.
Трафик ~70k rpm. При > трафике появляются лаги на других серверах - растет php-fpm, запросы не доходят.

Подозрение что nginx нужно больше ресурсов?

user nginx;
worker_processes auto;
pid /var/run/nginx.pid;

load_module modules/ngx_http_vhost_traffic_status_module.so;

events {
    use epoll;
    worker_connections 2048;
    multi_accept on;
}

http {
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    send_timeout 2;
    keepalive_timeout 30;
    client_body_timeout 10;
    reset_timedout_connection on;
    types_hash_max_size 2048;
    # server_tokens off;
    server_names_hash_bucket_size 128;
    # server_name_in_redirect off;

    open_file_cache max=200000 inactive=20s;
    open_file_cache_valid 30s;
    open_file_cache_min_uses 2;
    open_file_cache_errors on;

    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    # https://docs.docker.com/v17.09/engine/userguide/networking/configure-dns/
    # Note: The DNS server is always at 127.0.0.11
    resolver 127.0.0.11 valid=5s;

    ssl_prefer_server_ciphers on;
    ssl_protocols             TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers               HIGH:!aNULL:!MD5;
    ssl_session_cache   shared:SSL:10m;

    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;

    gzip on;
    gzip_disable "msie6";

    # gzip_vary on;
    # gzip_proxied any;
    # gzip_comp_level 6;
    # gzip_buffers 16 8k;
    # gzip_http_version 1.1;
    # gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

    vhost_traffic_status_zone;
    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

Comments

[Алексей Блышко]

пассаж интересный - лаги на других серверах, а виноват нгинкс. Но нгинку явно тесно - в таких условиях я бы рекомендовал расширяться по достижению 75% нагрузки на цпу в среднем.

При желании можно и тут поколдовать - логи там выключить, гзип отключить, но вангую что 99% нагрузки это https и лучшее что тут можно проверить - кэширование статики на стороне клиента.

[andrei_pro]

Алексей Блышко, статики нету, только апи

[Алексей Блышко]

andrei_pro, возможно в апи есть статика, которую можно эффективно кэшировать. Но это все от лукавого - основной момент нагрузки, это установка соединения. Стабильные накладные расходы клиент-серверного взаимодействия постороенного по схеме запрос-ответ.

[Lynn «Кофеман»]

А конфиг сервера-то где?

Answer 1

[Иван Шумов]

Итак, что мы имеем - туча всякого на одном сервере что уже плохо. Отличное время задуматься о масштабировании. Что можно сделать для старта:

1. взять несколько более дешевых виртуалок
   
2. разнести отдельно nginx, rabbitmq
   
3. подумать о том чтобы избавиться от докера. последний раз я видел чтобы он хорошо работал в больших облаках вроде AWS ECS, но не на отдельных VPS
   
4. настроить горизонтальное масштабирование и dns-round-robin
   

также:

• напомню что число портов ограничено и при большом числе одновременных соединений они могут тупо закончиться
  
• слой с приложением тоже стоит масштабировать
  

Comments

[metajiji]

А чем докер мешает по вашему мнению?

[Иван Шумов]

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

[metajiji]

Иван Шумов, не знаю где вы это взяли, но это не правда. Сетевая латенси, о которой вы говорите берется от неграмотного использования и не понимания принципов работы docker. Да действительно она будет, но только в том случае, если порты будут проброшены (publish), а проброс делается через docker-proxy, который написан на go и под нагрузками даёт просадки по cpu и rps. Выход? Не делать проброс в портов, а использовать сеть хоста! --net host, при создании.

Мощь cgroup и образов не даёт никакого оверхеда в рантайме, зато мега круто повышает скорость и простоту доставки приложения до прода + воспроизводимость в разных окружениях.
Для справки, если без докеры, то systemd из коробки использует cgroup для запускаемых сервисов.

[Иван Шумов]

metajiji, я это не взял, а получил на опыте в больших проектах. С ресурсами да, там не то чтобы много ест, просто немного поджирает, а что до сети то, все-же, надо знать не то как конфигурируется докер, а как работают сети и как работает сама контейнеризация и виртуалитзация в принципе + давайте не забывать про NAT. Увы, для подобных параметров rps/rpm это уже становится видимым

[metajiji]

Иван Шумов, ну вот опять, откуда нат в докере взялся? С какой целью на VPS входящий трафик прогонять через такого монстра как NAT?
Я вам тоже из личного опыта говорю :) ничего он не жрет, считай бесплатный, главное головой пользоваться при принятии решений, что и как будет работать.
Для того, чтобы с входящих соединений убрать все оверхеды решение простое - не использовать ничего перед ними, тоесть использовать сеть хоста. В итоге nginx окажется на интерфейсах хоста, так, как будто он был запущен на хосте! Ни NAT ни docker-proxy больше не помешают и задержек не будет. И зачем тут глубокие познания сети? :)

[Иван Шумов]

metajiji, ну, просто по тому что на самом деле это работает не так) NAT присутствует везде в сетевой адресации, просто в разном виде. Контейнер это тоже на уровне сети изолированная коробочка, какие бы настройки мы там не прикручивали)

[metajiji]

Иван Шумов, итак мы выяснили, что при использовании хвостовой cgroup для сети по сетевой части оверхеда нет, теперь смотрим на изоляцию процессов, сколько килобайт там потратится на новый неймспейс? 1-2? Мне кажется это не та экономия :) кстати, при использовании, например systemd, можно руками так же как и докер настроить capabilities, создать cgroup namespaces, чтобы, например применить отличные от хоста sysctl. И это даже происходит в некоторых сервисах и никто не жалуется на оверхед :))
Что касаемо изоляции это очень хорошо, ведь с докером очень легко доставить весь софт со всеми зависимыми библиотеками! Кроме того повышается безопасность. Взломав вордпресс, зловреды вряд-ли выйдут на хост и узнают ключи от хоста или пароли от соседних проектов или демонов.
И самое главное, что накладные расходы минимальны, так ещё и лимитировать можно потребление ресурсов! :)

Кстати, если нужен shm между контейнерами, то можно использовать общий неймспейс для процессов (ipc), и да, если процесс на хосте, то можно хостовый неймспейс взять, но это уже так себе изоляция :)

Докеры на vps норм штука, при умелом использовании.

[Иван Шумов]

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

[metajiji]

Иван Шумов, тогда в вашем кейсе нужен packer или ostree. Там можно проконтролировать каждый файлик и собрать микромонолит :)))) вроде модный тренд кстати:)

[Иван Шумов]

metajiji, ну вот да, но до этой части изменения архитектуры меня не пускали)

[andrei_pro]

Иван Шумов, metajiji, увеличение cpu до 12 не сильно помогло. Docker на host еще не переводили, если подозрение еще на файловую систему (nodejs expess):

[metajiji]

andrei_pro, iotop посмотрите, видно будет за файловую систему, кто ест диск.

[metajiji]

metajiji, @anderi_pro ещё стоит видимо на хосте запустить strace и посмотреть что же такого делает nginx, что отнимает столько процессорного времени.

Answer 2

[Badbuka]

Судя по LA вам не хватает 2х cpu

Comments

[andrei_pro]

Скажите как вы посчитали?
А так же что за показатели sy/si ?

[Badbuka]

Load average в правом верхнем углу вашей картинки, за 1,5,15 минут соответственно

[Badbuka]

Грубо говоря это число не должно превышать количество ядер в системе. Если хотите углубиться в теорию то загуглите load average

Answer 3

[metajiji]

Выглядит так, как будто nginx использует много cpu.
Конфиг не полный, поэтому предположу, что:
1. в конфигах много regex правил и они не оптимальны.
2. Порты до nginx зачем-то проброшены через docker-proxy(настоятельно рекомендую не делать проброс портов в продакшене вообще никогда!, Docker proxy написан на go и требует очень много CPU! Решение проблемы простое --net host, при создании контейнера с nginx.
3. Настроено gd сжатие через nginx, отсюда и трафик на cpu. Решение либо не генерить их на лету, либо отселять на другой хост.

Полный конфиг nginx можно увидеть командой nginx -T (пишу по памяти, проверьте справку:))

Comments

[metajiji]

Когда уберет проброса портов и если будет много трафика и будете упираться в conntrack, так же рекомендую в iptables в цепочке raw сделать notrack для 80 и 443 ну или на каких у вас работает nginx. Это значительно разгрузит сетевой стек и cpu.

Answer 4

[Алексей Блышко]

да

Comments

[andrei_pro]

Добавить cpu или может что-то в конфиге?

[Алексей Блышко]

andrei_pro, cpu

Answer 5

[Пума Тайланд]

Ну так увеличьте процы до 8 штук с четырех если и так очевидно что их не хватает