提醒：一大波工作任务正在袭来

[YANG Boyuan]

[OT]
相信大家的考试差不多都完了，你是否感到有些空余时间了呢？
不用担心，下面我来列出一部分待办事项，大家准备再次忙起来吧！

[正题]
1. 东区活动室的后续
1.1 钥匙问题
6月24日得到的钥匙一共有12把（2把原配+10把 fork）。为了便于管理，拿到钥匙的同学麻烦到
https://lug.ustc.edu.cn/wiki/lug/room-keys 登记一下，需要钥匙的同学请联系张光宇。
1.2 椅子问题
拿到活动室的时候只有三把椅子。不知道现在情况如何，如果还没有搬的话还是抓紧时间在8月真正放暑假之前把椅子配齐比较好。

2. 2014-09-20 SFD
按照往年的惯例，SFD 的准备应当从现在开始。寻找演讲嘉宾等等事情该起个头了 @Roy Zhang
欢迎有兴趣在 SFD 期间做客科大的朋友与我们联系。

3. 更新 Wiki
这个学期对不少基础服务有了改动，例如 LDAP、PXE、查询机等等，希望能把一学期以来的改动写一份备忘放在 lug wiki 中，方便以后参考和管理。

其它可以做的事情也是不少，例如 freeshell 常出的 OOM 和硬盘空间不足、freeshell 用户协议的更新、freeshell
服务邮件编码问题、mirrors 一些源同步失败问题、mirrors 磁盘性能问题、lug.ustc 新主页问题、LUG
书库的整理登记、向图书馆要机器、旧pxe服务器的处理等等，大家有空就一步一步来吧。对 LUG 的项目有兴趣的同学也可以参与进来，毕竟 LUG
的发展需要新生力量。

(PS:其实就是来催工的 :p

--
Boyuan Yang
<073...@gmail.com>

[Roy Zhang]

收到！正愁最近没活干呢…

> --
> -- 来自USTC LUG
> 请使用gmail订阅，不要灌水。
> 更多信息more info：http://groups.google.com/group/ustc_lug?hl=en?hl=en
>
> ---
> You received this message because you are subscribed to the Google Groups "USTC_LUG" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to ustc_lug+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Hao Wang]

工作狂。。。

Roy Zhang <pudh...@gmail.com>于2014年7月4日星期五写道：

[YANG Boyuan]

又想到了一些事情，不妨再列出来：
1. 公开课网上的视频和 slide 还有缺失，其中第7次（如何高效地找东西）给的视频却是第8次的。
列一下缺失的slides:
lesson9 （正则表达式基础）
lesson7 （如何高效地找东西）
麻烦演讲者补上。

2. 对 mirrors 添加软件源需求的处理
积攒下来的 request 有：
wenyinos (wenyinos.org)
LMDE (Linux Mint Debian Edition)
ubuntu-ports
XBMC (xbmc.org)
FreeBSD(pkg)
Sabayon Linux
msys2

有一些回复过，有些没有。

3. 版衫
看来这次又坑掉了……

[SJ Zhu]

版衫现在做，开学拿，合不合适？九月份还要穿短袖吗？
或者做些其他类型的衣服？不一定是T恤

(Sent from my mobile device.)

[Bojie Li]

话说，除了 T 恤还有什么衣服类型可做？

版衫为什么说又坑了？没找到做版衫的商家吗？

[Bojie Li]

虽然很久没碰 mirrors 了，还是想说两句。为什么申请源的请求都没有被处理？是因为磁盘阵列的性能问题吗？我的感觉是，申请添加的的源大多比较小众，占用的磁盘空间不多，访问量也不大，不容易给磁盘带来很多负载。只要没有版权问题，源不算太大，都可以添加。

我希望搞一个在线表单，用户可以提交 rsync、ftpsync 的源进去，系统自动尝试连接，如果连接成功就保存配置文件（但不启用）并发邮件给管理员，管理员如果认为可以添加，就到 mirrors 服务器上启用这个配置文件。这样可行吗？

2014-7-5 下午11:09于 "YANG Boyuan" <073...@gmail.com>写道：

[SJ Zhu]

做版衫的厂家可选teeker www.teeker.com，6月份我和他们联系过。不过这个可以再商量。

衣服还有就是卫衣吧

(Sent from my mobile device.)

[Bojie Li]

还有一些服务不应当被遗忘，比如 TimeMachine，PXE installer 和 Live 系统。我们目前只对 Web 服务的可用性做了监控，像 TimeMachine、PXE 之类的服务该如何监控？这是个有些挑战的问题。

Freeshell 和 blog 目前的用户协议缺失或者比较混乱，freeshell 首页上的文案和图片不合适，感兴趣的同学可以重写。

最近 freeshell、vpn 的一些问题几位同学比我发现或响应得早，这是非常赞的。但发现问题之后是否可以尝试解决？我的代码质量不高且没有留下足够的文档是根本问题，不过 debug 未知的系统也是一种能力。系统出现严重故障时，全球应急响应中心要以最快速度从数以百万行计的代码中定位故障、修复服务，这时候代码的作者可能在地球的另一端睡大觉呢。我自然没有资格做这种 24 小时待命的工作，但总要用到开源软件，有一些小众的软件质量并不很高，总不能发现软件有 bug 就坐等上游修复吧。思科网络认证考试据说是第一天把网络建好，晚上考官给你搞点破坏，第二天把网络修好。假如我在 blog 服务器上故意加一条错误的路由规则或 iptables 规则导致某部分网络不通，用户报 bug 之后，有多少人能修复？私以为 debug 比 coding 要求对系统更深刻和更细致的理解，比如 coding 只要牢记栈不要溢出，而 debug 则要脑补出爆栈后究竟会发生什么。

[Bojie Li]

学到个新词，涨姿势了！

吐槽：Google “卫衣”，广告第二条是 “360 手机卫士官方最新下载”，这是因为它们都有个 “卫” 字吗？

[Femrat]

弱弱问一句… Li说的是CCIE考试么……

[崔灏 (CUI Hao)]

关于“占用的磁盘空间不多，访问量也不大”这点，往另一方面想，如果“访问量不大”，那究竟有没有必要去加呢？我觉得加源还是得考虑需求的，科大学生对这个源需求有多大，国内 Linux 社区对个源需求有多大。

加源不管怎么说还是会带来一些额外的维护成本的（故障处理）。加一个没什么影响，那加十个呢，五十个呢？总是不能随意就加的。

一直说的停机检查，这个月就做了吧（立 deadline）。张荣葳、张光宇应该都在学校，我过一星期也就回校了。mirrors 虚拟机架构之类的问题，也可以一并处理了。

PS：我还不会加源呢，(￣_￣|||) 汗……

--
崔灏 / CUI Hao
Homepage: http://cuihao.tk/
Twitter: @cuihaoleo

[Yuanchong Zhu]

正好我也在，一起来做吧。mirrors也该做一次大修了。

灿烂星空，你就是我的英雄！

[Bojie Li]

Mirrors 为什么要停机检查？为什么要大修？

[Bojie Li]

好像是 2001 年以前的 CCIE…… 刚查了下现在的 CCIE 机考已经是一天了，形式估计也不一样了。不过通过这个考试不意味着就能胜任配置网络的任务，因为考试做对 80% 就行，但要是在生产环境配错 20% 的网络，那肯定要被开除了。不通过考试也未必不能配置网络，因为考的一些边角协议很可能用不到。考试费用这么贵，去考的都是土豪啊！

[Bojie Li]

我觉得以科大的带宽总量，真正价值很大的源我们反而加不了，比如 sourceforge。Linux 社区需求比较大的源就是几个大发行版了吧，mirrors 都已经做了，再加多少小发行版或开源软件，访问量之和都比不上大发行版的一个零头。

关于维护，我觉得也应该分等级，比如 Debian 这种重要的源，同步失败就应当给管理员发邮件；一些源同步不太稳定，那就设置成连续 24 小时同步失败就发邮件；剩下的不重要的源就在那里放着，什么时候管理员有空了再去 status 页面看看。所以哪怕 mirrors 增加 100 个不重要的源，维护成本也不会显著增加。

[Yifan Gao]

Bojie Li <boj...@gmail.com>于2014年7月6日星期日写道：

还有一些服务不应当被遗忘，比如 TimeMachine，PXE installer 和 Live 系统。

Timemachine （网站）正在做，届计划实现在线注册，状态监控，ldap绑定，双备份等功能。 

--
Yifan Gao(高一凡)

[Bojie Li]

2014-07-06 20:09 GMT+08:00 Yifan Gao <ylgao...@gmail.com>:

Timemachine （网站）正在做，届计划实现在线注册，状态监控，ldap绑定，双备份等功能。 

什么是双备份？ 

[Yifan Gao]

开启 2014年7月6日 at 下午8:43:17, Bojie Li (boj...@gmail.com) 写:

2014-07-06 20:09 GMT+08:00 Yifan Gao <ylgao...@gmail.com>:

Timemachine （网站）正在做，届计划实现在线注册，状态监控，ldap绑定，双备份等功能。 

什么是双备份？ 

将用户数据定期备份（实时难度有点大）到另一个硬盘，或另一台主机。

P.S. 由于Mac的文件系统和Linux文件系统并不相同，一般的同步软件（rsync）同步数据会丢失一些属性信息。netatalk的做法是借助BerkeleyDB来存储这部分信息。

[Thomas Copper]

双备份不会就是raid 1吧…

[Yifan Gao]

我倒是想。。。。。。

-- 
Yifan Gao

开启 2014年7月6日 at 下午9:07:47, Thomas Copper (univers...@gmail.com) 写:

[Bojie Li]

2014-07-06 21:02 GMT+08:00 Yifan Gao <ylgao...@gmail.com>:

将用户数据定期备份（实时难度有点大）到另一个硬盘，或另一台主机。

备份到哪台机器？现在 lug（除 timemachine 和给其他人用的 ftp 目录外），blog，gitlab 服务器每天凌晨都会增量同步到 mirrors 的磁盘阵列上，用的是 rdiff-backup。timemachine 不需要用 rdiff-backup，因为这个会保留文件的所有历史版本，timemachine 本来就是备份工具，除非打算提供 snapshot 功能，不需要保留历史版本。

[Yifan Gao]

TimeMachine （时间机器）是一个有历史版本记录的备份工具，它允许用户将电脑状态回退到过去的某个时间点（即乘坐TimeMachine回到过去）。因此TM的备份实际上是诸多备份的集合（增量的），所以rdiff-backup不太合适。

至于备份到哪，等做完再说吧

-- 
Yifan Gao

开启 2014年7月6日 at 下午9:09:32, Bojie Li (boj...@gmail.com) 写:

[Yifan Gao]

我发现迁移旧数据难度有点大。

由于当时分发账号时没有留下用户信息，因此难以将TM用户和LDAP用户对应起来，不知道大家有没有什么好办法(手工迁移除外)？

不过这个问题考虑得有点早。。。。

-- 
Yifan Gao

开启 2014年7月6日 at 下午9:16:32, Yifan Gao (ylgao...@gmail.com) 写:

[Thomas Copper]

Timemachine用户大部分都不是lug成员，不会涉及ldap的…

[Yifan Gao]

我打算将账户部分全部放在LDAP上，不再在本机建立用户。只是目前TM用户账户是UNIX账户，迁移不过去。

-- 
Yifan Gao

开启 2014年7月6日 at 下午10:32:41, Thomas Copper (univers...@gmail.com) 写:

[Guangyu Zhang]

数据备份可以考虑DRBD，基于网络的Raid 1

如果所有用户都是通过邮件申请的TM，那么可以翻翻邮件历史

[Bojie Li]

2014-07-07 12:55 GMT+08:00 Guangyu Zhang <zguan...@gmail.com>:

数据备份可以考虑DRBD，基于网络的Raid 1

DRBD 是不是要把已有的数据移出来，重新分区呢？

[Yifan Gao]

邮件历史估计有点难，因为发送邮件不会存在l...@ustc.edu.cn上。另一方面，最早注册的应该是在2012年，不知道l...@ustc.edu.cn上的收件箱是否还有保存用户的申请（即便保存了也不易与tmuser**之类的用户名对应）

-- 
Yifan Gao

开启 2014年7月7日 at 下午12:56:08, Guangyu Zhang (zguan...@gmail.com) 写:

如果所有用户都是通过邮件申请的TM，那么可以翻翻邮件历史

[Yifan Gao]

以前尝试过用DRBD镜像MySQL ，但就像boj说的，可能需要对硬盘重新分区，不知道lug.ustc.edu.cn好不好搞？

-- 
Yifan Gao

开启 2014年7月7日 at 下午12:56:08, Guangyu Zhang (zguan...@gmail.com) 写:

数据备份可以考虑DRBD，基于网络的Raid 1

[Bojie Li]

接收的邮件在 l...@ustc.edu.cn 都没有删除。Web 登录 l...@ustc.edu.cn，搜索 TimeMachine 申请邮件吧。

--

[Bojie Li]

MySQL 的数据库文件随时做个 snapshot，是一致的吗（也就是还能不能打开）？感觉如果不能的话数据库服务器突然掉电就危险了……不过我 rsync 出来的 MySQL 数据库文件经常是无法打开的，所以就 mysqldump 了。

--

[Yifan Gao]

一般是同时部署Heartbeat+DRBD+MySQL，实现故障节点自动隔离。另，DRBD已经被MySQL官方写入文档手册作为推荐的高可用的方案之一。

在 2014年7月8日星期二UTC+8上午12时52分31秒，Bojie Li写道：

[Bojie Li]

为什么不用 MySQL 自身的 primary + slave 方案？

[Yifan Gao]

只能说各有优势吧，这里有详细介绍：http://dev.mysql.com/doc/refman/5.5/en/ha-overview.html

在 2014年7月8日星期二UTC+8上午9时35分00秒，Bojie Li写道：

[Bojie Li]

我还是没看懂 MySQL Replication 和 DRBD 各有什么优势…… 主要是我不知道 DRBD 是怎么工作的，要是工作在块设备层的 DRBD 与 MySQL server 之间没有交互，那肯定是不行的，因为 MySQL 采用 DirectIO 访问存储设备，自己管理缓存，DRBD 悄悄更新一个块，MySQL 用的还是被缓存的旧数据。而且 MySQL 不是 append-only 存储，会不会存在数据不一致，比如数据库的一行跨越两个块，第一个块更新了，第二个块还没来得及更新，这时候正好来个读，读到的行就是不一致的。你知道这些问题是如何解决的吗？或者我的理解有误？

据我所知，MySQL Replication 有两种模式，一种是基于 statement 的，就是把每条 SQL 查询发到 slave 重新执行一遍，这里的缺点（1）如果写操作频繁，slave 的处理能力不如 master，则 slave 处的操作可能会排起长队（2）某些与系统状态相关或者使用了 UDF（User Defined Function）的语句不能被复制。另一种复制模式是基于 row 的，也就是 master 把改动的每一行发给 slave，缺点是日志量和传输的数据量比较大。DRBD 这种基于块设备的复制感觉跟 row-based MySQL replication 差不多吧，能比较它们的优缺点吗？

[Yifan Gao]

不知道我的理解有没有错，恳请大家指正：

-- 
Yifan Gao

开启 2014年7月8日 at 上午10:19:59, Bojie Li (boj...@gmail.com) 写:

我还是没看懂 MySQL Replication 和 DRBD 各有什么优势…… 主要是我不知道 DRBD 是怎么工作的，要是工作在块设备层的 DRBD 与 MySQL server 之间没有交互，那肯定是不行的，因为 MySQL 采用 DirectIO 访问存储设备，自己管理缓存，DRBD 悄悄更新一个块，MySQL 用的还是被缓存的旧数据。

DRBD只是忠实地同步硬盘数据，你可以想象成MySQL存储在一个RAID1设备上。（P.S.在同一时间提供服务的只有一个设备，slaver只有写操作；万一主从机写操作冲突，DRBD的冲突处理机制有3种可选）

而且 MySQL 不是 append-only 存储，会不会存在数据不一致，比如数据库的一行跨越两个块，第一个块更新了，第二个块还没来得及更新，这时候正好来个读，读到的行就是不一致的。你知道这些问题是如何解决的吗？或者我的理解有误？

 据我所知，MySQL的事物机制会保证数据的一致性，但master突然断电之类的，可能会出现读不一致的情形。我不清楚缓存机制在DRND+MySQL方案是怎么处理的，有没有人知道技术细节？求教~~

据我所知，MySQL Replication 有两种模式，一种是基于 statement 的，就是把每条 SQL 查询发到 slave 重新执行一遍，这里的缺点（1）如果写操作频繁，slave 的处理能力不如 master，则 slave 处的操作可能会排起长队

如果是基于日志的复制（Replication），要保证实时性，从机的配置应该与主机尽可能相同（包括CPU、内存、磁盘等）；但由于DRBD关心的只是数据，从机不用按照日志执行一遍SQL操作，只需网络和磁盘能力足够即可。

（2）某些与系统状态相关或者使用了 UDF（User Defined Function）的语句不能被复制。另一种复制模式是基于 row 的，也就是 master 把改动的每一行发给 slave，缺点是日志量和传输的数据量比较大。DRBD 这种基于块设备的复制感觉跟 row-based MySQL replication 差不多吧，能比较它们的优缺点吗？

DRBD本来不是为MySQL设计的，是通用的工具，可以用来热备整个应用，用起来比较方便（但Replication效率较高）。例如freeshell前台：如果用Replication做热备，那么用户上传的镜像等数据则需要单独使用一套热备机制，但DRBD则是一揽子解决方案

[Bojie Li]

是我想错了，MySQL + DRBD 是热备份方案而非负载均衡方案，也就是备份节点和主节点只能有一个工作（一般是配合 heartbeat 和 LVS，两个节点“共享” Virtual IP），不同于 MySQL replication，备份节点的 MySQL server 平时根本不开启，不承载任何请求，当然就没有读一致性问题了。MySQL replication 由于是应用层做的，不管是 statement-based 还是 row-based，都可以保证行的更新是原子操作，因此 slave 节点可以承载读请求，起到负载均衡的作用。

[Bojie Li]

2014-07-06 10:03 GMT+08:00 崔灏 (CUI Hao) <cuiha...@gmail.com>:

一直说的停机检查，这个月就做了吧（立 deadline）。张荣葳、张光宇应该都在学校，我过一星期也就回校了。mirrors 虚拟机架构之类的问题，也可以一并处理了。

刚问了下 Roy Zhang，说是要解决 mirrors 的磁盘阵列问题。我也觉得磁盘阵列的性能不到预期值的三分之一。磁盘阵列是 16 块 2 TB 硬盘（7200 rpm）做的 RAID 6。RAID 6 的读操作是没有 penalty 的，写操作有 6 倍的 penalty（每个写操作需要写 6 块磁盘）。然而磁盘阵列上的写很少，95% 以上是读。磁盘阵列以外其他磁盘是两块一组的 RAID 1，满载时的读 IOPS 可达 200 次/秒，这也比较符合每块 7200 rpm 磁盘 100 iops 的经验值。如此推算，磁盘阵列的读性能应该可达 1600 iops，但事实上只有 300~500 iops。这些指标可以用 iostat -x -t 5 命令看到，第一次输出不准，等 5 秒再看。

[Zhang Cheng]

2014-07-10 16:43 GMT+08:00 Bojie Li <boj...@gmail.com>:

刚问了下 Roy Zhang，说是要解决 mirrors 的磁盘阵列问题。我也觉得磁盘阵列的性能不到预期值的三分之一。磁盘阵列是 16 块 2 TB 硬盘（7200 rpm）做的 RAID 6。RAID 6 的读操作是没有 penalty 的，写操作有 6 倍的 penalty（每个写操作需要写 6 块磁盘）。然而磁盘阵列上的写很少，95% 以上是读。磁盘阵列以外其他磁盘是两块一组的 RAID 1，满载时的读 IOPS 可达 200 次/秒，这也比较符合每块 7200 rpm 磁盘 100 iops 的经验值。如此推算，磁盘阵列的读性能应该可达 1600 iops，但事实上只有 300~500 iops。这些指标可以用 iostat -x -t 5 命令看到，第一次输出不准，等 5 秒再看。

​iops不是唯一的指标，也要考虑throughput，比如顺序读写的时候，肯定是读写带宽比iops首先到瓶颈。throughput受影响的因素就比较多了，比如总线带宽、网络质量（iscsi的磁盘）、系统缓存等等。

ioutil达到100%时，iops不一定会到顶。所以从多个方面都分别调研一下吧，我也不是十分清楚这里面的情况。

另外，我还发现fio报告的数字不太准，但是我没有找到说明。比如今天我在ec2上测试ebs的ssd性能，fio的命令如下：

fio --name fio_test_file --direct=1 --bs=8k --size=1G --numjobs=16 --time_based --runtime=1800 --group_reporting  --randrepeat=0 --directory=/ssd/md0  --rw=randread​

fio的实时输出：

Jobs: 16 (f=16): [rrrrrrrrrrrrrrrr] [39.9% done] [105.5M/0K /s] [13.2K/0  iops] [eta 18m:02s]

但是iostat －x1看到的情况：

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util

xvde              0.00     0.00 3153.00    0.00 25224.00     0.00    16.00     1.68    0.53    0.53    0.00   0.25  80.00

xvdd              0.00     0.00 3061.00    0.00 24488.00     0.00    16.00    14.24    4.65    4.65    0.00   0.33 100.00

md0               0.00     0.00 6214.00    0.00 49712.00     0.00    16.00     0.00    0.00    0.00    0.00   0.00   0.00

可以看到iostat报告两个盘加起来总共只有6k的iops，但是fio却报告有13.2k（而且这个数字一直很稳定）。根据aws的说明，iostat的输出符合aws的限制（每块盘3k的iops）。另外，无论是fio的统计输出还是iostat的报告，都表示没有read merge。从throughput的数据看，fio报告的也是iostat报告的两倍多一点。

--

Cheng,

Best Regards

[Zhang Cheng]

2014-07-10 17:41 GMT+08:00 Zhang Cheng <steph...@gmail.com>:

ioutil达到100%时，iops不一定会到顶。所以从多个方面都分别调研一下吧，我也不是十分清楚这里面的情况。

​我大致看了一下，io util 大致等于 iops*svctm。下面是mirrors.ustc上刚才抓的一次输出：

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util

sdc               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00

sdd               0.00     1.00    3.00    3.00   384.00    12.00   132.00     0.00    0.00    0.00    0.00   0.00   0.00

sda               0.00     1.00    0.00   62.00     0.00  2528.00    81.55     0.19    3.10    0.00    3.10   0.19   1.20

sde               2.00     0.00  322.00    0.00 19740.00     0.00   122.61     2.24    6.94    6.94    0.00   2.91  93.60

sdf               8.00     0.00   88.00    0.00 10832.00     0.00   246.18     0.79    8.95    8.95    0.00   4.82  42.40

sdg               0.00     0.00    3.00    0.00   336.00     0.00   224.00     0.09   29.33   29.33    0.00  18.67   5.60

sdb              21.00     0.00  654.00    0.00 64756.00     0.00   198.03     2.26    3.43    3.43    0.00   1.10  72.00

dm-0              0.00     0.00    0.00   45.00     0.00   236.00    10.49     0.09    2.04    0.00    2.04   0.09   0.40

dm-1              0.00     0.00    3.00    0.00   336.00     0.00   224.00     0.09   29.33   29.33    0.00  18.67   5.60

dm-2              0.00     0.00  106.00    0.00 11136.00     0.00   210.11     0.89    8.38    8.38    0.00   4.00  42.40

dm-3              0.00     0.00  324.00    0.00 19616.00     0.00   121.09     2.26    6.98    6.98    0.00   2.89  93.60

dm-4              0.00     0.00    3.00    3.00   384.00    12.00   132.00     0.00    0.00    0.00    0.00   0.00   0.00

dm-5              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00

dm-6              0.00     0.00    0.00   18.00     0.00  2292.00   254.67     0.11    6.00    0.00    6.00   0.44   0.80

sdh              15.00     0.00  155.00   56.00 14240.00 23884.00   361.36    41.26   97.08   18.25  315.29   4.74 100.00

svctm（service time）是平均每次io操作的时间，单位毫秒，所以总的 io数*svctm ​表示在这一秒内有多长时间磁盘都在工作，如果整个一秒磁盘都在工作，说明磁盘满载了。如果iops很小，但是io util很大的话，说明svctm很大。svctm很大，可能是因为写的block很大（也就是吞吐率比较大），也可能是总线、网络的问题、阵列的问题，还有可能是其他原因，可以具体分析一下。

--

Cheng,

Best Regards

[Bojie Li]

fio 报告的数字不准的情况我没遇到过，测试的时候我都是一边开着 fio 一边开着 iostat 在看，不管是机械硬盘还是 SSD，fio 和 iostat 的数据都是比较相符的。你在物理机器上测试时，fio 与 iostat 也相差一倍吗？

对机械硬盘来说，ioutil 100% 时的 iops 与磁盘请求的并行度有关。并行度越高，也就是请求等待队列越长，磁盘径向相邻的请求的平均径向距离就越短，相邻两个被处理的请求之间，花在寻道上的时间也就会越短。当然并行度高到一定程度后，iops 的变化就不明显了，因为相邻两个磁盘请求的间隔基本上等于寻道时间 + 扇区旋转到磁头下面的时间，降低的只是前半部分，后半部分的期望始终是磁盘旋转半圈的时间。固态硬盘的情况我不了解。

mirrors 的 throughput 问题应该不大，因为 mirrors 跟磁盘阵列之间是千兆网卡（eth1），外部网络连接也是千兆网卡（eth0），磁盘阵列再快，取来了数据吐不出去也是白搭。只要使用了合适类型的总线（比如别用 USB 2.0 接 SSD），我觉得总线很难成为计算机系统的瓶颈，USB 3.0 500 MB/s，SATA 3.0 600 MB/s，PCI-E 3.0x1 984 GB/s，SSD 的吞吐量很少有到这么高的吧，除非一台机器上挂多块 SSD。PCI-E 3.0x16 有 128 Gbps，这跟内存的吞吐量都在同一数量级了：1600 MHz * 总线宽度 64 bit * 4 通道 = 410 Gbps（这还得用最新的 CPU 架构）。

2014-07-10 17:41 GMT+08:00 Zhang Cheng <steph...@gmail.com>:

--

[Yuanchong Zhu]

突然间发现mirrors上没开AHCI……然后蛋疼的找了篇phoronix的评测，可以凑合着看看：http://www.phoronix.com/scan.php?page=article&item=intel_linux_ahci&num=1

--
灿烂星空，你就是我的英雄！

[Zhang Cheng]

2014-07-10 20:14 GMT+08:00 Bojie Li <boj...@gmail.com>:

fio 报告的数字不准的情况我没遇到过，测试的时候我都是一边开着 fio 一边开着 iostat 在看，不管是机械硬盘还是 SSD，fio 和 iostat 的数据都是比较相符的。你在物理机器上测试时，fio 与 iostat 也相差一倍吗？

​不一定差一倍，不准的情况也不能稳定重现。我最近做了许多磁盘IO的测试，发现了许多情况下fio与iostat不符的情况。​

 

对机械硬盘来说，ioutil 100% 时的 iops 与磁盘请求的并行度有关。并行度越高，也就是请求等待队列越长，磁盘径向相邻的请求的平均径向距离就越短，相邻两个被处理的请求之间，花在寻道上的时间也就会越短。当然并行度高到一定程度后，iops 的变化就不明显了，因为相邻两个磁盘请求的间隔基本上等于寻道时间 + 扇区旋转到磁头下面的时间，降低的只是前半部分，后半部分的期望始终是磁盘旋转半圈的时间。固态硬盘的情况我不了解。

mirrors 的 throughput 问题应该不大，因为 mirrors 跟磁盘阵列之间是千兆网卡（eth1），外部网络连接也是千兆网卡（eth0），磁盘阵列再快，取来了数据吐不出去也是白搭。只要使用了合适类型的总线（比如别用 USB 2.0 接 SSD），我觉得总线很难成为计算机系统的瓶颈，USB 3.0 500 MB/s，SATA 3.0 600 MB/s，PCI-E 3.0x1 984 GB/s，SSD 的吞吐量很少有到这么高的吧，除非一台机器上挂多块 SSD。PCI-E 3.0x16 有 128 Gbps，这跟内存的吞吐量都在同一数量级了：1600 MHz * 总线宽度 64 bit * 4 通道 = 410 Gbps（这还得用最新的 CPU 架构）。

​理论上应该是这样的。我说的意思是，在trouble shotting的时候，​不要忽略这些情况。如果服务器到iscsi之间的网络质量有问题呢？磁盘的响应时间，也不要简单的拿寻道时间的概念来分析。比如写一个4k的block和8k的block，花在写上面的时间是不一样的。比如在复制一个电影文件的时候，iops肯定不是瓶颈，但io util肯定是100%，问题就是svctm比较大，每一次访问的耗时比较长。mirrors的硬盘在算吞吐率的时候不能光看网卡的吞吐率，磁盘阵列本身也不是不可能没问题。

--

Cheng,

Best Regards

[Bojie Li]

2014-07-10 21:40 GMT+08:00 Zhang Cheng <steph...@gmail.com>:

2014-07-10 20:14 GMT+08:00 Bojie Li <boj...@gmail.com>:

fio 报告的数字不准的情况我没遇到过，测试的时候我都是一边开着 fio 一边开着 iostat 在看，不管是机械硬盘还是 SSD，fio 和 iostat 的数据都是比较相符的。你在物理机器上测试时，fio 与 iostat 也相差一倍吗？

​不一定差一倍，不准的情况也不能稳定重现。我最近做了许多磁盘IO的测试，发现了许多情况下fio与iostat不符的情况。​

你觉得这可能是什么原因呢？

 

 

对机械硬盘来说，ioutil 100% 时的 iops 与磁盘请求的并行度有关。并行度越高，也就是请求等待队列越长，磁盘径向相邻的请求的平均径向距离就越短，相邻两个被处理的请求之间，花在寻道上的时间也就会越短。当然并行度高到一定程度后，iops 的变化就不明显了，因为相邻两个磁盘请求的间隔基本上等于寻道时间 + 扇区旋转到磁头下面的时间，降低的只是前半部分，后半部分的期望始终是磁盘旋转半圈的时间。固态硬盘的情况我不了解。

mirrors 的 throughput 问题应该不大，因为 mirrors 跟磁盘阵列之间是千兆网卡（eth1），外部网络连接也是千兆网卡（eth0），磁盘阵列再快，取来了数据吐不出去也是白搭。只要使用了合适类型的总线（比如别用 USB 2.0 接 SSD），我觉得总线很难成为计算机系统的瓶颈，USB 3.0 500 MB/s，SATA 3.0 600 MB/s，PCI-E 3.0x1 984 GB/s，SSD 的吞吐量很少有到这么高的吧，除非一台机器上挂多块 SSD。PCI-E 3.0x16 有 128 Gbps，这跟内存的吞吐量都在同一数量级了：1600 MHz * 总线宽度 64 bit * 4 通道 = 410 Gbps（这还得用最新的 CPU 架构）。

​理论上应该是这样的。我说的意思是，在trouble shotting的时候，​不要忽略这些情况。如果服务器到iscsi之间的网络质量有问题呢？磁盘的响应时间，也不要简单的拿寻道时间的概念来分析。比如写一个4k的block和8k的block，花在写上面的时间是不一样的。比如在复制一个电影文件的时候，iops肯定不是瓶颈，但io util肯定是100%，问题就是svctm比较大，每一次访问的耗时比较长。mirrors的硬盘在算吞吐率的时候不能光看网卡的吞吐率，磁盘阵列本身也不是不可能没问题。

--

Cheng,

Best Regards

--

[Zhang Cheng]

2014-07-10 22:34 GMT+08:00 Bojie Li <boj...@gmail.com>:

​不一定差一倍，不准的情况也不能稳定重现。我最近做了许多磁盘IO的测试，发现了许多情况下fio与iostat不符的情况。​

你觉得这可能是什么原因呢？

​我不知道。我给aws发了ticket，他们也很积极的做了许多同样的测试，但是似乎没有发现fio与iostat不一致的情况。我以前也没发现过，但这两天经常会发现。

fio统计的是自己issue出去的io操作数量，iostat统计的是最终发送给底层设备的io操作数量。在fio的参数中指定了direct=1，应该就已经避开了文件系统缓存，按理说应该没有地方会“吞掉”这些io，也就是不应该不一致。

而且我的这个结果中，不仅iops不一致，throughput也不一致，fio表示自己确实读出了一倍多的数据，这一点很奇怪。​

--

Cheng,

Best Regards

[Yuanchong Zhu]

fio统计的是自己issue出去的io操作数量——有没有可能别的程序也在做IO操作呢？

--

-- 来自USTC LUG
请使用gmail订阅，不要灌水。
更多信息more info：http://groups.google.com/group/ustc_lug?hl=en?hl=en

---
You received this message because you are subscribed to the Google Groups "USTC_LUG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ustc_lug+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
灿烂星空，你就是我的英雄！

[Zhang Cheng]

2014-07-10 22:50 GMT+08:00 Yuanchong Zhu <redsk...@gmail.com>:

fio统计的是自己issue出去的io操作数量——有没有可能别的程序也在做IO操作呢？

​现在是fio issue的数量比iostat看到的多，如果有别的程序在做io的话，一般来说iostat只会看到更多，不会更少。而且iostat种并没有看到io merge。​

--

Cheng,

Best Regards

[Yuanchong Zhu]

额……我想反了……

前面说的AHCI问题，如果最后决定停机维护的话，最好也调整一下，SATA盘不用AHCI作甚……

--

-- 来自USTC LUG
请使用gmail订阅，不要灌水。
更多信息more info：http://groups.google.com/group/ustc_lug?hl=en?hl=en

---
You received this message because you are subscribed to the Google Groups "USTC_LUG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ustc_lug+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
灿烂星空，你就是我的英雄！