6.1. 微性能测试列表

这一章包含了一些在 FreeBSD 上或者 FreeBSD 自身做适合的微性能测试的建议。

要在每一次单独的测试的时候使用所有我们给出的建议是不可能的。 但是你用得越多，你测试小差别的能力就会越好。

• 关闭 APM 和任何其他干扰时钟的东西 (ACPI ?)。

• 进入单用户模式。例如，cron(8) 和其他的守护进程只会增加测试的不准确性。sshd(8) 这个守护进程也会造成问题。如果在测试的时候需要 ssh 连接， 那么你或者关闭 SSHv1 的密匙再生功能，或者在测试的时候杀死 sshd 父进程。

• 不要运行 ntpd(8)。

• 如果有 syslog(3) 事件发生，使用一个空白的 /etc/syslogd.conf 运行 syslogd(8)， 或者，不要运行它。

• 最小化磁盘 I/O，可能的话，要完全避免。

• 不要挂载不必要的文件系统。

• 可能的话，把 /， /usr， 和其他任何文件挂载为只读。 这样的话可以从 I/O 方面去掉到磁盘的异步更新(等等)。

• 使用 newfs(8) 来生成要测试读写的文件系统。 在每次测试运行前使用 tar(1) 或者 dump(8) 给测试文件系统灌输文件。测试开始前先卸载文件系统， 然后再挂载。这样做的话能得到一个连续的文件系统格局。 对于经典测试，我们要测试的目录是 /usr/obj(用 newfs 重新初始化，然后再挂载)。 要获得 100% 的再现，请使用 dd(1) 产生的文件来灌输文件系统。(也就是： dd if=myimage of=/dev/ad0s1h bs=1m)

• 使用基于 malloc 的或者预先装载的 md(4) 分区。

• 测试的每次单独迭代之间重启系统。 这可以给你一个更连续的状态。

• 从内核中去掉所有不重要的设备驱动。例如，如果测试不需要 USB， 那么就不要把 USB 放到内核中。驱动加载经常会产生延时。

• 不要配置不使用的硬件。如果测试不使用硬盘，使用 atacontrol(8) 和 camcontrol(8) 去掉硬盘。

• 除非必要，否则不要配置网络， 或者等到测试完要把测试结果传输到另一台机器的时候再启动网络。

  如果系统必须连接到公共网络，一定要注意广播数据。 即使这些数据很难被注意到，也会占用 CPU 的时钟周期。 组播也有类似的情况。

• 把每一个文件系统放到它自己的硬盘上。 这可以最小化磁盘的磁头搜索优化的抖动。

• 尽量减少把结果输出到串口或 VGA 控制台。 将结果导入文件可以减少震动干扰。 (串口终端很容易变成一个瓶颈。) 在测试的时候不要触碰键盘，甚至space 或 back-space 键也会以数字形式显示出来。

• 确认你的测试足够长， 但不是太长。 如果测试太短， 就无法忽略时间戳的误差影响， 而如果太长， 温度的变化会影响计算机内的石英晶体的频率。 经验值： 多于一分钟， 少于一个小时。

• 尽量保证机器所在环境的温度恒定。 这会同时影响石英晶体和磁盘驱动器的算法。 要得到稳定的时钟，可以考虑使用 稳定时钟注入(stabilized clock injection)。例如，使用 OCXO + PLL， 把测试结果注入时钟电路而不是主板上的xtal。 要了解更多，请联系 Poul-Henning Kamp <phk@FreeBSD.org>。

• 测试至少要运行三次。但是对于 “测试前” 和 “测试后” 的代码，最好分别都运行二十次以上。 尽可能交错执行测试，这样可以侦测测试环境对测试的影响。 不要 1：1 的交错，要 3：3 的交错， 这样就可以检测人机交互对测试的影响。

  好的类型，比如：bababa{bbbaaa}*， 可以在 1+1 的运行后给出一些提示（在测试出错时可以停止测试）， 以及在首次 3+3 运行后的标准差（如果测试时间较长可以给出一些）， 和测试运行的趋势与稍后一些交互数字。

• 使用 ministat(1) 来查看数字是否具有统计学上的意义。 你可以买一本 “Cartoon guide to statistics” ISBN: 0062731025，高度推荐， 如果你已经忘记或者根本不知道标准差和 Student's T 测试。

• 不要使用后台 fsck(8) 除非你是在对后台 fsck进行 benchmark。同时，在 /etc/rc.conf 中关闭 background_fsck，除非在系统起动后， 你的 benchmark 在 fsck 运行 60+ 秒后仍然没开始。 因为一旦开启了后台 fsck，rc(8) 会把 fsck 唤醒并检查是否要在文件系统上运行之。 类似的，除非你的测试对象包括 snapshots， 就要确定系统中没有任何 snapshots。

• 如果你的 benchmark 有预期之外的性能低下问题， 就要检测有没有来自未知系统资源的高频率中断。 有一些版本的 ACPI 就有 “运行混乱” 的问题，并且会产生过多的中断。 要诊断奇怪的测试结果，可以抓一些 vmstat -i 的片段然后查看是否有不正常的现象。

• 要谨慎对待内核和用户空间的优化参数，对于调试也是这样。 因为很容易就会忽略一些东西， 然后才会意识到测试不能用来比较同样的事情。

• 除非你的测试对内核参数 WITNESS 和 INVARIANTS 有兴趣，否则不要在开启了这些内核参数后进行你的 benchmark。 WITNESS 会导致 400%+ 的性能损失。 类似的，用户态的 malloc(3) 参数在 -CURRENT 版本和生产版本中默认值都是不同的。