本文转自http://www.os2ora.com
Linux操作系统资源监控工具重点推荐 — collectl
Kaya 发表于 os2ora.com
对系统资源的监控，是系统管理者一个必备的任务。从OS角度讲，包括CPU/IO/Network/FS等等，从Database的角度讲，包括Active Sessions/ON CPU/Disks/Top Segments/Top SQL等等。而Database对资源的利用也反映在OS一级上，对OS计算资源的充分均衡利用是我们的目标。那么，如何有效的掌握OS的资源利用情况就成为了一个System Administrator，Database Administrator日常工作的一个重点。
Linux上的常规监控工具主要有top, vmstat, iostat, netstat, sar这些。对这些工具的熟练运用应该能解决大部分问题，不过，这些工具也太散了，学习周期是一个很大的问题。有没有一个包揽所有这些工具的一个超级命令呢？
这就是本文要推荐的一个工具了，collectl，一个开源的sourceforge上的项目，http://collectl.sourceforge.net。
先摆摆架构图
三种模式：
Interactive Mode: This is the default and in this mode data is read from /proc and passes through analyze.
Record Mode: Data passes from /proc the same way as Interactive Mode but instead of going through the Analyze function it written it to a file.
Playback Mode: Here collectl works virtually identical to Interactive Mode except instead of reading data from /proc it reads it from a file.
另一个摩登的，独此一家的，现成的特性是支持socket发送数据，这对于一个有几十台以上机器的cluster来说简直就是一个福音。可以通过另一个命令接收整个cluster里面所有机器实时发送过来的数据，通过一个屏幕显示出来，这对于掌握整个cluster的工作状态是极其方便的。
对于一般的机房来说，虽然机房里的所有机器不是一般意义上的cluster，但是也可以在所有机器上安装collectl,然后把性能信息实时发送到一个监控机器，实现grid control。当然，这里指的是安装了Linux操作系统的机器。
collectl支持的性能数据种类应该是最全的一个，包括IO/CPU/Network/NFS/Infiniband/Lustre/Process/Slabs等等。
最后贴一个collectl在Exadata上的一个应用，监控所有的8个数据库节点还有14个cell节点。
看起来Exadata V1的IO已经很强劲，对否？
collectl有一个工具colmux可以实现上面的类似功能，是collectl作者的另一个开源项目，叫Collectl Utilities(http://collectl-utils.sourceforge.net/)。
如果对上图监控方式感兴趣的朋友可以用邮件的方式和我进一步联系。
闲话Linux内核——学习，揣摩与玩味
Kaya 发表于 os2ora.com
周末翻阅了以前写在msn space上的文章，不经意间找到了一篇2006年写的关于Linux内核的文章，那时想不到自己会变成一个Database Performance Engineer，不过里面的一些观点却和现在的工作不谋而合，只不过那时面对的Linux Kernel，现在面对的却是Oracle Database，看来有一些根本的东西是不会变的。
quote begin“
最早接触Linux内核是在大三的时候，那时《操作系统》的课程设计就是进行Linux内核源代码的分析与进程调度的改进。题目是大的有点吓人，特别是对那时一个涉足未深的年轻人看来。不过那时做的事情很简单，认认真真的看了《Linux内核源代码情景分析》的前言部分（主要讲的AT&T汇编语言，内核中一些特殊的编程规则），与进程调度相关的部分，包括进程的管理，进程的切换，进程与中断，软中断，系统调用，进程互斥与同步机制。并画了几张图阐述了进程调度的路线，对spinlock机制进行了深入的剖析。明白了2.4的内核为何是非抢占式内核，进程调度器其实也不是什么神奇的东 东—— 一个函数罢了，啥叫process context。同时，为了完成“进程调度机制的改进”，看了实现可抢占的两个补丁，哦，现在已经整合进2.6了，也怪不得昨天看2.6进程调度的介绍有种似曾相识的感觉。
可以说，那时的分析完全是理论学习。对于内核编程的实践几乎没有。带来的好处最主要的在于提高了对操作系统运行的认识与提高了代码的阅读能力。
回头去看这段往事，总觉得存在着有所改进的地方。
现在看来，内核是啥呢？只是一个比较大的软件项目，可以拿它与Eclipse相比，或者mplayer相比，或者就是与任何一个开源软件处于同层次的东西，只是它更具复杂性，涉及到的软件与硬件的东西更全面罢了。
或者说，经过这几年对开源项目的接触，对软件项目的参与，Linux内核在我心目中的神秘感已然消失，Eclipse在软件架框方面应该可以算出类拔萃，EFI在BIOS这一层上也实现了新的可扩展的和良好的设备管理模型，而Linux在操作系统的层次上也应该是一个典范，值得去学习，去揣摩，去玩味。
2.6内核之于2.4内核，无疑是前进了一大步，进程调度，设备管理等等方面都形成了更良好的framework。同时也涌现出了好多优秀的传道士及其杰作，如《Linux Kernel Development Second Edition》《Linux Device Driver Third Edition》。我更想把这些带有浓厚实践性质的书籍当做进入Linux 内核世界的一个极佳的“切入点”。想起Eclipse世界一本与此类似的书《contributing to eclipse》，一个提倡的规则就是“MONKEY SEE/MONKEY DO RULE Always start by copying the structure of a similar plug-in.”。从内核中学习内核，增强内核，应该是内核编程的一个原则。
不可否认地，“情景分析”是《Linux内核源代码情景分析》的一个亮点，为过去乏味的Linux内核源代码阅读注入了一丝亮色。可是，不管怎样，这还是一个静态的过程，我更期望能从一个动态的系统中获取关于她的内幕与运作规律。
所以，如果能够设想出一些观测内核运行的切入点，并藉此实现对内核机制的动态掌握，真真切切感知内核的运行，有时更能得出一些独具特色的结论进而做出更进一步的改进。
例如对内核调度机制的分析，有以下几个简单的问题：一秒钟内内核大概会做多少次进程切换。系统一般会存在着哪些进程，哪些系统因素会显著地加剧进程切换的次数。这些进程的运行与时间存在着怎样的分布关系（即进程与时间的函数关系）。通过在内核代码中加入相应的进行统计的代码，就可以画出这种函数图出来。再通过对它的分析，就更能从中发现出一些共性东西，数学性的东西，改进的空间。
内核中的调试机制，是与内核打交道首当其冲的问题，也是进行窥探内核的途径。做为一个工具，是实现此种学习的一个必经之路。如printk，如proc文件系统等。
而实践的过程，就是一个发现问题的过程，bottom halves有几种机制，softirq, workqueue, tasklet,他们之间有哪些区别，timer的实现有哪些，在进行实践的过程中，必定会碰到这些问题，并会主动地去寻找这类问题的答案，最后的结果就是自己编写的代码能够良好的运行于内核之中。
这里有另一问题，在内核中是否可以调用一般的系统调用？如open,close,read等等。会存在什么问题？又当如何解决？呵呵，当一个一个的问题被你解决之后，与Linux内核之间的接触又亲密了一层。
从实践中来，到实践中去吧。
当从一个业余者的角度来看Linux内核时，我想，有趣才是最好的导师，寓学于乐吧。
“quote end
遗憾的是，自从做完了研究生的毕业论文之后，就基本上不去做Linux Kernel相关的东西了，但从现在一个Database Performance Engineer的观点看，那时的一些想法和现在的工作还是有一些共性的。比如从一个动态的系统中获取关于她的内幕与运作规律; 通过在内核代码中加入相应的进行统计的代码，就可以画出这种函数图出来,再通过对它的分析，就更能从中发现出一些共性东西，数学性的东西，改进的空间; 内核中的调试机制，是与内核打交道首当其冲的问题，也是进行窥探内核的途径,做为一个工具，是实现此种学习的一个必经之路。如printk，如proc文件系统等。
Linux性能分析工具重点推荐 – nmon analyser
Kaya 发表于 os2ora.com
除了上一篇文章提到的collectl, IBM出品的nmon其实也是一个不错的Linux上的性能监控工具，在写这篇文章时顺带google了nmon一把，惊喜地发现nmon也open source了。还是以sourceforge为根据地，网址是http://nmon.sourceforge.net.
nmon在监控数据与易用性方面几乎与collectl不相上下，对监控单台机器的系统性能还是不错的选择的。不过，nmon没有如collectl一样的网络接口，如果用来它实时监控几十台机器，可能要开几十个窗口，这基本上是不可能的事情。
下面是nmon官方网站最新版本的一个截图：
不过，nmon却做出了另一个突出贡献。这就是推出了一个nmon analyser，而且以开放源代码的形式提供，它的目的是实现对nmon产生的历史性能数据的分析，产生一系列的图表。
以图表分析性能数据的作用是很明显的。密密麻麻的数字，也许只有经过一定的聚合计算，人们才能大致地了解数据的含义，说得忽悠人一点，那就是数据挖掘。不过，聚合计算有个问题，就是会把系统可能出现的瓶颈掩盖掉，举个Jonathan Lewis打过的比方，一个人头部放在寒冰里，脚放在烈火中，按平均值理论，这个人会感觉得很舒服。而利用图形的方式对数据进行描述，就不会导致数据的丢失，而且会使数据特征一目了然。
还是一个来自官方网站上nmon analyser分析结果的一个截图：
nmon analyser其实就是一个Excel文件，里面嵌套了VBA脚本用来分析nmon产生的文本文件并产生一系列的图形报表。深入地分析这些脚本，你会发现，这个analyser其实是一个极好的框架，很容易利用这个analyser来分析自己的数据，而不局限于nmon产生的文件。举个例子，可以用nmon analyser来产生由collectl产生的文件。这当然需要对nmon analyser的脚本做一定的改写，下面是一个例子：
这里可能要做更深一步的说明，无论是nmon或者collectl，都提供了一种把它们做为后台daemon进程对系统进行监控并产生监控日志的功能。这些监控日志就可以被用于对系统的历史性能的分析。collectl甚至还做了一个功能，根据用户指定的时间跨度，自动地从日志里面抽取出这段时间里的历史数据。analyser的作用就在于分析这些日志，并产生相应的分析报告和图表。
因此，从某种程度上说，nmon anlayser为我们提供了一个框架，利用这个框架，我们可以利用起Excel强大的数据分析与绘图功能，实现对文本文件数据的自动处理。这才是本文要说明的最终结论。