Когда к nginx идёт более 1024 соединений и он падает, что делать будете?

Диагностика и решение проблемы с падением Nginx при более 1024 соединений

Когда Nginx падает при превышении 1024 соединений, это классический симптом ограничений, накладываемых операционной системой или конфигурацией самого Nginx. Я бы действовал по следующему плану диагностики и устранения.

1. Анализ логов и сбор первичной информации

Первым делом необходимо изучить логи Nginx и системные логи для понимания характера ошибки.

# Проверка логов ошибок Nginx
tail -f /var/log/nginx/error.log

# Поиск критических ошибок в системном журнале
journalctl -u nginx --since "5 minutes ago" | grep -i error

# Проверка доступных логов ядра (возможные OOM или segfault)
dmesg | tail -50

Ключевые моменты, на которые обращаю внимание:

• "too many open files" - указывает на исчерпание лимитов файловых дескрипторов
• "worker_connections are not enough" - недостаточно соединений в конфигурации Nginx
• Segmentation fault - возможная ошибка в модуле или самом Nginx

2. Проверка системных ограничений

Проблема с 1024 соединениями часто связана с лимитами файловых дескрипторов в Linux.

# Проверка текущих лимитов для процесса Nginx
cat /proc/$(pgrep -o nginx)/limits | grep "open files"

# Проверка системных лимитов
ulimit -n
ulimit -Hn

# Глобальные лимиты системы
sysctl fs.file-max
sysctl fs.nr_open

3. Увеличение лимитов файловых дескрипторов

Если проблема в лимитах, необходимо увеличить их на нескольких уровнях:

Временное увеличение для текущей сессии:

ulimit -n 65536

Постоянная настройка в конфигурации системы:

# Добавление в /etc/security/limits.conf
echo "nginx soft nofile 65536" >> /etc/security/limits.conf
echo "nginx hard nofile 65536" >> /etc/security/limits.conf

# Для систем с systemd создаем или редактируем сервисный файл
mkdir -p /etc/systemd/system/nginx.service.d
echo -e "[Service]\nLimitNOFILE=65536" > /etc/systemd/system/nginx.service.d/limits.conf
systemctl daemon-reload
systemctl restart nginx

Увеличение глобальных лимитов:

# В /etc/sysctl.conf
echo "fs.file-max = 2097152" >> /etc/sysctl.conf
sysctl -p

4. Оптимизация конфигурации Nginx

Проверяю и оптимизирую основные параметры соединений в nginx.conf:

# Основной конфигурационный файл nginx.conf
events {
    # Увеличиваем worker_connections (по умолчанию 512)
    worker_connections 4096;
    
    # Оптимизация метода обработки соединений
    use epoll; # Для Linux
    
    # Увеличиваем multi_accept
    multi_accept on;
}

http {
    # Оптимизация таймаутов
    keepalive_timeout 65;
    keepalive_requests 100;
    
    # Увеличение буферов
    client_body_buffer_size 128k;
    client_header_buffer_size 4k;
    large_client_header_buffers 4 16k;
    
    # Оптимизация файловых дескрипторов
    worker_rlimit_nofile 65536;
}

5. Мониторинг и нагрузочное тестирование

После внесения изменений необходимо проверить результат:

# Мониторинг текущих соединений
ss -tunap | grep nginx | wc -l
netstat -an | grep :80 | wc -l

# Проверка использования файловых дескрипторов
ls -l /proc/$(pgrep -o nginx)/fd | wc -l

# Нагрузочное тестирование (пример с Apache Benchmark)
ab -n 10000 -c 2000 http://ваш_сайт/

6. Дополнительные оптимизации

Если проблема сохраняется, рассматриваю дополнительные меры:

• Увеличение числа worker процессов в Nginx:

worker_processes auto; # или явное количество по числу ядер CPU

• Настройка TCP-стека ОС:

# Увеличение диапазона локальных портов
echo "net.ipv4.ip_local_port_range = 1024 65535" >> /etc/sysctl.conf

# Увеличение максимального числа соединений в очереди
echo "net.core.somaxconn = 65536" >> /etc/sysctl.conf

# Увеличение буферов TCP
echo "net.core.rmem_max = 16777216" >> /etc/sysctl.conf
echo "net.core.wmem_max = 16777216" >> /etc/sysctl.conf

sysctl -p

• Рассмотрение архитектурных изменений:
  • Внедрение кеширования статического контента
  • Настройка балансировщика нагрузки перед Nginx
  • Использование CDN для разгрузки сервера
  • Вертикальное/горизонтальное масштабирование инфраструктуры

7. Проактивные меры на будущее

Для предотвращения повторения проблемы:

• Настройка мониторинга ключевых метрик:

  • Количество активных соединений
  • Использование файловых дескрипторов
  • Загрузка CPU и памяти
  • Очереди соединений

• Реализация алертинга при приближении к критическим значениям

• Планирование регулярных нагрузочных тестов

• Документирование инцидента и процедур восстановления

Важный нюанс: Если Nginx падает с segmentation fault при высокой нагрузке, проблема может быть в конкретном модуле, сборке Nginx или аппаратных проблемах. В этом случае необходимо:

1. Проверить целостность дисков (smartctl)
2. Протестировать оперативную память (memtest86+)
3. Обновить Nginx до стабильной версии
4. Отключить проблемные модули по одному для диагностики

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