一.业务背景+系统架构 本次场景为kafka+storm+redis+hbase,通过kafka的数据,进入storm的spout组件接收,转由storm的Bolt节点进行业务逻辑处理,最后再推送进kafka. 表数据相关的逻辑为:查询Hbase表数据,首次查询会写入redis和storm cache,再次查询,会直接从redis或cache中取值. storm应用: 二.性能测试场景 1.数据:json类型的用户偏好数据700万 2.灌入方式:java脚本 3.hbase表:生产全量数据导入…

问题背景 在业务使用redis过程中,出现了read timeout 的异常. 问题排查 直接原因 运维查询redis慢查询日志,发现在异常时间节点,有redis慢查询日志,执行sadd 命令花费了1秒钟.但由于redis是单线程应用,执行单条命令的阻塞,会造成其他命令的排队等候,导致read timeout. 深入排查-为什么sadd这么慢呢 为什么sadd这么慢呢?查阅redis文档看到,sadd操作的复杂度是O(1)的,实际使用本机docker搭建redis进行测试,使用脚本进行sadd,…

起因是本地为开发工程打包,总是提示 source 1.3 不支持注释.enum等等,但询问开发开发表示自己本地打包正常. 于是排查版本问题.开发的jdk是1.6版本,自己的是1.7,于是想要不降级吧,自己重新安装个1.6看看.有想法就有行动,闹心的行动. 下载一个64位JDK1.6后,没有拆卸原有的1.7,直接就安装了.闷声作大死,eclipse直接打不开了,提示: 使用window本身服务拆卸1.7时,可以正常拆卸,但是卸载1.6时,总会提示ddl寻找不到, 最后在网上找了个工具 your u…

Atitit. 最佳实践 QA----降低cpu占有率--cpu占用太高怎么办 跟个磁盘队列长度雅十,一到李80%走不行兰.... 1. 寻找线程too 多的.关闭... Taskman>>>show colomn  thread 资源管理器>>>cpu>>>看线程数.. 作者::老哇的爪子Attilax艾龙,EMAIL:1466519819@qq.com 转载请注明来源: http://blog.csdn.net/attilax 2. 关闭Flash…

背景 将log4j.xml的日志级别从error调整为info后,进行压测发现CPU占用很高达到了90%多(之前也就是50%,60%的样子). 问题排查 排查思路:  看进程中的线程到底执行的是什么,导致CPU占用较高. 1. 使用top命令查看到底是哪个应用占用的cpu比较高 左边的图是日志级别为info CPU较高的服务器, 右边为输出级别为error cpu正常的服务器. 2. 使用top -Hp pid 命令查看进程中的线程 可以看到左边运行中的线程比右边要多(实际上左边运行状态的线程常…

Q:  最近公司测试一个接口,数据库采用Mongo    并发策略:并发400个用户,每3秒加载5个用户,持续运行30分钟    数据量:8000条左右 压测结果发现:    TPS始终在5左右    而CPU高达99%,内存使用情况也高达1.7G    网卡流量145K 请问这种情况,是哪里的性能出现问题? A:你这个CPU和内存监控的得是web服务器 就是部署程序的机器.    1.尝试查看出现这类情况时候数据库process,看看是否是当时进程到达了所设置的进程数上限.如果是则调整数据库进…

首先查看nginx的error日志,无异常打印. cpu占用如下图所示: top - 10:05:40 up 233 days, 16:28, 4 users, load average: 25.53, 25.39, 21.62Tasks: 836 total, 20 running, 816 sleeping, 0 stopped, 0 zombieCpu(s): 51.8%us, 4.1%sy, 0.0%ni, 31.0%id, 6.1%wa, 0.0%hi, 6.9%si, 0.0%stM…

1.查看主进程占用cpu高: 此处主进程:27823 ~]# top top - :0: up days, :, 3 users, load average: 13.12, 13.31, 13.23 Tasks: total, running, sleeping, stopped, zombie %Cpu(s):100.0 us, 0.0 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem : total, free, used,…

原文:MySQL SYS CPU高的案例分析(二) 后面又做了补充测试,增加了每秒context switch的监控,以及SQL执行时各步骤消耗时间的监控. [测试现象一] 启用1000个并发线程的压测程序,保持压测程序持续运行,保持innodb_spin_wait_delay默认值不变 在10:17:14秒将innodb_spin_wait_delay值从默认值6调整为18,看到sys从40%降到20% TPS从1.7W增加到2W context switch从82W降到78W [测试现象二]…

原文:MySQL SYS CPU高的案例分析(一) [现象] 最近关注MySQL CPU告警的问题时,发现有一种场景,有一些服务器最近都较频繁的出现CPU告警,其中的现象是 SYS CPU占比较高. 下面的截图来源于“MySQL CPU报警”采集的文件 [问题分析] 可以分析出这服务器CPU升高的原因是由于表的高并发写入引起.优化方案通常是通知开发停止写入或降低写入频率. 究竟是什么原因导致高并发写入时CPU sys的占比这么高. 从采集的[Perf Stat]指标看到CPU有大量消耗是集中ke…