服务器在高负载下崩溃
目前我们正在运行一个引起媒体关注的设置，我们预计这个stream量还会继续。 我们有1个haproxy负载均衡器，3个应用程序服务器（2个映像，1个通用）和一个数据库服务器。 loadbalancer根据url获取所有的加载和redirect。 问题是，我们的应用程序崩溃或每10分钟左右响应时间非常低（在graphics下降时，它的图像）。 你们知道什么是错的吗？ 如果您需要更多信息，请提供。
haproxyconfiguration：
global log /dev/log local0 log /dev/log local1 notice chroot /var/lib/haproxy user haproxy group haproxy daemon defaults log global mode tcp option tcplog option dontlognull contimeout 5000 clitimeout 50000 srvtimeout 50000 errorfile 400 /etc/haproxy/errors/400.http errorfile 403 /etc/haproxy/errors/403.http errorfile 408 /etc/haproxy/errors/408.http errorfile 500 /etc/haproxy/errors/500.http errorfile 502 /etc/haproxy/errors/502.http errorfile 503 /etc/haproxy/errors/503.http errorfile 504 /etc/haproxy/errors/504.http frontend http bind *:80 mode http option forwardfor acl content_php path_end getImage.php acl getMedia path_end getMedia.php use_backend getImage if content_php use_backend getImage if getMedia default_backend backend frontend monitoring bind *:1234 mode http stats enable stats uri / stats auth gobi:dlkjaDSgasd backend backend mode http option forwardfor balance source option httpclose server app1 10.129.75.237:80 check backend getImage mode http option forwardfor balance roundrobin option httpclose server image1 10.129.62.139:80 check server image2 10.129.63.146:80 check 负载均衡器： 
DATABASESERVER： 
generalServer： 
imageServer1： 
imageServer2： 
- 如何诊断负载均衡器故障
- Apache的httpd，Tomcat：负载平衡似乎在两个tomcat之间工作，但一停止，服务死亡
- Nginx-rtmp-module边缘节点如何从多个主节点抽取stream
- haproxy – 路由请求并保持相同的基本URL
- Nginx反向代理导致文件下载需要花费过多时间才能启动
这种速度下降可能是由于tcp端口的耗尽，因为已build立连接的峰值等待应用服务器的响应（可能也是使用数据库，或者向其他服务器发出请求），所以在这种情况下，应用服务器可以打开2个（或更多）每个请求的端口。
同时validation在nginx上configuration的错误页面，最好有一个用于500错误的静态html，但是让你的应用程序快速失败，尽快提供错误，避免不必要的计算。
例如，要小心你的电子邮件联系表格，如果字段没有正确validation并提交给应用程序层进行计算和数据库持久化，请务必在validation数据后打开这些连接。
之后，增加net.core.somaxconn=2048并使用sysctlconfiguration工具启用port net.ipv4.tcp_tw_reuse=1 。
所以我们找出了问题。 数据库服务器就像往常一样。 我们有两个问题：
1）我们有一个使用三个连接的MySQL查询。 原来这个函数崩溃了Mysql。 我们重写了这个查询，使用4个没有连接的mysql查询，解决了这个问题。 （一个hot-fix的位，我们可能会重写这个函数，所以可以caching它）。
2）当我们只使用了10％的caching时，我们正在经历大约99.9％的I / O等待。https://dba.stackexchange.com/questions/121324/mysql-only-using-10-of-cache 。 我们试图编辑mysqlconfiguration（在底部引用）。 这帮了很多，但没有解决问题。 原来共享服务器上的另一个用户导致99.8％的I / O峰值。 联系我们的服务器提供商后，他们将服务器移动到另一个分区，问题已修复。
table_open_cache = 1024 sort_buffer_size = 4M read_buffer_size = 128k query_cache_size= 128M query_cache_type = 1 tmp_table_size = 64M thread_cache_size = 20 innodb_buffer_pool_size = 512M innodb_additional_mem_pool_size = 20M innodb_log_file_size = 64M innodb_log_buffer_size = 8M innodb_file_per_table innodb_file_format = Barracuda