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内核源代码阅读注入了一丝亮色。可是，不管怎样，这还是一个静态的过程，我更期望能从一个动态的系统中获取关于她的内幕与运作规律。
所以，如果能够设想出一些观测内核运行的切入点，并藉此实现对内核机制的动态掌握，真真切切感知内核的运行，有时更
