我有一个使用大量连接的网站和应用程序.它通常有大约3,000个静态打开的连接,并且可以在几秒钟的时间内接收5,000到50,000次连接尝试.
由于TIME_WAIT状态套接字,我遇到了耗尽本地端口以打开新连接的问题.即使将tcp_fin_timeout设置为较低的值(1-5),这似乎只会导致过多的开销/减速,并且它仍然偶尔会无法打开新的套接字.
我已经查看了tcp_tw_reuse和tcp_tw_recycle,但我不确定这些中哪一个是首选,或者如果同时使用这两个选项.
我正在努力将我的应用程序扩展到多个服务器,并且一个要求是客户端始终与同一服务器通信(过多的实时数据用于允许服务器之间的有效弹跳).
我目前的设置是一个小型服务器集群(使用Linode).我有一个使用"平衡源"运行HAProxy的前端节点,因此IP始终指向同一节点.
我注意到"平衡源"不是一个非常均匀的分布.使用我当前的测试设置(2个后端服务器),当使用80-100个源IP的样本大小时,一个服务器通常具有3-4倍的连接.
有没有办法实现更均衡的分配？显然,粘性会议禁止"完美"平衡,但是40/60分割将优于25/75分割.
我有一张桌子,每分钟大约有10-15k个参赛作品.每个人在进入时都标有当前时间戳.该表是一个MEMORY表,因为丢失数据不是问题.
每一分钟,我都有一个运行以下查询的脚本:
DELETE FROM tracker WHERE post_time < DATE_SUB(NOW(), INTERVAL 15 MINUTE)
这个查询大约需要1-2秒才能运行,这也不错,但似乎这种类型的查询(删除早于以前的所有内容X)在对MEMORY表运行时应该能够更快地执行.它也有相应的CPU尖峰,每分钟像拇指一样突出.
我可以对查询进行任何优化以更有效地运行此查询吗？
我最近注意到我的MySQL服务器正在创建相当多的磁盘表[创建临时磁盘表:67,创建临时表:304].
我一直在努力确定哪些查询正在创建这些表,但我没有运气.我已经为查询耗时超过1秒启用了慢查询日志,但是那里显示的查询没有意义.在慢速查询日志中定期显示的唯一查询是使用主键作为where子句更新用户表上的单个行.
我对所有经常运行的查询都进行了'解释',而且我对罪魁祸首感到茫然.