Чому мій веб-сервер припиняє з'єднання із скиданням TCP при великому навантаженні?

У мене невелика установка VPS з nginx. Я хочу витіснити якомога більше продуктивності, тому я експериментував з оптимізацією та тестуванням навантаження.

Я використовую Blitz.io для тестування завантаження, отримавши невеликий статичний текстовий файл, і зіткнувся з незвичайною проблемою, коли сервер, як видається, надсилає TCP скидання, як тільки кількість одночасних підключень досягне приблизно 2000. Я знаю, що це дуже велика кількість, але від використання htop-сервера все ще є достатньо запасу часу та пам'яті процесора, тому я хотів би розібратися в джерелі цього питання, щоб побачити, чи зможу я ще більше просунути його.

Я працюю на Ubuntu 14.04 LTS (64-розрядний) на 2 ГБ Linode VPS.

У мене недостатньо репутації, щоб опублікувати цей графік безпосередньо, тому ось посилання на графік Blitz.io:

Ось те, що я зробив, щоб спробувати з’ясувати джерело проблеми:

• Значення конфігурації nginx worker_rlimit_nofileвстановлено на 8192
• вже nofileвстановлені в 64000 для твердих і м'яких обмежень для rootі www-dataкористувача (то , що Nginx працює як) в/etc/security/limits.conf

• немає жодних ознак, в чому щось не /var/log/nginx.d/error.logтак

• У мене налаштування ufw, але немає обмежувальних норм. Журнал ufw вказує, що нічого не блокується, і я спробував відключити ufw з тим же результатом.

• Показових помилок у програмі немає /var/log/kern.log
• Показових помилок у програмі немає /var/log/syslog

• Я додав наступні значення /etc/sysctl.confі завантажував їх sysctl -pбез ефекту:

  net.ipv4.tcp_max_syn_backlog = 1024
  net.core.somaxconn = 1024
  net.core.netdev_max_backlog = 2000
  

Будь-які ідеї?

EDIT: Я зробив новий тест, розширивши 3000 підключень у дуже маленькому файлі (всього 3 байти). Ось графік Blitz.io:

Знову ж таки, за словами Бліц, всі ці помилки - це помилки "скидання з’єднання TCP".

Ось графік пропускної здатності Лінода. Майте на увазі, що це середня 5 хвилин, тому низький прохід фільтрується трохи (миттєва пропускна здатність, ймовірно, набагато вище), але все-таки це нічого:

ЦП:

I / O:

Ось htopпід кінець тесту:

Я також захопив частину трафіку за допомогою tcpdump за іншим (але схожим на вигляд) тестом, починаючи захоплення, коли почалися входи помилки: sudo tcpdump -nSi eth0 -w /tmp/loadtest.pcap -s0 port 80

Ось файл, якщо хтось хоче його подивитися (~ 20 МБ): https://drive.google.com/file/d/0B1NXWZBKQN6ETmg2SEFOZUsxV28/view?usp=sharing

Ось графік пропускної здатності від Wireshark:

(Рядок - це всі пакети, сині смужки - помилки TCP)

З моєї інтерпретації захоплення (і я не експерт), схоже, що прапорці TCP RST надходять із джерела тестування навантаження, а не з сервера. Отже, якщо припустити, що щось не так на стороні служби тестування навантажень, чи можна з впевненістю вважати, що це результат певного управління мережею або зменшення DDOS між службою тестування навантаження та моїм сервером?

Дякую!

Можливо, існує будь-яка кількість джерел скидання з'єднання. Тестер навантаження може бути поза доступними ефемерними портами, з яких ініціювати з'єднання. У пристрої, який є на шляху (наприклад, брандмауер, що працює в NAT), може бути вичерпаний пул NAT і він не може забезпечити вихідний порт для з'єднання. балансир навантаження або брандмауер на вашому кінці, який, можливо, досяг межі з'єднання? І якщо робити джерело NAT на вхідному трафіку, це також може випробувати виснаження портів.

Один би дійсно потрібен файл pcap з обох кінців. Що ви хочете шукати, це якщо спроба з'єднання надіслана, але ніколи не дістається до сервера, але все одно видається так, ніби вона була скинута сервером. Якщо це так, то щось по лінії повинно було скинути з'єднання. Виснаження басейнів NAT є загальним джерелом подібних проблем.

Також netstat -st може дати вам додаткову інформацію.

Деякі ідеї спробувати, виходячи з мого власного недавнього подібного настрою. З посиланнями:

Ви кажете, що це статичний текстовий файл. На всякий випадок, якщо відбувається яка-небудь обробка вище, по всій видимості, розетки домену покращують пропускну здатність TCP через з'єднання на базі TC:

https://rtcamp.com/tutorials/php/fpm-sysctl-tweaking/ https://engineering.gosquared.com/optimising-nginx-node-js-and-networking-for-heavy-workloads

Незалежно від припинення:

Увімкнути multi_accept і tcp_nodelay: http://tweaked.io/guide/nginx/

Вимкнути повільний старт TCP: /programming/17015611/disable-tcp-slow-start http://www.cdnplanet.com/blog/tune-tcp-initcwnd-for-optimum-performance/

Оптимізуйте вікно застосу TCP (initcwnd): http://www.nateware.com/linux-network-tuning-for-2013.html

Щоб встановити максимальну кількість відкритих файлів (якщо це спричиняє вашу проблему), потрібно додати "fs.file-max = 64000" в /etc/sysctl.conf

Подивіться, скільки портів знаходиться у TIME_WAITстані, використовуючи команду, netstat -patunl| grep TIME | wc -lта змініть net.ipv4.tcp_tw_reuseна 1.