一条select语句引起的瓶颈问题思考
2013-02-27 23:01
996 查看
情境还原:
公司一项目新上线,刚上线的第2天,在后台发现数据库服务器与IIS服务器的网络IO出现瓶颈,1GB的网络带宽,占用了70%-100%,也就是每秒传输数据700MB-1GB,数据库使用内存高达21GB。
IIS服务器CPU使用率时常爆至80%-90%,导致网站频频出现连接超时。
原因:晚上只好暂时关闭网站,进行服务器维护,作全面的检查跟踪,发现是一句Select语句导致:
Select * From Table1
这条语句,语法是没问题的,但在应用上出了问题。Table1存储的是10多万行数据,表数据每天都会上万的增长。
为了统计总行数,频频调用这语句,每秒刷新不低于1000次。
也因此导致网络出现瓶颈。
解决:后面把Select语句改成
即可解决问题,网络 IO数据马上降至10MB以下,数据库使用内存也保持在预计范围12GB。
看似非常简单的问题,其实不然。解决这问题,所花的时间周期是6小时,检查问题使用1小时,修改代码使用5小时。
公司一项目新上线,刚上线的第2天,在后台发现数据库服务器与IIS服务器的网络IO出现瓶颈,1GB的网络带宽,占用了70%-100%,也就是每秒传输数据700MB-1GB,数据库使用内存高达21GB。
IIS服务器CPU使用率时常爆至80%-90%,导致网站频频出现连接超时。
原因:晚上只好暂时关闭网站,进行服务器维护,作全面的检查跟踪,发现是一句Select语句导致:
Select * From Table1
这条语句,语法是没问题的,但在应用上出了问题。Table1存储的是10多万行数据,表数据每天都会上万的增长。
为了统计总行数,频频调用这语句,每秒刷新不低于1000次。
也因此导致网络出现瓶颈。
解决:后面把Select语句改成
Select Count(*) from Table1
即可解决问题,网络 IO数据马上降至10MB以下,数据库使用内存也保持在预计范围12GB。
看似非常简单的问题,其实不然。解决这问题,所花的时间周期是6小时,检查问题使用1小时,修改代码使用5小时。
相关文章推荐
- 一条select语句引起的瓶颈问题思考
- Struts2单例引起的问题及解决思考
- 数值得整数次方——小问题引起大思考
- 对团队中“这是某某某的问题”引起的思考
- 上游哥们积压问题导致我加班引起的思考
- 主从复制问题引起的架构优化思考
- 对于String s = new String("abc") 等问题引起的思考
- ElasticStack系列之十五 & query cache 引起性能问题思考
- Struts2单例引起的问题及解决思考
- sql注入问题引起的思考
- 对团队中“这是某某某的问题”引起的思考
- 一段旧代码,引起的关于OO中一个问题的思考
- 一个问题引起的思考
- UAT测试后上线出现问题的引起的思考
- 由Microsoft.Practices.EnterpriseLibrary.Data.SqlCe出现问题引起的思考
- ubuntu下一个乱码问题引起的思考和学习
- 一条if语句引起的思考
- UAT测试后上线出现问题的引起的思考
- 一条运维短信引起的思考
- Bootstrap Modal 关闭时引起的问题