注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

gmd20的个人空间

// 编程和生活

 
 
 

日志

 
 

看到数据库连接database connection的性能优化和问题的两篇文章  

2015-01-17 15:45:47|  分类: 程序设计 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
mysql5.7 的连接优化,connect/查询/disconnect 这样的select语句可以做到每秒接近了 5.7万个左右。
每秒能够创建和释放这么多连接的啊!  不是nginx那些http短连接的是每秒多少。 主要问题又是锁竞争的优化。
这个说做了很多优化,比5.6性能提高了一倍多
Improving connect/disconnect performance
http://mysqlserverteam.com/improving-connectdisconnect-performance/


另外一篇是facebook说他们数据库连接复用导致最后的路由器负载不均衡,所有的连接都聚集到一个path上面。
原因是数据库连接池的管理算法, 空闲连接的管理队列使用 most recent use( MRU) + 一个限制时间。  因为很多并行连接,最后一个返回的肯定是最慢的那个,网络最拥挤的那一个。但这个算法每次去队列最后使用的一个(最后返还到队列的那个)也就是最慢的那个来用。因为集群里面机器太多,几百台机器,每个都是使用最慢的那个连接来用,最后的这些连接本来就是可能被hash到同一个拥堵的路由路径上面的。导致路由器里面越拥堵的连接使用的越多,最后压块路由器。 路由器本来有根据ip 和port来做hash负载均衡的也顶不住。因为前面这个算法选择都是同一条拥堵路径上面的连接。 
修复问题简单的把MRU+ 回收时间限制,改成least recent use (LRU) + 连接回收时间限制就好了。
选择那些返回比较快的连接来用,而不是最慢(最拥挤)的那个连接来用,这样选出来的连接就不会是在后端路由器那些拥挤path的连接了。这样路由器层的连接选路的hash算法就在不同path,负载就均衡了。
一个简单的东西在集群多机器下面也可能导致问题啊
原文图示比较清楚可以看一下。需要梯子
https://code.facebook.com/posts/1499322996995183/solving-the-mystery-of-link-imbalance-a-metastable-failure-state-at-scale/
  评论这张
 
阅读(266)| 评论(0)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017