![适用于高负载的最佳 sysctl.conf 配置 - 极其繁忙的内容流服务器](https://linux22.com/image/543663/%E9%80%82%E7%94%A8%E4%BA%8E%E9%AB%98%E8%B4%9F%E8%BD%BD%E7%9A%84%E6%9C%80%E4%BD%B3%20sysctl.conf%20%E9%85%8D%E7%BD%AE%20-%20%E6%9E%81%E5%85%B6%E7%B9%81%E5%BF%99%E7%9A%84%E5%86%85%E5%AE%B9%E6%B5%81%E6%9C%8D%E5%8A%A1%E5%99%A8.png)
对于高负载、极其繁忙的内容流服务器,最佳的 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 模块可在 SQF(短队列优先)配置中的这 4 个套接字之间平衡 fastcgi 请求。
我们的服务器占用大量带宽,即网络连接一直处于繁忙状态。刚过 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
答案1
性能调优和识别瓶颈问题很难解决,通常需要大量信息才能诊断。该过程的关键是检查它所使用的过程,看看是否能找到耗尽的资源。当您说服务器对 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 范围内,那就说明文件描述符用完了,这就是您需要调整的地方。