高负载的最佳 sysctl.conf 配置 - 非常繁忙的内容流服务器

Dan*_*son 9 debian file-sharing performance-tuning lighttpd debian-lenny

什么是高负载、极其繁忙的内容流服务器的最佳 sysctl.conf 配置?服务器从远程服务器(如 amazon、s3 等)获取内容,然后使用 php 将内容动态流式传输给用户,而无需将其保存到硬盘上。php 使用 CURL 来获取文件,然后使用flush() 同时流式传输它,所以没有太多的硬盘工作......只有网络和带宽。

该服务器为四核至强,具有 1Gbit 全双工 NIC、8GB RAM 和 500GBx2 RAID。服务器内存使用率和 CPU 负载非常低。

我们在其上运行 debian lenny 和 lighttpd2(是的,我知道它还没有发布 :-) )和 php 5.3.6 和 php fastcgi 和 spawn-fcgi 绑定在 4 个不同的 unix 套接字上,每个套接字有 20 个孩子。最大 fcgi 请求为 20,在 lighttpd2 配置中使用 mod_balancer 模块来平衡这 4 个 SQF(短队列优先)配置中的套接字之间的 fastcgi 请求。

我们的服务器使用大量带宽,即网络连接一直很忙。就在 100 到 200 个并行连接之后,服务器开始变慢并最终变得无响应,开始出现连接超时错误。当我们有 cpanel 时,我们从来没有出现超时错误,所以它不可能是脚本问题。应该是网络配置问题。


lighttpd2 配置:worker processes = 8,keep alive requests 为32,keep alive idle timeout 为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
Run Code Online (Sandbox Code Playgroud)

Nei*_*ely 5

像这样的性能调优和识别瓶颈是一个难以解决的问题,并且经常需要大量信息来诊断。该过程的关键是遍历它使用的过程,看看是否可以找到正在耗尽的资源。当你说服务器对 php 没有响应,但 html 仍然提供服务时,这是一个有趣的数据点。它们的服务方式有什么不同?这可能是微妙的网络缓冲区溢出,或者可能比这更基本。您可能只是用尽了 20 个子 fcgi 子进程限制,并且它们都忙于提供数据,而新请求则被塞进监听队列(并最终超时),等待 fcgi php 进程出现。

试图获得盒子可见性的真正技巧是在出现问题时登录盒子并开始收集信息。

要了解有多少 php 进程正在运行,您应该能够运行以下内容:

ps auxgmww | grep php
Run Code Online (Sandbox Code Playgroud)

如果您想计算它们而不是自己计算它们,您可以执行以下操作:

ps auxgmww | grep php | wc -l
Run Code Online (Sandbox Code Playgroud)

回到关于性能调整的原始问题,在更改 syctl.conf 之前,您可能想查看服务器在问题发生时告诉您的内容,您可以通过执行以下操作来找到这一点:

sysctl -a > sysctl.txt
Run Code Online (Sandbox Code Playgroud)

然后查看您的文本文件 - 这是大量数据,但在调整任何给定值之前,请查看 sysctl 输出是否报告了有关当前用于该可调参数的内容以及它可能正在消耗的内容的任何信息。一个例子是打开的文件,你可以在这里看到一个示例输出:

fs.file-nr = 3456   0   102295
Run Code Online (Sandbox Code Playgroud)

这告诉我们我们使用了 3456 个文件描述符,但我们的限制是 102295,所以我们离我们的限制还差得很远。如果第一个数字在 100000 范围内,那将告诉您文件描述符用完了,这就是您需要调整的内容。