前言

经常做系统分析会接触到很多有用的工具，比如 iostat,它是用来分析磁盘性能、系统 I/O 的利器。

本文将重点介绍 iostat 命令的使用，并分析容易引起误解的几个指标。

iostat

iostat - Report Central Processing Unit (CPU) statistics and input/output statistics for devices and partitions.

上面是 man 手册关于 iostat 命令的介绍，非常简单明了。iostat 是我们经常用来分析 cpu 负载和磁盘 I/O 情况的工具。

iostat 基本使用

常用命令（个人习惯）：

1

iostat -xk 2 10

参数的解释可以查看 man 手册：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

OPTIONS
       -c     Display the CPU utilization report.
       -d     Display the device utilization report.
       -g group_name { device [...] | ALL }
              Display statistics for a group of devices.  The iostat command reports statistics for each individual device in the list then a line of global statistics for the group displayed as group_name and made  up  of  all  the
              devices in the list. The ALL keyword means that all the block devices defined by the system shall be included in the group.
       -h     Make the Device Utilization Report easier to read by a human.
       -j { ID | LABEL | PATH | UUID | ... } [ device [...] | ALL ]
              Display  persistent  device  names.  Options  ID,  LABEL,  etc.  specify  the type of the persistent name. These options are not limited, only prerequisite is that directory with required persistent names is present in
              /dev/disk.  Optionally, multiple devices can be specified in the chosen persistent name type.  Because persistent device names are usually long, option -h is enabled implicitly with this option.
       -k     Display statistics in kilobytes per second.
       -m     Display statistics in megabytes per second.
       -N     Display the registered device mapper names for any device mapper devices.  Useful for viewing LVM2 statistics.
       -p [ { device [,...] | ALL } ]
              The -p option displays statistics for block devices and all their partitions that are used by the system.  If a device name is entered on the command line, then statistics for it and all its partitions  are  displayed.
              Last,  the  ALL  keyword  indicates  that  statistics  have to be displayed for all the block devices and partitions defined by the system, including those that have never been used. If option -j is defined before this
              option, devices entered on the command line can be specified with the chosen persistent name type.
       -T     This option must be used with option -g and indicates that only global statistics for the group are to be displayed, and not statistics for individual devices in the group.
       -t     Print the time for each report displayed. The timestamp format may depend on the value of the S_TIME_FORMAT environment variable (see below).
       -V     Print version number then exit.
       -x     Display extended statistics.
       -y     Omit first report with statistics since system boot, if displaying multiple records at given interval.
       -z     Tell iostat to omit output for any devices for which there was no activity during the sample period.

简单讲，-x 参数能比较详细的给出一些指标，2 代表间隔时间为 2s，统计输出 10 次。

最近挺火的微信跳一跳

最近新版微信的『跳一跳』小程序着实火了一把，也把小程序这个概念再次推波助澜了一波，看来以后小程序这个入口会有大作为。

张小龙：一个好的 APP 应该是用完即走的。

这句话对用户来说是个好消息，对其他创业者来说却可能会招来恶语相向。现在这个时代的步伐越来越快，大家好像都很忙，时间越来越珍贵。如果以后微信真的把小程序这个入口做好了，我觉得对于用户来说，是件好事，当然前提是做好了，比如安全性啥的，比如不会被外挂啥的！

现在中午，吃完饭没事大家都会高呼 “来一波！来一波！”，就是微信小游戏『坦克大战』，3V3 玩得不亦乐乎！

废话不多说，看着别人微信跳一跳几百分那么高的分，感觉坐不住了，为了装逼，所以有了这篇博文！

林夕水共是我，这是目前能让好友看到的最高分

前言

问题的提出是为了精细化提高 nginx(marxxx) 的性能，遂分析写日志对于请求的影响，上一篇《nginx写日志对于响应速度的影响探究（一）》中其实提出了两个问题还有待研究：

• log buffer 分别为 4k、64k、128k 不同情况下，相较而言 log buffer 为 64k 时 nginx 性能表现更优，这里的表现指 cpu 压满情况下 qps 更高。so why ?
• request time 成周期性波动，周期为 60s，即大概每 60s request time 会出现一个突峰，如下图。so why ？
  

写在前面

今天是 2018 年 01 月 04 号，已经是 2018 年的第四天了，最近这几天一直在做年终总结，回顾自己整年的工作，成长，问题，计划新的一年。2017年对于我来说，”tough year”!发生了太多的事，太多太多的事，开心的，烦恼的，2017年初计划的事情没有一件让我自己满意，想想嘘嘘不已！

这几天好好的写一篇总结！2018年对我来说，很重要！

回顾一下

上一篇文章 CPU.IOWAIT 偏高问题中其实已经大致分析出了问题所在。

文中『Find The Murderer』章节也指出了可能造成 IOWAIT% 偏高的进程，但不够有说服力。故此文尝试进一步的分析造成 IOWAIT% 偏高的原因！

问题描述

小米监控发现我自己的一台机器的cpu.iowait偏高，波动很严重。

惯例闲聊

现在是杭州的冬天，鼻炎让我一直难受，特别不舒服，鼻子快被我拧坏了，最近过的也很糟心，各种烦心事，几乎一周一件烦心事甚至一周好几件烦心事，最近过得感觉很不好！以前我感觉我自己很潇洒，很酷，现在越来越发现我不酷了，连自身形象我都懒得去整理了，胡子一周不想剃，衣服放一周不想洗，头发每天乱糟糟的，几乎每天都不敢去看镜子了。

真的很不喜欢冬天！不喜欢冷！不喜欢浑浑噩噩！不喜欢越来越没激情！

这已经是2017年的最后一个月了，回想年初定下的目标，几乎没有一件事达成或满意，一直想学的茶道一直也没去做，茶具也没买，骑车这件大事也慢慢落下了，身体也慢慢垮了，唯一感觉工作本身成长很大，这样下去不行的！

好了，废话不多说，这篇博文是完完全全的工作内容，所以内容会很技术，很严肃很干货。

问题提出

为了精细化提高 nginx(marxxx) 的性能, 现分析写日志对于请求的影响。

• 条件

1. 日志大小为 500 字节
2. 响应大小 111 字节
3. 除日志外 nginx 服务不进行任何 io 操作，使用 nginx 语法直接返回响应

• 变量

1. qps服务压力了决定的磁盘承受的写日志的压力
2. request time分布
3. nginx log buffer: 分别测试 log buffer 为 4k, 64k, 128k 以及关闭log的情况

探究结论

杭州天气变冷了

最近杭州的温度下降的有点多，提前进入冬天的节奏，鼻涕不停的流。相对冷，我更喜欢热。冷真的让我受不了，杭州可还算是南方啊！

好久也没写博客了，这段时间一直在忙工作的事情，甚至都没顾上自己的生活。也好久没去骑车了，天气变冷了，身体也越来越垮了。想想下个月5号还有一场180KM的骑行比赛，腿上顿时一阵抽搐，该练练腿了。

该平衡下工作和生活了。没事骑骑车，写写博客了。好了废话不多说，今天分享的是拉取小米监控(open-falcon)历史监控数据。

open-falcon是个啥?

正如官网介绍的那样，open-falcon是一个分布式的、高性能的互联网企业级监控系统。

最近好忙

最近这段时间工作上很忙，几乎是没有时间照顾到自己的生活，有时候甚至废寝忘食，虽然挺享受这个过程的，但是感觉身体慢慢垮了下去，好久也没骑车了。

今年元旦定下的骑车计划目前看来是完不成了，计划完成2000公里，目前只骑了200多公里，而现在已经是快9月份了，离明年元旦也没几个月了。

哎…生活和工作真的平衡不了么？

好了废话不多说，今天分享的是使用python来操作es，包括数据的插入，查询，拉取，删除等。

Elasticsearch?

唠里个叨

关于python的笔记，比较杂，想到啥就说啥。

文件读写

官方文档: open

这是python内建的函数，基本用法如下：

hfile  = open(file_name [, access_mode][, buffering])

其中access_mode表示打开的模式，常用的如下：

举例如下：

为什么有这么一出

最早接触到数据可视化应该是大学的时候了吧，那个时候使用的工具是matlab,可以用matlat对数据进行分析，进行可视化。但是那个时候总觉得matlab很难用，或者说matlab的代码不太友好，不过我现在也基本忘记了具体怎么使用matlab了。

工作的原因，需要利用监控数据进行软件性能的定标，这个过程就需要用到数据可视化。把海量的数据进行分析，然后可视化，或者可视化然后分析，也算数据挖掘的范畴吧。具体内容是，拉取小米监控(open-falcon)的历史数据，然后分析CPU,QPS,BandWidth之间的关系。

选择了matplotlib

数据可视化工具有很多，各种语言的也不一样。我的老本行是使用c/c++，这方面的类库好像很少，正好，刚入门了python，python的第三方库很丰富，数据可视化方面的类库也很丰富，说出来的有Pandas、Seaborn、ggplot、Bokeh、pygal、Plotly、matplotlib,详细可以查看这篇文章。最终选择了matplotlib作为我的数据可视化工具，原因很简单，我分析了自己的需求，需要实现坐标图，可能涉及动画，可能涉及3D，可能涉及散点图等，同时网上关于matplotlib的例子很丰富，官网上的例子也很详尽，上手应该很容易，所以最终选择了matplotlib。

关于matplotlib的介绍，官网如是说：