网站性能着急,怎么定位性能瓶颈进行优化

2018-10-10 15:18:15 +08:00
 seraphv3

公司的网站大约有 180 用户使用,从监控工具听云来看,目前性能吃紧,需要优化。但是没有找到是什么导致了现在的性能吃紧,性能瓶颈在什么地方,向各位大神求助。

目前在 3 台阿里云机器上部署了 3 个 tomcat 实例,用的 nginx 做负载均衡。机器都是 8G 内存,分配了 4G 给 tomcat 的 JVM。网站用到了 mongodb,mysql,redis,3 个 tomcat 用的是同一个数据库。以前出现过 mongodb 性能瓶颈,加了索引之后解决了;还出现过 redis 性能瓶颈导致网站崩溃,切换了阿里云的专用 redis 服务器也解决了;还出现过代码问题导致的 OutOfMemoryError,也优化了。但是现在听云显示的是主要响应时间是在应用层时间上,应用层时间我理解是 CPU 占用的时间,但 CPU 占用率不到 50%,不应该花这么长时间。而且 3 台实例的响应时间统计基本是同步地时间变长变短。看慢请求列表,也是一些普通的不占什么资源的请求。

问下各位大神有什么优化思路。

下图是听云截图

5822 次点击
所在节点    Java
37 条回复
likuku
2018-10-10 18:38:30 +08:00
@seraphv3 [是一个集成了呼叫中心的 CRM 系统,主要是处理名单列表查询、活动统计(活动就是一组名单)、名单呼叫历史查询、工单列表查询等操作,做成多租户的,多的企业有 50000+名单。代码的话我再检查下]

我懂了,很类似我工作的某前司的业务。

看似客户少,但可能有的客户数据量巨大,且是这种企业工具型应用,在白天工作日很容易出现高峰,尤其早晚上下班高峰,工作日还常遇到处理大量数据的 SQL 长查询。

实际经验,建议多关注数据库,MySQL 开 slow log 记录慢查询,有针对性优化。

每客户都是单独库么? MySQL 都是 InnoDB 这种行级锁的现代表么(别觉的我问得傻,因为我遇到过)?
数据库假若不是云数据库,那么你数据库机器上,数据库文件落地的磁盘 IO 够不够快?是否都是 SSD 的?

有条件,建议按不同客户优先级(重要性 /付钱多少 /难搞程度) 分到优先级 /性能 不同的 独立数据库机器上。
likuku
2018-10-10 18:43:37 +08:00
#21 补充,之前遇到某新分支业务开发到上线很久都是 MyISAM,虽然都 21 世纪好多年了,还有人默认用它。
sampeng
2018-10-10 18:48:15 +08:00
看慢 sql。

应用慢那就要看一下是不是线程堵塞。。这个就很复杂的故事了。。。因为在云上。你的 mysql 装在实例上。。本身阿里云的 io 也是跟屎一样。。。所以说不清是 mysql 问题还是你代码问题。但你还有 redis 缓存。像种种企业应用。应该大部分数据都缓存命中才是。。。
zealzz
2018-10-10 18:49:01 +08:00
建议你还是做一个性能压测试,基本上能暴露短板,这样可以针对性的优化。以前用的 MySQL 数据都跑到亿的级别了,照样跑很流畅。之前遇到过的问题,大部分都是数据库首先成为瓶颈。这时读写分离、分区、分表实在不行就分库。
sampeng
2018-10-10 18:53:39 +08:00
redis 使用也要注意。。别存大 hash。或者一次性取一堆。。redis 是单线程的。不然你取的时候其他 client 都得等着。。这也会出现尖峰。

信息太少。。不好分析。。。
MeteorCat
2018-10-10 18:59:39 +08:00
htop 看下内存占用情况,是 mysql 负载大还是 java 负载大,3 个 tomcat 访问一个数据库是做 dao 吗?
seraphv3
2018-10-10 20:02:58 +08:00
@sampeng 我们确实存了大的 hash,但是取的时候已经改成了只取 hash 里面的一条数据,这应该是可以的吧?
yzkos
2018-10-10 21:22:03 +08:00
上面不是有慢事务追踪列表?
上面的每个都执行高达十几秒,看看是不是慢事务里的请求拉低了 Apdex 指标;
排查一下慢事务追踪列表里的执行时间是不是正常的;
dnsaq
2018-10-10 22:54:12 +08:00
目测是使用不当导致的 不说所有服务单个服务真正会用到极致的人都不多
dnsaq
2018-10-10 22:55:23 +08:00
主要是开发使用上,感觉和机器配置无关
metrxqin
2018-10-10 23:11:35 +08:00
愿意付费优化可以私信我。
watch
2018-10-10 23:23:13 +08:00
页面太大了吧 cdn 用上了么
qfdk
2018-10-11 00:27:27 +08:00
数据库查询咋写的 分页那边不会是 offset 之类的吧……
akira
2018-10-11 00:40:03 +08:00
看第一张图 redis 这里有点 问题 啊...
既然你是用了阿里云的,那就看看 redis 的性能监控,目测带宽数据有惊喜
lbp0200
2018-10-11 10:39:06 +08:00
可能一次请求要从 redis 读几个 G 的数据
sampeng
2018-10-11 10:44:05 +08:00
@seraphv3 这样应该没问题。不要一次性从 redis 取一坨东西。。带宽数据有惊喜。。尤其是事务处理上。。。
如果事务处理是写事务。加个队列。异步写好了。。。
cabing
2018-10-14 20:38:46 +08:00
180 日活,量很小啊。
数据库确实有点慢啊。不至于啊。我觉得几十 ms 就了不起了啊。
如果有 redis,redis 读写应该很快啊。几毫秒。。。
也可能是 dns,io 或者带宽有问题吧
可以看看服务器整体有啥问题。cpu,内存,磁盘 io,带宽,做个整体监控。。sar 命令就行。或者装个监控软件

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/496341

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX