Тайм-аут витой связи при большой нагрузке

Question

У нас есть веб-приложение Django, которое обслуживает умеренное количество пользователей, работающих на машине Ubuntu с 8 ядрами и не менее 32 ГБ оперативной памяти. У нас нет проблем с подключением пользователей через их браузер. Однако на бэкэнд (на том же сервере) мы также запускаем скрученный сервер. Django webapp пытается подключиться к нашему скрученному серверу, но после примерно 1100-1200 таких подключений (включая кучу постоянных подключений к другим устройствам на бэкэнд) все соединения начинают таймаут. Наш скрученный сервер работал отлично при низкой нагрузке, но теперь сервер, похоже, не может обрабатывать какие-либо новые соединения из Django. Время ожидания всех подключений. Мы не видим ничего плохого в нашем коде (который мы работаем уже пару лет, поэтому он должен быть довольно стабильным). Мы уже установили наши мягкие и жесткие ulimits в /etc/security/limits.conf до 50000/65000, и мы увеличили количество сомакс до 65536. Печать лимитов для нашего скрученного процесса приведена ниже. Общее количество файлов в процессах tope 25 составляет чуть более 5000. К сожалению, мы по-прежнему не можем получить более 1100-1200 одновременных подключений к нашему скрученному серверу. На что мы должны обратить внимание, чтобы наши витые соединения снова начали соединяться? Существуют ли другие параметры sysctl или других Ubuntu Linux, которые нам необходимо изменить? Нужны ли измененные параметры?

Limit      Soft Limit   Hard Limit   Units 
Max cpu time    unlimited   unlimited   seconds 
Max file size    unlimited   unlimited   bytes 
Max data size    unlimited   unlimited   bytes 
Max stack size   8388608    unlimited   bytes 
Max core file size  0     unlimited   bytes 
Max resident set   unlimited   unlimited   bytes 
Max processes    465901    465901    processes 
Max open files   50000    65000    files 
Max locked memory   65536    65536    bytes 
Max address space   unlimited   unlimited   bytes 
Max file locks   unlimited   unlimited   locks 
Max pending signals  465901    465901    signals 
Max msgqueue size   819200    819200    bytes 
Max nice priority   0     0 
Max realtime priority  0     0 
Max realtime timeout  unlimited   unlimited   us 

Answer 1

Twisted - это тонкая оболочка вокруг вашего приложения. Когда проблема с производительностью, почти всегда, проблема находится где-то внутри приложения, а не в Twisted. Поэтому ответа на этот вопрос нет.

Тем не менее, есть несколько методов исследования, которые вы могли бы использовать. Ваш процесс Twisted потребляет 100% процессор? Если это так, вам нужно как-то разбить его на несколько процессов (используя spawnProcess, sendFileDescriptor и adoptStreamPort, чтобы разрешить выполнение ввода-вывода в подпроцессах). Если нет, то ваша проблема - это, вероятно, некоторые непреднамеренные блокирующие операции ввода-вывода, которые не позволяют реактору обслуживать запросы: вы можете использовать что-то вроде twisted_hang для диагностики горячих точек, где реактор «застревает».

Существует также вероятность того, что проблема может быть на стороне Django соединения. Однако, не имея информации о том, как Django создает эти соединения, я еще немного догадываюсь.