什么是高负载，非常繁忙的内容stream媒体服务器最好的sysctl.confconfiguration？ 服务器从亚马逊，s3等远程服务器获取内容，然后使用phpdynamic地将内容stream式传输到用户，而不必将其保存到硬盘上。 PHP使用CURL来获取文件，然后使用flush（）来同步stream式传输，所以没有太多的硬盘工作…只有networking和带宽。
该服务器是四核心Xeon，具有1Gbit全双工NIC，8GB内存和500GBx2的RAID。 服务器内存使用情况和CPU负载相当低。
我们正在运行debian lenny和lighttpd2（是的，我知道它还没有发布:-)）与PHP 5.3.6和PHP的FastCGI与spawn-FBCG绑定在4个不同的Unixsockets，每个20个孩子。 最大fcgi请求数为20，使用lighttpd2configuration中的mod_balancer模块来平衡SQF（短队优先）configuration中这4个套接字之间的fastcgi请求。
我们的服务器使用了大量的带宽，即networking连接一直很忙。 在100到200个并行连接之后，服务器开始减速并最终变为无响应，开始发出连接超时错误。 当我们有cPanel的时候，我们从来没有超时的错误，所以它不能成为一个脚本问题。 它必须是networkingconfiguration问题。
lighttpd2configuration：工作进程= 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 性能调整和识别这样的瓶颈是一个难以解决的问题，并且经常需要大量的信息来诊断。 这个过程的关键是要通过它使用的过程，看看你是否能够find哪些资源正在耗尽。 当你说服务器对php没有响应，但html仍然服务，这是一个有趣的数据点。 这些服务之间有什么不同？ 它可能是微妙的networking缓冲区溢出，或者可能比这更基本。 你可能只是用尽了20个子fcgisubprocess的限制，而且他们都在忙着提供数据，而新的请求被堵塞到监听队列中（最终超时），等待一个fcgi php进程出现。
试图在盒子上查看时，真正的技巧就是在发生问题时login到盒子中，并开始收集信息。
要找出有多less个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范围内，那么会告诉你，你已经用完了文件描述符，这就是你需要调整的。