Лучшая конфигурация sysctl.conf для высокой нагрузки - чрезвычайно загруженный сервер потокового контента

Какова наилучшая конфигурация sysctl.conf для высоконагруженного, чрезвычайно загруженного сервера потоковой передачи контента? Сервер извлекает контент с удаленных серверов, таких как amazon, s3 и т. Д., Затем использует php для динамической потоковой передачи контента пользователю без сохранения его на жестком диске. php использует CURL для извлечения файла, затем использует flush () для одновременной потоковой передачи, поэтому не так много работы с жестким диском ... только сеть и пропускная способность.

Сервер представляет собой четырехъядерный процессор Xeon с 1 Гбит / с дуплексной сетевой картой, 8 ГБ ОЗУ и 500 ГБ x2 в RAID. Использование памяти сервера и загрузка процессора довольно низка.

Мы запускаем debian lenny и lighttpd2 на нем (да, я знаю, что он еще не выпущен :-)) с php 5.3.6 и php fastcgi с привязкой spawn-fcgi на 4 различных сокетах unix с 20 дочерними элементами в каждом. Максимальное количество запросов fcgi - 20, с модулем mod_balancer в конфигурации lighttpd2 для балансировки запросов fastcgi между этими 4 сокетами в конфигурации SQF (сначала короткая очередь).

Наши серверы используют большую пропускную способность, т. Е. Подключение к сети постоянно. Сразу после 100-200 параллельных подключений сервер начинает замедляться и в конечном итоге перестает отвечать на запросы, из-за чего возникают ошибки времени ожидания подключения. Когда у нас была cpanel, у нас никогда не возникало ошибок тайм-аута, поэтому это не может быть проблемой скрипта. Это должно быть проблемой конфигурации сети.

Конфигурация lighttpd2: рабочие процессы = 8, запросы на поддержание активности - 32, время простоя на поддержание - 10 секунд, а максимальное количество соединений - 8192.

Наше текущее содержание sysctl.conf:

net.ipv4.tcp_fin_timeout = 1
net.ipv4.tcp_tw_recycle = 1

# Increase maximum amount of memory allocated to shm

kernel.shmmax = 1073741824

# This will increase the amount of memory available for socket input/output queues
net.ipv4.tcp_rmem = 4096 25165824 25165824
net.core.rmem_max = 25165824
net.core.rmem_default = 25165824
net.ipv4.tcp_wmem = 4096 65536 25165824
net.core.wmem_max = 25165824
net.core.wmem_default = 65536
net.core.optmem_max = 25165824

net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_orphans = 262144
net.ipv4.tcp_max_syn_backlog = 262144
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syn_retries = 2

# you shouldn't be using conntrack on a heavily loaded server anyway, but these are
# suitably high for our uses, insuring that if conntrack gets turned on, the box doesn't die
# net.ipv4.netfilter.ip_conntrack_max = 1048576
#  net.nf_conntrack_max = 1048576

# For Large File Hosting Servers
net.core.wmem_max = 1048576
net.ipv4.tcp_wmem = 4096 87380 524288

Подобную настройку производительности и идентификацию «горлышков бутылок» сложно решить, и для диагностики часто требуется много информации. Ключ к процессу - пройти через процесс, который он использует, и посмотреть, сможете ли вы найти, какой ресурс исчерпан. Когда вы сказали, что сервер не отвечает на php, но html по-прежнему обслуживает, это интересная точка данных. Чем отличается то, как они подаются? Это может быть незначительное переполнение сетевого буфера, или оно может быть более простым, чем это. Возможно, вы просто исчерпали лимит 20 дочерних процессов fcgi, и все они заняты обслуживанием данных, в то время как новые запросы запираются в очереди на прослушивание (и в конечном итоге истекают) в ожидании запуска процесса fcgi php.

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

Чтобы узнать, сколько PHP-процессов запущено, вы должны иметь возможность запустить что-то вроде этого:

ps auxgmww | grep php

И если вы хотите получить их счет, а не считать их самостоятельно, вы можете сделать что-то вроде этого:

ps auxgmww | grep php | wc -l

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

sysctl -a > sysctl.txt

А затем просмотрите ваш текстовый файл - это много данных, но прежде чем настраивать какое-либо заданное значение, посмотрите, сообщает ли вывод sysctl о том, что он в данный момент использует для этой перестраиваемой конфигурации и что он может потреблять. Одним из примеров являются открытые файлы, которые вы можете увидеть пример вывода здесь:

fs.file-nr = 3456   0   102295

Это говорит нам о том, что мы используем 3456 файловых дескрипторов, но наш лимит составляет 102295, поэтому мы не приблизились к нашему пределу. Если бы первое число было в диапазоне 100000, это означало бы, что у вас заканчиваются файловые дескрипторы, и это то, что вам нужно настроить.