Я пытаюсь максимально масштабировать установку nginx.
Я запускаю один экземпляр nginx с 6 процессами worker_processes (6 ядер) и 5 внутренними серверами, состоящими из uwsgi установка с 10 рабочими в каждом. (всего 50 рабочих).
Однако любой тест, который я пытаюсь выполнить с другими параметрами (используя ab) для общего количества и одновременных подключений, кажется, на уровне около 1000 запросов в секунду.
Я отключил все журналы для nginx и uwsgi (чтобы избежать замедления из-за проблем с диском). Я тестирую приложение Flask на Python, которое просто отправляет {'status':'ok'} назад. Ни доступа к базе данных, ни вычислений, ничего.
Соответствующая часть конфигурации nginx выглядит так:
user www-data;
worker_processes 6;
worker_rlimit_nofile 100000;
pid /var/run/nginx.pid;
events {
use epoll;
worker_connections 2048;
multi_accept on;
}
http {
##
# Basic Settings
##
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
types_hash_max_size 2048;
# server_tokens off;
# server_names_hash_bucket_size 64;
# server_name_in_redirect off;
include /etc/nginx/mime.types;
default_type application/octet-stream;
##
# Logging Settings
##
access_log off; # /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
<...>
}
Я ищу любые советы, все, что я упустил из виду, для увеличения пропускной способности. Просмотр статистики по каждому uwsgi бассейн (с использованием uwsgitop) они не кажутся сложными для выполнения, что наводит меня на мысль, что узким местом является nginx. Кроме того, производительность была такой же с одним пулом рабочих вместо 10. Кроме того, htop также показывает, что я далек от максимума с точки зрения памяти или процессора.
Я рекомендую вам установить sysstat пакет затем проверьте записанную информацию с помощью сар.
sar -n SOCK -s <start_time> -e <end_time> чтобы получить количество розеток во время теста
sar -n DEV -s <start_time> -e <end_time> получать пакеты сетевых интерфейсов и пропускную способность
sar -d -s <start_time> -e <end_time> чтобы получить статистику io для каждого устройства
sar -v -s <start_time> -e <end_time> чтобы получить количество дескрипторов файлов и индексов
и т.д
Проверьте ограничения безопасности для ваших пользователей (максимальное количество открытых файлов, максимальное количество процессов и т. Д.).
Затем проверьте настройки ядра: диапазон локальных портов, somaxconn, устройство txqueue, netdev backlog, активируйте повторный цикл сокета для состояний TIME_WAIT, если необходимо (в отношении tcp-tw с sar -n SOCK) с SO_LINGER в nginx или tcp_tw_recycle (если вы этого не сделаете) t иметь NAT) или повторно использовать (для исходящих соединений), при необходимости измените количество tw_buckets, убедитесь, что sack / dsack и временные метки включены, уменьшите время ожидания FIN_WAIT_2, увеличьте максимальное количество дескрипторов файлов, если необходимо и т. д.
Может быть много факторов.
Прежде чем проверять все это, убедитесь, что вы не запускаете ab на той же установке, и это приложение Python имеет хорошее время отклика.
И простой тест, чтобы убедиться, что приложение python не является виновником: тот же тест на статическом файле непосредственно на сервере от nginx.
Я бы посмотрел на файловые дескрипторы, возможное насыщение сети / интерфейса и проблемы ввода-вывода.
Чтобы узнать, не перегружен ли сетевой интерфейс, используйте iptraf - инструмент командной строки для просмотра статистики в реальном времени. Просто:
iptraf
Для проблем ввода-вывода используйте iostat
iostat 1
который покажет использование ввода-вывода и загрузку каждую 1 секунду.
Для проблем с файловым дескриптором используйте lsof или / proc:
lsof -P -n -p <PID> | wc -l
ls /proc/<PID>/fd | wc -l
Использовать ulimit -a | grep files (как пользователь, запускающий процесс), чтобы проверить, сколько файлов вам разрешено открывать. По умолчанию 1024.
См. Эту страницу для получения дополнительной информации: http://www.cyberciti.biz/tips/linux-procfs-file-descriptors.html
См. Этот вопрос для конкретной проблемы дескриптора файла nginx, которая вполне может быть связана с вашей проблемой: понимание макс файловых дескрипторов для linux и nginx и лучшее значение для worker_rlimit_nofile
В дополнение к двум другим ответам здесь также может быть проблема conntrack (отслеживание соединения). Если вы используете Linux, и если вы используете netfilter (например, iptables), ваша таблица conntrack может быть заполнена.
Сначала проверьте, включен ли conntrack. Например:
$ /sbin/lsmod | grep conntrack
ip_conntrack 51617 1 xt_state
$ lsmod | grep -i con
nf_conntrack_ipv4 19159 5
nf_defrag_ipv4 12729 1 nf_conntrack_ipv4
nf_conntrack 92358 5 xt_state,iptable_nat,nf_conntrack_ipv4,nf_nat_ipv4,nf_nat
Результат будет зависеть от версии ядра.
Если если любой из nf_conntrack или ip_conntrack модули загружены, вы можете увидеть, сколько записей в conntrack есть, и проверить, какой у вас максимум, с помощью следующего:
Red Hat (RHEL, CentOS, Fedora и т. Д.):
$ sudo wc -l /proc/net/ip_conntrack
$ /sbin/sysctl -a | grep conntrack_max
or
$ sudo wc -l /proc/net/nf_conntrack
$ /sbin/sysctl -a | grep conntrack_max
Debian:
$ cat /proc/sys/net/netfilter/nf_conntrack_count
$ /sbin/sysctl -a | grep conntrack_max
Если вы заполнили таблицу conntrack, вам нужно будет увеличить лимит с помощью sysctl или /etc/sysctl.conf.
Заметка: conntrack относится не только к серверу. Вам нужно будет проверить каждую точку между вами и сервером: клиентский компьютер, балансировщик нагрузки (nginx), восходящий (внутренний) сервер и, возможно, даже любые маршрутизаторы.