Какая конфигурация sysctl.conf лучше всего подходит для высоконагруженного и чрезвычайно загруженного сервера потоковой передачи контента? Сервер извлекает контент с удаленных серверов, таких как amazon, s3 и т. Д., А затем использует php для динамической потоковой передачи контента пользователю, не сохраняя его на жестком диске. php использует CURL для извлечения файла, а затем использует flush () для одновременной потоковой передачи, поэтому жесткий диск работает не так много ... только сеть и пропускная способность.
Сервер представляет собой четырехъядерный процессор xeon с полнодуплексным сетевым адаптером 1 Гбит, ОЗУ 8 Гб и массивом RAID 500 Гбайт. Использование памяти сервера и загрузка процессора довольно низкие.
Мы запускаем на нем 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, это означало бы, что у вас заканчиваются файловые дескрипторы, и это то, что вам нужно настроить.