以前在 AIX 下，有的时候祭起 nmon ，比 topas 好用多了(去年 AIX 干脆集成了 nmon )。在 Linux 下，top 命令基本也是摆设。如果遇到某些机器没有安装 SYSSTAT 包, 直接把 nmon 抓回来还是挺方便的，省去了安装的麻烦。
最方便的就是能迅速抽取不同维度的性能概览数据。想想其实一个日常用的工具也有很多创新的，nmon 和 topas 读取的数据源是一样的(Perfstat API)，但细节上做得更为到位(看来 Nigel 对用户体验也”略懂”阿)。nmon 抓取的数据很容易输出为 Round-Robin Database (RRD) 格式。便于进一步做数据展现。
AIX 提供的 Perfstat API 很赞，如果自己有兴趣，也可以自己写工具调用数据用以运维数据参考。我以前还写了两个山寨小工具，一个抽取网卡数据吞吐量，一个抽取磁盘 I/O 量。不会 C 也能照猫画虎弄出来。
–EOF–
利用空余时间读了一下这本《Linux 操作系统之奥秘》。其实我买这本书开始只为验证一下，看看所谓的”奥秘”到底所指何物。以前对作者也不太熟悉，读罢倒是收起了调侃之心。
看了几章之后觉得这本书还是值得推荐一下。书店里已经有太多 How To 与 Code Review 之类的 Linux 图书(类似的内容也多数可以从网络上 Google 到)，这样把硬件和操作系统结合起来讲(硬件技术更新也很快，软硬结合才是王道)的图书还是很有新鲜感。很多我们每天都能看到的信息来龙去脉能够有个更清楚的了解，绝对有助于我们更深入的驾驭 Linux 。所谓知其然，知其所以然嘛。
关于”硬件测试”的一章，描述 CPU 测试的部分内容不错。不过后面关于硬盘性能的测试有点简单了。发现一点不太严谨的地方，比如 p173 所说的 “SuSE 的 reiserfs” ，容易让读者误会 reiserfs 是属于 SuSE 家的。
这本书挺适合系统管理员仔细阅读一下，我看过的几章中发现了平时不太注意的知识点。其实一本书看到一个管用的知识点已经很不错了。
–EOF–
A: 动态连接器（dynamic linker）决定使用哪个操作系统 ABI (Application Binary Interface) 库的。LD_ASSUME_KERNE 的值要设定为操作系统版本号。比如 2.4.1 。更多参见 Metalink 文档：433292.1 。
补充：在 Glibc-2.5-20 以上版本修复。各发行商有单独的版本。RHEL 4.x 中在 4.7 以上修复。不过 RHEL 4.7 Kernel 也有问题。
其中一个是 Root device MPIO support，尽管可能没有人会在根设备用 MPIO. 另外一个是 I/O-AT 的支持，I/O-AT 是 Intel 的网络加速技术. 第三个是 Dynamically switchable per-queue I/O schedulers 。
零星记录的一点东西，以后想到什么再补充。 另外，推荐一下 hutuworm 同学的 BLOG 。很有嚼头。
–EOF–
又读了一遍这个 PPT： Federation at Flickr: Doing Billions of Queries Per Day ，发现还是值得咀嚼一下，尽管这”甘蔗”已经被吃过了。
Flickr 数据库的硬件配置一般用 16G 内存，6块 15K 硬盘，RAID 10，在 EM64T 下跑 RHEL 4，运行在 Deadline I/O 调度器 模式 。回写 Cache 用控制器电池而不用磁盘的 Cache。Swappiness 设置为 0 . 。
上面提到了 Flickr 是把 Swappiness 设置为 0 ，简单的通过:
echo 0 > /proc/sys/vm/swappiness
个别情况下这样也可能没起作用，因为实际上对 Swap 的调用是由如下的公式计算得到的：
swap_tendency = mapped_ratio/2 + distress + vm_swappiness;
其中 vm_swappiness 默认值是 60.
这是个防御性的措施。Linux Kernel 2.6 （个别版本）有些诡异行为，当有大量物理内存空闲的时候，Linux 仍(或许)会傻乎乎的调用 Swap 空间，这导致有的时候系统性能很差。有人建议如果是 INNODB 的引擎的话，可以用 O_DIRECT 的方式强制直接调用物理内存。但似乎副作用很大（存疑)。
如果关闭 Swap (swapoff -a)的话，又会遇到 OOM 的问题。这是绝对不推荐的。
还有人用的方式是把 Swap 建立到 RAM 盘上。
Swap 的自动校正其实是个老问题，几年前可能超过 4g 的 Linux 服务器都不多，而现在动辄几十 G 的内存配置，应用场景发生了很大变化，Kernel 的算法思路肯定也要调整一些了吧(尽管几年来不断看到有小的 Patch 出来，可好像 RHEL 的 Kernel 还是老样子)。
我在这里抛砖引玉，大家实际应用中应该也遇到类似问题吧? 有什么建议? 还是干脆就不管? 默认情况下其实也能跑…
–EOF–