性能测试实战30讲
高楼
前HP高级性能专家,7DGroup创始人
立即订阅
4922 人已学习
课程目录
已完结 36 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词丨“老板,之前咱TPS是100,我优化完是10000”
免费
第一模块:性能测试基础篇 (6讲)
01丨性能综述:性能测试的概念到底是什么?
02丨性能综述:TPS和响应时间之间是什么关系?
03丨性能综述:怎么理解TPS、QPS、RT、吞吐量这些性能指标?
04丨JMeter和LoadRunner:要知道工具仅仅只是工具
05丨指标关系:你知道并发用户数应该怎么算吗?
06丨倾囊相授:我毕生所学的性能分析思路都在这里了
免费
第二模块:性能测试工具及性能场景篇 (9讲)
07丨性能测试工具:如何录制脚本?
08丨案例: 手把手教你编写最简单的性能脚本
09丨关联和断言:一动一静,核心都是在取数据
10丨案例:在JMeter中如何设置参数化数据?
11丨性能脚本:用案例和图示帮你理解HTTP协议
12丨性能场景:做参数化之前,我们需要考虑什么?
13丨性能测试场景:如何进行场景设计?
14丨性能测试场景:如何理解业务模型?
15丨性能测试场景:如何进行监控设计?
春节策划 (2讲)
春节策划丨性能评估和性能分析试题,等你挑战!
春节策划丨快来挑战一下自己的分析逻辑吧!
第三模块:性能监控分析工具篇 (10讲)
16丨案例:性能监控工具之Grafana+Prometheus+Exporters
17丨CentOS:操作系统级监控及常用计数器解析(上)
18丨CentOS:操作系统级监控及常用计数器解析(下)
19丨Java & C ++:代码级监控及常用计数器解析(上)
20丨Java & C ++:代码级监控及常用计数器解析(下)
21丨Tomcat:中间件监控及常用计数器解析
22丨MySQL:数据库级监控及常用计数器解析(上)
23丨MySQL:数据库级监控及常用计数器解析(下)
24丨Kafka:性能监控工具之队列级监控及常用计数器解析
25丨SkyWalking:性能监控工具之链路级监控及常用计数器解析
第四模块:性能测试分析实战篇 (7讲)
26丨案例:手把手带你理解TPS趋势分析
27丨案例:带宽消耗以及Swap(上)
28丨案例:带宽消耗以及Swap(下)
29丨案例:如何应对因网络参数导致的TPS呈锯齿状?
30丨案例:为什么参数化数据会导致TPS突然下降?
31丨案例:当磁盘参数导致I/O高的时候,应该怎么办?
32丨当Postgres磁盘读引起I/O高的时候,应该怎么办?
结束语 (1讲)
结束语丨见过林林总总的乱象,才知未来的无限可能
性能测试实战30讲
登录|注册

32丨当Postgres磁盘读引起I/O高的时候,应该怎么办?

高楼 2020-03-04
在性能分析的人眼里,性能瓶颈就是性能瓶颈。无论这个性能瓶颈出现在代码层、操作系统层、数据库层还是其他层,最终的目的只有一个结果:解决掉!
有人可能会觉得这种说法过于霸道。
事实上,我要强调的性能分析能力,是一套分析逻辑。在这一套分析逻辑中,不管是操作系统、代码还是数据库等,所涉及到的都只是基础知识。如果一个人都掌握这些内容,那确实不现实,但如果是对一个性能团队的要求,我觉得一点也不高。
在性能测试和性能分析的项目中,没有压力发起,就不会有性能瓶颈,也就谈不上性能分析了。所以每个问题的前提,都是要有压力。
但不是所有的压力场景都合理,再加上即使压力场景不合理,也能压出性能瓶颈,这就会产生一种错觉:似乎一个错误的压力场景也是有效的。
我是在介入一个项目时,首先会看场景是否有效。如果无效,我就不会下手去调了,因为即使优化好了,可能也给不出生产环境应该如何配置的结论,那工作就白做了。
所以要先调场景。
我经常会把一个性能测试项目里的工作分成两大阶段:

整理阶段

在这个阶段中,要把之前项目中做错的内容纠正过来。不止有技术里的纠正,还有从上到下沟通上的纠正。

调优阶段

这才真是干活的阶段。
在这个案例中,同样,我还是要表达一个分析的思路。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《性能测试实战30讲》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(6)

  • 罗辑思维
    分享下自己学习体会:
    为什么缓存可以加速I/O的访问速度?
    老师说的缓存应该有两个:操作系统的缓存和PostgreSQL的缓存。它俩作用都是为了把经常访问的数据(也就是热点数据),提前读入到内存中。这样,下次访问时就可以直接从内存读取数据,而不需要经过硬盘,从而加速I/O 的访问速度。

    因为没接触过PostgreSQL,在做思考题时找了些资料,下面是延伸的学习。
    PostgreSQL缓存跟操作系统的缓存有啥联系?

    1.在访问数据时,数据会先加载到操作系统缓存,然后再加载到shared_buffers,这个加载过程可能是一些查询,也可以使用pg_prewarm预热缓存。
    2.当然也可能同时存在操作系统和shared_buffers两份一样的缓存(双缓存)。
    3.查找到的时候会先在shared_buffers查找是否有缓存,如果没有再到操作系统缓存查找,最后再从磁盘获取。
    4.操作系统缓存使用简单的LRU(移除最近最久未使用的缓存),而PostgreSQL采用的优化的时钟扫描,即缓存使用频率高的会被保存,低的被移除。

    PostgreSQL缓存读顺序share_buffers -> 操作系统缓存 -> 硬盘。那么也可能是操作系统缓存不足,而不定是share_buffers。通过文章中vmstat命令看到cache有260G,free值也很稳定,所以应该检查PostgreSQL的缓存。(老师执行vmstat是不是埋了个伏笔)。

    参考资料
    https://www.cnblogs.com/zhangfx01/p/postgresql_shared_buffer.html
    https://blog.csdn.net/kwame211/article/details/78665999

    作者回复: 认真的同学,必须赞!

    2020-03-05
    1
  • 你比昨天快乐🌻
    酣畅淋漓,看完了,有种跃跃欲试的感觉,难道是幻想,哈哈

    作者回复: 要的就是这份骚动。😀😀

    2020-03-24
  • kubxy
    老师,在分析过程中,对数据量的计算是否不准确?
    磁盘的块大小为4096B,那么30万个磁盘块的数据量应该是:
    300,000 * 4096B / 1024 / 1024 = 1172M

    作者回复: 这个不是30万个block。而是kB,你看上面的标头。

    2020-03-16
    1
  • 。。。
    继续打卡

    作者回复: 坚持学习是唯一进步的方式。

    2020-03-12
  • 月亮和六便士
    老师,1jmeter tps是150 2jmeter tps是200能说明什么? 在场景对比中增加jmeter数量我怎么觉得是压力不够呢,怎么能说明server哪个节点有瓶颈

    作者回复: 你觉得压力不够就再加压力看tps能不能增加。

    2020-03-04
  • Geek_65c0a2
    刚开始分析时使用vmstat,发现bi高。
    如果这时看top命令的话,iowait应该也高吧?

    作者回复: 是的,iowait在top中也可以看到,只是在这个例子中没有用top这个命令分析而已。

    2020-03-04
收起评论
6
返回
顶部