《理解 Linux 的处理器负载均值》阅读笔记续
有位同事把《理解 Linux 的处理器负载均值（翻译）》群发给了公司的tech团队，同事们纷纷加以评论，下面是对其中经典内容的收集和整理，如果有同学看到下面的内容似曾相识的话，请不要奇怪:-)。
- Google的工程师都知道, 如果Google面临同质竞争(导致upper line/广告收入的降低), Google最后的一个武器就是他们高效价廉的计算能力。Google自今年五月份以来公布关于其数据中心的技术细节, 其中包括他们高达80%的应用可以被GAE支持(动态部署), 免费冷却技术的大量使用, 极为优化的TPUE, 以及利用通用服务器(所以较为不易出现短板)来提高计算资源的平均利用率…..等项目, Google早已在2003年就开始有序地提高它的计算资源效率, 而这几个月公布的技术还是3-4年历史, 可见Google在计算资源效能的领先。
- 如看到cpu iowait达到70－80%, 系统run的进程只有1－2个，而load达到几十或者上百。 这个明显是有资源堵塞了，比如磁盘啊，网络啊，增加再多的CPU资源也无效。再一个极端情况，我们看到系统load是1.x，机器有4个核，可程序设计的垃圾，单线程，它只吃一个核, 不加机器或者提高频率就无法解决。所以有时候单独看load,或者单独看cpu利用率都不能的得出准确的答案，系统优化
和资源利用需要我们去持久的仔细分析。 - iowait不能简单的理解就是磁盘IO，其他的如内存IO，网络IO都会涉及到iowait.就我们的系统而言，网络IO出现磁盘和网络，且用nas方式连接到存储的，很容易就出现高iowait,典型的代表就是image应用。
- 还有合理的写磁盘，尽量使数据都压缩在同一block(操作系统)内，这需要对应用程序和操作系统同时做调整。
- 根据实际经验，iowait 70%还能跑但挺吃力了，load高都是io等待引起的，有必要通过增加磁盘等途径降低io压力。
- 多个磁盘并发操作来降低io等待时间。比如原来有两块盘来处理任务iowait很高，但是如果你增加到4块或6块盘并发操作，iowait是有一定的程度的下降的，具体下降多少还是要取决于io类型。转速是可以提高io速度，但是现在的单块普通硬盘极限值也就是170/s，oracle等数据库密集型io操作都是通过大量的磁盘来完成的。所以才会有热火朝天的ssd硬盘。
- 对于磁盘来说，在转速一定的情况下，一块磁盘承受的IOPS是固定的，因为io wait主要在于磁头寻道的时间。所以简单点看IO wait，要不就增加磁盘数量（提高IOPS），要不就系统增加cache（减少IO），别无他法。
- 对于CPU密集型的应用，可以很容易根据load值的大小决定是否需要增加CPU数量或者服务器数量。对于IO密集型的应用，如果系统load很高，cpu 利用率低，iowait非常高的话，建议修改程序架构（推荐，比如：引入cache机制等），或者升级存储设备（比如：利用SSD硬盘或者更高级别的存储）除了uptime外，top, vmstat 等也是非常重要的系统性能诊断命令。
- 应该更加关注应用的响应时间，注重通过性能优化等技术手段提升应用效率。加服务器虽然简单有效，但往往掩盖了软件本身的问题，而且潜在地造成了浪费。
- 很多WEB类应用是不能充分利用系统资源的。所以会推行虚拟机,也就是在一台物理机上跑多个虚拟机，比较适合于对网络和DISK IO要求不太高的应用。
