这几天公司网站每当业务高峰的时候,就出现如下状况:
1)web服务器CPU负载30~50%左右。(状况正常)
2)Mysql数据库负载正常。
3)连接Redis的Jedis 2.5.2 + common.pool2,一直报can not get a resource。
Jedis Pool的配置是:
timeout=2000
max_total=30
max_idle=5
max_wait=3000
查看redis的监控软件发现redis连接数居然是max_total的3,4倍。
原因分析,及解决方法
1)怀疑,使用jedis的代码没有把获得的资源还回到pool中。但查代码后,确保生产环境程序,在代码层面都将资源还回到pool中了。
问题依旧。
2)既然都还回pool了,就怀疑是不是2周前将jedis从2.0升级到2.5.2。新的jedis-2.5.2,放弃了原先的common.pool,而使用了common.pool2。
由于,近期未更改过代码,仅是jedis升级。所以决定将部署版本还原到jedis-2.0版本。
问题依旧。
3)再次检查代码,
按照,减少jedis从pool中获取次数,且即使还回pool中的原则。将下述类似的代码:
for (int i = 0; i < 100; i++) {
Jedis jedis = null;
try {
jedis = getJedisFromPool();
String str = jedis.hget("key");
} catch (TimeoutException e) {
throw e;
}
finally{
if(jedis!=null){
// set jedis back to pool
releaseJedisInstance(jedis);
}
}
}
修改为:
String[] keyArr = new String[100]
for (int i = 0; i < 100; i++) {
keyArr[i] = "key" + i;
}
Jedis jedis = null;
try {
jedis = getJedisFromPool();
List<String> result = jedis.hmget(keyArr);
} catch (TimeoutException e) {
throw e;
}
finally{
if(jedis!=null){
// set jedis back to pool
releaseJedisInstance(jedis);
}
}
当天部署后,顺利通过当天第二个业务高峰。
第二天,凌晨0点----6点,Mysql服务器因为负载过高,导致网站瘫痪。
分析及解决方式:
1)分析:查看Mysql的log,发现有个业务,是200多万条数据的A表与200多万条数据的B表,进行了大量的,频繁的left join查询。从而导致大量的慢查询。
解决方式:
a)在B表中冗余字段,建立必要索引。
b)评审代码,优化sql。
2)分析:凌晨,网站开始进行大量后台统计。统计的时候会进行大量的高负载操作。
解决方式:
a)统计在生产库以外的备份出的库上进行。统计数据的查询及使用,也连接备份出的库。
b)去除不必要的统计功能。
3)分析:分析Nginx日志,发现有恶意刷某一页面或功能的请求。
解决方式:
a)增强该部分的代码。
b)在iptable上设置,例如:1分钟内请求大于300次,就屏蔽此IP。
4) 分析:各大搜索引擎,凌晨开始爬虫工作。我们公司网站的历史数据都是未做静态化处理的。
解决方式:历史数据,进行静态化处理。优势,
a)避免不必要的库查询。
b)搜索爬虫,对静态页面的支持更佳,从而提高SEO的效果。
c)静态页面可使用Varnish等,进行缓存操作。
当天夜里,至次日,数据库至此,解决数据库负载过高的情况。
但是,到目前位置,并未完美的且根本解决问题。因为,如果业务高峰再大一些,现有架构的程序依然不能支撑。
描绘一下出问题时的架构:(只画出Redis部分)
放弃pool连接,改用短连接后的,新的架构:(只画出Redis部分)
实现,redis的读写分离,redis主从结构。
在新架构上使用压力测试工具,进行压力测试:
1000并发,1000次请求
1)Web服务器,CPU稳定在150%。
2)Mysql无压力。
3)Redis无压力。
4)Web服务器,Mysql,Redis各个服务器的IO输出正常。
至此问题解决。
总结:
1)代码一定要优化,针对数据库,Redis这样的资源,一定要本着节约的原则。
2)pool 和 短连接比较。
| Pool连接 | 短连接 |
扩展性 | 不容易水平扩展 | 容易水平扩展 |
稳定性 | 弱,不易实现负载均衡 | 强,,易实现负载均衡 |
读写分离 | 不容易实现 | 容易实现 |
3)压力测试尽量多做
介绍一个压力测试工具。
siege -c 1000 -r 1000 http://www.baidu.com
当然Apache自带的 ab 工具,WebBench,apache-jmete都是不错的工具。
- 大小: 17 KB
- 大小: 35.4 KB
分享到:
相关推荐
本文通过一次实际的性能调优案例,深入探讨了如何定位和解决性能问题。首先,问题起因是因为一个消息平台在二期开发完成后,在性能测试中出现了响应速度波动大,TPS(每秒事务数)和请求响应时间不稳定的情况,低谷...
本文档详细记录了一次针对ORACLE 9i数据库的性能优化过程。通过一系列具体的调整措施,成功地降低了数据库服务器的整体负载,提升了系统的响应速度与稳定性。以下将具体介绍本次优化工作的背景、采取的策略及其效果...
### 数据库性能调优技术——索引调优 ...综上所述,索引调优是一个细致且复杂的过程,需要根据具体情况灵活应用各种技术和策略。希望本文能够为读者提供一定的指导意义,帮助大家更好地管理和优化数据库性能。
这包括了解每个表的结构、主键索引情况、每个表的记录数、创建索引的列类型、索引的最后一次 rebuild 时间、索引中的空闲空间等。 二、分析 SQL 语句的执行计划 分析 SQL 语句的执行计划是调优的关键一步骤。可以...
- **一次只改变一个性能参数**:避免同时调整多个参数,以免难以判断哪些更改产生了效果。 - **架构与流程概览**:理解DB2的内部架构对于有效调优至关重要。 **1.6 架构与流程概览** DB2内部结构主要包括以下几个...
文档中还包含了修订记录,它说明了文档自2016年8月第一版发布以来,随着产品版本的更新和技术的发展,文档经历了多次修订和更新,反映了海思公司对于产品和技术不断改进和完善的态度。 总而言之,ISP图像调优指南是...
5. 经过第一次Minor GC后仍然存活的对象会被移动到Survivor区,并且每次GC后年龄+1。 6. 当对象年龄达到一定阈值时,会被移至老年代。 #### 五、年轻代中的GC 在年轻代中,JVM需要确保To Survivor空间为空。在每次...
4. rgw_gc_processor_period 这个控制多久时长以后 GCworker 开始下一轮的 GC 操作,如果单次 GC 需要操作的列表条目数较少,可以适当缩短这个时长。 GC 是 RGW 中的一种重要机制,可以有效地释放无用的对象占用的...
atime记录了文件最后一次被访问的时间,每次读取文件都会更新这一记录,这无疑会增加磁盘I/O操作。禁用atime可以通过编辑/etc/fstab文件实现,在相应的挂载选项中添加noatime参数。例如,将一个挂载为ext3文件系统的...
通过上述内容,我们可以看出Spark调优是一个复杂而细致的过程,不仅需要深入理解Spark的工作原理,还需要不断尝试和调整以达到最佳性能。此外,结合实际案例的学习也是提升Spark调优能力的有效途径。
2. **文档记录**:详细记录每一次调优过程及其结果,方便后续查询和回溯。 3. **备份计划**:在进行重大改动之前,做好完整的备份方案以防万一。 总之,《Sun Java System Application Server Enterprise Edition ...
在Java编程领域,性能调优是一项至关重要的任务,它能够帮助我们...记住,性能调优不是一次性的工作,而是一个持续的过程,需要不断地测试、分析和改进。只有这样,我们才能确保我们的Java应用程序始终保持最佳状态。
### 性能调优方案Arthus:一次真实的性能调优实践与探索 #### 一、性能调优的必要性及难点 **1.1 性能满足业务需求** 随着互联网技术的发展,用户对系统的响应速度、稳定性等性能指标提出了更高的要求。例如,在...
#### 性能调优过程 性能调优是一个迭代的过程,旨在识别并解决影响查询性能的问题。这个过程通常包括以下几个步骤: 1. **问题识别**:通过监控工具(如数据库监控工具)来识别慢查询。 2. **数据分析**:利用DBQL...
VMware vCenter Server是VMware虚拟化环境中的核心组件,它负责管理VMware ESXi主机和虚拟机,提供集中...然而,调优和监控工作并非一次性的任务,随着虚拟环境的不断变化和业务需求的增长,这些工作需要不断重复进行。