性能之巅的笔记(47)

>我来写笔记

按有用程度 按页码先后 最新笔记

  • 觋祉

    觋祉 (六根清净方为道,退步原来是向前)

    这个对着磁盘阵列大叫的使磁盘IO突然变慢的实验太让人吃惊了,虽然在加入物理震动的解释很合理,但让人突然感觉,磁盘也有生命似的:),对着你不喜欢的机器大叫吧,它是可以感觉到的!!! Greggs对着磁盘阵列大叫的那个视频地址https://www.youtube.com/watch?v=tDacjrSCeq4 太让人震惊的效果了,因为你知道的原因可能你看不到这个视频,下面是主要的截图 这个是greggs的大叫的方式   (1回应)

    2017-11-03 10:10   1人喜欢

  • maxy218

    maxy218

    翻译错误: 原文:This differs from /proc, which has evolved over time and had various system statistics added to the top-level directory 翻译:与/proc不同的是,/sys经过一段时间的发展,把各种系统信息放在了顶层目录 意思完全翻译反了。。。这么简单的从句。。。而且明显不是笔误,明显就是译者没看懂原文才会翻译成这样 这又是一本被翻译糟蹋的好书么?表示担忧

    2016-10-08 07:29   1人喜欢

  • 上上谦

    上上谦

    写之前看了一下之前的笔记还是5.30写的。这一章看了一个半月。。。 读完这一章开,始理解作者的表达方式,开始理解性能分析的基本思维方式,开始觉得书虽然写的不咋地,但作者是真的牛p. 包括这一章在内,整体的体验就是,内容好多,都很有用,但是找不到重点。特别是,作者可能是害怕读者不理解自己在说什么,所以每章之前都会介绍很多基础知识。但是读完的感觉是,原来就会的东西,看完了没什么新理解,原来就看不懂的东西,...

    2019-07-17 00:41

  • 上上谦

    上上谦

    其实挺奇怪,从第六章开始就详细介绍各个指标的细节了。为什么在这之前还能插进三章的篇幅。本来以为可能是想在深入细节以前,先介绍一些思维方式之类的。结果看完三章以后。我唯一的感觉是: Dtrace 真是个好东西。。。 越来越怀疑,有可能整本书都是这个工具的广告。后边各个章节其实都是在用这个工具秀操作 ================================================= 第三章 操作系统 没有读到什么有意思的东西 1. 对称多处理器,...

    2019-05-30 00:09

  • 上上谦

    上上谦

    本章可以分为三个部分:2.5之前、2.5和2.5之后。之所以这么说是因为如果删掉2.5的话,好像内容也没什么区别。。。 译者的操作也是犀利,居然能创造出“讹方法”这么牛逼的词。 首先是2.5之前,讲了一些比较有意思的,浅显易懂的概念。就是有点意识流,想到什么讲什么,看完基本就全忘了: 1.不理智的人扭曲事实来适应理论,而不是改变理论来适应事实 2.cpu与内存的关系。这个地方非常有意思:内存能缓存计算结果,降低cpu的使用...

    2019-05-27 23:05

  • 上上谦

    上上谦

    一本书,竟然有6个推荐序,里边各种夹带私货也是醉了。。。。 绪论虽然只有12页,比起前边将近40页的推荐有用多了。再次说明了吹一万次牛逼都不如秀一次操作。。。 第一章内容不多,但是都挺有意思的,下边这些内容,让人很期待后续: 1.首先是“容量规划”,希望看完这本书以后,能够知道如何在软件开发时,就定义资源的占用情况,还有开发中如何定义监控 2.性能分析的两种视角:负载分析和资源分析,虽然感觉跟说了一句废话一...

    2019-05-20 23:58

  • 2sin18°

    2sin18° (维天之命,于穆不已)

    1.9.2 方法论: 注:rt 直接翻译成回归测试比较费解,也许叫做缺陷收敛测试更合适。同样,文中的 nrt 与其翻译成非回归性测试不如叫做性能进步测试。 首先,需要用一个基准测试来定量刻画系统的性能。基准测试包括多样的,且逐渐增长的workload,系统的workload处理能力指标,以及通常被忽视的resouce占用情况。 然后,自动化基准测试,可视化展现以发现insights。对于指标增长需要更多解释。测试本身也有可能是问题来源。

    2018-02-19 11:13

  • 2sin18°

    2sin18° (维天之命,于穆不已)

    1.9.1 方法论: 首先,定量确认问题。use方法的问题是resoyrce类型很多,一开始通常只会聚焦在cpu,memory,disk,nic的关键指标上。这里一开始只看了cpu和disk。问题确认,是disk层次的workload过高。 然后,问题分析。在e2e的workload么有明显变化的情况下,disk的workload变高了,同时cpu没有变高(也就是说usercall没有增加,syscall没有增加,那问题应该出现在os内部机制上。 最后,问题定位。os内部如何处理disk workload...

    2018-02-19 00:00

  • 2sin18°

    2sin18° (维天之命,于穆不已)

    性能问题的本质是特定workload与特定resouce的utilization/saturation下性能指标达不到预期。 这里存在许多疑问。首先,如何定量刻画并复现问题场景?workload如何测量?resouce在device层次还是在os层次还是在app层次?如何测量?然后,resource之间如何互相影响?关键点在哪里?最后,性能指标如何与resource的指标关联?是否可以转化为用latency来衡量? 动态追踪的一个主要障碍是对linux的版本要求较高。没有systemtap,用p...

    2018-02-18 23:43

  • 觋祉

    觋祉 (六根清净方为道,退步原来是向前)

    这里是use方法中使用率(接口用于接收和发送帧的时间)和饱和度(由于接口满负载,额外的队列,缓冲或者阻塞的程度)的度量方式, 使用nicstat 命令中sat 反映此接口的饱和度,%util 为最大使用率可以直接查看,这个nicstat 没有在stat包中要单独安装请注意!

    2017-12-22 16:42

<前页 1 2 3 4 5 后页>

笔记是你写在书页留白边上的内容;是你阅读中的批注、摘抄及随感。

笔记必须是自己所写,不欢迎转载。摘抄原文的部分应该进行特殊标明。

性能之巅

>性能之巅