flyinweb 's BLOG

BIND 9的FAQ

flyinweb — 2009-6-16 17:58:09

本文译自BIND主网站上的一篇文章：http://www.isc.org/products/BIND/FAQ.html。应该说，这些问题都非常典型，对BIND 9用户的日常维护和管理可以提供不小的帮助。

1. 当我在Linux 2.2.x上使用以--enable-threads选项编译的bind程序时，为什么-u参数不起作用？
答：Linux线程并没有完全实现Posix线程（pthreads）标准。特别是setuid()只能对当前线程起作用，而不适用于整个进程。正是由于此项限制，Linux上的BIND 9就无法像在其他支持的系统平台上一样使用setuid()。在创建线程之前不能调用setuid()，因为服务器只有在线程启动之后才能开始监听预留端口。
对于2.2.18或2.3.99-pre3以及更新的内核而言，则能在调用setuid()之后仍然保持可用性。这使得BIND 9可以更早些调用setuid()，而同时又保持了绑定预留端口的能力。这是针对Linux所作的特别处理。
在2.2内核上，BIND 9的确放弃了许多root权限，所以相对于那些没有放弃权限的root进程而言，这会更加安全一些。
如果Linux线程已经正常工作，那么这项限制也就不复存在。
用户可以使用--disable-threads选项（这是默认选项）来编译BIND9，这样会生成一个非线程的版本，用户能够使用-u选项。

2、为什么named的日志中会给出警告信息"no TTL specified - using SOA MINTTL instead"？
答：你的zone文件不符合RFC1035标准。你可以使用两种方法来解决此问题：
1）在zone文件的开头加入一行对TTL的定义，例如：$TTL 86400
2）在zone文件的第一条记录中包含TTL字段，例如：example.com. 86400 IN SOA ns hostmaster

3、为什么我在Linux上会看到5个（或者更多）的named副本？
答：在ps下每个Linux线程也会像进程一样显示出来。一般运行的线程个数为n+4，这里n表示CPU的数目。注意在内存量的使用上并不遵从累加的原则；如果每个进程使用10M内存，那么所有线程总共也只使用10M内存。

4、为什么即便我在Linux系统上用root身份运行BIND 9，在访问配置文件或zone文件时，仍然会得到关于"permission denied"错误的日志？
答：在Linux上，BIND 9在启动时就放弃了绝大部分root权限，这其中就包括打开其他用户所属文件的权限。因此，如果服务器是以root身份运行的，那么配置文件和zone文件也应该由root所有。

5、为什么我得到类似于"dns_zone_load: zone foo/IN: loading master file bar: ran out of space"的错误提示？
答：这通常是由于TXT记录中少了一个引号所致。检查所有TXT记录是否都包含了完整的引号。

6、我怎样能够在Linux上从多线程named生成一个可用的core文件？
答：如果Linux内核是2.4.7或更新的版本，多线程core导出（dump）是可用的（也就是说，将导出正确的线程）。否则，如果使用的是2.2内核，那么需要应用在contrib/linux/coredump-patch中的内核补丁并重新编译内核。该补丁可以使多线程程序导出正确的线程。

7、我怎样限制别人查询我的服务器版本？
答：在named.conf的"options"段中放置"version"选项，并将其值设成与你实际使用版本不同的其他版本。注意：这样做不能避免攻击，反而可能会妨碍别人对你服务器问题的诊断尝试，而且这同样可能成为别人鉴别你服务器的标志。

8、我怎样限制只有远程用户才能查询服务器版本？
答：当存有版本信息的内部视图被最后匹配时，下面的视图语句将拦截查询。上面一问回答中的警告在这里同样适用。
view "chaos" chaos {
match-clients { ; };
allow-query { none; };
zone "." {
type hint;
file "/dev/null"; // or any empty file
};
};

9、"no source of entropy found"或"could not open entropy source foo"是什么意思？
答：服务器需要信息熵（entropy）源来执行特定的操作，通常这与DNSSEC相关。这些信息提示没有信息熵源。在有/dev/random或类似设备的系统上，默认会使用它们。信息源也可以通过named.conf中的random-device选项来定义。

10、我安装了BIND 9并且重新启动了named，但是它仍然是BIND 8，这是为什么？
答：BIND 9默认安装在/usr/local下。而BIND 8通常安装在/usr下。检查是否正确的named在运行。

11、我尝试使用TSIG来验证动态更新或者zone传输。我确信密钥设置是正确的，但是服务器仍然拒绝TSIG，为什么？
答：这可能是时钟不准的问题。检查客户端的时钟和服务器上的是否同步（例如使用ntp）。

12、我尝试编译BIND 9，但"make"却因为某些文件无法找到而失败了。为什么？
答：使用并行或分布式的"make"来编译BIND 9是不支持的，而且也无法工作。如果你确实使用的是它们中一种，建议你使用一般的make或gmake来替代。

13、我有一台BIND 9的主服务器和一台BIND 8.2.3的从服务器，而主服务器记录到类似于"notify to 10.0.0.1#53 failed: unexpected end of input"的错误信息。哪有问题？
答：该错误信息是由BIND 8.2.3中一个已知的bug所致，这在BIND 8.2.4中得到了修复。你可以完全不必理会它 - 不管错误信息如何，notify都在正常工作着。

14、我不断地得到如下的日志信息，为什么？
Dec 4 23:47:59 client 10.0.0.1#1355: updating zone 'example.com/IN': update failed: 'RRset exists (value dependent)' prerequisite not satisfied (NXRRSET)
答：DNS更新程序允许更新请求在进行更新之前进行测试以确认特定的条件是否满足。以上信息说明条件不满足，无法继续进行更新。参看doc/rfc/rfc2136.txt以获知关于前提条件的更多信息。

15、我不断地得到如下的日志信息，为什么？
Jun 21 12:00:00.000 client 10.0.0.1#1234: update denied
答：有人在尝试使用RFC2136动态更新协议来更新你的DNS数据。Windows 2000的机器有这样的习惯：无需事先配置就发送动态更新请求给DNS服务器。如果更新请求来自于Windows 2000机器，请参看<http://support.microsoft.com/support/kb/articles/q246/8/04.asp> 以了解如何关闭它。

16、我看到如下的日志信息，为什么？
couldn't open pid file '/var/run/named.pid': Permission denied
答：很可能你是以非root用户在运行named，而该用户又对/var/run没有写权限。通常的修复方法是创建由named用户所有的/var/run/named目录并设置pid文件为"/var/run/named/named.pid"，或者设置pid文件为"named.pid"，这将把该文件放到由directory选项指定的目录（在此情况下，该目录必须对named用户可写）下去。

17、当我在执行“dig . ns"时，许多关于root服务器的A记录都丢失了。为什么？
答：这是正常的情况，并无大碍。在BIND 9实现RFC 2181的信任级别（trust ranking）的方法和BIND 9对避免相关数据（glue）进入回答所作的努力上，有些令人迷惑的副面效果。
当BIND 9第一次启动并初始化其缓冲时，它接收根服务器地址作为根服务器权威响应的附加数据，并且这些记录符合包含在响应中作为附加数据的条件。随后，它接收根服务器地址的子集作为根服务器的非权威（推荐）响应的附加数据。这导致这些地址现在被视为非权威的（相关的）数据，它们不适合包含在响应中。
服务器的确总是有一组完整的根服务器地址作为缓冲，只是有可能没有包括全部的地址作为附加数据，这取决于它们最后接收的是响应还是相关数据。你通常可以使用显式查询如“dig a.root-servers.net A"来查找这些地址。

18、从BIND 9主服务器传输zone到Windows 2000从服务器失败了。为什么？
答：这可能是由于Windows 2000 DNS服务器的一个bug所致，在Windows机器上，大于16K的DNS消息就无法正确处理。这可以通过设置选项"transfer-format one-answer;"来解决。也可以检查你的zone是否包含了内嵌的空格或其他的特殊字符，例如"John\032Doe\213s\032Computer"，因为根据已知信息，这些名字也会导致Windows 2000从服务器不正确地拒绝zone。

19、为什么当我在执行"rndc reload"或SIGHUP时，我的zone文件并不重新载入？
答：既可以通过编辑zone文件并重新引导服务器来更新zone文件，也可以通过动态更新来实现，但不能同时使用两种方法。如果你已经针对zone使用了"allow-update"选项来激活动态更新，那你就不能再手工编辑zone文件，此时服务器将不再尝试重新载入zone文件。

20、我可以在域名服务器上查询域名服务器，但不能从其他机器上查到。为什么？
答：这通常是由防火墙配置阻止了查询和/或响应所导致的结果。

21、我怎样可以让服务器同时作为内部和外部视图的从服务器？当我试着这样做时，从服务器上的两个视图传输了主服务器上的同一视图。
答：你应该为主服务器和从服务器设定多IP地址。例如：
主服务器： 10.0.1.1 (internal), 10.0.1.2 (external, IP alias)
internal:
match-clients { !10.0.1.2; !10.0.1.4; 10.0.1/24; };
notify-source 10.0.1.1;
transfer-source 10.0.1.1;
query-source address 10.0.1.1;
external:
match-clients { any; };
recursion no; // don't offer recursion to the world
notify-source 10.0.1.2;
transfer-source 10.0.1.2;
query-source address 10.0.1.2;
从服务器：10.0.1.3 (internal), 10.0.1.4 (external, IP alias)
internal:
match-clients { !10.0.1.2; !10.0.1.4; 10.0.1/24; };
notify-source 10.0.1.3;
transfer-source 10.0.1.3;
query-source address 10.0.1.3;
external:
match-clients { any; };
recursion no; // don't offer recursion to the world
notify-source 10.0.1.4;
transfer-source 10.0.1.4;
query-source address 10.0.1.4;
将external地址设为别名，这样所有在这台机器上的dns客户端默认看到的是internal视图。

22、当我尝试使用rndc时，我得到错误信息"network unreachable"或"connection refused"，尽管我知道named正在运行。
答：你可能在/etc/rndc.conf中有"default-server localhost"，你的/etc/hosts或DNS将"localhost"同时解析成IPv4回退地址127.0.0.1和IPv6回退地址::1，而此时你的IPv6根本无法工作。将"default-server localhost"改作"default-server 127.0.0.1"以确保rndc不会尝试使用IPv6连接域名服务器。

23、我用的是Freebsd 4.4，运行"rndc-confgen -a"就停在那儿不动？
答：没有配置/dev/random。使用rundcontrol(8)告知内核使用特定中断作为随机事件的源。你可以通过在/etc/rc.conf中设置rand_irqs来使之永久生效。
/etc/rc.conf
rand_irqs="3 14 15"

24、为什么named监听的UDP端口不是53？
答：named使用系统选定的端口连接到其他域名服务器进行查询。这可以通过使用query-source进行覆盖以锁定端口和/或地址。

25、当传输zone文件时，我得到错误信息如"multiple RRs of singleton type"以及"CNAME and other data"。这是什么意思？
答：这提示了主zone文件不正确。你可以通过使用dig来找到zone传输所包含的记录，然后在其上运行named-checkzone。
dig axfr example.com @master-server > tmp
named-checkzone example.com tmp

26、我得到错误信息如"named.conf: 99 : unexpected end of input"，这里99是named.conf的最后一行。
答：有些文本编辑器（记事本和写字板）无法在文本文件的最后一行放置行终止标识（例如CR/LF）。这可以通过在文件的最后“加入”一空行来修复。named期望在EOL后紧跟的是一个EOF，如果不符合此条件，它就当作被删除了。

27、我得到警告信息如"zone example.com/IN: refresh: failure trying master 1.2.3.4#53: timed out".
答：1）检查你是否可以由从服务器到主服务器进行UDP查询：
dig +norec example.com soa @1.2.3.4
2）你可能生成的查询超过了从服务器所能处理的能力。降低串行查询率。
serial-query-rate 5; // default 20

Red Hat Enterprise Linux在IBM xSeries服务器上的调优

flyinweb — 2009-6-16 11:27:48

供稿人：吴晓鹏
一.理解Linux的性能
我们可以在文章的开始就列出一个列表，列出可能影响Linux操作系统性能的一些调优参数，但这样做其实并没有什么价值。因为性能调优是一个非常困难的任务，它要求对硬件、操作系统、和应用都有着相当深入的了解。如果性能调优非常简单的话，那些我们要列出的调优参数早就写入硬件的微码或者操作系统中了，我们就没有必要再继续读这篇文章了。正如下图所示，服务器的性能受到很多因素的影响。

当面对一个使用单独IDE硬盘的有20000用户的数据库服务器时，即使我们使用数周时间去调整I/O子系统也是徒劳无功的，通常一个新的驱动或者应用程序的一个更新却可以使这个服务器的性能得到明显的提升。正如我们前面提到的，不要忘记系统的性能是受多方面因素影响的。理解操作系统管理系统资源的方法将帮助我们在面对问题时更好的判断应该对哪个子系统进行调整。
下面的部分对Linux操作系统的架构进行了简单的介绍，对Linux内核的完整的分析超出了我们这本红皮书的内容，感兴趣的读者可以寻找相关文档做更深入的研究。本书对Linux性能的调整主要针对Red Hat发行版本。
1．Linux的CPU调度
任何计算机的基本功能都十分简单，那就是计算。为了实现计算的功能就必须有一个方法去管理计算资源、处理器和计算任务（也被叫做线程或者进程）。非常感谢Ingo Molnar，他为Linux内核带来了O（1）CPU调度器，区别于旧有的O（n）调度器，新的调度器是动态的，可以支持负载均衡，并以恒定的速度进行操作。
新调度器的可扩展性非常好，无论进程数量或者处理器数量，并且调度器本身的系统开销更少。新调取器的算法使用两个优先级队列。
活动运行队列
过期运行队列
调度器的一个重要目标是根据优先级权限有效地为进程分配CPU 时间片，当分配完成后它被列在CPU的运行队列中，除了 CPU 的运行队列之外，还有一个过期运行队列。当活动运行队列中的一个任务用光自己的时间片之后，它就被移动到过期运行队列中。在移动过程中，会对其时间片重新进行计算。如果活动运行队列中已经没有某个给定优先级的任务了，那么指向活动运行队列和过期运行队列的指针就会交换，这样就可以让过期优先级列表变成活动优先级的列表。通常交互式进程（相对与实时进程而言）都有一个较高的优先级，它占有更长的时间片，比低优先级的进程获得更多的计算时间，但通过调度器自身的调整并不会使低优先级的进程完全被饿死。新调度器的优势是显著的改变Linux内核的可扩展性，使新内核可以更好的处理一些有大量进程、大量处理器组成的企业级应用。新的O(1)调度器包含仔2.6内核中，但是也向下兼容2.4内核。

新调度器另外一个重要的优势是体现在对NUMA(non-uniform memory architecture)和SMP（symmetric multithreading processors）的支持上，例如INTEL@的超线程技术。
改进的NUMA支持保证了负载均衡不会发生在CECs或者NUMA节点之间，除非发生一个节点的超出负载限度。Linux的CPU调度器没有使用大部分UNIX和Windows操作系统使用的进程－线程模式，它只使用了线程。在Linux中一个进程表示为一组线程，可以用线程组ID或者TDGID代替标准UNIX中的进程ID或者PID。然而大多数Linux命令例如ps和top都使用PIDs表达，因此在下面的文章中我们会经常使用进程和线程组。
2．Linux的内存架构
今天我们面对选择32位操作系统还是64位操作系统的情况。对企业级用户它们之间最大的区别是64位操作系统可以支持大于4GB的内存寻址。从性能角度来讲，我们需要了解32位和64位操作系统都是如何进行物理内存和虚拟内存的映射的。
在下面图示中我们可以看到64位和32位Linux内核在寻址上有着显著的不同。探究物理内存到虚拟内存的映射超出了本文研究的范围，因此这里我们只是着重研究一下Linux内存架构的特点。
在32位架构中，比如IA-32，Linux内核可以直接寻址的范围只有物理内存的第一个GB（如果去掉保留部分还剩下896MB），访问内存必须被映射到这小于1GB的所谓ZONE_NORMAL空间中，这个操作是由应用程序完成的。但是分配在ZONE_HIGHMEM中的内存页将导致性能的降低。
在另一方面，64位架构比如x86-64（也称作EM64T或者AMD64）。ZONE_NORMAL空间将扩展到64GB或者128GB（实际上可以更多，但是这个数值受到操作系统本身支持内存容量的限制）。正如我们看到的，使用64位操作系统我们排除了因ZONE_HIGHMEM部分内存对性能的影响的情况。

二．性能监测工具
Linux开放和灵活的特性使得它有很多的性能监测软件，这些工具中有的是传统UNIX系统的Linux版本，其他是专门为Linux设计的工具，大部分Linux性能监测工具都是基于proc虚拟文件系统的。
在这一章里我们介绍一些常用性能监测工具和讨论一些有用的命令。所有我们讨论的工具，除了Capacity Manager，都是Red Hat Enterprise Linux (RHEL)所提供的，不需要从网络下载或者其他途径得到。
1．uptime
Uptime命令的显示结果包括服务器已经运行了多长时间，有多少登陆用户和对服务器性能的总体评估（load average）。load average值分别记录了上个1分钟，5分钟和15分钟间隔的负载情况，load average不是一个百分比，而是在队列中等待执行的进程的数量。如果进程要求CPU时间被阻塞（意味着CPU没有时间处理它），load average值将增加。另一方面，如果每个进程都可以立刻得到访问CPU的时间，这个值将减少。
load average的最佳值是1，这说明每个进程都可以立刻被CPU处理。在不同的系统间这个值也是不同的，例如一个单CPU的工作站，load average为1或者2都是可以接受的，但是在一个多CPU的系统中这个值通常为8或者10。
你可以使用uptime判断一个性能问题是出现在服务器上还是网络上。例如，如果一个网络应用运行性能不理想，运行uptime检查系统负载是否比较高，如果不是这个问题更可能出现在你的网络上。
Uptime命令执行示例

Tip:你可以用w命令代替uptime，w命令也可以提供目前登陆用户的信息。
2．Dmesg
Dmesg的主要功能是显示内核信息，当硬件或者内核中加载的模块出现问题的时候dmesg可以提供一些有用的信息。另外，利用dmesg你可以查看有哪些硬件安装在你的服务器上。在每次启动的时候，Linux检查硬件并且记录这些信息。你可以使用/bin/dmesg命令来查看这些信息。

3．Top
Top命令显示了实际CPU使用情况，默认情况下，它显示了服务器上占用CPU的任务信息并且每5秒钟刷新一次。你可以通过多种方式分类它们，包括PID、时间和内存使用情况。
下图是一个top命令结果的示例，

你可以使用renice命令为一个进程分配新的优先级。如果一个进程宕掉或者占用了太多的内存，可以使用kill命令杀死进程。下面是输出值的介绍，
PID：进程标识
USER；进程所有者的用户名
PRI：进程的优先级
NI：nice级别
SIZE：进程占用的内存数量（代码＋数据＋堆栈）
RSS；进程使用的物理内存数量
SHARE；该进程和其他进程共享内存的数量
STAT：进程的状态：S＝休眠状态，R＝运行状态，T＝停止状态，D＝中断休眠状态，Z＝僵尸状态
%CPU：共享的CPU使用
%MEM；共享的物理内存
TIME：进程占用CPU的时间
COMMAND：启动任务的命令行（包括参数）
Top命令有下面几个有用的热键，包括
t：是否显示概要信息
m：是否显示内存信息
A：通过不同的系统资源情况分类显示结果，对快速判断系统中影响性能的进程十分有效
f：输入一个top的交互式的配置画面
o：激活交换式的分类的选择
进程的优先级和nice级别
进程优先级是一个决定进程被CPU执行优先顺序的参数，内核会根据需要调整这个值。Nice值是一个对优先权的限制。进程优先级的值不能低于nice值。（nice值越低优先级越高）
进程优先级是无法去手动改变的，只有通过改变nice值去间接的调整进程优先级。如果一个进程运行的太慢了，你可以通过指定一个较低的nice值去为它分配更多的CPU资源。当然，这意味着其他的一些进程将被分配更少的CPU资源，运行更慢一些。Linux支持nice值的范围是19（低优先级）到-20（高优先级），默认的值是0。如果需要改变一个进程的nice值为负数（高优先级），必须使用su命令登陆到root用户。下面是一些调整nice值的命令示例，
以nice值-5开始程序xyz
#nice –n -5 xyz
改变已经运行的程序的nice值
#renice level pid
将pid为2500的进程的nice值改为10
#renice 10 2500
僵尸进程
当一个进程被结束，在它结束之前通常需要用一些时间去完成所有的任务（比如关闭打开的文件），在一个很短的时间里，这个进程的状态为僵尸状态。在进程完成所有关闭任务之后，会向父进程提交它关闭的信息。有些情况下，一个僵尸进程不能关闭它自己，这时这个进程状态就为z（zombie）。不能使用kill命令杀死僵尸进程，因为它已经标志为“dead”。如果你无法摆脱一个僵尸进程，你可以杀死它的父进程，这个僵尸进程也就消失了。然而，如果父进程是init进程，你不能杀死init进程，因为init是一个重要的系统进程，这种情况下你只能通过一次重新启动来摆脱僵尸进程。
4．iostat
iostat是sysstat的一部分，如果你没有安装这个包，在Red Hat Enterprise Linux光盘中找到sysstat的rpm包进行安装。Iostat显示自系统启动后的平均CPU时间（与uptime类似），它也可以显示磁盘子系统的使用情况，iostat可以用来监测CPU利用率和磁盘利用率。下图是一个命令输出的示例，

CPU利用率分四个部分：
%user：user level（应用）的CPU占用率情况
%nice：加入nice优先级的user level的CPU占用率情况
％sys：system level（内核）的CPU占用情况
%idle：空闲的CPU资源情况
磁盘占用率有下面几个部分：
Device：块设备名
Tps：设备每秒进行传输的数量（每秒的I/O请求）。多个单独的I/O请求可以被组成一个传输操作，因为一个传输操作可以是不同的容量。
Blk_read/s, Blk_wrtn/s：该设备每秒读写的块的数量。块可能为不同的容量。块的大小一般为1024、2048、4048byte。例如，块设备/dev/sda1的块大小可以通过下面命令查看
# dumpe2fs -h /dev/sda1 |grep -F "Block size"
会得到类似下面的输出
dumpe2fs 1.34 (25-Jul-2003)
Block size: 1024
Blk_read, Blk_wrtn：自系统启动以来读写的块设备的总量。
5．Vmstat
Vmstat命令提供了对进程、内存、页面I/O块和CPU等信息的监控，vmstat可以显示检测结果的平均值或者取样值，取样模式可以提供一个取样时间段内不同频率的监测结果。下面是一个vmstat命令的输出结果的示例。
注：在取样模式中需要考虑在数据收集中可能出现的误差，将取样频率设为比较低的值可以尽可能的减小误差的影响。

下面介绍一下各列的含义
·process（procs）
r：等待运行时间的进程数量
b：处在不可中断睡眠状态的进程
w：被交换出去但是仍然可以运行的进程，这个值是计算出来的
·memoryswpd：虚拟内存的数量
free：空闲内存的数量
buff：用做缓冲区的内存数量
·swap
si：从硬盘交换来的数量
so：交换到硬盘去的数量
·IO
bi：向一个块设备输出的块数量
bo：从一个块设备接受的块数量
·system
in：每秒发生的中断数量，包括时钟
cs：每秒发生的context switches的数量
·cpu(整个cpu运行时间的百分比)
us：非内核代码运行的时间（用户时间，包括nice时间）
sy：内核代码运行的时间（系统时间）
id：空闲时间，在Linux 2.5.41之前的内核版本中，这个值包括I/O等待时间
等待I/O操作的时间，在Linux 2.5.41之前的内核版本中这个值为0
Vmstat命令提供了大量的附加参数，可以参考vmstat的man手册去查询所有的参数，下面列举几个十分有用的参数。
·m：显示内核的内存利用率
·a：显示内存页面信息，包括活跃和不活跃的内存页面
·n：显示报头行，这个参数在使用取样模式并将命令结果输出到一个文件时非常有用。例如root#vmstat –n 2 10以2秒的频率显示10输出结果
·当使用-p {分区}时，vmstat提供对I/O结果的统计
6.ps和pstree
ps和pstree命令是系统分析最常用的基本命令，ps命令提供了一个正在运行的进程的列表，列出进程的数量取决于命令所附加的参数。例如ps –A 命令列出所有进程和它们相应的进程ID（PID），进程的PID是使用其他一些工具之前所必须了解的，例如pmap或者renice。
在运行java应用的系统上，ps –A 命令的输出很容易就会超过屏幕的显示范围，这样就很难得到所有进程的完整信息。这时，使用pstree命令可以以树状结构来显示所有的进程信息并且可以整合子进程的信息。Pstree命令对分析进程的来源十分有用。下面是命令的示例，

7.Numastat
随着NUMA架构的不断发展，例如eServer xSeries 445及其后续产品eServer xSeries 460，现在NUMA架构已经成为了企业级数据中心的主流。然而，NUMA架构在性能调优方面面临了新的挑战，例如内存分配的问题在NUMA系统之前并没人感兴趣，Red Hat Enterprise Linux 4提供了一个监测NUMA架构的工具。Numastat命令提供了本地内存与远程内存使用情况的对比和各个节点的内存使用情况。Numa_miss列显示分配失败的本地内存，numa_foreign列显示分配远程内存（访问速度慢）信息，过多的调用远程内存将增加系统的延迟从而影响整个系统的性能。使运行在一个节点上的进程都访问本地内存将极大的改善系统的性能。

8.sar
sar程序是sysstat安装包的一部分，如果你没有安装这个包，在Red Hat Enterprise Linux的源文件中寻找这个rpm包进行安装，sar命令用于收集、报告和保存系统的信息。Sar命令由三个应用组成：sar，用与显示数据；sa1和sa2，用于收集和存储数据。关于sar工具的详细参数说明可以参考man手册。
为了以后分析日志，可以使用sa1和sa2配置系统获得并且记录日志信息。为了实现这个目的，如下图例所示向/etc/crontab中加入相应的内容。注意默认的情况下cron每天都会定时的运行sar命令，如果系统安装了sar相应的安装包。

sar命令所生成的数据保存在/var/log/sa/目录下，数据按照时间保存，可以根据时间来查询相应的性能数据。例如，显示21号的网络信息使用下面的命令sar -n DEV -f sa21|less，命令结果如下，

你也可以使用sar在命令行下得到一个实时的执行结果，收集的数据可以包括CPU利用率、内存页面、网络I/O等等。如下例所示，

9．KDE System Guard
KDE System Guard (KSysguard)是一个KDE的任务管理器和性能监测工具。它是一个客户端/服务器结构的应用，因此可以监测本地或者远程主机。

图形界面中可以用左侧的Sensor选择显示的信息，一个Sensor可以返回一个简单的值或者更复杂的信息例如表格。针对每一类信息都提供了一个或多个显示信息，这些显示信息可以保存或者互相独立的在工作表中加载。
KSysguard窗口中包括菜单栏、工具栏和状态栏，页面浏览和工作区。当你第一次打开时，可以看到默认的情况：本地主机做为localhost列在Sensor浏览里，在工作区中有两个表格。每个Sensor监测某些系统参数，所有的Sensor显示可以在工作区中以拖拽的形式操作，有下面三个选项：
·可以在工作区中删除和代替Sensor
·可以编辑工作表的属性以增加显示的行数和列数
·可以建立新的工作表并且加入新的Sensor以满足应用的需要
下面介绍一下工作区，如下图所示工作区中显示两张表，
·system load：在启动KSysguard中默认显示的
·process Table

System load工作表中包括四个Sensor窗口，cpu负载、平均负载、物理内存和交换空间。多个Sensor可以被显示在一个窗口中，如果想查看窗口中正在监测的分Sensor信息，将鼠标移到图标上，相应的说明会显示出来。也可以在图标上点鼠标右键选择Properties，然后选择页面表，就可以看到相应的说明信息。

点击Process Table表将显示所有在服务器上运行进程的信息，这个表默认显示的是系统CPU的利用率，但是它可以通过选择其他分页来显示其他信息。

因为环境或者应用的需要，你可能有多种不同的Sensor需要监测，实现这个最好的方法就是自定义一个工作表。下面就简单的指导一下如何根据需要建立自定义的工作表。
（1）．创建一个空的工作表，点击File → New。

（2）．输入标题、工作表的行数和列数，也就是监测窗口的数量，在例子中是4个。当信息输入完成后，点击ok建立空工作表。

(3)．在窗口左边将需要的Sensor拖到右边的窗口中。
(4)．点击File → Save保存新的工作表。

如果想要了解关于KDE System Guard的更多信息请访问下面的链接
http://docs.kde.org/en/3.2/kdebase/ksysgaurd
10．Gnome System Monitor
虽然没有KDE System Guard那么强大的功能，Gnome桌面环境也有自己的图形化的性能监测工具。Gnome System Monitor可以图形化的显示系统性能相关的参数，所有的统计结果都是实时的，如果需要长时间的统计结果需要通过其他的性能监测工具来实现。
11．free
free命令显示系统的所有内存的使用情况，包括空闲内存、被使用的内存和交换内存空间。Free命令显示也包括一些内核使用的缓存和缓冲区的信息。下面是命令结果的示例，

当使用free命令的时候，需要记住linux的内存结构和虚拟内存的管理方法，比如空闲内存数量的限制，还有swap空间的使用并不标志一个内存瓶颈的出现。
Free命令有用的参数：
·-b,-k,-m和-g分别按照bytes, kilobytes, megabytes, gigabytes显示结果。
·-l区别显示low和high内存
·-c {count}显示free输出的次数
12．Pmap
pmap命令显示一个或者多个进程使用内存的数量，你可以用这个工具来确定服务器上哪个进程占用了过多的内存从而导致内存瓶颈。
命令格式：pmap
关于pmap命令的详细语法可以使用下面命令查询
pmap -?

13．Strace
strace截取和记录进程的系统调用信息，还包括进程接受的命令信号。这是一个有用的诊断和调试工具，系统管理员可以通过strace来解决程序上的问题。
命令格式，需要指定需要监测的进程ID，下图是一个命令结果的示例。
strace -p
使用下面命令可以获得关于strace的完整语法信息
strace -?
注：当针对某个进程执行strace命令时，对该进程的运行性能将产生很大的影响，所以这个命令仅仅应该用在收集数据的时候。

14．ulimit
这个命令是基于bash的，可以通过ulimit来控制系统资源的使用，使用-a参数列出所有可调的参数。
ulimit –a

-H和-S参数可以对指定的资源进行软限制和硬限制，如果超过了软限制，系统管理员会接收到一个警告，在达到硬限制的时候命令就会提示报错。
例如，为系统打开文件的数量设定一个硬限制
ulimit -Hn 4096
为打开文件设定一个软限制
ulimit -Sn 1024
查看硬限制和软限制的值
ulimit -Hn
ulimit -Sn
这是一个很有用的命令，例如现在想在系统启动时对Oracle用户进行限制，在/etc/security/limits.conf中加入如下两行：
soft nofile 4096
hard nofile 10240
另外确保/etc/pam.d/system-auth文件有下面内容
session required /lib/security/$ISA/pam_limits.so
这一行确保系统会执行这个限制。
如果要查看ulimit命令的详细语法，可以执行
ulimit -?
15．Mpstat
mpstat命令是sysstat包的一部分，如果没有安装sysstat包，可以在Red Hat Enterprise Linux安装源文件中找到并且安装这个rpm包。Mpstat命令用于监测一个多CPU系统中每个可用CPU的情况。Mpstat命令可以显示每个CPU或者所有CPU的运行情况，同时也可以像vmstat命令那样使用参数进行一定频率的采样结果的监测。下面是使用mpstat -P ALL命令的显示结果的示例，

关于完整的命令语法请用下面命令查看
mpstat -?
16. Capacity Manager
Capacity Manager是IBM Director系统管理的一个附加组件，可以提供对不同平台下的多个系统进行长期的性能监测。除了对性能的监测，Capacity Manager还包括对容量的计划，提供对系统将来可能的容量的分析和建议。Capacity Manager可以输出多种文件格式包括HTML, XML和GIF。IBM Director可以被应用在不同操作系统平台下，这样就为在异构环境下对数据的收集和分析提供了有力的工具。
如果使用Capacity Manager，必须在系统中安装相关的rpm包。安装完成后在IBM Director Console中选择Capacity Manager →Monitor Activator

拖拽Monitor Activator图标到一个单独的或者一组已经安装相应程序的系统，在接下来的窗口中可以选择多种子系统进行监测。Capacity Manager在Linux下会有少部分功能受一些参数的限制。

Monitor Activator窗口在右边的窗口中显示相关系统目前的状态，在左边的窗口中显示显示可用的性能监测。添加一个新的监测，选择相应的监测图标点击On。改变将在Monitor Activator窗口关闭后马上生效，配置完成后，IBM Director将开始收集并且存储所要求的性能数据。如果要为收集的信息创建一个报告，选择Capacity Manager → Report Generator并且拖拽操作你想监测的单个或者一组系统，IBM Director将显示下面的界面，

在这里根据你的需要选择是立刻执行或者指定时间执行。在生产环境中，在固定的时间收集Capacity Manager报告是一个比较好的方法，我们可以选择在每周末系统并不繁忙的时候产生一次系统报告。一旦报告收集完成将存储在IBM Director服务器上，可以通过Report Viewer任务来查看。
下图是一个报告结果的示例

在Report Viewer窗口中可以选择需要查看的不同性能参数，Capacity Manager的结果可以被输出为HTML或者XML文件，为了分析需要可以被显示在内部的web服务器上
（注：本文来自红皮书Tuning Red Hat Enterprise Linux on IBM eServer xSeries Servers redp3861.pdf）

6．Linux文件系统
Linux作为一个开源操作系统的优势之一就是为用户提供了多种操作系统的支持。现代Linux内核几乎可以支持所有计算机系统常用的文件系统，从基本的FAT到高性能的文件系统例如JFS。因为Red Hat Enterprise Linux主要支持两种文件系统（ext2和ext3），我们将主要介绍它们的特点，对其他Linux文件系统我们仅做简要介绍。
（1）ext2
ext2文件系统是ext3文件系统的前身。是一个快速、简便的文件系统，它与目前大部分文件系统的显著不同就是ext2不支持日志。
（2）ext3，Red Hat默认的文件系统
自从Red Hat 7.2开始，安装默认的文件系统就是ext3。Ext3是应用广泛的ext2文件系统的更新版本，它加入了对日志的支持。下面列举了这个文件系统的一些特性。
可用性：ext3可以保证数据写入磁盘的一致性，万一出现了非正常的关机（电源的失效或者系统的崩溃），服务器不需要花费时间去校验数据的一致性，因此极大的减少了系统恢复的时间。
数据完整性：加入特殊的日志功能，所有数据，包括文件数据和元数据都是有日志记录的。
速度：通过data=writeback参数，你可以根据应用的需要来调整数据的写入速度。
灵活性：从ext2转换到ext3文件系统是非常简单的并且不需要重新格式化硬盘。通过执行tune2fs命令和编辑/etc/fstab文件，你可以非常容易的将ext2文件系统更新到ext3文件系统。Ext3文件系统也可以禁用日志后作为ext2使用。利用一些第三方的工具软件可以更灵活的使用ext3文件系统，比如PartitionMagic可以编辑ext3分区。
（3）ReiserFS
ReiserFS是一个快速的日志文件系统，它优化了磁盘空间的使用、加快了故障恢复速度。今天ReiserFS是SUSE Linux默认的文件系统。
（4）JFS
JFS是一个完全64位的文件系统，它可以支持非常大的文件和分区。JFS是由IBM为AIX系统开发的，现在在GPL license下以及可以使用了。JFS对大容量的分区和文件，尤其是HPC和数据库应用来说是一种理想的操作系统。如果你想了解更多关于JFS的信息，请访问下面链接
http://jfs.sourceforge.net
(5)XFS
XFS是SGI为IRIX系统开发的高性能的日志文件系统。它的特点和应用都和JFS相当接近。
7．Proc文件系统
proc文件系统不是一个实时文件系统，但是它的作用却非常大。它提供了一个运行中的内核的接口，并不存储实际的数据。Proc文件系统使系统管理员可以监控和调整内核运行状态。下图描述了一个proc文件系统的示例，大部分Linux性能调优工具都需要借助proc文件系统的信息来进行工作。

在proc文件系统中，我们可以看到分别记录不同信息的多个子目录，但是proc目录下的大部分文件可读性都不是很强，建议最好使用可读性更强的工具例如vmstat等来查看proc中记录的信息。请牢记proc目录的相应目录结构。
在/proc目录下的文件
proc根目录下保存着一些记录了系统信息的文件，这些文件你可以通过vmstat和cpuinfo等工具来读取。
数字1到X
各个以数字为名称的文件夹，代表的是运行进程的PID。例如，目录1记录了init进程的一些统计信息。
acpiapci是一个现代桌面和笔记本电脑的电源配置和管理接口，因为apci主要是一个个人电脑的技术，所以在一些服务器系统上经常被禁用。可以访问下面链接获得更多acpi的相关信息
http://www.apci.info
bus
这个子目录记录了系统的总线子系统的信息，例如pci总线或者usb接口。
irq
irq子目录下记录了系统的中断信息。
net
net子目录记录了一些关于你的网卡的重要信息，比如接收的多点广播封包或者每个网卡的路由。
scsi
scsi子目录包含了关于系统的scsi子系统的信息，例如连接的设备或者驱动的版本。ips子目录是记录关于IBM ServerRAID阵列卡信息的。
sys
sys目录下包含了一些可以调整的内核参数。
tty
tty子目录包含了系统虚拟终端的信息。

8．理解Linux调优参数
在我们介绍Linux系统的各种调优参数和性能监测工具之前，需要先讨论一些关于性能调优的参数。因为Linux是一个开源操作系统，所以又大量可用的性能监测工具。对这些工具的选择取决于你的个人喜好和对数据细节的要求。所有的性能监测工具都是按照同样的规则来工作的，所以无论你使用哪种监测工具都需要理解这些参数。下面列出了一些重要的参数，有效的理解它们是很有用处的。
（1）处理器参数
CPU utilization
这是一个很简单的参数，它直观的描述了每个CPU的利用率。在xSeries架构中，如果CPU的利用率长时间的超过80％，就可能是出现了处理器的瓶颈。
Runable processes
这个值描述了正在准备被执行的进程，在一个持续时间里这个值不应该超过物理CPU数量的10倍，否则CPU方面就可能存在瓶颈。
Blocked
描述了那些因为等待I/O操作结束而不能被执行的进程，Blocked可能指出你正面临I/O瓶颈。
User time
描述了处理用户进程的百分比，包括nice time。如果User time的值很高，说明系统性能用在处理实际的工作。
System time
描述了CPU花费在处理内核操作包括IRQ和软件中断上面的百分比。如果system time很高说明系统可能存在网络或者驱动堆栈方面的瓶颈。一个系统通常只花费很少的时间去处理内核的操作。
Idle time
描述了CPU空闲的百分比。
Nice time
描述了CPU花费在处理re-nicing进程的百分比。
Context switch
系统中线程之间进行交换的数量。
Waiting
CPU花费在等待I/O操作上的总时间，与blocked相似，一个系统不应该花费太多的时间在等待I/O操作上，否则你应该进一步检测I/O子系统是否存在瓶颈。
Interrupts
Interrupts值包括硬Interrupts和软Interrupts，硬Interrupts会对系统性能带来更多的不利影响。高的Interrupts值指出系统可能存在一个软件的瓶颈，可能是内核或者驱动程序。注意Interrupts值中包括CPU时钟导致的中断（现代的xServer系统每秒1000个Interrupts值）。
（2）内存参数
Free memory
相比其他操作系统，Linux空闲内存的值不应该做为一个性能参考的重要指标，因为就像我们之前提到过的，Linux内核会分配大量没有被使用的内存作为文件系统的缓存，所以这个值通常都比较小。
Swap usage
这个值描述了已经被使用的swap空间。Swap usage只表示了Linux管理内存的有效性。对识别内存瓶颈来说，Swap In/Out才是一个比较又意义的依据，如果Swap In/Out的值长期保持在每秒200到300个页面通常就表示系统可能存在内存的瓶颈。
Buffer and cache
这个值描述了为文件系统和块设备分配的缓存。注意在Red Hat Enterprise Linux 3和更早一些的版本中，大部分空闲内存会被分配作为缓存使用。在Red Hat Enterprise Linux 4以后的版本中,你可以通过修改/proc/sys/vm中的page_cache_tuning来调整空闲内存中作为缓存的数量。
Slabs
描述了内核使用的内存空间，注意内核的页面是不能被交换到磁盘上的。
Active versus inactive memory
提供了关于系统内存的active内存信息，Inactive内存是被kswapd守护进程交换到磁盘上的空间。
（3）网络参数
Packets received and sent
这个参数表示了一个指定网卡接收和发送的数据包的数量。
Bytes received and sent
这个参数表示了一个指定网卡接收和发送的数据包的字节数。
Collisions per second
这个值提供了发生在指定网卡上的网络冲突的数量。持续的出现这个值代表在网络架构上出现了瓶颈，而不是在服务器端出现的问题。在正常配置的网络中冲突是非常少见的，除非用户的网络环境都是由hub组成。
Packets dropped
这个值表示了被内核丢掉的数据包数量，可能是因为防火墙或者是网络缓存的缺乏。
Overruns
Overruns表达了超出网络接口缓存的次数，这个参数应该和packets dropped值联系到一起来判断是否存在在网络缓存或者网络队列过长方面的瓶颈。
Errors
这个值记录了标志为失败的帧的数量。这个可能由错误的网络配置或者部分网线损坏导致，在铜口千兆以太网环境中部分网线的损害是影响性能的一个重要因素。
（4）块设备参数
Iowait
CPU等待I/O操作所花费的时间。这个值持续很高通常可能是I/O瓶颈所导致的。
Average queue length
I/O请求的数量，通常一个磁盘队列值为2到3为最佳情况，更高的值说明系统可能存在I/O瓶颈。
Average wait
响应一个I/O操作的平均时间。Average wait包括实际I/O操作的时间和在I/O队列里等待的时间。
Transfers per second
描述每秒执行多少次I/O操作（包括读和写）。Transfers per second的值与kBytes per second结合起来可以帮助你估计系统的平均传输块大小，这个传输块大小通常和磁盘子系统的条带化大小相符合可以获得最好的性能。
Blocks read/write per second
这个值表达了每秒读写的blocks数量，在2.6内核中blocks是1024bytes，在早些的内核版本中blocks可以是不同的大小，从512bytes到4kb。
Kilobytes per second read/write
按照kb为单位表示读写块设备的实际数据的数量。

Linux 性能调优的几种方法

flyinweb — 2009-6-16 10:20:23

按照传统，Linux不同的发行版本和不同的内核对各项参数及设置均做了改动，从而使得系统能够获得更好的性能。下边将分四部分介绍在Red Hat Enterprise Linux AS和SUSE LINUX Enterprise Server系统下，如何用以下几种技巧进行性能的优化：
1、Disabling daemons （关闭 daemons)
2、Shutting down the GUI (关闭GUI)
3、Changing kernel parameters (改变内核参数）
4、Kernel parameters （内核参数）
5、Tuning the processor subsystem（处理器子系统调优）
6、Tuning the memory subsystem （内存子系统调优）
7、Tuning the file system（文件系统子系统调优）
8、Tuning the network subsystem（网络子系统调优）
1 关闭daemons
有些运行在服务器中的daemons (后台服务)，并不是完全必要的。关闭这些daemons可释放更多的内存、减少启动时间并减少CPU处理的进程数。减少daemons数量的同时也增强了服务器的安全性。缺省情况下，多数服务器都可以安全地停掉几个daemons。
Table 10-1列出了Red Hat Enterprise Linux AS下的可调整进程.
Table 10-2列出了SUSE LINUX Enterprise Server下的可调整进程

注意：关闭xfs daemon将导致不能启动X，因此只有在不需要启动GUI图形的时候才可以关闭xfs daemon。使用startx命令前，开启xfs daemon，恢复正常启动X。

可以根据需要停止某个进程，如要停止sendmail 进程，输入如下命令：
Red Hat: /sbin/service sendmail stop
SUSE LINUX: /etc/init.d/sendmail stop
也可以配置在下次启动的时候不自动启动某个进程，还是sendmail：
Red Hat: /sbin/chkconfig sendmail off
SUSE LINUX: /sbin/chkconfig -s sendmail off
除此之外，LINUX还提供了图形方式下的进程管理功能。对于Red Hat，启动GUI，使用如下命令： /usr/bin/redhat-config-services 或者鼠标点击 Main Menu -> System Settings ->
Server Settings -> Services.

提示：并非所有的daemons都会显示在该配置界面，如要看到全部的daemons，使用如下命令：
/sbin/chkconfig –list
对于SUSE LINUX,图形界面是YaST2, 可用如下命令来启动
/sbin/yast2 runlevel 或者如Figure 10-2所示用鼠标点击
Browse: YaST/ −> YaST modules −> System −> Runlevel editor

2 关闭GUI
只要有可能，就不要在Linux server上启动GUI图形，通常在Linux server上，没有必要启动GUI。，所有的管理任务均可在命令行方式下完成、或者通过重定向X和Web浏览器界面。有几个可用的基于Web的工具(例如webmin, Linuxconf, 和SWAT).
需要的时候启动GUI，用完马上关闭GUI。多数情况，服务器运行在runlevel 3，即在机器启动的时候不进入GUI。命令行方式下，执行startx 来启动Xserver.
1. 查看runlevel的命令：runlevel
会显示出上次和当前的runlevel (如N 5 表示没有上次的runlevel (N) ，当前的runlevel是5).
2. 在不同的runlevels之间切换，使用命令 init
如切换到run level 3，键入命令init 3
下边是对Linux中不同runlevels的简要描述
– 0 – Halt 停机(不要将0设置为缺省，否则服务器启动后就会马上关闭)
– 1 - Single user mode 单用户模式
– 2 - Multi-user 不带NFS的多用户模式 (如果没有网络，相当与3)
– 3 - Full multi-user mode 完全多用户模式
– 4 – Unused 未使用
– 5 - X11
– 6 – Reboot 重启(不要将6设置为缺省，否则服务器会不断地重启)
修改文件/etc/inittab 来设置机器启动的runlevel，如Figure 10-3。

对于SUSE LINUX Enterprise Server, 执行YaST runlevel 命令改变缺省runlevel值.
如图Figure 10-2。
缺省情况下，保存了6个控制台：F1……F6。为节省内存，可以减少为3个。使用mingetty ttyx命令来实现，如图Figure 10-3
提示：即便是已经关闭了GUI，依然可以远程连接并启动GUI，可以使用ssh-x

3 改变内核参数
Linux内核是操作系统的核心，对所有的Linux发行版本是通用的。内核参数可以改变，在命令行下执行sysctl 命令。
提示：缺省情况下，LINUX内核包括不必重启就可以使用sysctl命令的必要的模块。尽管如此，如果你在安装系统的时候选择移除该功能，那么你只有重新启动LINUX，才可以使得改变生效。
SUSE LINUX 提供了图形界面下的修改方式。使用如下命令来启动powertweak工具：
/sbin/yast powertweak
使用如下命令启动基于字符的管理菜单：
/sbin/yast2 powertweak

Red Hat也提供了图形界面下更改sysctl参数的方式：
/usr/bin/redhat-config-proc
如图Figure 10-5
Parameter storage locations
内核参数保存在/proc(特别是/proc/sys)，提供了内核、处理器、内存、网络及其他组件的相关参数。每个执行的进程都有一个以相应PID命名的目录。Figure 10-3列出了一些包括内核信息的文件。

4 内核的参数
Table 10-5 列出了Red Hat V2.4与性能关系密切的一些内核参数。

5 处理器子系统调优
处理器对于应用和数据库服务器来讲是最重要的硬件子系统之一。然而在这些系统中，CPU经常是性能的瓶颈。
在配有Xeon处理器的高端服务器中，你可以启用或者关闭Hyper-Threading（超线程功能）。Hyper-Threading在操作系统里将一颗处理器虚拟化为两颗使用。Red Hat Enterprise Linux AS和SUSE LINUX Enterprise Server都支持该功能，从而可以使处理器在同一时刻执行两个线程或者进程。对于支持Hyper-Threading的操作系统和软件来说，不需要增加CPU时钟频率即可使性能得到明显的改进。例如，在4路的服务器上起用Hyper-Threading功能并使用性能监测工具（如top）来检测，可以看到8颗处理器。如图Figure 10-6

提示，对于Hyper-Threading：
_ 基于SMP内核的LINUX才可以支持Hyper-Threading
_ 安装的CPU数量越多，从Hyper-Threading获得的性能上的提高就越少。可获得的性能提高大约为：
– 2颗物理CPU: 15-25%
– – 4颗物理CPU: 1-13%
– – 8颗物理CPU: 0-5%
– 如需更多的关于Hyper-Threading信息，可浏览：
http://www.intel.com/business/bss/products/hyperthreading/server/
EM64T是 Intel IA-32处理器的64-bit扩展。意思是，处理器能够支持更多的内存并支持64-bit应用同时完全兼容现存的32-bit应用。Red Hat Enterprise Linux 3 Update 2 和 SUSE LINUX Enterprise Server 9支持这种新的处理器。如需更多的EM64T信息，可浏览:
http://www.intel.com/technology/64bitextensions/
选择正确的内核
Red Hat Enterprise Linux AS和SUSE LINUX Enterprise Server都包括有若干个内核包，如Table 10-6所列。选择合适的内核对性能非常重要。

6 内存子系统的调优
内存子系统的调优不是很容易，需要不停地监测来保证内存的改变不会对服务器的其他子系统造成负面影响。如果要改变虚拟内存参数(在/proc/sys/vm)，建议您每次只改变一个参数然后监测效果。对与虚拟内存的调整包括以下几个项目：
_ 配置Linux内核如何更新dirty buffers到磁盘。磁盘缓冲区用于暂存磁盘的数据。相对于内存来讲，磁盘缓冲区的速度很慢。因此，如果服务器使用这类内存，性能会成问题。当缓冲区内的数据完全dirty，使用：sysctl -w vm.bdflush="30 500 0 0 500 3000 60 20 0"
vm.bdflush有9个参数，但是建议您只改变其中的3个：
1 nfract, 为排队写入磁盘前，bdflush daemon允许的缓冲区最大百分比
2 ndirty, 为bdflush即刻写的最大缓冲区的值。如果这个值很大，bdflush需要更多的时间完成磁盘的数据更新。
7 nfract_sync, 发生同步前，缓冲区变dirty的最大百分比。
配置kswapd daemon，指定Linux的内存交换页数量
sysctl -w vm.kswapd="1024 32 64"
三个参数的描述如下：
– tries_base 相当于内核每次所交换的“页”的数量的四倍。对于有很多交换信息的系统，增加这个值可以改进性能。
– tries_min 是每次kswapd swaps出去的pages的最小数量。
– swap_cluster 是kswapd 即刻写如的pages数量。数值小，会提高磁盘I/O的性能；数值大可能也会对请求队列产生负面影响。
如果要对这些参数进行改动，请使用工具vmstat检查对性能的影响。其它可以改进性能的虚拟内存参数为：
_ buffermem
_ freepages
_ overcommit_memory
_ page-cluster
_ pagecache
_ pagetable_cache

7 文件系统的调优
总体而言，所有数据都要从磁盘获取并都要保存到磁盘。磁盘访问速度通常以毫秒来计算，比其它组件要慢上千倍（如内存、PCI操作是以纳秒或者微秒来计算的）。Linux文件系统定义了数据存储和访问的方式。
Linux可用的文件系统有多种，它们的性能和可扩展性各不相同。除了保存和管理磁盘数据，文件系统还负责保证数据的完整性。新版的Linux缺省安装已经包括日志文件系统（journaling file systems），日志文件系统可防止系统崩溃时导致的数据不一致问题。对文件系统元数据（metadata）的更改都被保存在一份单独的日志里，当发生系统崩溃时可以根据日志正确地恢复数据。除此之外，日志使系统重新启动时不必进行文件系统的检查，从而缩短了恢复时间。
同其他方面的计算一样，性能和完整性是相互平衡的。然而，因Linux服务器多用于企业环境及数据中心，因此要求具备更高的可用性。
这里，我们将介绍Red Hat Enterprise Linux AS和SUSE LINUX Enterprise Server的文件系统及其性能调优。
7.1 安装Linux前，硬件方面的考虑
当前Linux的发行版本对CPU、硬盘和内存方面均有明确的安装要求。然而，对于如何设置磁盘子系统的说明远远不够。由于Linux服务器被广泛的应用于各种环境，数据中心的服务器整合，我们首先要回答的问题就是：“该服务器的功能是什么？”
磁盘子系统可能是整个服务器系统性能的主要方面。了解服务器的功能是判断I/O子系统对性能产生多大影响的关键。
下面几种服务器的磁盘I/O性能是非常重要的：
_ 文件和打印服务器要求在用户和磁盘子系统之间快速地移动数据。因文件服务器的功能是向客户端发送数据，所以要快速读取所有的数据。
_ 数据库服务器的最终目标是从磁盘上的数据仓库里查找和获取数据。即便有足够的内存，多数数据库服务器依然需要大量的磁盘I/O将数据读入内存和更新磁盘数据。
下面几种服务器的磁盘I/O性能不是最重要的：
_ 邮件服务器用于电子邮件的存储和转发，通常产生较大的通信量。对这类服务器来讲，网络性能更为重要。
_ Web服务器用于发布静态和动态的Web页面，网络和内存子系统的性能非常重要。
磁盘技术的选择
除了理解服务器功能，还要了解磁盘容量的部署。下面是当前几种可选的磁盘技术及其容量、特点：

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
技术    花费    功能    容量及其限制
────────────────────────────────────────────
EIDE    最低    直连、本地存储低端服务器，如x305 每控制器最多2块盘
────────────────────────────────────────────
SCSI    低    直连、本地存储中、高端服务器，如x346、x365 已经使用了10年的标准；对数据线长度、传输带宽和磁盘数量均有限制单个通道的并发访问的数量也有所限制，限制了群集功能
────────────────────────────────────────────
SATA    低    中端数据存储应用 2002年开始出现，是EIDE技术的延续；点对点协议，每个驱动器都有一个独立的通道，增强扩展能力；连续的磁盘访问性能可与SCSI相比；支持RAID
────────────────────────────────────────────
iSCSI    较低    中端数据存储，如Web/文件服务器定位于中端存储和远程启动；节省基础架构的开销提供了TCP/IP/Ethernet的灵活性和可靠性；TCP/IP的高延迟影响性能；目前Red Hat Enterprise Linux还不支持
────────────────────────────────────────────
Fibre Channel    高    高端的企业存储，如数据库服务器低延迟、高吞吐量，长传输距离可达10公里 2 Gbps传输速率；路径冗余功能提高可靠性；一个光纤环路支持127个设备，共享带宽，实现大规模群集
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

磁盘的数量
磁盘的数量多少会影响到系统性能。对磁盘容量的需求通常是考虑磁盘数量的唯一因素，而忽视了吞吐量的因素。好的性能是依赖于提供I/O读写的磁头数量。可通过RAID技术来实现，包括软RAID和硬件RAID。许多型号的xSeries服务器提供了硬件RAID支持，Linux 还提供了软RAID功能。2.4 Linux kernel的软RAID是通过md设备驱动实现的，支持EIDE或SCSI硬盘。支持的RAID级别为RAID-0, RAID-1,和RAID-5，可以在初始安装配置或者用mdadm工具配置。Table 10-8列出了可选的IBMRAID控制器：

提示：通常增加硬盘数量是提高磁盘性能的一个最有效方法。
更多的内容，请参考如下文档的第121页Chapter 7, “Disk subsystem”
_ IBM TotalStorage Disk Solutions for xSeries, SG24-6874-00
http://www.redbooks.ibm.com/abstracts/sg246874.html
_ IBM Eserver xSeries ServeRAID Technology
http://www.pc.ibm.com/ww/eserver/xseries/scsi_raid.html
7.2 Ext3: Red Hat的缺省文件系统
从Red Hat 7.2开始，缺省文件系统为Ext3。相对于Ext2，增加了日志。其主要特点为：
_ Availability（可用性）：Ext3提供数据的写一致功能。即意外宕机情况下，不需要检查数据的一致性，使系统恢复时间从几小时缩短为几秒钟。
_ Data integrity（数据完整性）：通过mount命令定义日志方式：data=journal，所有的数据，包括文件数据和元数据，都被定义为日志型。
_ Speed（速度）：通过定义日志方式：data=writeback, 可以选择获得数据完整性还是写速度的优势来满足不同的业务需求。
_ Flexibility（灵活性）：从Ext2升级到Ext3非常简单，且不需要重新格式化硬盘。使用命令tune2fs 并编辑文件/etc/fstab，便可完成升级。注意，Ext3可被mount为不带日志属性的ext2文件系统。
另外，许多第三方厂家兼容Ext3 file systems，如PartitionMagic。
7.3 ReiserFS: SUSE LINUX的缺省文件系统
从SUSE LINUX 7.1开始，缺省安装的文件系统即为由Hans Reiser开发的ResierFS。在其设计之初便包括如下性能方面的考虑 From its initial design, key performance
aspects have included:
_ 日志文件系统（Journaling）的设计提高了可靠性和恢复速度。
_ 使用平衡树数据结构可以同时存储内容数据和安全元数据，使其获得更快的访问速度。
_ 有效地利用磁盘空间，与其他文件系统不同，ResierFS不依赖于数据块的大小。Efficient use of disk space because, unlike other file systems, this file system
does not rely on block sizes.
目前SUSE LINUX Enterprise Server 8的ReiserFS为V3.6，下一代文件系统是Reiser4。Reiser4提供的是不间断的文件系统,通过实现“atomic”文件系统避免系统崩溃,保证完成I/O操作；使用新的访问算法来获取2到5倍的性能提高。
提示: Red Hat Enterprise Linux AS不支持ReiserFS
7.4 通过Linux kernel对文件系统调优
缺省文件系统的设置或许适合大多数应用环境。尽管如此，我们还是提供了如下几个提高磁盘性能的方法：
访问时间更新
linux文件系统当文件被访问，创建，更新的时候会保留纪录。默认的，当文件读写操作的时候，系统会更新last-time-read属性。因为写操作是比较耗费资源的操作，减少不必要的i/o可以整体上提高磁盘性能。
在挂接文件系统的时候，加入noatime参数可以禁止inode节点访问时间的修改。如果文件更新时间对于特定的应用不是很重要的话，比如web服务，就可以把noatime参数加入/etc/fstab文件中
比如：
/dev/sdb1 /mountlocation ext3 defaults,noatime 1 2
推荐利用单独的分区作为挂接点并打开noatime开关
Tuning the elevator algorithm（调整阶梯算法）
磁盘I/O 阶梯算法产生于V2.4 kernel。它是通过控制I/O请求获得服务前在队列中等待时间，来调整块I/O的运算法则。
这是由调整阶梯算法的读写值实现的。通过增加延迟（更大的读、写值），I/O请求在队列中等待更长时间，给I/O scheduler更好地完成I/O操作，改进性能。
对应用于大量磁盘I/O的Linux服务器，要在吞吐量和延迟方面找到一个合理的平衡点。Linux文件系统使用块设备，因此改进块读写的频率可以改进文件系统的性能。一个准则是，小缓存、平横的长延迟读写有利于大量磁盘I/O的Linux服务器。阶梯算法的调整是一个交互的过程，首先要获得基准性能曲线，然后改动设置，观察效果。Example 10-1给出了如何用/sbin/elvtune命令显示当前设置以及如何改动读写队列的数值。
提示：Red Hat建议您将读延迟（-r）调整为写延迟(-w)的一半。
做过改动之后，确保/sbin/elvtune call被加到/etc/rc.d/rc.local (Red Hat)或者/etc/init.d/boot.local (SUSE LINUX)中，使设置在系统重新启动后生效。
redhat推荐调整升降算法来让读延迟是写延迟的一半
注意，2.6核心的linux指出elvtune命令已经作废，取而代之的是调整/sys/block结构

选择Ext3文件系统的日志模式
Ext3文件系统可选三种日志模式,使用mount命令来完成:
_ data=journal
文件数据和元数据均设置为日志方式,性能开销比较大
_ data=ordered (缺省设置)
顺序写入，先写文件数据，再写元数据
_ data=writeback
提供最快的访问速度,但是牺牲了数据的一致性。元数据仍然被记录到日志，从而确保元数据的完整。文件数据会在系统崩溃之后恢复到原先的状态。
三种方法改变日志模式：
_ 使用mount 命令：
mount -o data=writeback /dev/sdb1 /mnt/mountpoint 这里/dev/sdb1 是挂载的文件系统
_ 在/etc/fstab文件的选项中：
/dev/sdb1 /testfs ext3 defaults,journal=writeback 0 0
_ 更改root分区的data=ordered，更改上述/etc/fstab 文件，执行mkinitrd命令来扫描/etc/fstab 文件并创建新的印象文件。升级grub或lilo指向新的印象文件。更多有关Ext3的介绍，请参考：
http://www.redhat.com/support/wpapers/redhat/ext3/
Tuning ReiserFS （调整ReiserFS）
ReiserFS的优势之一是支持大量的小文件。取代传统Linux文件系统的块结构，ReiserFS使用树型结构，保存小文件的全部内容和大文件的结尾。ReiserFS不使用固定的块大小，避免出现碎片而浪费磁盘空间。
挂载ReiserFS 文件系统时，有一个选项可以改进系统性能，但是会消耗更多的磁盘空间。使用notail来关闭“tail packing”选项，具体方法如下：

Setting bdflush
通过调整虚拟内存子系统也可以改进文件系统性能。Bdflush内核进程保证dirty buffers (任何当前被修改的只存在于易失性内存的数据)与磁盘一致。修改/proc/sys/vm/bdflush变量，来改变写入磁盘速率，避免磁盘竞争问题。对/proc下的任何修改即刻生效，但是重新启动后会恢复到原来状态。在/etc/rc.d/rc.local文件中加入echo命令使所做的修改永久生效。
1. 对于2.4 Linux kernels，在/proc/sys/vm/bdflush包括九个变量：nfract：dirty buffers在buffer cache中的最大百分比。Nfract值越大，写入磁盘的延迟越长。当内存不足时，大量的I/O操作被处理。为使磁盘I/O操作均匀分布，保持较低的值。
2. Ndirty：bdflush process可以一次写入磁盘的最大dirty buffers值。该值过大会导致大量I/O请求，过小会在bdflush daemon执行不够频繁的时候导致内存不足。
3. dummy2 未使用
4. dummy3 未使用
5. interval 唤醒kupdate的最低速率。缺省是5秒，最小0秒，最大600秒。
6. age_buffer操作系统将buffer cache写入磁盘前等待的最长时间。缺省30秒，最小1秒，最大6000秒。
7. nfract_sync 激活bdflush同步的dirty buffers百分比，缺省为60%.
8. nfract_stop 停止bdflush的dirty buffers百分比，却省为20%.
9. dummy5 未使用下面是更改bdflush变量的示例:

SCSI磁盘的标签命令队列Tagged command queuing (TCQ)，产生于SCSI-2标准，是一种将到达SCSI驱动器的指令序列进行打标签和重新排序的方法。对于繁重、随机访问的I/O负荷，这种方法通过对I/O请求的重排序，使驱动器磁头位置最优化，改进I/O性能。
一些IBM xSeries服务器集成了Adaptec AIC-7xxx SCSI控制器。执行命令：cat /proc/scsi/aic7xxx/0来检查当前TCQ的设置，不必重新编译内核。可以在/etc/modules.conf中添加如下两行内容，指定参数aic7xxx=global_tag_depth:xx

Block sizes块大小
数据块大小是对磁盘读写的最小单位，直接影响服务器性能。如果服务器处理的多为小文件，那么较小的数据块尺寸会更有效。反之，如果服务器处理的多为大文件，大的数据尺寸块会提高系统性能。如果要改变数据块的大小必须重新格式化磁盘。做了RAID的磁盘，stripe size 就是数据块的容量（光纤盘采用segment）。根据应用的不同合理选择正确的块大小，通常的原则是顺序读写应用宜使用大的块容量，象数据库这样的随机读写操作使用等同于记录大小的块容量更合适。
不同系统版本，可选的块大小不同：
_ Red Hat Enterprise Linux AS with Ext3 可选的块大小为1 KB, 2 KB和4 KB
_ SUSE LINUX Enterprise Server with ReiserFS可选的块大小为4 KB
分区设置的原则
Linux缺省安装创建三个分区：
_ 一个swap分区(自动设定为2倍内存大小但不超过2 GB)
_ 一个小的boot分区:/boot (例如100 MB)
_ 其它空间给根分区 /
关于Linux磁盘分区的优化存在许多的争论。如果只有一个根分区的话，对于将来要增加新分区时会比较麻烦。而分区太多对文件系统的管理又会变的复杂。Linux安装过程中，允许创建多个分区。
创建多个磁盘分区的好处：
_文件系统出色的颗粒度属性使安全性得到改进。例如，允许所有用户和进程容易地访问/var和/tmp分区，并防止恶意访问。通过将这些分区分布到不同的磁盘，可在不影响系统正常运行的情况下对一些分区进行重建和恢复。
_ 某块磁盘故障导致的数据丢失不影响其他磁盘的数据，改进数据完整性。
_ 全新的安装或升级不影响其它分区。
_ 更有效的备份过程
设计分区时要考虑到备份工具，要了解备份工具是以分区为边界或是以更细颗粒度级别，如文件系统为边界。下表列出了要考虑与根分区分开的五个分区，这些分区的划分可以改进性能和灵活性。

要更深层了解Linux文件系统和分区，访问如下关于文件系统层次的网页
http://www.pathname.com/fhs
7.5 交换分区
当物理内存被全部占用，而系统又需要更多的内存时，交换设备发挥作用。这时，系统会将内存中很少使用的数据交换到磁盘的交换分区，释放物理内存。最初的交换分区在安装系统的过程建立，原则上是两倍的物理内存大小。Linux kernels 2.4 支持每分区24GB的交换分区，32-bit系统理论上支持最大8T分区大小。交换分区存在于独立的磁盘。
对于安装好的系统，增加内存时，需要设置更多的交换空间。两种方法可以实现：
·创建一个新的分区作为交换分区。如果没有空闲空间创建新的分区，可以创建一个交换文件。
·如有选择，最好是创建一个交换分区。
从磁盘I/O到交换分区绕过了文件系统，所有的性能开销都在写文件上，因此使提高了性能。
另外一种改进性能的方法是创建多个交换空间，实现并行读写磁盘。增加了交换分区或交换文件后，/etc/fstab文件包含如Example 10-5所示内容：

通常情况下，Linux首先使用/dev/sda2交换分区，然后是/dev/sdb2，依次类推，直到获得足够的交换空间。也就是说，当没有更大空间需求的话，只有/dev/sda2被使用。将数据分散到更多的交换分区可以改进性能，这是因为所有的读写请求是被并行处理的。如果按照Example 10-6改变文件配置，可以给前三个分区赋予更高的优先级。

交换分区是从最高优先级开始使用的（32767最高，0为最低），给前三个分区赋予相同的优先级使数据被写到三个磁盘中；而不是写满一个再写下一个。三个分区并行使用，以提高性能。当前三个分区用满之后，第四个分区开始启用。也可以将所有分区设置为同一个优先级，但是假如这里有一块磁盘的速度比其它磁盘慢的话，性能就会下降。通常的做法是把交换分区放在最快的磁盘中。
提示：交换分区不是物理内存的替代品，它存在于物理磁盘中，性能远远低于内存访问速度。

8 网络子系统的调优
操作系统安装完毕，就要对网络子系统进行调优。对其它子系统的影响：影响CPU利用率，尤其在有大量TCP连接、块尺寸又非常小时，内存的使用会明显增加。
如何预防性能下降
如下的sysctl命令用于改变安全设置，但是它也可以防止网络性能的下降。这些命令被设置为缺省值。
·关闭如下参数可以防止黑客对服务器IP地址的攻击

·开启TCP SYN cookies，保护服务器避免受syn-flood攻击，包括服务取决denial-of-service (DoS) 或者分布式服务拒绝distributed denial-of-service (DDoS) (仅适用Red Hat Enterprise Linux AS)

·以下命令使服务器忽略来自被列入网关的服务器的重定向。因重定向可以被用来进行攻击，所以我们只接受有可靠来源的重定向。

另外，你可以配置接受或拒绝任何ICMP重定向。ICMP重定向是路由器传输路由信息的机制。比如，当网关接收到来自所接网络主机的Internet数据报时，网关可以发送重定向信息到一台主机。网关检查路由表获得下一个网关的地址,第二个网关将数据报路由到目标网络.关闭这些重定向得命令如下:
·如果这个服务器不是一台路由器,那么它不会发送重定向,所以可以关闭该功能:

·配置服务器拒绝接受广播风暴或者smurf 攻击attacks:

·忽略所有icmp包或者pings:

·有些路由器针对广播祯发送无效的回应,每个都产生警告并在内核产生日志.这些回应可以被忽略:

针对TCP和UDP的调优
下边的命令用来对连接数量非常大的服务器进行调优.
·对于同时支持很多连接的服务器,新的连接可以重新使用TIME-WAIT套接字. 这对于Web服务器非常有效:

如果你使用该命令,还要启动TIME-WAIT 套接字状态的快速循环功能:

图Figure 10-7显示出将这些功能启用,连接数量明显降低.因为每个TCP传输都包含远程客户端的协议信息缓存,所以有利于提高性能.缓存中存放round-trip时间、最大segment大小、拥塞窗口的信息。

·参数tcp_fin_timeout 是套接字关闭时，保持FIN-WAIT-2状态的时间。一个TCP连接以three-segment SYN序列开始, 以three-segment FIN序列结束.均不保留数据.通过改变tcp_fin_timeout的值, 从FIN序列到内存可以空闲出来处理新连接的时间缩短了,使性能得到改进.改变这个值的前要经过认真的监测,避免因为死套接字造成内存溢出.

·服务器的一个问题是,同一时刻的大量TCP连接里有很多的连接被打开但是没有使用. TCP的keepalive功能检测到这些连接,缺省情况下,在2小时之后丢掉. 2个小时的可能导致内存过度使用,降低性能.因此改成1800秒(30分钟)是个更好的选择:

·对于所有协议的队列,设置最大系统发送缓存(wmem) 和接收缓存(rmem)到8MB

这些设置指定了创建TCP套接字时为其分配的内存容量. 另外,使用如下命令发送和接收缓存.该命令设定了三个值:最小值、初始值和最大值：

第三个值必须小于或等于wmem_max和rmem_max。
· (SUSE LINUX Enterprise Server适用) 通过保留路径验证来源数据包。缺省情况下，路由器转发所有的数据包，即便是明显的异常网络流量。通过启动和是的过滤功能，丢掉这些数据包：

·当服务器负载繁重或者是有很多客户端都是超长延时的连接故障，可能会导致half-open连接数量的增加。这对于Web服务器很来讲很平常,尤其有很多拨号客户时.这些half-open连接保存在 backlog connections 队列中.将这个值最少设置为4096 (缺省为1024). 即便是服务器不接收这类连接,设置这个值还能防止受到denial-of-service (syn-flood)的攻击.

·设置ipfrag参数,尤其是NFS和Samba服务器。这里,我们可以设置用于重新组合IP碎片的最大、最小内存。当ipfrag_high_thresh值被指派，碎片会被丢弃直到达到ipfrag_low_thres值。
当TCP数据包传输发生错误时，开始碎片整理。有效的数据包保留在内存，同时损坏的数据包被转发。例如，设置可用内存范围从256 MB到384 MB:

Linux 性能监测工具及调优介绍

flyinweb — 2009-6-16 10:17:23

Linux 性能监测工具及调优介绍
LINUX系统下，大多数的性能监测工具保存在/proc目录下。这里我们将Linux AS 和 SUSE LINUX Enterprise Server中，命令行及图形方式下的性能监测工具做概括性介绍。这些工具有些在系统工具盘里，有些可以从网上下载。sar, iostat,和pstat这三个工具在distribution CD里，也可以从网上下载，网址是http://perso.wanadoo.fr/sebastien.godard/。
表--Linux 性能监测工具

这些工具提供了IBM Director Capacity Manager之外的一些功能，能够在某个时间段内对系统性能进行监测。IBM Director适用于多种操作系统平台，从而使得异构环境下数据的收集和分析更容易。下面分三部分逐个介绍每个命令。
1、uptime
uptime命令用于查看服务器运行了多长时间以及有多少个用户登录，快速获知服务器的负荷情况。
uptime的输出包含一项内容是load average，显示了最近1-，5-，15分钟的负荷情况。它的值代表等待CPU处理的进程数，如果CPU没有时间处理这些进程，load average值会升高；反之则会降低。
load average的最佳值是1，说明每个进程都可以马上处理并且没有CPU cycles被丢失。对于单CPU的机器，1或者2是可以接受的值；对于多路CPU的机器，load average值可能在8到10之间。
也可以使用uptime命令来判断网络性能。例如，某个网络应用性能很低，通过运行uptime查看服务器的负荷是否很高，如果不是，那么问题应该是网络方面造成的。
下边是uptime的输出样式

2、dmesg
dmesg命令主要用来显示内核信息。使用dmesg可以有效诊断机器硬件故障或者添加硬件出现的问题。
另外，使用dmesg可以确定您的服务器安装了那些硬件。每次系统重启，系统都会检查所有硬件并将信息记录下来。执行/bin/dmesg命令可以查看该记录。
下边是dmesg的输出样式

3、top
top命令显示处理器的活动状况。缺省情况下，显示占用CPU最多的任务，并且每隔5秒钟做一次刷新。
3.1 Process priority and nice levels
Process priority的数值决定了CPU处理进程的顺序。LIUNX内核会根据需要调整该数值的大小。nice value局限于priority。priority的值不能低于nice value（nice value值越低，优先级越高）。您不可以直接修改Process priority的值，但是可以通过调整nice level值来间接地改变Process priority值，然而这一方法并不是所有时候都可用。如果某个进程运行异常的慢，可以通过降低nice level为该进程分配更多的CPU。
Linux 支持的 nice levels 由19 (优先级低)到-20 (优先级高)，缺省值为0。
执行/bin/ps命令可以查看到当前进程的情况。
4、iostat
iostat由Red Hat Enterprise Linux AS发布。同时iostat也是Sysstat的一部分，可以下载到，网址是http://perso.wanadoo.fr/sebastien.godard/
执行iostat命令可以从系统启动之后的CPU平均时间，类似于uptime。除此之外，iostat还对创建一个服务器磁盘子系统的活动报告。该报告包含两部分：CPU使用情况和磁盘使用情况。
下边是iostat的输出样式

CPU占用情况包括四块内容
%user：显示user level (applications)时，CPU的占用情况。
%nice：显示user level在nice priority时，CPU的占用情况。
%sys:显示system level (kernel)时，CPU的占用情况。
%idle: 显示CPU空闲时间所占比例。
磁盘使用报告分成以下几个部分：
Device: 块设备的名字
tps: 该设备每秒I/O传输的次数。多个I/O请求可以组合为一个，每个I/O请求传输的字节数不同，因此可以将多个I/O请求合并为一个。
Blk_read/s, Blk_wrtn/s: 表示从该设备每秒读写的数据块数量。块的大小可以不同，如1024, 2048 或 4048字节，这取决于partition的大小。
例如，执行下列命令获得设备/dev/sda1 的数据块大小：
dumpe2fs -h /dev/sda1 |grep -F "Block size"
输出结果如下
dumpe2fs 1.34 (25-Jul-2003)
Block size: 1024
Blk_read, Blk_wrtn: 指示自从系统启动之后数据块读/写的合计数。
5、vmstat
vmstat提供了processes, memory, paging, block I/O, traps和CPU的活动状况.
下边是vmstat的输出样式

各输出列的含义：
Process
– r: The number of processes waiting for runtime.
– b: The number of processes in uninterruptable sleep.
Memory
– swpd: The amount of virtual memory used (KB).
– free: The amount of idle memory (KB).
– buff: The amount of memory used as buffers (KB).
Swap
– si: Amount of memory swapped from the disk (KBps).
– so: Amount of memory swapped to the disk (KBps).
IO
– bi: Blocks sent to a block device (blocks/s).
– bo: Blocks received from a block device (blocks/s).
System
– in: The number of interrupts per second, including the clock.
– cs: The number of context switches per second.
CPU (these are percentages of total CPU time)
- us: Time spent running non-kernel code (user time, including nice time).
– sy: Time spent running kernel code (system time).
– id: Time spent idle. Prior to Linux 2.5.41, this included IO-wait time.
– wa: Time spent waiting for IO. Prior to Linux 2.5.41, this appeared as zero.

Linux 性能监测工具及调优介绍(二)
这部分内容包括：sar;KDE System Guard;free;Traffic-vis
6 sar
sar是Red Hat Enterprise Linux AS发行的一个工具，同时也是Sysstat工具集的命令之一，可以从以下网址下载：http://perso.wanadoo.fr/sebastien.godard/
sar用于收集、报告或者保存系统活动信息。sar由三个应用组成：sar显示数据、sar1和sar2用于收集和保存数据。
使用sar1和sar2，系统能够配置成自动抓取信息和日志，以备分析使用。配置举例：在/etc/crontab中添加如下几行内容

同样的，你也可以在命令行方式下使用sar运行实时报告。如图所示：
从收集的信息中，可以得到详细的CPU使用情况(%user, %nice, %system, %idle)、内存页面调度、网络I/O、进程活动、块设备活动、以及interrupts/second

7 KDE System Guard
KDE System Guard (KSysguard) 指KDE任务管理和性能监视。监视本地及远程客户端/服务器架构体系的中的主机。
如图14-1

如图所示，使用传感器获取显示的信息。传感器可以返回简单的数值或者复杂的表格信息。
对于每一种类型的信息，提供了一个或者更多显示。并以工作表的形式独立保存。
每个传感器监视一个部件。所有显示的传感器均可以用鼠标拖拽。有三个选择
1可以删除和替换某个传感器
2可以编辑修改行数和列数
3可以建立新的工作表并选择所需的传感器
如图14-2

7.1 Work space
如图14-2所示，有两个tabs：System Load和Process Table
System Load
该工作表中有四个传感器视窗：CPU Load, Load Average (1 Minute), Physical Memory, 和 Swap Memory.
从Physical Memory window可以看到，同一个window中可以显示多个传感器。在图上移动鼠标，根据所出现的描述信息可以知道哪个传感器正被监视。也可以点鼠标右键该图并选择Properties--Sensors，如图14-3所示。

Process Table
图14-4

点击Process Table显示所有执行的进程。缺省情况下，按照System CPU utilization排序，也可以简单地通过鼠标点击相应项改变排序的方式。
定制一个work sheet
指导定制创建一个如图14-7所示的work sheet
1. 选择File-> New ,如图 14-5

2. 输入标题以及行列数；即最多的监视窗口数，这里为四个。如图14-6

注：最短2秒更新间隔
3. 现在只需简单将传感器从左恻拖拽到右恻的窗口中。显示可选项为
– Signal Plotter. 显示一个或者多个传感器，如果有多个，则分层显示。如果显示屏足够大，以网格方式显示。
缺省情况下，为自动排列方式，最大和最小值自动设置。如果要修改最大最小值，首先要关闭自动排列方式。
– Multimeter. 以数字方式显示传感器的值。在属性对话框中，可以改变上限和下限。超过限制时，显示警告色。
– BarGraph. 将传感器的值显示为dancing bars. 同Multimeter一样，在属性对话框中，可以改变上限和下限。超过限制时，显示警告色。
– Sensor Logger ：Sensor Logger不显示任何值，而是将上述信息记录到某个文件中，并加入日期和时间。对每个传感器，你必须定义一个日志文件、记录日志的时间间隔、以及是否报警。
4.点File -> Save，保存worksheet.

如需获取更多KDE System Guard信息，访问:http://docs.kde.org/en/3.2/kdebase/ksysgaurd
注：work sheet被保存在用户目录中，其他管理员可能无法访问。
8 free
/bin/free命令显示所有空闲的和使用的内存数量，包括swap。同时也包含内核使用的缓存。

9 Traffic-vis
Traffic-vis是一套测定哪些主机在IP网进行通信、通信的目标主机以及传输的数据量。并输出纯文本、HTML或者GIF格式的报告。
注：Traffic-vis仅仅适用于SUSE LINUX ENTERPRISE SERVER。
如下命令用来收集网口eth0的信息：
traffic-collector -i eth0 -s /root/output_traffic-collector
可以使用killall命令来控制该进程。如果要将报告写入磁盘，可使用如下命令：
killall -SIGUSR1 traffic-collector
要停止对信息的收集，执行如下命令：killall -SIGTERM traffic-collector
注意，不要忘记执行最后一条命令，否则会因为内存占用而影响性能。
可以根据packets, bytes, TCP连接数对输出进行排序，根据每项的总数或者收/发的数量进行。
例如根据主机上packets的收/发数量排序，执行命令：
traffic-sort -i output_traffic-collector -o output_traffic-sort -Hp
如要生成HTML格式的报告，显示传输的字节数，packets的记录、全部TCP连接请求和网络中每台服务器的信息，请运行命令：
traffic-tohtml -i output_traffic-sort -o output_traffic-tohtml.html
可以通过浏览器方式查看报告的内容，如图14-8

如要生成GIF格式（600X600）的报告，请运行命令：
traffic-togif -i output_traffic-sort -o output_traffic-togif.gif -x 600 -y 600
图14-9显示了网络中主机之间通信的情况。GIF格式的报告可以方便地发现网络广播，查看哪台主机在TCP网络中使用IPX/SPX协议并隔离网络，需要记住的是，IPX是基于广播包的协议。如果我们需要查明例如网卡故障或重复IP的问题，需要使用特殊的工具。例如SUSE LINUX Enterprise Server自带的Ethereal。

技巧和提示：使用管道，可以只需执行一条命令来产生报告。如生成HTML的报告，执行命令：
cat output_traffic-collector | traffic-sort -Hp | traffic-tohtml
-o output_traffic-tohtml.html
如要生成GIF文件，执行命令：
cat output_traffic-collector | traffic-sort -Hp | traffic-togif
-o output_traffic-togif.gif -x 600 -y 600

Linux 性能监测工具及调优介绍(三)
这部分内容包括：pmap;strace;ulimit;mpstat
10 pmap
pmap可以报告某个或多个进程的内存使用情况。使用pmap判断主机中哪个进程因占用过多内存导致内存瓶颈。图14-9显示了SUSE LINUX
Enterprise Server下pmap命令执行结果
pmap -x

图14-10显示了smbd进程所占用的内存
pmap

11 strace
strace截取和记录系统进程调用，以及进程收到的信号。是一个非常有效的检测、指导和调试工具。系统管理员可以通过该命令容易地解决程序问题。
使用该命令需要指明进程的ID(PID)，例如：
strace -p
图14-11 shows an example of the output of strace.

12 ulimit
ulimit内置在bash shell中，用来提供对shell和进程可用资源的控制
使用选项-a列出可以设置的所有参数：
ulimit -a

-H和-S选项指明所给资源的软硬限制。如果超过了软限制，系统管理员会收到警告信息。硬限制指在用户收到超过文件句炳限制的错误信息之前，可以达到的最大值。
例如可以设置对文件句炳的硬限制：ulimit -Hn 4096
例如可以设置对文件句炳的软限制：ulimit -Sn 1024
查看软硬值，执行如下命令：
ulimit -Hn
ulimit -Sn
例如限制Oracle用户. 在/etc/security/limits.conf输入以下行:
soft nofile 4096
hard nofile 10240
对于Red Hat Enterprise Linux AS，确定文件/etc/pam.d/system-auth包含如下行
session required /lib/security/$ISA/pam_limits.so
对于SUSE LINUX Enterprise Server，确定文件/etc/pam.d/login 和/etc/pam.d/sshd包含如下行：
session required pam_limits.so
这一行使这些限制生效。
13 mpstat
mpstat是Sysstat工具集的一部分，下载地址是http://perso.wanadoo.fr/sebastien.godard/
mpstat用于报告多路CPU主机的每颗CPU活动情况，以及整个主机的CPU情况。
例如，下边的命令可以隔2秒报告一次处理器的活动情况，执行3次
mpstat 2 3

如下命令每隔1秒显示一次多路CPU主机的处理器活动情况，执行3次
mpstat -P ALL 1 3

apache安装完成后，如何添加模块

flyinweb — 2009-6-12 16:28:22

apache安装完成后，如何添加模块(http://blog.sina.com.cn/s/blog_4890155d01000bo7.html)

apache安装后，如果想再添加模块，往往不想重新安装一次，再者，我在安装中发现，并不是安装文件中所有的modules都会被默认安装，即使在安装中使用了 ./configure --prefix=/usr/local/apache --enable-so --enable-modules=all --enable-mods-shared=all也是如此。我使用上述方法安装的apache2.2.6就没有安装proxy相关模块。这时，需要手工生成so文件，但会自动的被复制到你的apache安装目录的modules中，然后修改apache的配置文件，加载相关模块，验证apache配置并重启服务即可。以上描述的具体操作步骤如下：
操作系统：linux redhat 4.5 ES
apache版本：2.2.6 可自行下载tar包

1. 拷贝安装包到/usr/local,并在目标目录下进行解压。

[root@localhost local]# cd /usr/local
[root@localhost local]# tar -zxvf httpd-2.2.4.tar.gz

2. 配置安装参数，安装的目标目录为/usr/local/apache，建议设置enable-mods-shared=all，不用的module注释掉就行了！

[root@localhost local]# cd httpd-2.2.4
[root@localhost httpd-2.2.4]# ./configure --prefix=/usr/local/apache --enable-so --enable-mods-shared=all

3. 编译并安装。

[root@localhost httpd-2.2.4]# make
[root@localhost httpd-2.2.4]# make install

4. 启动Apache，并测试。

[root@localhost httpd-2.2.4]# cd /usr/local/apache/bin
[root@localhost bin]# ./apachectl start

打开浏览器，并在地址栏中输入主机的IP地址
如http://Localhost/
如果出现以下画面则说明安装成功。
It works!

注意：安装完成后检查系统服务中的HTTPD服务是否已经启动，如果启动需要先停止。
5. 编译mod_proxy.so.

[root@localhost httpd-2.2.4]# cd modules
[root@localhost modules]# /usr/local/apache/bin/apxs -c -i mod_proxy.c proxy_util.c

这时生成的mod_proxy.so会被自动复制到/usr/local/apache/modules
6. 修改配置文件

[root@localhost modules]# cd /usr/local/apache/conf
[root@localhost conf]# vi httpd.conf

添加一行

LoadModule proxy_module modules/mod_proxy.so

7. 测试配置是否正确

[root@localhost conf]# cd ..
[root@localhost apache]# cd bin
[root@localhost bin]# ./apachectl configtest

出现如下信息证明配置正确

[Fri Nov 23 15:45:55 2007] [warn] module rewrite_module is already loaded, skipping
Syntax OK

8. 重新启动apache

[root@localhost bin]# ./apachectl stop
[root@localhost bin]# ./apachectl start

完成！！

apache apx 添加模块(http://hi.baidu.com/seesea8/blog/item/0cfe8d16355d5054f2de32f7.html)
Apache安装完成后，添加mod_proxy模块
apxs是一个为Apache HTTP服务器编译和安装扩展模块的工具，用于编译一个或多个源程序或目标代码文件为动态共享对象，使之可以用LoadModule指令在运行时加载到Apache服务器中。

1. 进入apache源代码的modules目录
2. 运行如下命令自动编译、安装和修改httpd.conf文件，激活mod_proxy模块：

apache path/bin/apxs -c -i -a mod_proxy.c proxy_util.c

选项说明：
-c 执行编译操作
-i 安装操作，安装一个或多个动态共享对象到服务器的modules目录
-a 自动增加一个LoadModule行到httpd.conf文件，以激活此模块，若此行存在则启用之
-A 与-a类似，但是它增加的LoadModule行前有井号前缀(#)
-e 需要执行编辑操作，可与-a和-A选项配合使用，与-i操作类似，修改httpd.conf文件，但并不安装此模块

3. 重启apache。

apache 添加 mod_rewrite 模块(http://hi.baidu.com/howard_2008/blog/item/33cda0c71e9794d8d10060d5.html)
我使用的是httpd 2.0.55 注意配置httpd.conf 时是 rewrite_module 而不是 mod_rewrite

1、Apache安装rewrite模块的时候需要DBM支持，否则无法编译。使用rpm -qa gdbm 查询，如果没有，需要先下载并安装gdbm：
下载地址：ftp://ftp.gnu.org/gnu/gdbm/

安装步骤:

./configure
make
make install
make install-compat (如果不执行此步,无法编译出ndbm.h头文件)

2、安装

#cd /root/src/httpd-2.0.55/modules/mappers
#/usr/local/apache/bin/apxs -c mod_rewrite.c
#gcc -shared -o mod_rewrite.so mod_rewrite.o -lgdbm
#/usr/local/apache/bin/apxs -i -A -n mod_rewrite mod_rewrite.so

/usr/local/apache/bin/ 是我正在使用的apahce的目录

3、配置httpd.conf
加入 LoadModule rewrite_module modules/mod_rewrite.so

注意是 rewrite_module 而不是 mod_rewrite

Filesystem Hierarchy Standard

flyinweb — 2009-6-12 16:20:07

Filesystem Hierarchy Standard
Filesystem Hierarchy Standard Group
Edited by
Rusty Russell
Daniel Quinlan
Christopher Yeoh
Copyright © 1994-2004 Daniel Quinlan
Copyright © 2001-2004 Paul 'Rusty' Russell
Copyright © 2003-2004 Christopher Yeoh
This standard consists of a set of requirements and guidelines for file and directory placement under UNIX-like operating systems. The guidelines are intended to support interoperability of applications, system administration tools, development tools, and scripts as well as greater uniformity of documentation for these systems.
All trademarks and copyrights are owned by their owners, unless specifically noted otherwise. Use of a term in this document should not be regarded as affecting the validity of any trademark or service mark.
Permission is granted to make and distribute verbatim copies of this standard provided the copyright and this permission notice are preserved on all copies.
Permission is granted to copy and distribute modified versions of this standard under the conditions for verbatim copying, provided also that the title page is labeled as modified including a reference to the original standard, provided that information on retrieving the original standard is included, and provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one.
Permission is granted to copy and distribute translations of this standard into another language, under the above conditions for modified versions, except that this permission notice may be stated in a translation approved by the copyright holder.
Table of Contents
1. Introduction
Purpose
Conventions
2. The Filesystem
3. The Root Filesystem
Purpose
Requirements
Specific Options
/bin : Essential user command binaries (for use by all users)
Purpose
Requirements
Specific Options
/boot : Static files of the boot loader
Purpose
Specific Options
/dev : Device files
Purpose
Specific Options
/etc : Host-specific system configuration
Purpose
Requirements
Specific Options
/etc/opt : Configuration files for /opt
/etc/X11 : Configuration for the X Window System (optional)
/etc/sgml : Configuration files for SGML (optional)
/etc/xml : Configuration files for XML (optional)
/home : User home directories (optional)
Purpose
Requirements
/lib : Essential shared libraries and kernel modules
Purpose
Requirements
Specific Options
/lib : Alternate format essential shared libraries (optional)
Purpose
Requirements
/media : Mount point for removeable media
Purpose
Specific Options
/mnt : Mount point for a temporarily mounted filesystem
Purpose
/opt : Add-on application software packages
Purpose
Requirements
/root : Home directory for the root user (optional)
Purpose
/sbin : System binaries
Purpose
Requirements
Specific Options
/srv : Data for services provided by this system
Purpose
/tmp : Temporary files
Purpose
4. The /usr Hierarchy
Purpose
Requirements
Specific Options
/usr/X11R6 : X Window System, Version 11 Release 6 (optional)
Purpose
Specific Options
/usr/bin : Most user commands
Purpose
Specific Options
/usr/include : Directory for standard include files.
Purpose
Specific Options
/usr/lib : Libraries for programming and packages
Purpose
Specific Options
/usr/lib : Alternate format libraries (optional)
Purpose
/usr/local : Local hierarchy
/usr/local/share
/usr/sbin : Non-essential standard system binaries
Purpose
/usr/share : Architecture-independent data
Purpose
Requirements
Specific Options
/usr/share/dict : Word lists (optional)
/usr/share/man : Manual pages
/usr/share/misc : Miscellaneous architecture-independent data
/usr/share/sgml : SGML data (optional)
/usr/share/xml : XML data (optional)
/usr/src : Source code (optional)
Purpose
5. The /var Hierarchy
Purpose
Requirements
Specific Options
/var/account : Process accounting logs (optional)
Purpose
/var/cache : Application cache data
Purpose
Specific Options
/var/cache/fonts : Locally-generated fonts (optional)
/var/cache/man : Locally-formatted manual pages (optional)
/var/crash : System crash dumps (optional)
Purpose
/var/games : Variable game data (optional)
Purpose
/var/lib : Variable state information
Purpose
Requirements
Specific Options
/var/lib/ : Editor backup files and state (optional)
/var/lib/hwclock : State directory for hwclock (optional)
IBMISCMISCELLANEOUSVARIABLEDATA">/var/lib/misc : Miscellaneous variable data
/var/lock : Lock files
Purpose
/var/log : Log files and directories
Purpose
Specific Options
/var/mail : User mailbox files (optional)
Purpose
/var/opt : Variable data for /opt
Purpose
/var/run : Run-time variable data
Purpose
Requirements
/var/spool : Application spool data
Purpose
Specific Options
/var/spool/lpd : Line-printer daemon print queues (optional)
/var/spool/rwho : Rwhod files (optional)
/var/tmp : Temporary files preserved between system reboots
Purpose
/var/yp : Network Information Service (NIS) database files (optional)
Purpose
6. Operating System Specific Annex
Linux
/ : Root directory
/bin : Essential user command binaries (for use by all users)
/dev : Devices and special files
/etc : Host-specific system configuration
/lib64 and /lib32 : 64/32-bit libraries (architecture dependent)
/proc : Kernel and process information virtual filesystem
/sbin : Essential system binaries
/usr/include : Header files included by C programs
/usr/src : Source code
/var/spool/cron : cron and at jobs
7. Appendix
The FHS mailing list
Background of the FHS
General Guidelines
Scope
Acknowledgments
Contributors
Chapter 1. Introduction
Purpose
This standard enables:
Software to predict the location of installed files and directories, and
Users to predict the location of installed files and directories.
We do this by:
Specifying guiding principles for each area of the filesystem,
Specifying the minimum files and directories required,
Enumerating exceptions to the principles, and
Enumerating specific cases where there has been historical conflict.
The FHS document is used by:
Independent software suppliers to create applications which are FHS compliant, and work with distributions which are FHS complaint,
OS creators to provide systems which are FHS compliant, and
Users to understand and maintain the FHS compliance of a system.
The FHS document has a limited scope:
Local placement of local files is a local issue, so FHS does not attempt to usurp system administrators.
FHS addresses issues where file placements need to be coordinated between multiple parties such as local sites, distributions, applications, documentation, etc.
Conventions
We recommend that you read a typeset version of this document rather than the plain text version. In the typeset version, the names of files and directories are displayed in a constant-width font.
Components of filenames that vary are represented by a description of the contents enclosed in "" and ">[/i]" characters, [/i]. Electronic mail addresses are also enclosed in "" but are shown in the usual typeface.
Optional components of filenames are enclosed in "[[/i]" and "][/i]" characters and may be combined with the "" and ">[/i]" convention. For example, if a filename is allowed to occur either with or without an extension, it might be represented by [.][/i].
Variable substrings of directory names and filenames are indicated by "*[/i]".
The sections of the text marked as Rationale[/i] are explanatory and are non-normative.
Chapter 2. The Filesystem
This standard assumes that the operating system underlying an FHS-compliant file system supports the same basic security features found in most UNIX filesystems.
It is possible to define two independent distinctions among files: shareable vs. unshareable and variable vs. static. In general, files that differ in either of these respects should be located in different directories. This makes it easy to store files with different usage characteristics on different filesystems.
"Shareable" files are those that can be stored on one host and used on others. "Unshareable" files are those that are not shareable. For example, the files in user home directories are shareable whereas device lock files are not.
"Static" files include binaries, libraries, documentation files and other files that do not change without system administrator intervention. "Variable" files are files that are not static.

Rationale

Shareable files can be stored on one host and used on several others. Typically, however, not all files in the filesystem hierarchy are shareable and so each system has local storage containing at least its unshareable files. It is convenient if all the files a system requires that are stored on a foreign host can be made available by mounting one or a few directories from the foreign host.
Static and variable files should be segregated because static files, unlike variable files, can be stored on read-only media and do not need to be backed up on the same schedule as variable files.
Historical UNIX-like filesystem hierarchies contained both static and variable files under both /usr and /etc. In order to realize the advantages mentioned above, the /var hierarchy was created and all variable files were transferred from /usr to /var. Consequently /usr can now be mounted read-only (if it is a separate filesystem). Variable files have been transferred from /etc to /var over a longer period as technology has permitted.
Here is an example of a FHS-compliant system. (Other FHS-compliant layouts are possible.)
[/i]
shareable
unshareable
static
/usr
/etc

/opt
/boot
variable
/var/mail
/var/run

/var/spool/news
/var/lock
Chapter 3. The Root Filesystem
Purpose
The contents of the root filesystem must be adequate to boot, restore, recover, and/or repair the system.
To boot a system, enough must be present on the root partition to mount other filesystems. This includes utilities, configuration, boot loader information, and other essential start-up data. /usr, /opt, and /var are designed such that they may be located on other partitions or filesystems.
To enable recovery and/or repair of a system, those utilities needed by an experienced maintainer to diagnose and reconstruct a damaged system must be present on the root filesystem.
To restore a system, those utilities needed to restore from system backups (on floppy, tape, etc.) must be present on the root filesystem.

Rationale

The primary concern used to balance these considerations, which favor placing many things on the root filesystem, is the goal of keeping root as small as reasonably possible. For several reasons, it is desirable to keep the root filesystem small:
It is occasionally mounted from very small media.
The root filesystem contains many system-specific configuration files. Possible examples include a kernel that is specific to the system, a specific hostname, etc. This means that the root filesystem isn't always shareable between networked systems. Keeping it small on servers in networked systems minimizes the amount of lost space for areas of unshareable files. It also allows workstations with smaller local hard drives.
While you may have the root filesystem on a large partition, and may be able to fill it to your heart's content, there will be people with smaller partitions. If you have more files installed, you may find incompatibilities with other systems using root filesystems on smaller partitions. If you are a developer then you may be turning your assumption into a problem for a large number of users.
Disk errors that corrupt data on the root filesystem are a greater problem than errors on any other partition. A small root filesystem is less prone to corruption as the result of a system crash.
Applications must never create or require special files or subdirectories in the root directory. Other locations in the FHS hierarchy provide more than enough flexibility for any package.

Rationale

There are several reasons why creating a new subdirectory of the root filesystem is prohibited:
It demands space on a root partition which the system administrator may want kept small and simple for either performance or security reasons.
It evades whatever discipline the system administrator may have set up for distributing standard file hierarchies across mountable volumes.
Distributions should not create new directories in the root hierarchy without extremely careful consideration of the consequences including for application portability.
Requirements
The following directories, or symbolic links to directories, are required in /.
Directory
Description
bin
Essential command binaries
boot
Static files of the boot loader
dev
Device files
etc
Host-specific system configuration
lib
Essential shared libraries and kernel modules
media
Mount point for removeable media
mnt
Mount point for mounting a filesystem temporarily
opt
Add-on application software packages
sbin
Essential system binaries
srv
Data for services provided by this system
tmp
Temporary files
usr
Secondary hierarchy
var
Variable data
Each directory listed above is specified in detail in separate subsections below. /usr and /var each have a complete section in this document due to the complexity of those directories.
Specific Options
The following directories, or symbolic links to directories, must be in /, if the corresponding subsystem is installed:
Directory
Description
home
User home directories (optional)
lib
Alternate format essential shared libraries (optional)
root
Home directory for the root user (optional)
Each directory listed above is specified in detail in separate subsections below.
/bin : Essential user command binaries (for use by all users)
Purpose
/bin contains commands that may be used by both the system administrator and by users, but which are required when no other filesystems are mounted (e.g. in single user mode). It may also contain commands which are used indirectly by scripts. [1]
Requirements
There must be no subdirectories in /bin.
The following commands, or symbolic links to commands, are required in /bin.
Command
Description
cat[/b]
Utility to concatenate files to standard output
chgrp[/b]
Utility to change file group ownership
chmod[/b]
Utility to change file access permissions
chown[/b]
Utility to change file owner and group
cp[/b]
Utility to copy files and directories
date[/b]
Utility to print or set the system data and time
dd[/b]
Utility to convert and copy a file
df[/b]
Utility to report filesystem disk space usage
dmesg[/b]
Utility to print or control the kernel message buffer
echo[/b]
Utility to display a line of text
false[/b]
Utility to do nothing, unsuccessfully
hostname[/b]
Utility to show or set the system's host name
kill[/b]
Utility to send signals to processes
ln[/b]
Utility to make links between files
login[/b]
Utility to begin a session on the system
ls[/b]
Utility to list directory contents
mkdir[/b]
Utility to make directories
mknod[/b]
Utility to make block or character special files
more[/b]
Utility to page through text
mount[/b]
Utility to mount a filesystem
mv[/b]
Utility to move/rename files
ps[/b]
Utility to report process status
pwd[/b]
Utility to print name of current working directory
rm[/b]
Utility to remove files or directories
rmdir[/b]
Utility to remove empty directories
sed[/b]
The `sed' stream editor
sh[/b]
The Bourne command shell
stty[/b]
Utility to change and print terminal line settings
su[/b]
Utility to change user ID
sync[/b]
Utility to flush filesystem buffers
true[/b]
Utility to do nothing, successfully
umount[/b]
Utility to unmount file systems
uname[/b]
Utility to print system information
If /bin/sh[/b] is not a true Bourne shell, it must be a hard or symbolic link to the real shell command.
The [[/b] and test[/b] commands must be placed together in either /bin or /usr/bin.

Rationale

For example bash behaves differently when called as sh[/b] or bash[/b]. The use of a symbolic link also allows users to easily see that /bin/sh[/b] is not a true Bourne shell.
The requirement for the [[/b] and test[/b] commands to be included as binaries (even if implemented internally by the shell) is shared with the POSIX.2 standard.
Specific Options
The following programs, or symbolic links to programs, must be in /bin if the corresponding subsystem is installed:
Command
Description
csh[/b]
The C shell (optional)
ed[/b]
The `ed' editor (optional)
tar[/b]
The tar archiving utility (optional)
cpio[/b]
The cpio archiving utility (optional)
gzip[/b]
The GNU compression utility (optional)
gunzip[/b]
The GNU uncompression utility (optional)
zcat[/b]
The GNU uncompression utility (optional)
netstat[/b]
The network statistics utility (optional)
ping[/b]
The ICMP network test utility (optional)
If the gunzip[/b] and zcat[/b] programs exist, they must be symbolic or hard links to gzip. /bin/csh[/b] may be a symbolic link to /bin/tcsh[/b] or /usr/bin/tcsh[/b].

Rationale

The tar, gzip and cpio commands have been added to make restoration of a system possible (provided that / is intact).
Conversely, if no restoration from the root partition is ever expected, then these binaries might be omitted (e.g., a ROM chip root, mounting /usr through NFS). If restoration of a system is planned through the network, then ftp[/b] or tftp[/b] (along with everything necessary to get an ftp connection) must be available on the root partition.
/boot : Static files of the boot loader
Purpose
This directory contains everything required for the boot process except configuration files not needed at boot time and the map installer. Thus /boot stores data that is used before the kernel begins executing user-mode programs. This may include saved master boot sectors and sector map files. [2]
Specific Options
The operating system kernel must be located in either / or /boot. [3]
/dev : Device files
Purpose
The /dev directory is the location of special or device files.
Specific Options
If it is possible that devices in /dev will need to be manually created, /dev must contain a command named MAKEDEV, which can create devices as needed. It may also contain a MAKEDEV.local for any local devices.
If required, MAKEDEV must have provisions for creating any device that may be found on the system, not just those that a particular implementation installs.
/etc : Host-specific system configuration
Purpose
The /etc hierarchy contains configuration files. A "configuration file" is a local file used to control the operation of a program; it must be static and cannot be an executable binary. [4]
Requirements
No binaries may be located under /etc. [5]
The following directories, or symbolic links to directories are required in /etc:
Directory
Description
opt
Configuration for /opt
X11
Configuration for the X Window system (optional)
sgml
Configuration for SGML (optional)
xml
Configuration for XML (optional)
Specific Options
The following directories, or symbolic links to directories must be in /etc, if the corresponding subsystem is installed:
Directory
Description
opt
Configuration for /opt
The following files, or symbolic links to files, must be in /etc if the corresponding subsystem is installed: [6]
File
Description
csh.login
Systemwide initialization file for C shell logins (optional)
exports
NFS filesystem access control list (optional)
fstab
Static information about filesystems (optional)
ftpusers
FTP daemon user access control list (optional)
gateways
File which lists gateways for routed (optional)
gettydefs
Speed and terminal settings used by getty (optional)
group
User group file (optional)
host.conf
Resolver configuration file (optional)
hosts
Static information about host names (optional)
hosts.allow
Host access file for TCP wrappers (optional)
hosts.deny
Host access file for TCP wrappers (optional)
hosts.equiv
List of trusted hosts for rlogin, rsh, rcp (optional)
hosts.lpd
List of trusted hosts for lpd (optional)
inetd.conf
Configuration file for inetd (optional)
inittab
Configuration file for init (optional)
issue
Pre-login message and identification file (optional)
ld.so.conf
List of extra directories to search for shared libraries (optional)
motd
Post-login message of the day file (optional)
mtab
Dynamic information about filesystems (optional)
mtools.conf
Configuration file for mtools (optional)
networks
Static information about network names (optional)
passwd
The password file (optional)
printcap
The lpd printer capability database (optional)
profile
Systemwide initialization file for sh shell logins (optional)
protocols
IP protocol listing (optional)
resolv.conf
Resolver configuration file (optional)
rpc
RPC protocol listing (optional)
securetty
TTY access control for root login (optional)
services
Port names for network services (optional)
shells
Pathnames of valid login shells (optional)
syslog.conf
Configuration file for syslogd (optional)
mtab does not fit the static nature of /etc: it is excepted for historical reasons. [7]
/etc/opt : Configuration files for /opt
Purpose
Host-specific configuration files for add-on application software packages must be installed within the directory /etc/opt/, where  is the name of the subtree in /opt where the static data from that package is stored.
Requirements
No structure is imposed on the internal arrangement of /etc/opt/.
If a configuration file must reside in a different location in order for the package or system to function properly, it may be placed in a location other than /etc/opt/.

Rationale

Refer to the rationale for /opt.
/etc/X11 : Configuration for the X Window System (optional)
Purpose
/etc/X11[/i] is the location for all X11 host-specific configuration. This directory is necessary to allow local control if /usr[/i] is mounted read only.
Specific Options
The following files, or symbolic links to files, must be in /etc/X11 if the corresponding subsystem is installed:
File
Description
Xconfig
The configuration file for early versions of XFree86 (optional)
XF86Config
The configuration file for XFree86 versions 3 and 4 (optional)
Xmodmap
Global X11 keyboard modification file (optional)
Subdirectories of /etc/X11 may include those for xdm and for any other programs (some window managers, for example) that need them. [8] We recommend that window managers with only one configuration file which is a default .*wmrc file must name it system.*wmrc (unless there is a widely-accepted alternative name) and not use a subdirectory. Any window manager subdirectories must be identically named to the actual window manager binary.
/etc/sgml : Configuration files for SGML (optional)
Purpose
Generic configuration files defining high-level parameters of the SGML systems are installed here. Files with names *.conf indicate generic configuration files. File with names *.cat are the DTD-specific centralized catalogs, containing references to all other catalogs needed to use the given DTD. The super catalog file catalog references all the centralized catalogs.
/etc/xml : Configuration files for XML (optional)
Purpose
Generic configuration files defining high-level parameters of the XML systems are installed here. Files with names *.conf indicate generic configuration files. The super catalog file catalog references all the centralized catalogs.
/home : User home directories (optional)
Purpose
/home is a fairly standard concept, but it is clearly a site-specific filesystem. [9] The setup will differ from host to host. Therefore, no program should rely on this location. [10]
Requirements
User specific configuration files for applications are stored in the user's home directory in a file that starts with the '.' character (a "dot file"). If an application needs to create more than one dot file then they should be placed in a subdirectory with a name starting with a '.' character, (a "dot directory"). In this case the configuration files should not start with the '.' character. [11]
/lib : Essential shared libraries and kernel modules
Purpose
The /lib directory contains those shared library images needed to boot the system and run the commands in the root filesystem, ie. by binaries in /bin and /sbin. [12]
Requirements
At least one of each of the following filename patterns are required (they may be files, or symbolic links):
File
Description
libc.so.*
The dynamically-linked C library (optional)
ld*
The execution time linker/loader (optional)
If a C preprocessor is installed, /lib/cpp[/i] must be a reference to it, for historical reasons. [13]
Specific Options
The following directories, or symbolic links to directories, must be in /lib, if the corresponding subsystem is installed:
Directory
Description
modules
Loadable kernel modules (optional)
/lib : Alternate format essential shared libraries (optional)
Purpose
There may be one or more variants of the /lib directory on systems which support more than one binary format requiring separate libraries. [14]
Requirements
If one or more of these directories exist, the requirements for their contents are the same as the normal /lib directory, except that /lib/cpp is not required. [15]
/media : Mount point for removeable media
Purpose
This directory contains subdirectories which are used as mount points for removeable media such as floppy disks, cdroms and zip disks.

Rationale

Historically there have been a number of other different places used to mount removeable media such as /cdrom, /mnt or /mnt/cdrom. Placing the mount points for all removeable media directly in the root directory would potentially result in a large number of extra directories in /. Although the use of subdirectories in /mnt as a mount point has recently been common, it conflicts with a much older tradition of using /mnt directly as a temporary mount point.
Specific Options
The following directories, or symbolic links to directories, must be in /media, if the corresponding subsystem is installed:
Directory
Description
floppy
Floppy drive (optional)
cdrom
CD-ROM drive (optional)
cdrecorder
CD writer (optional)
zip
Zip drive (optional)
On systems where more than one device exists for mounting a certain type of media, mount directories can be created by appending a digit to the name of those available above starting with '0', but the unqualified name must also exist. [16]
/mnt : Mount point for a temporarily mounted filesystem
Purpose
This directory is provided so that the system administrator may temporarily mount a filesystem as needed. The content of this directory is a local issue and should not affect the manner in which any program is run.
This directory must not be used by installation programs: a suitable temporary directory not in use by the system must be used instead.
/opt : Add-on application software packages
Purpose
/opt is reserved for the installation of add-on application software packages.
A package to be installed in /opt must locate its static files in a separate /opt/ or /opt/ directory tree, where  is a name that describes the software package and  is the provider's LANANA registered name.
Requirements
Directory
Description
Static package objects
LANANA registered provider name
The directories /opt/bin, /opt/doc, /opt/include, /opt/info, /opt/lib, and /opt/man are reserved for local system administrator use. Packages may provide "front-end" files intended to be placed in (by linking or copying) these reserved directories by the local system administrator, but must function normally in the absence of these reserved directories.
Programs to be invoked by users must be located in the directory /opt//bin or under the /opt/ hierarchy. If the package includes UNIX manual pages, they must be located in /opt//share/man or under the /opt/ hierarchy, and the same substructure as /usr/share/man must be used.
Package files that are variable (change in normal operation) must be installed in /var/opt. See the section on /var/opt for more information.
Host-specific configuration files must be installed in /etc/opt. See the section on /etc for more information.
No other package files may exist outside the /opt, /var/opt, and /etc/opt hierarchies except for those package files that must reside in specific locations within the filesystem tree in order to function properly. For example, device lock files must be placed in /var/lock and devices must be located in /dev.
Distributions may install software in /opt, but must not modify or delete software installed by the local system administrator without the assent of the local system administrator.

Rationale

The use of /opt for add-on software is a well-established practice in the UNIX community. The System V Application Binary Interface [AT&T 1990], based on the System V Interface Definition (Third Edition), provides for an /opt structure very similar to the one defined here.
The Intel Binary Compatibility Standard v. 2 (iBCS2) also provides a similar structure for /opt.
Generally, all data required to support a package on a system must be present within /opt/, including files intended to be copied into /etc/opt/ and /var/opt/ as well as reserved directories in /opt.
The minor restrictions on distributions using /opt are necessary because conflicts are possible between distribution-installed and locally-installed software, especially in the case of fixed pathnames found in some binary software.
The structure of the directories below /opt/ is left up to the packager of the software, though it is recommended that packages are installed in /opt// and follow a similar structure to the guidelines for /opt/package. A valid reason for diverging from this structure is for support packages which may have files installed in /opt//lib or /opt//bin.
/root : Home directory for the root user (optional)
Purpose
The root account's home directory may be determined by developer or local preference, but this is the recommended default location. [17]
/sbin : System binaries
Purpose
Utilities used for system administration (and other root-only commands) are stored in /sbin, /usr/sbin, and /usr/local/sbin. /sbin contains binaries essential for booting, restoring, recovering, and/or repairing the system in addition to the binaries in /bin. [18] Programs executed after /usr is known to be mounted (when there are no problems) are generally placed into /usr/sbin. Locally-installed system administration programs should be placed into /usr/local/sbin. [19]
Requirements
The following commands, or symbolic links to commands, are required in /sbin.
Command
Description
shutdown[/b]
Command to bring the system down.
Specific Options
The following files, or symbolic links to files, must be in /sbin if the corresponding subsystem is installed:
Command
Description
fastboot
Reboot the system without checking the disks (optional)
fasthalt
Stop the system without checking the disks (optional)
fdisk
Partition table manipulator (optional)
fsck
File system check and repair utility (optional)
fsck.*
File system check and repair utility for a specific filesystem (optional)
getty
The getty program (optional)
halt
Command to stop the system (optional)
ifconfig
Configure a network interface (optional)
init
Initial process (optional)
mkfs
Command to build a filesystem (optional)
mkfs.*
Command to build a specific filesystem (optional)
mkswap
Command to set up a swap area (optional)
reboot
Command to reboot the system (optional)
route
IP routing table utility (optional)
swapon
Enable paging and swapping (optional)
swapoff
Disable paging and swapping (optional)
update
Daemon to periodically flush filesystem buffers (optional)
/srv : Data for services provided by this system
Purpose
/srv contains site-specific data which is served by this system.

Rationale

This main purpose of specifying this is so that users may find the location of the data files for particular service, and so that services which require a single tree for readonly data, writable data and scripts (such as cgi scripts) can be reasonably placed. Data that is only of interest to a specific user should go in that users' home directory.
The methodology used to name subdirectories of /srv is unspecified as there is currently no consensus on how this should be done. One method for structuring data under /srv is by protocol, eg. ftp, rsync, www, and cvs. On large systems it can be useful to structure /srv by administrative context, such as /srv/physics/www, /srv/compsci/cvs, etc. This setup will differ from host to host. Therefore, no program should rely on a specific subdirectory structure of /srv existing or data necessarily being stored in /srv. However /srv should always exist on FHS compliant systems and should be used as the default location for such data.
Distributions must take care not to remove locally placed files in these directories without administrator permission. [20]
/tmp : Temporary files
Purpose
The /tmp directory must be made available for programs that require temporary files.
Programs must not assume that any files or directories in /tmp are preserved between invocations of the program.

Rationale

IEEE standard P1003.2 (POSIX, part 2) makes requirements that are similar to the above section.
Although data stored in /tmp may be deleted in a site-specific manner, it is recommended that files and directories located in /tmp be deleted whenever the system is booted.
FHS added this recommendation on the basis of historical precedent and common practice, but did not make it a requirement because system administration is not within the scope of this standard.
Chapter 4. The /usr Hierarchy
Purpose
/usr is the second major section of the filesystem. /usr is shareable, read-only data. That means that /usr should be shareable between various FHS-compliant hosts and must not be written to. Any information that is host-specific or varies with time is stored elsewhere.
Large software packages must not use a direct subdirectory under the /usr hierarchy.
Requirements
The following directories, or symbolic links to directories, are required in /usr.
Directory
Description
bin
Most user commands
include
Header files included by C programs
lib
Libraries
local
Local hierarchy (empty after main installation)
sbin
Non-vital system binaries
share
Architecture-independent data
Specific Options
Directory
Description
X11R6
XWindow System, version 11 release 6 (optional)
games
Games and educational binaries (optional)
lib
Alternate Format Libraries (optional)
src
Source code (optional)
An exception is made for the X Window System because of considerable precedent and widely-accepted practice.
The following symbolic links to directories may be present. This possibility is based on the need to preserve compatibility with older systems until all implementations can be assumed to use the /var hierarchy.
    /usr/spool -> /var/spool
    /usr/tmp -> /var/tmp
    /usr/spool/locks -> /var/lock
Once a system no longer requires any one of the above symbolic links, the link may be removed, if desired.
/usr/X11R6 : X Window System, Version 11 Release 6 (optional)
Purpose
This hierarchy is reserved for the X Window System, version 11 release 6, and related files.
To simplify matters and make XFree86 more compatible with the X Window System on other systems, the following symbolic links must be present if /usr/X11R6 exists:
    /usr/bin/X11 -> /usr/X11R6/bin
    /usr/lib/X11 -> /usr/X11R6/lib/X11
    /usr/include/X11 -> /usr/X11R6/include/X11
In general, software must not be installed or managed via the above symbolic links. They are intended for utilization by users only. The difficulty is related to the release version of the X Window System — in transitional periods, it is impossible to know what release of X11 is in use.
Specific Options
Host-specific data in /usr/X11R6/lib/X11 should be interpreted as a demonstration file. Applications requiring information about the current host must reference a configuration file in /etc/X11, which may be linked to a file in /usr/X11R6/lib. [21]
/usr/bin : Most user commands
Purpose
This is the primary directory of executable commands on the system.
Specific Options
The following directories, or symbolic links to directories, must be in /usr/bin, if the corresponding subsystem is installed:
Directory
Description
mh
Commands for the MH mail handling system (optional)
/usr/bin/X11 must be a symlink to /usr/X11R6/bin if the latter exists.
The following files, or symbolic links to files, must be in /usr/bin, if the corresponding subsystem is installed:
Command
Description
perl[/b]
The Practical Extraction and Report Language (optional)
python[/b]
The Python interpreted language (optional)
tclsh[/b]
Simple shell containing Tcl interpreter (optional)
wish[/b]
Simple Tcl/Tk windowing shell (optional)
expect[/b]
Program for interactive dialog (optional)

Rationale

Because shell script interpreters (invoked with #! on the first line of a shell script) cannot rely on a path, it is advantageous to standardize their locations. The Bourne shell and C-shell interpreters are already fixed in /bin, but Perl, Python, and Tcl are often found in many different places. They may be symlinks to the physical location of the shell interpreters.
/usr/include : Directory for standard include files.
Purpose
This is where all of the system's general-use include files for the C programming language should be placed.
Specific Options
The following directories, or symbolic links to directories, must be in /usr/include, if the corresponding subsystem is installed:
Directory
Description
bsd
BSD compatibility include files (optional)
The symbolic link /usr/include/X11 must link to /usr/X11R6/include/X11 if the latter exists.
/usr/lib : Libraries for programming and packages
Purpose
/usr/lib includes object files, libraries, and internal binaries that are not intended to be executed directly by users or shell scripts. [22]
Applications may use a single subdirectory under /usr/lib. If an application uses a subdirectory, all architecture-dependent data exclusively used by the application must be placed within that subdirectory. [23]
Specific Options
For historical reasons, /usr/lib/sendmail[/b] must be a symbolic link to /usr/sbin/sendmail[/b] if the latter exists. [24]
If /lib/X11 exists, /usr/lib/X11 must be a symbolic link to /lib/X11, or to whatever /lib/X11 is a symbolic link to. [25]
/usr/lib : Alternate format libraries (optional)
Purpose
/usr/lib performs the same role as /usr/lib for an alternate binary format, except that the symbolic links /usr/lib/sendmail and /usr/lib/X11 are not required. [26]
/usr/local : Local hierarchy
Purpose
The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr.
Locally installed software must be placed within /usr/local rather than /usr unless it is being installed to replace or upgrade software in /usr. [27]
Requirements
The following directories, or symbolic links to directories, must be in /usr/local
Directory
Description
bin
Local binaries
etc
Host-specific system configuration for local binaries
games
Local game binaries
include
Local C header files
lib
Local libraries
man
Local online manuals
sbin
Local system binaries
share
Local architecture-independent hierarchy
src
Local source code
No other directories, except those listed below, may be in /usr/local after first installing a FHS-compliant system.
Specific Options
If directories /lib or /usr/lib exist, the equivalent directories must also exist in /usr/local.
/usr/local/etc may be a symbolic link to /etc/local.

Rationale

The consistency of /usr/local/etc is beneficial to installers, and is already used in other systems. As all of /usr/local needs to be backed up to reproduce a system, it introduces no additional maintenance overhead, but a symlink to /etc/local is suitable if systems want alltheir configuration under one hierarchy.
Note that /usr/etc is still not allowed: programs in /usr should place configuration files in /etc.
/usr/local/share
The requirements for the contents of this directory are the same as /usr/share. The only additional constraint is that /usr/local/share/man and /usr/local/man directories must be synonomous (usually this means that one of them must be a symbolic link). [28]
/usr/sbin : Non-essential standard system binaries
Purpose
This directory contains any non-essential binaries used exclusively by the system administrator. System administration programs that are required for system repair, system recovery, mounting /usr, or other essential functions must be placed in /sbin instead. [29]
/usr/share : Architecture-independent data
Purpose
The /usr/share hierarchy is for all read-only architecture independent data files. [30]
This hierarchy is intended to be shareable among all architecture platforms of a given OS; thus, for example, a site with i386, Alpha, and PPC platforms might maintain a single /usr/share directory that is centrally-mounted. Note, however, that /usr/share is generally not intended to be shared by different OSes or by different releases of the same OS.
Any program or package which contains or requires data that doesn't need to be modified should store that data in /usr/share (or /usr/local/share, if installed locally). It is recommended that a subdirectory be used in /usr/share for this purpose.
Game data stored in /usr/share/games must be purely static data. Any modifiable files, such as score files, game play logs, and so forth, should be placed in /var/games.
Requirements
The following directories, or symbolic links to directories, must be in /usr/share
Directory
Description
man
Online manuals
misc
Miscellaneous architecture-independent data
Specific Options
The following directories, or symbolic links to directories, must be in /usr/share, if the corresponding subsystem is installed:
Directory
Description
dict
Word lists (optional)
doc
Miscellaneous documentation (optional)
games
Static data files for /usr/games (optional)
info
GNU Info system s primary directory (optional)
locale
Locale information (optional)
nls
Message catalogs for Native language support (optional)
sgml
SGML data (optional)
terminfo
Directories for terminfo database (optional)
tmac
troff macros not distributed with groff (optional)
xml
XML data (optional)
zoneinfo
Timezone information and configuration (optional)
It is recommended that application-specific, architecture-independent directories be placed here. Such directories include groff[/b], perl[/b], ghostscript[/b], texmf[/b], and kbd[/b] (Linux) or syscons[/b] (BSD). They may, however, be placed in /usr/lib for backwards compatibility, at the distributor's discretion. Similarly, a /usr/lib/games hierarchy may be used in addition to the /usr/share/games hierarchy if the distributor wishes to place some game data there.
/usr/share/dict : Word lists (optional)
Purpose
This directory is the home for word lists on the system; Traditionally this directory contains only the English words file, which is used by look(1)[/b] and various spelling programs. words may use either American or British spelling.

Rationale

The reason that only word lists are located here is that they are the only files common to all spell checkers.
Specific Options
The following files, or symbolic links to files, must be in /usr/share/dict, if the corresponding subsystem is installed:
File
Description
words
List of English words (optional)
Sites that require both American and British spelling may link words to /usr/share/dict/american-english or /usr/share/dict/british-english.
Word lists for other languages may be added using the English name for that language, e.g., /usr/share/dict/french, /usr/share/dict/danish, etc. These should, if possible, use an ISO 8859 character set which is appropriate for the language in question; if possible the Latin1 (ISO 8859-1) character set should be used (this is often not possible).
Other word lists must be included here, if present.
/usr/share/man : Manual pages
Purpose
This section details the organization for manual pages throughout the system, including /usr/share/man. Also refer to the section on /var/cache/man.
The primary  of the system is /usr/share/man. /usr/share/man contains manual information for commands and data under the / and /usr filesystems. [31]
Manual pages are stored in //man/. An explanation of , , , and  is given below.
A description of each section follows:
man1: User programs Manual pages that describe publicly accessible commands are contained in this chapter. Most program documentation that a user will need to use is located here.
man2: System calls This section describes all of the system calls (requests for the kernel to perform operations).
man3: Library functions and subroutines Section 3 describes program library routines that are not direct calls to kernel services. This and chapter 2 are only really of interest to programmers.
man4: Special files Section 4 describes the special files, related driver functions, and networking support available in the system. Typically, this includes the device files found in /dev and the kernel interface to networking protocol support.
man5: File formats The formats for many data files are documented in the section 5. This includes various include files, program output files, and system files.
man6: Games This chapter documents games, demos, and generally trivial programs. Different people have various notions about how essential this is.
man7: Miscellaneous Manual pages that are difficult to classify are designated as being section 7. The troff and other text processing macro packages are found here.
man8: System administration Programs used by system administrators for system operation and maintenance are documented here. Some of these programs are also occasionally useful for normal users.
Specific Options
The following directories, or symbolic links to directories, must be in /usr/share//, unless they are empty: [32]
Directory
Description
man1
User programs (optional)
man2
System calls (optional)
man3
Library calls (optional)
man4
Special files (optional)
man5
File formats (optional)
man6
Games (optional)
man7
Miscellaneous (optional)
man8
System administration (optional)
The component  describes the manual section.
Provisions must be made in the structure of /usr/share/man to support manual pages which are written in different (or multiple) languages. These provisions must take into account the storage and reference of these manual pages. Relevant factors include language (including geographical-based differences), and character code set.
This naming of language subdirectories of /usr/share/man is based on Appendix E of the POSIX 1003.1 standard which describes the locale identification string — the most well-accepted method to describe a cultural environment. The  string is:
[_][.][,]
The  field must be taken from ISO 639 (a code for the representation of names of languages). It must be two characters wide and specified with lowercase letters only.
The  field must be the two-letter code of ISO 3166 (a specification of representations of countries), if possible. (Most people are familiar with the two-letter codes used for the country codes in email addresses.) It must be two characters wide and specified with uppercase letters only. [33]
The  field must represent the standard describing the character set. If the field is just a numeric specification, the number represents the number of the international standard describing the character set. It is recommended that this be a numeric representation if possible (ISO standards, especially), not include additional punctuation symbols, and that any letters be in lowercase.
A parameter specifying a  of the profile may be placed after the field, delimited by a comma. This may be used to discriminate between different cultural needs; for instance, dictionary order versus a more systems-oriented collating order. This standard recommends not using the  field, unless it is necessary.
Systems which use a unique language and code set for all manual pages may omit the  substring and store all manual pages in . For example, systems which only have English manual pages coded with ASCII, may store manual pages (the man directories) directly in /usr/share/man. (That is the traditional circumstance and arrangement, in fact.)
Countries for which there is a well-accepted standard character code set may omit the field, but it is strongly recommended that it be included, especially for countries with several competing standards.
Various examples:
Language
Territory
Character Set
Directory
English
—
ASCII
/usr/share/man/en
English
United Kingdom
ISO 8859-15
/usr/share/man/en_GB
English
United States
ASCII
/usr/share/man/en_US
French
Canada
ISO 8859-1
/usr/share/man/fr_CA
French
France
ISO 8859-1
/usr/share/man/fr_FR
German
Germany
ISO 646
/usr/share/man/de_DE.646
German
Germany
ISO 6937
/usr/share/man/de_DE.6937
German
Germany
ISO 8859-1
/usr/share/man/de_DE.88591
German
Switzerland
ISO 646
/usr/share/man/de_CH.646
Japanese
Japan
JIS
/usr/share/man/ja_JP.jis
Japanese
Japan
SJIS
/usr/share/man/ja_JP.sjis
Japanese
Japan
UJIS (or EUC-J)
/usr/share/man/ja_JP.ujis
Similarly, provision must be made for manual pages which are architecture-dependent, such as documentation on device-drivers or low-level system administration commands. These must be placed under an  directory in the appropriate man directory; for example, a man page for the i386 ctrlaltdel(8) command might be placed in /usr/share/man//man8/i386/ctrlaltdel.8.
Manual pages for commands and data under /usr/local are stored in /usr/local/man. Manual pages for X11R6 are stored in /usr/X11R6/man. It follows that all manual page hierarchies in the system must have the same structure as /usr/share/man.
The cat page sections (cat) containing formatted manual page entries are also found within subdirectories of /, but are not required nor may they be distributed in lieu of nroff source manual pages.
The numbered sections "1" through "8" are traditionally defined. In general, the file name for manual pages located within a particular section end with ..
In addition, some large sets of application-specific manual pages have an additional suffix appended to the manual page filename. For example, the MH mail handling system manual pages must have mh appended to all MH manuals. All X Window System manual pages must have an x appended to the filename.
The practice of placing various language manual pages in appropriate subdirectories of /usr/share/man also applies to the other manual page hierarchies, such as /usr/local/man and /usr/X11R6/man. (This portion of the standard also applies later in the section on the optional /var/cache/man structure.)
/usr/share/misc : Miscellaneous architecture-independent data
This directory contains miscellaneous architecture-independent files which don't require a separate subdirectory under /usr/share.
Specific Options
The following files, or symbolic links to files, must be in /usr/share/misc, if the corresponding subsystem is installed:
File
Description
ascii
ASCII character set table (optional)
magic
Default list of magic numbers for the file command (optional)
termcap
Terminal capability database (optional)
termcap.db
Terminal capability database (optional)
Other (application-specific) files may appear here, but a distributor may place them in /usr/lib at their discretion. [34]
/usr/share/sgml : SGML data (optional)
Purpose
/usr/share/sgml contains architecture-independent files used by SGML applications, such as ordinary catalogs (not the centralized ones, see /etc/sgml), DTDs, entities, or style sheets.
Specific Options
The following directories, or symbolic links to directories, must be in /usr/share/sgml, if the corresponding subsystem is installed:
Directory
Description
docbook
docbook DTD (optional)
tei
tei DTD (optional)
html
html DTD (optional)
mathml
mathml DTD (optional)
Other files that are not specific to a given DTD may reside in their own subdirectory.
/usr/share/xml : XML data (optional)
Purpose
/usr/share/xml contains architecture-independent files used by XML applications, such as ordinary catalogs (not the centralized ones, see /etc/sgml), DTDs, entities, or style sheets.
Specific Options
The following directories, or symbolic links to directories, must be in /usr/share/xml, if the corresponding subsystem is installed:
Directory
Description
docbook
docbook XML DTD (optional)
xhtml
XHTML DTD (optional)
mathml
MathML DTD (optional)
/usr/src : Source code (optional)
Purpose
Source code may be place placed in this subdirectory, only for reference purposes. [35]
Chapter 5. The /var Hierarchy
Purpose
/var contains variable data files. This includes spool directories and files, administrative and logging data, and transient and temporary files.
Some portions of /var are not shareable between different systems. For instance, /var/log, /var/lock, and /var/run. Other portions may be shared, notably /var/mail, /var/cache/man, /var/cache/fonts, and /var/spool/news.
/var is specified here in order to make it possible to mount /usr read-only. Everything that once went into /usr that is written to during system operation (as opposed to installation and software maintenance) must be in /var.
If /var cannot be made a separate partition, it is often preferable to move /var out of the root partition and into the /usr partition. (This is sometimes done to reduce the size of the root partition or when space runs low in the root partition.) However, /var must not be linked to /usr because this makes separation of /usr and /var more difficult and is likely to create a naming conflict. Instead, link /var to /usr/var.
Applications must generally not add directories to the top level of /var. Such directories should only be added if they have some system-wide implication, and in consultation with the FHS mailing list.
Requirements
The following directories, or symbolic links to directories, are required in /var.
Directory
Description
cache
Application cache data
lib
Variable state information
local
Variable data for /usr/local
lock
Lock files
log
Log files and directories
opt
Variable data for /opt
run
Data relevant to running processes
spool
Application spool data
tmp
Temporary files preserved between system reboots
Several directories are `reserved' in the sense that they must not be used arbitrarily by some new application, since they would conflict with historical and/or local practice. They are:
    /var/backups
    /var/cron
    /var/msgs
    /var/preserve
Specific Options
The following directories, or symbolic links to directories, must be in /var, if the corresponding subsystem is installed:
Directory
Description
account
Process accounting logs (optional)
crash
System crash dumps (optional)
games
Variable game data (optional)
mail
User mailbox files (optional)
yp
Network Information Service (NIS) database files (optional)
/var/account : Process accounting logs (optional)
Purpose
This directory holds the current active process accounting log and the composite process usage data (as used in some UNIX-like systems by lastcomm[/b] and sa[/b]).
/var/cache : Application cache data
Purpose
/var/cache is intended for cached data from applications. Such data is locally generated as a result of time-consuming I/O or calculation. The application must be able to regenerate or restore the data. Unlike /var/spool, the cached files can be deleted without data loss. The data must remain valid between invocations of the application and rebooting the system.
Files located under /var/cache may be expired in an application specific manner, by the system administrator, or both. The application must always be able to recover from manual deletion of these files (generally because of a disk space shortage). No other requirements are made on the data format of the cache directories.

Rationale

The existence of a separate directory for cached data allows system administrators to set different disk and backup policies from other directories in /var.
Specific Options
Directory
Description
fonts
Locally-generated fonts (optional)
man
Locally-formatted manual pages (optional)
www
WWW proxy or cache data (optional)
Package specific cache data (optional)
/var/cache/fonts : Locally-generated fonts (optional)
Purpose
The directory /var/cache/fonts should be used to store any dynamically-created fonts. In particular, all of the fonts which are automatically generated by mktexpk[/b] must be located in appropriately-named subdirectories of /var/cache/fonts. [36]
Specific Options
Other dynamically created fonts may also be placed in this tree, under appropriately-named subdirectories of /var/cache/fonts.
/var/cache/man : Locally-formatted manual pages (optional)
Purpose
This directory provides a standard location for sites that provide a read-only /usr partition, but wish to allow caching of locally-formatted man pages. Sites that mount /usr as writable (e.g., single-user installations) may choose not to use /var/cache/man and may write formatted man pages into the cat directories in /usr/share/man directly. We recommend that most sites use one of the following options instead:
Preformat all manual pages alongside the unformatted versions.
Allow no caching of formatted man pages, and require formatting to be done each time a man page is brought up.
Allow local caching of formatted man pages in /var/cache/man.
The structure of /var/cache/man needs to reflect both the fact of multiple man page hierarchies and the possibility of multiple language support.
Given an unformatted manual page that normally appears in /man//man, the directory to place formatted man pages in is /var/cache/man///cat, where  is derived from  by removing any leading usr and/or trailing share pathname components. (Note that the  component may be missing.) [37]
Man pages written to /var/cache/man may eventually be transferred to the appropriate preformatted directories in the source man hierarchy or expired; likewise formatted man pages in the source man hierarchy may be expired if they are not accessed for a period of time.
If preformatted manual pages come with a system on read-only media (a CD-ROM, for instance), they must be installed in the source man hierarchy (e.g. /usr/share/man/cat). /var/cache/man is reserved as a writable cache for formatted manual pages.

Rationale

Release 1.2 of the standard specified /var/catman for this hierarchy. The path has been moved under /var/cache to better reflect the dynamic nature of the formatted man pages. The directory name has been changed to man to allow for enhancing the hierarchy to include post-processed formats other than "cat", such as PostScript, HTML, or DVI.
/var/crash : System crash dumps (optional)
Purpose
This directory holds system crash dumps. As of the date of this release of the standard, system crash dumps were not supported under Linux but may be supported by other systems which may comply with the FHS.
/var/games : Variable game data (optional)
Purpose
Any variable data relating to games in /usr should be placed here. /var/games should hold the variable data previously found in /usr; static data, such as help text, level descriptions, and so on, must remain elsewhere, such as /usr/share/games.

Rationale

/var/games has been given a hierarchy of its own, rather than leaving it merged in with the old /var/lib as in release 1.2. The separation allows local control of backup strategies, permissions, and disk usage, as well as allowing inter-host sharing and reducing clutter in /var/lib. Additionally, /var/games is the path traditionally used by BSD.
/var/lib : Variable state information
Purpose
This hierarchy holds state information pertaining to an application or the system. State information is data that programs modify while they run, and that pertains to one specific host. Users must never need to modify files in /var/lib to configure a package's operation.
State information is generally used to preserve the condition of an application (or a group of inter-related applications) between invocations and between different instances of the same application. State information should generally remain valid after a reboot, should not be logging output, and should not be spooled data.
An application (or a group of inter-related applications) must use a subdirectory of /var/lib for its data. There is one required subdirectory, /var/lib/misc, which is intended for state files that don't need a subdirectory; the other subdirectories should only be present if the application in question is included in the distribution. [38]
/var/lib/ is the location that must be used for all distribution packaging support. Different distributions may use different names, of course.
Requirements
The following directories, or symbolic links to directories, are required in /var/lib:
Directory
Description
misc
Miscellaneous state data
Specific Options
The following directories, or symbolic links to directories, must be in /var/lib, if the corresponding subsystem is installed:
Directory
Description
Editor backup files and state (optional)
Packaging support files (optional)
State data for packages and subsystems (optional)
hwclock[/b]
State directory for hwclock (optional)
xdm[/b]
X display manager variable data (optional)
/var/lib/ : Editor backup files and state (optional)
Purpose
These directories contain saved files generated by any unexpected termination of an editor (e.g., elvis[/b], jove[/b], nvi[/b]).
Other editors may not require a directory for crash-recovery files, but may require a well-defined place to store other information while the editor is running. This information should be stored in a subdirectory under /var/lib (for example, GNU Emacs would place lock files in /var/lib/emacs/lock).
Future editors may require additional state information beyond crash-recovery files and lock files — this information should also be placed under /var/lib/.

Rationale

Previous Linux releases, as well as all commercial vendors, use /var/preserve for vi or its clones. However, each editor uses its own format for these crash-recovery files, so a separate directory is needed for each editor.
Editor-specific lock files are usually quite different from the device or resource lock files that are stored in /var/lock and, hence, are stored under /var/lib.
/var/lib/hwclock : State directory for hwclock (optional)
Purpose
This directory contains the file /var/lib/hwclock/adjtime.

Rationale

In FHS 2.1, this file was /etc/adjtime, but as hwclock[/b] updates it, that was obviously incorrect.
/var/lib/misc : Miscellaneous variable data
Purpose
This directory contains variable data not placed in a subdirectory in /var/lib. An attempt should be made to use relatively unique names in this directory to avoid namespace conflicts. [39]
/var/lock : Lock files
Purpose
Lock files should be stored within the /var/lock directory structure.
Lock files for devices and other resources shared by multiple applications, such as the serial device lock files that were originally found in either /usr/spool/locks or /usr/spool/uucp, must now be stored in /var/lock. The naming convention which must be used is "LCK.." followed by the base name of the device. For example, to lock /dev/ttyS0 the file "LCK..ttyS0" would be created. [40]
The format used for the contents of such lock files must be the HDB UUCP lock file format. The HDB format is to store the process identifier (PID) as a ten byte ASCII decimal number, with a trailing newline. For example, if process 1230 holds a lock file, it would contain the eleven characters: space, space, space, space, space, space, one, two, three, zero, and newline.
/var/log : Log files and directories
Purpose
This directory contains miscellaneous log files. Most logs must be written to this directory or an appropriate subdirectory.
Specific Options
The following files, or symbolic links to files, must be in /var/log, if the corresponding subsystem is installed:
File
Description
lastlog
record of last login of each user
messages
system messages from syslogd[/b]
wtmp
record of all logins and logouts
/var/mail : User mailbox files (optional)
Purpose
The mail spool must be accessible through /var/mail and the mail spool files must take the form . [41]
User mailbox files in this location must be stored in the standard UNIX mailbox format.

Rationale

The logical location for this directory was changed from /var/spool/mail in order to bring FHS in-line with nearly every UNIX implementation. This change is important for inter-operability since a single /var/mail is often shared between multiple hosts and multiple UNIX implementations (despite NFS locking issues).
It is important to note that there is no requirement to physically move the mail spool to this location. However, programs and header files must be changed to use /var/mail.
/var/opt : Variable data for /opt
Purpose
Variable data of the packages in /opt must be installed in /var/opt/, where  is the name of the subtree in /opt where the static data from an add-on software package is stored, except where superseded by another file in /etc. No structure is imposed on the internal arrangement of /var/opt/.

Rationale

Refer to the rationale for /opt.
/var/run : Run-time variable data
Purpose
This directory contains system information data describing the system since it was booted. Files under this directory must be cleared (removed or truncated as appropriate) at the beginning of the boot process. Programs may have a subdirectory of /var/run; this is encouraged for programs that use more than one run-time file. [42] Process identifier (PID) files, which were originally placed in /etc, must be placed in /var/run. The naming convention for PID files is .pid. For example, the crond[/b] PID file is named /var/run/crond.pid.
Requirements
The internal format of PID files remains unchanged. The file must consist of the process identifier in ASCII-encoded decimal, followed by a newline character. For example, if crond[/b] was process number 25, /var/run/crond.pid would contain three characters: two, five, and newline.
Programs that read PID files should be somewhat flexible in what they accept; i.e., they should ignore extra whitespace, leading zeroes, absence of the trailing newline, or additional lines in the PID file. Programs that create PID files should use the simple specification located in the above paragraph.
The utmp file, which stores information about who is currently using the system, is located in this directory.
System programs that maintain transient UNIX-domain sockets must place them in this directory.
/var/spool : Application spool data
Purpose
/var/spool contains data which is awaiting some kind of later processing. Data in /var/spool represents work to be done in the future (by a program, user, or administrator); often data is deleted after it has been processed. [43]
Specific Options
The following directories, or symbolic links to directories, must be in /var/spool, if the corresponding subsystem is installed:
Directory
Description
lpd
Printer spool directory (optional)
mqueue
Outgoing mail queue (optional)
news
News spool directory (optional)
rwho
Rwhod files (optional)
uucp
Spool directory for UUCP (optional)
/var/spool/lpd : Line-printer daemon print queues (optional)
Purpose
The lock file for lpd[/b], lpd.lock, must be placed in /var/spool/lpd. It is suggested that the lock file for each printer be placed in the spool directory for that specific printer and named lock.
Specific Options
Directory
Description
printer
Spools for a specific printer (optional)
/var/spool/rwho : Rwhod files (optional)
Purpose
This directory holds the rwhod[/b] information for other systems on the local net.

Rationale

Some BSD releases use /var/rwho for this data; given its historical location in /var/spool on other systems and its approximate fit to the definition of `spooled' data, this location was deemed more appropriate.
/var/tmp : Temporary files preserved between system reboots
Purpose
The /var/tmp directory is made available for programs that require temporary files or directories that are preserved between system reboots. Therefore, data stored in /var/tmp is more persistent than data in /tmp.
Files and directories located in /var/tmp must not be deleted when the system is booted. Although data stored in /var/tmp is typically deleted in a site-specific manner, it is recommended that deletions occur at a less frequent interval than /tmp.
/var/yp : Network Information Service (NIS) database files (optional)
Purpose
Variable data for the Network Information Service (NIS), formerly known as the Sun Yellow Pages (YP), must be placed in this directory.

Rationale

/var/yp is the standard directory for NIS (YP) data and is almost exclusively used in NIS documentation and systems. [44]
Chapter 6. Operating System Specific Annex
This section is for additional requirements and recommendations that only apply to a specific operating system. The material in this section should never conflict with the base standard.
Linux
This is the annex for the Linux operating system.
/ : Root directory
On Linux systems, if the kernel is located in /, we recommend using the names vmlinux or vmlinuz, which have been used in recent Linux kernel source packages.
/bin : Essential user command binaries (for use by all users)
Linux systems which require them place these additional files into /bin:
setserial[/b]
/dev : Devices and special files
The following devices must exist under /dev.
/dev/null
All data written to this device is discarded. A read from this device will return an EOF condition.
/dev/zero
This device is a source of zeroed out data. All data written to this device is discarded. A read from this device will return as many bytes containing the value zero as was requested.
/dev/tty
This device is a synonym for the controlling terminal of a process. Once this device is opened, all reads and writes will behave as if the actual controlling terminal device had been opened.

Rationale

Previous versions of the FHS had stricter requirements for /dev. Other devices may also exist in /dev. Device names may exist as symbolic links to other device nodes located in /dev or subdirectories of /dev. There is no requirement concerning major/minor number values.
/etc : Host-specific system configuration
Linux systems which require them place these additional files into /etc.
lilo.conf
/lib64 and /lib32 : 64/32-bit libraries (architecture dependent)
The 64-bit architectures PPC64, s390x, sparc64 and AMD64 must place 64-bit libraries in /lib64, and 32-bit (or 31-bit on s390) libraries in /lib.
The 64-bit architecture IA64 must place 64-bit libraries in /lib.

Rationale

This is a refinement of the general rules for /lib and /usr/lib. The architectures PPC64, s390x, sparc64 and AMD64 support support both 32-bit (for s390 more precise 31-bit) and 64-bit programs. Using lib for 32-bit binaries allows existing binaries from the 32-bit systems to work without any changes: such binaries are expected to be numerous. IA-64 uses a different scheme, reflecting the deprecation of 32-bit binaries (and hence libraries) on that architecture.
/proc : Kernel and process information virtual filesystem
The proc filesystem is the de-facto standard Linux method for handling process and system information, rather than /dev/kmem and other similar methods. We strongly encourage this for the storage and retrieval of process information as well as other kernel and memory information.
/sbin : Essential system binaries
Linux systems place these additional files into /sbin.
Second extended filesystem commands (optional):
badblocks[/b]
dumpe2fs[/b]
e2fsck[/b]
mke2fs[/b]
mklost+found[/b]
tune2fs[/b]
Boot-loader map installer (optional):
lilo[/b]
Optional files for /sbin:
Static binaries:
ldconfig[/b]
sln[/b]
ssync[/b]
Static ln[/b] (sln[/b]) and static sync[/b] (ssync[/b]) are useful when things go wrong. The primary use of sln[/b] (to repair incorrect symlinks in /lib after a poorly orchestrated upgrade) is no longer a major concern now that the ldconfig[/b] program (usually located in /usr/sbin) exists and can act as a guiding hand in upgrading the dynamic libraries. Static sync[/b] is useful in some emergency situations. Note that these need not be statically linked versions of the standard ln[/b] and sync[/b], but may be.
The ldconfig[/b] binary is optional for /sbin since a site may choose to run ldconfig[/b] at boot time, rather than only when upgrading the shared libraries. (It's not clear whether or not it is advantageous to run ldconfig[/b] on each boot.) Even so, some people like ldconfig[/b] around for the following (all too common) situation:
I've just removed /lib/.
I can't find out the name of the library because ls[/b] is dynamically linked, I'm using a shell that doesn't have ls[/b] built-in, and I don't know about using "echo *[/b]" as a replacement.
I have a static sln[/b], but I don't know what to call the link.
Miscellaneous:
ctrlaltdel[/b]
kbdrate[/b]
So as to cope with the fact that some keyboards come up with such a high repeat rate as to be unusable, kbdrate[/b] may be installed in /sbin on some systems.
Since the default action in the kernel for the Ctrl-Alt-Del key combination is an instant hard reboot, it is generally advisable to disable the behavior before mounting the root filesystem in read-write mode. Some init[/b] suites are able to disable Ctrl-Alt-Del, but others may require the ctrlaltdel[/b] program, which may be installed in /sbin on those systems.
/usr/include : Header files included by C programs
These symbolic links are required if a C or C++ compiler is installed and only for systems not based on glibc.
    /usr/include/asm -> /usr/src/linux/include/asm-
    /usr/include/linux -> /usr/src/linux/include/linux
/usr/src : Source code
For systems based on glibc, there are no specific guidelines for this directory. For systems based on Linux libc revisions prior to glibc, the following guidelines and rationale apply:
The only source code that should be placed in a specific location is the Linux kernel source code. It is located in /usr/src/linux.
If a C or C++ compiler is installed, but the complete Linux kernel source code is not installed, then the include files from the kernel source code must be located in these directories:
    /usr/src/linux/include/asm-
    /usr/src/linux/include/linux
is the name of the system architecture.

Note

/usr/src/linux may be a symbolic link to a kernel source code tree.

Rationale

It is important that the kernel include files be located in /usr/src/linux and not in /usr/include so there are no problems when system administrators upgrade their kernel version for the first time.
/var/spool/cron : cron and at jobs
This directory contains the variable data for the cron[/b] and at[/b] programs.
Chapter 7. Appendix
The FHS mailing list
The FHS mailing list is located at . You can subscribe to the mailing list at this page http://sourceforge.net/projects/freestandards/.
Thanks to Network Operations at the University of California at San Diego who allowed us to use their excellent mailing list server.
As noted in the introduction, please do not send mail to the mailing list without first contacting the FHS editor or a listed contributor.
Background of the FHS
The process of developing a standard filesystem hierarchy began in August 1993 with an effort to restructure the file and directory structure of Linux. The FSSTND, a filesystem hierarchy standard specific to the Linux operating system, was released on February 14, 1994. Subsequent revisions were released on October 9, 1994 and March 28, 1995.
In early 1995, the goal of developing a more comprehensive version of FSSTND to address not only Linux, but other UNIX-like systems was adopted with the help of members of the BSD development community. As a result, a concerted effort was made to focus on issues that were general to UNIX-like systems. In recognition of this widening of scope, the name of the standard was changed to Filesystem Hierarchy Standard or FHS for short.
Volunteers who have contributed extensively to this standard are listed at the end of this document. This standard represents a consensus view of those and other contributors.
General Guidelines
Here are some of the guidelines that have been used in the development of this standard:
Solve technical problems while limiting transitional difficulties.
Make the specification reasonably stable.
Gain the approval of distributors, developers, and other decision-makers in relevant development groups and encourage their participation.
Provide a standard that is attractive to the implementors of different UNIX-like systems.
Scope
This document specifies a standard filesystem hierarchy for FHS filesystems by specifying the location of files and directories, and the contents of some system files.
This standard has been designed to be used by system integrators, package developers, and system administrators in the construction and maintenance of FHS compliant filesystems. It is primarily intended to be a reference and is not a tutorial on how to manage a conforming filesystem hierarchy.
The FHS grew out of earlier work on FSSTND, a filesystem organization standard for the Linux operating system. It builds on FSSTND to address interoperability issues not just in the Linux community but in a wider arena including 4.4BSD-based operating systems. It incorporates lessons learned in the BSD world and elsewhere about multi-architecture support and the demands of heterogeneous networking.
Although this standard is more comprehensive than previous attempts at filesystem hierarchy standardization, periodic updates may become necessary as requirements change in relation to emerging technology. It is also possible that better solutions to the problems addressed here will be discovered so that our solutions will no longer be the best possible solutions. Supplementary drafts may be released in addition to periodic updates to this document. However, a specific goal is backwards compatibility from one release of this document to the next.
Comments related to this standard are welcome. Any comments or suggestions for changes may be directed to the FHS editor (Daniel Quinlan ) or the FHS mailing list. Typographical or grammatical comments should be directed to the FHS editor.
Before sending mail to the mailing list it is requested that you first contact the FHS editor in order to avoid excessive re-discussion of old topics.
Questions about how to interpret items in this document may occasionally arise. If you have need for a clarification, please contact the FHS editor. Since this standard represents a consensus of many participants, it is important to make certain that any interpretation also represents their collective opinion. For this reason it may not be possible to provide an immediate response unless the inquiry has been the subject of previous discussion.
Acknowledgments
The developers of the FHS wish to thank the developers, system administrators, and users whose input was essential to this standard. We wish to thank each of the contributors who helped to write, compile, and compose this standard.
The FHS Group also wishes to thank those Linux developers who supported the FSSTND, the predecessor to this standard. If they hadn't demonstrated that the FSSTND was beneficial, the FHS could never have evolved.
Contributors
Brandon S. Allbery
Keith Bostic
Drew Eckhardt
Rik Faith
Stephen Harris
Ian Jackson
Andreas Jaeger
John A. Martin
Ian McCloghrie
Chris Metcalf
Ian Murdock
David C. Niemi
Daniel Quinlan
Eric S. Raymond
Rusty Russell
Mike Sangrey
David H. Silber
Thomas Sippel-Dau
Theodore Ts'o
Stephen Tweedie
Fred N. van Kempen
Bernd Warken
Christopher Yeoh
Notes
[1]
Command binaries that are not essential enough to place into /bin must be placed in /usr/bin, instead. Items that are required only by non-root users (the X Window System, chsh, etc.) are generally not essential enough to be placed into the root partition.
[2]
Programs necessary to arrange for the boot loader to be able to boot a file must be placed in /sbin. Configuration files for boot loaders must be placed in /etc.
The GRUB bootloader reads its configurations file before booting, so that must be placed in /boot. However, it is a configuration file, so should be in /etc. The answer here is a symbolic link such as /etc/grub/menu.lst -> /boot/menu.lst.
[3]
On some i386 machines, it may be necessary for /boot to be located on a separate partition located completely below cylinder 1024 of the boot device due to hardware constraints.
Certain MIPS systems require a /boot partition that is a mounted MS-DOS filesystem or whatever other filesystem type is accessible for the firmware. This may result in restrictions with respect to usable filenames within /boot (only for affected systems).
[4]
The setup of command scripts invoked at boot time may resemble System V, BSD or other models. Further specification in this area may be added to a future version of this standard.
[5]
It is recommended that files be stored in subdirectories of /etc rather than directly in /etc.
[6]
Systems that use the shadow password suite will have additional configuration files in /etc (/etc/shadow and others) and programs in /usr/sbin (useradd[/b], usermod[/b], and others).
[7]
On some Linux systems, this may be a symbolic link to /proc/mounts, in which case this exception is not required.
[8]
/etc/X11/xdm holds the configuration files for xdm. These are most of the files previously found in /usr/lib/X11/xdm. Some local variable data for xdm is stored in /var/lib/xdm.
[9]
Different people prefer to place user accounts in a variety of places. This section describes only a suggested placement for user home directories; nevertheless we recommend that all FHS-compliant distributions use this as the default location for home directories.
On small systems, each user's directory is typically one of the many subdirectories of /home such as /home/smith, /home/torvalds, /home/operator, etc. On large systems (especially when the /home directories are shared amongst many hosts using NFS) it is useful to subdivide user home directories. Subdivision may be accomplished by using subdirectories such as /home/staff, /home/guests, /home/students, etc.
[10]
If you want to find out a user's home directory, you should use the getpwent(3) library function rather than relying on /etc/passwd because user information may be stored remotely using systems such as NIS.
[11]
It is recommended that apart from autosave and lock files programs should refrain from creating non dot files or directories in a home directory without user intervention.
[12]
Shared libraries that are only necessary for binaries in /usr (such as any X Window binaries) must not be in /lib. Only the shared libraries required to run binaries in /bin and /sbin may be here. In particular, the library libm.so.* may also be placed in /usr/lib if it is not required by anything in /bin or /sbin.
[13]
The usual placement of this binary is /usr/bin/cpp.
[14]
This is commonly used for 64-bit or 32-bit support on systems which support multiple binary formats, but require libraries of the same name. In this case, /lib32 and /lib64 might be the library directories, and /lib a symlink to one of them.
[15]
/lib/cpp is still permitted: this allows the case where /lib and /lib are the same (one is a symbolic link to the other).
[16]
A compliant implementation with two CDROM drives might have /media/cdrom0 and /media/cdrom1 with /media/cdrom a symlink to either of these.
[17]
If the home directory of the root account is not stored on the root partition it will be necessary to make certain it will default to / if it can not be located.
We recommend against using the root account for tasks that can be performed as an unprivileged user, and that it be used solely for system administration. For this reason, we recommend that subdirectories for mail and other applications not appear in the root account's home directory, and that mail for administration roles such as root, postmaster, and webmaster be forwarded to an appropriate user.
[18]
Originally, /sbin binaries were kept in /etc.
[19]
Deciding what things go into "sbin"[/i] directories is simple: if a normal (not a system administrator) user will ever run it directly, then it must be placed in one of the "bin"[/i] directories. Ordinary users should not have to place any of the sbin directories in their path.
For example, files such as chfn[/b] which users only occasionally use must still be placed in /usr/bin. ping[/b], although it is absolutely necessary for root (network recovery and diagnosis) is often used by users and must live in /bin for that reason.
We recommend that users have read and execute permission for everything in /sbin except, perhaps, certain setuid and setgid programs. The division between /bin and /sbin was not created for security reasons or to prevent users from seeing the operating system, but to provide a good partition between binaries that everyone uses and ones that are primarily used for administration tasks. There is no inherent security advantage in making /sbin off-limits for users.
[20]
This is particularly important as these areas will often contain both files initially installed by the distributor, and those added by the administrator.
[21]
Examples of such configuration files include Xconfig, XF86Config, or system.twmrc)
[22]
Miscellaneous architecture-independent application-specific static files and subdirectories must be placed in /usr/share.
[23]
For example, the perl5 subdirectory for Perl 5 modules and libraries.
[24]
Some executable commands such as makewhatis[/b] and sendmail[/b] have also been traditionally placed in /usr/lib. makewhatis[/b] is an internal binary and must be placed in a binary directory; users access only catman[/b]. Newer sendmail[/b] binaries are now placed by default in /usr/sbin. Additionally, systems using a sendmail[/i]-compatible mail transfer agent must provide /usr/sbin/sendmail[/b] as a symbolic link to the appropriate executable.
[25]
Host-specific data for the X Window System must not be stored in /usr/lib/X11. Host-specific configuration files such as Xconfig or XF86Config must be stored in /etc/X11. This includes configuration data such as system.twmrc even if it is only made a symbolic link to a more global configuration file (probably in /usr/X11R6/lib/X11).
[26]
The case where /usr/lib and /usr/lib are the same (one is a symbolic link to the other) these files and the per-application subdirectories will exist.
[27]
Software placed in / or /usr may be overwritten by system upgrades (though we recommend that distributions do not overwrite data in /etc under these circumstances). For this reason, local software must not be placed outside of /usr/local without good reason.
[28]
/usr/local/man may be deprecated in future FHS releases, so if all else is equal, making that one a symlink seems sensible.
[29]
Locally installed system administration programs should be placed in /usr/local/sbin.
[30]
Much of this data originally lived in /usr (man, doc) or /usr/lib (dict, terminfo, zoneinfo).
[31]
Obviously, there are no manual pages in / because they are not required at boot time nor are they required in emergencies. Really.
[32]
For example, if /usr/local/man has no manual pages in section 4 (Devices), then /usr/local/man/man4 may be omitted.
[33]
A major exception to this rule is the United Kingdom, which is `GB' in the ISO 3166, but `UK' for most email addresses.
[34]
Some such files include: airport, birthtoken, eqnchar, getopt, gprof.callg, gprof.flat, inter.phone, ipfw.samp.filters, ipfw.samp.scripts, keycap.pcvt, mail.help, mail.tildehelp, man.template, map3270, mdoc.template, more.help, na.phone, nslookup.help, operator, scsi_modes, sendmail.hf, style, units.lib, vgrindefs, vgrindefs.db, zipcodes
[35]
Generally, source should not be built within this hierarchy.
[36]
This standard does not currently incorporate the TeX Directory Structure (a document that describes the layout TeX files and directories), but it may be useful reading. It is located at ftp://ctan.tug.org/tex/
[37]
For example, /usr/share/man/man1/ls.1 is formatted into /var/cache/man/cat1/ls.1, and /usr/X11R6/man//man3/XtClass.3x into /var/cache/man/X11R6//cat3/XtClass.3x.
[38]
An important difference between this version of this standard and previous ones is that applications are now required to use a subdirectory of /var/lib.
[39]
This hierarchy should contain files stored in /var/db in current BSD releases. These include locate.database and mountdtab, and the kernel symbol database(s).
[40]
Then, anything wishing to use /dev/ttyS0 can read the lock file and act accordingly (all locks in /var/lock should be world-readable).
[41]
Note that /var/mail may be a symbolic link to another directory.
[42]
/var/run should be unwritable for unprivileged users (root or users running daemons); it is a major security problem if any user can write in this directory.
[43]
UUCP lock files must be placed in /var/lock. See the above section on /var/lock.
[44]
NIS should not be confused with Sun NIS+, which uses a different directory, /var/nis.

Error 500.13 (Server too busy) 解决方案

flyinweb — 2009-6-10 13:53:45

Error 500.13 (Server too busy) with many sites on one machine

There are 4 main reasons in IIS 6 why the Server Too Busy error will be displayed
in response to an ASP request:

1) The application pool's ASP queue is full (or in other words, the metabase value
ASPRequestQueueMax has been reached)

2) A new App Pool cannot be spawned due to OS process limits (or in other words, we
have reached the maximum number of concurrently running application pools.

3) An ASP request has been in the ASP queue longer than the value set for the
metabase key ASPQueueTimeout

4) We have run out of desktop heap.

I would take a Hang dump using DebugDiag tool and see what is happening and why the requests are taking long time to execute. Normally this would turn out to be code issue.

Important : Are you running these sites in Seperate app pools or 1 single app pool? If they are in single pool, then try seperating them in different app pool.

Another thing is system resources, are you running many products like SQL/Exchange on the same box as IIS and also are they any third party apps, many processes running on this box? If there are many processes running it might cause desktop heap issue. you could use Dheapmonitor and see if there is enough desktop heap available to spwan a new process.

***********************************************************

I wanted to post the solution to this problem as it cost me a $300 call to MS tech support to find the answer. The fix is very simple and is applicable to MANY other situations on nearly every recent windows OS. Basically I was running out of non-interactive desktop heap even though I had a vast surplus of memory. The reason for this is that every single version of windows is CRIPPLED by default with very restrictive heap limits which make absolutely no sense even for hardware from 5 or 10 years ago. There are 2 things you can do to fix this. First, you can increase the maximum total heap size using the following steps:

1.  Start Registry Editor.

2.  Locate and then click the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management

3.  Configure the following entries:

Name: SessionViewSize
Data Type: REG_DWORD
Value data: 120 (decimal)

4. Configure the following entries:

Name: SessionPoolSize
Data Type: REG_DWORD
Value data: 60 (decimal)

That alone will not fix the problem because now you need to increase the limits on the specific sections of the desktop heap, namely the Interactive and Non-Interactive parts:

1.  Start Registry Editor.

2.  Locate and then click the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Subsytems

3.  Find the value in this key called Windows, it will be a long string of name-value pairs that looks something like this:

%SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows SharedSection=1024,3072,512 Windows=On SubSystemType=Windows ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=winsrv:ConServerDllInitialization,2 ProfileControl=Off MaxRequestThreads=16

The portion of this section that we're interested in is the "SharedSection=1024,3072,512" part. Those 3 numbers define, in kb, the size of various specific heap limits in this order: global, interactive, non-interactive. You most likely will not ever need to mess with the first one (global).

The third (non-interactive) value is the one that enabled me to host hundreds/thousands of sites on a single server without getting the 500.13 errors. If you're running more than about 60-80 IIS websites and getting those 500.13's like I was, you need to increase this number. I increased it to 8192 on my server (an 8-core dual xeon with 8 GB RAM) and am now able to run more websites on that one machine than I was able to run on 6 separate windows servers without the adjustment. Needless to say this clever limitation is making MS a lot of $$$ and I am living proof. I bought 6 copies of server 2k3 x64 when I could have done it with 1! In light of this and hardware costs the $300 it cost me to find out was well worth it.

The second (interactive) value can be increased to allow you to scale your usage of interactive desktop heap, or in other words you can now run way more windows desktop apps simultaneously. I found this to be of particular value on a windows xp machine that I was trying to run many (100+) copies of the same app. After a certain points the instances would become unstable and could not spawn any more processes. I increased the middle value and the limit was lifted.

After adjusting these numbers reboot your machine and do performance tests to verify that you are now able to run everything without problems. Increasing the individual numbers too much can make you use up too much memory and eventually hit that total heap maximum we adjusted in the first part (which is why we increased it to help prevent this from happening.) I suggest increasing in 2 MB increments until you hit a point where you are no longer hitting those limits, but don't push it much further than you need to. As I mentioned before, I'm having no problems with my numbers set to 1024,10240,8192 and can run over 600 websites (and probably thousands more) without a hitch.

I find it hard to believe that I've never run across anything on the web that really talks about the significance of these numbers and what a massive artificially-imposed limitation they are on the windows platform. There are a couple of reference pages here and there which talk about adjusting the heap but they carefully avoid talking in detail about the real-world implications. Also I did see in at least one or two places people posting on forums who had the exact same problem/scenario as me but they never got the answer they needed and NOWHERE on the web have I ever been able to find a link between the 500.13 problem (which plagues even 2k8 servers) and the desktop heap adjustments fix to it. Also I haven't found any page at all which really explains, in a way that most people would find useful, how to go about tweaking these numbers to your particular situation.

To most home users this is probably no big deal but for we business users who are trying to maximize our performance and fully take advantage of new hardware (especially those doing windows web hosting), this heap issue is massively important. Personally I think MS should have refunded my $300 on grounds that is a (mostly) undocumented bug but I'm sure they have a different "perspective" on the whole issue and I didn't bother trying to argue it. At best I can hope to prevent them from making some more money off other poor suckers who are trying to find the answer to the same problem.

I should also mention that the MS techs were not especially forthcoming about WHY I was having this problem and what these various tweaks were doing. It was as if they wanted to solve my problem just enough to make me go away without actually letting me understand what was going on. The only reason I know as much as I do is because I badgered them relentlessly for the missing info, the why's and how's. This after I paid them $300 for the support call. And it took them nearly 2 weeks to finally get to a resolution. They did not seem to want to encourage me to explore the upper limits of these numbers and they did not really seem to want to explain the rationale behind how to tweak them. I had to drag it out of them.

Also I should note that this specific problem will most likely not affect you if you are running IIS in purely x64 mode. I am running classic ASP apps which make use of 32-bit DLLs like ASPUpload so my IIS has to be set to run in a 32 bit compatible mode.

I hope this helps at least one person out there because I spent literally years trying to find a solution, and $10,000's trying to work around not having a solution. (Buying and hosting lots of servers and windows licenses.)

As a cross-platform dev who has always been the devils advocate for MS, I am now thoroughly disgusted and alienated by this company and although I'll continue to develop and support my existing applications I am done doing any new development on this platform.

informix sysmaster表详解

flyinweb — 2009-6-9 14:25:54

一、实例信息
*sysconfig  ————>;  onconfig文件
*sysprofile ————>; 服务器统计信息
*syslog ————>; 逻辑日志
*sysvpprof ————>; 虚拟处理器
create table "sysmaster".sysconfig {服务器配置参数}
(
  cf_id   integer,   {唯一数字标志符 }
  cf_name   char(18),  {onconfig参数名 }
  cf_flags    integer,   {标志，0=在视图中 }
  cf_original  char(256), {启动时在onconfig中的值 }
  cf_effective char(256), {实际使用的值 }
  cf_default   char(256)  {onconfig文件中不指定时默认使用的值 }
);
grant select on sysconfig to public;

create table "sysmaster".sysprofile {服务器概貌信息}
(
  name char(13), {概貌元素名 }
  value integer    {当前值 }
);
grant select on sysprofile to public;

create table "sysmaster".syslogs {逻辑日志信息}
(
  number smallint, {日志文件号 }
  uniqid  integer,  {日志文件唯一ID }
  size integer,  {日志文件页 }
  used integer,  {日志文件使用的页 }
  is_used integer,  {1为已用，0为未用 }
  is_current integer,  {1为当前 }
  is_backed_up integer,  {1为备份 }
  is_new integer,  {1为新 }
  is_archived integer,  {1为存档 }
  is_temp integer,  {1为临时 }
  flags    smallint  {日志文件标志 }
);
grant select on syslogs to public;

create table "sysmaster".sysvpprof {虚处理器信息与统计}
(
  vpid integer, {虚拟处理器 }
  class char(50, {虚拟处理器类名(cpu, adm, lio, pio等)}
  usercpu float,   {用户时间unix秒数 }
  syscpu   float    {系统时间unix秒数 }
);
grant select on sysvpprof to public;

二、dbspace与块信息
*sysdbspaces ————>; dbspace
*syschunks ————>; 块
*syschkio ————>; 块I/O
*syschfree ————>; 块自由空间注：syschfree是个不支持的表

create table "sysmaster".sysdbspaces {dbspace配置}
(
  dbsnum smallint, {dbspace号 }
  name char(18), {dbspace名 }
  owner char(8),  {dbspace拥有者 }
  fchunk smallint, {dbspace第一块 }
  nchunks smallint, {dbspace块数 }
  is_mirrored integer,  {dbspace是否镜像 1=YES，0=NO}
  is_blobspace integer,  {dbspace是否大对象空间 }
  is_temp integer,  {dbspace是否临时，1=YES，0=NO }
  flags smallint  {dbspace标志 }
);
grant select on sysdbspaces to public;

create table "sysmaster".syschunks {chunk配置}
(
  chknum smallint, {chunk号 }
  dbsnum smallint, {dbspace号 }
  nxchknum smallint, {dbspace中下一个块号 }
  chksize integer,  {chunk中的页 }
  offset integer,  {设备页偏移量 }
  nfree integer,  {块中未用页数 }
  is_offline integer,  {chunk是否脱机，1=YES，0=NO}
  is_recovering integer,  {chunk是否恢复，1=YES，0=NO}
  is_blobchunk integer,  {chunk是否blobchunk，1=YES，0=NO}
  is_inconsistent integer,{chunk是否不一致，1=YES，0=NO }
  flags smallint, {由bitbal转换的块标志 }
  fname char(128),{设备路径名 }
  mfname char(128),{镜像设备路径名 }
  moffset integer,  {镜像设备偏移量 }
  mis_offline integer,  {镜像是否脱机，1=YES，0=NO }
  mis_recovering integer, {镜像是否恢复，1=YES，0=NO }
  mflags smallint  {镜像块标志 }
);
grant select on syschunks to public;

create table "sysmaster".syschfree {显示块中的未用空间块}
(
  chknum   integer, { chunk number       块号     }
  extnum   integer, { extent number in chunk 块区域号     }
  start    integer, { physical addr of start 开始物理地址 }
  leng     integer { length of extent  区域长度     }
);
create unique index syschfreeidx on syschfree (chknum, extnum);
revoke all on syschfree from public;
grant select on syschfree to public;

create table "sysmaster".syschkio {块设备I/O统计信息}
(
  chunknum smallint, {块号 }
  reads integer,  {读操作数 }
  pagesread integer,  {读页数 }
  writes integer,  {写操作数 }
  pageswritten integer,  {写页数 }
  mreads integer,  {镜像读操作数 }
  mpagesread integer,  {镜像读页数 }
  mwrites integer,  {镜像写操作数 }
  mpageswritten integer   {镜像写页数 }
);
grant select on syschkio to public;

三、数据库与表信息
*sysdatabases ————>; 数据库
*systabnames ————>; 表
*sysextents ————>; 表区域
*sysptprof ————>; 表I/O

create table "sysmaster".sysdatabase {实例中所有的数据库信息}
(
  name char(18), {数据库名 }
  partnum integer,  {systables表ID }
  owner char(8),  {生成者用户名 }
  created integer,  {生成日期 }
  is_logging integer,  {无缓冲日志，1=YES，0=NO }
  is_buff_log integer,  {缓冲日志，1=YES，0=NO }
  is_ansi integer,  {ANSI方式数据库1=YES，0=NO }
  is_nls integer,  {NLS支持，1=YES，0=NO }
  flags smallint  {指示日志的标志 }
);
grant select on sysdatabase to public;

create table "sysmaster".systabnames {实例中的所有表}
(
  partnum integer, { table id for table  表号 }
  dbsname char(18), { database name 数据库名}
  owner char(8), { table owner 表拥有者 }
  tabname char(18), { table name           表名 }
  collate       char(32)        { collation assoc with database 与GLS的相关性 }
);
create unique index systabs_pnix on systabnames(partnum);
revoke all on systabnames from public;
grant select on systabnames to public;

create table "sysmaster".sysextents {实例中的表和每个区域}
(
  dbsname char(18), {数据库名 }
  tabname char(18), {表名 }
  start integer,  {这个区域的物理地址 }
  size integer   {这个区域的长度(页数) }
);
grant select on sysextents to public;

create table "sysmaster".sysptnext {区域的信息}
(
  pe_partnum  integer, { partnum for this partition 这个区域的编号 }
  pe_extnum   smallint, { extent number 区域号 }
  pe_phys  integer, { physical addr for this extent 这个区域的物理地址 }
  pe_size  integer, { size of this extent 这个区域的长度(页数) }
  pe_log   integer { logical page for start 开始逻辑页 }
);
create unique index sysptnextidx on sysptnext (pe_partnum, pe_extnum);
revoke all on sysptnext from public;
grant select on sysptnext to public;

create table "sysmaster".sysptprof {表I/O概貌}
(
  dbsname char(18),  {数据库名}
  tabname char(18),  {表名    }
  partnum integer,  {表编号  }
  lockreqs integer,  {锁请求  }
  lockwts integer,  {锁等待  }
  deadlks integer,  {死锁    }
  lktouts integer,  {锁超时  }
  isreads integer,  {读      }
  iswrites integer,  {写入    }
  isrewrites integer,  {改写    }
  isdeletes integer, {删除    }
  bufreads integerinteger, {缓冲区读}
  bufwrites integer,  {行冲区写}
  seqscans integer,  {顺序扫描}
  pagreads integer, {磁盘读  }
  pagwrites integer {磁盘写  }
);
grant select on sysptprof to public;

四、用户对话信息
*syssessions ————————>; 对话数据
*syssesprof ————————>; 用户统计信息
*syslocks                 ————————>; 用户锁
*syseswts ————————>; 等待时间

create table "sysmaster".syssessions {用户对话与连接信息}
(
  sid integer, {对话号 }
  username char(8), {用户名 }
  uid smallint,{用户unix号 }
  pid integer, {用户进程号 }
  hostname char(16),{主机名 }
  tty char(16),{tty端口 }
  connected integer, {用户连接时间 }
  feprogram char(16),{程序名 }
  pooladdr integer, {专有对话池指针 }
  is_wlatch integer, {标志1=YES，0=NO，等待锁存 }
  is_wlock integer, {标志1=YES，0=NO，等待锁 }
  is_wbuff integer, {标志1=YES，0=NO，等待缓冲区 }
  is_wckpt integer, {标志1=YES，0=NO，等待校验点 }
  is_wlogbuf integer, {标志1=YES，0=NO，等待日志缓冲区}
  is_wtrans integer, {标志1=YES，0=NO，等待事务 }
  is_monitor integer, {标志1=YES，0=NO，监视进程 }
  is_incrit integer, {标志1=YES，0=NO，在关键段中 }
  state integer  {标志 }
);
grant select on syssessions to public;

create table "sysmaster".syssesprof {用户对话性能统计}
(
  sid integer,    {对话号 }
  lockreqs decimal(16,0),    {请求的锁 }
  locksheld decimal(16,0),    {锁保持 }
  lockwts decimal(16,0),    {锁等待  }
  deadlks decimal(16,0),    {发现的死锁 }
  lktouts decimal(16,0),    {死锁超时 }
  logrecs decimal(16,0),    {逻辑日志记录写入 }
  isreads decimal(16,0),    {读 }
  iswrites decimal(16,0),    {写 }
  isrewrites decimal(16,0),    {改写 }
  isdeletes decimal(16,0),    {删除 }
  iscommits decimal(16,0),    {提交 }
  isrollbacks decimal(16,0),    {撤销 }
  longtxs decimal(16,0),    {长事务 }
  bufreads decimal(16,0),    {缓冲区读 }
  bufwrites decimal(16,0),    {缓冲区写 }
  seqscans decimal(16,0),    {顺序扫描 }
  pagreads decimal(16,0),    {页读 }
  pagwrites decimal(16,0),    {页写 }
  total_sorts decimal(16,0),    {总排序 }
  dsksorts decimal(16,0),    {磁盘排序 }
  max_sortdiskspace  decimal(16,0),{排序使用的最大空间 }
  logspused decimal(16,0),    {当前使用的日志字节 }
  maxlogsp decimal(16,0)     {逻辑日志使用的最大空间}
);
grant select on syssesprof to public;

create table "sysmaster".syslocks {服务器上的锁活动}
(
  dbsname char(18), {数据库 }
  tabname char(18), {表名 }
  rowidlk integer,  {索引关键字锁的行号 }
  keynum smallint, {索引关键字锁的关键字号}
  type integer,  {锁拥有者对话ID }
  owner integer,  {第一个等待者对话ID }
  waiter char(4)   {锁类型 }
);
grant select on syslocks to public;
{*******************************************************
注：锁类型包括
*B ——————>;byte lock(字节锁)
*IS ——————>;intent shared lock(意图共享锁)
*S ——————>;shared lock(共享锁)
*XS ——————>;repeatable read shared key(可重复读共享锁)
*U ——————>;update lock(更新锁)
*IX ——————>;intent exclusive lock(意图独占锁)
*SIX ——————>;shared intent exclusive(共享意图独占锁)
*X ——————>;exclusive lock(独占锁)
*XR ——————>;repreatable read exclusive(可重复读独占锁)
基本说来，这些锁类型是三种锁的组合：共享锁(S)、独占锁(X)、更新锁(U)。共享锁使其他用户也能读数据，但不能改变数据。独占锁不让其他用户共享数据。
更新锁在更新数据时不让其他用户改变数据。
IDS中可以锁定的对象包括：
*数据库 ——————>;每个用户打开数据库时即对数据库采用共享锁，防止别人删除正在使用的数据。这个操作显示为sysmaster数据库和sysdatabase表中的锁，rowid指向包含数据库名的记录。
*表 ——————>;表锁显示为表上的锁，rowid为0，keynum为0。
*页 ——————>;页锁显示为rowid以00结尾，即页中的所有行均锁定。
*行 ——————>;行锁显示实际rowid(不以00结尾)。
*键 ——————>;键锁显示为keynum如果行的索引需要更新，则锁在该行的索引。
********************************************************}

create table "sysmaster".sysseswts {对象等待状态与时间}
(
  sid integer,  {对话ID  }
  reason char(50), {等待原因说明  }
  numwaits integer,  {这个原因的等待数  }
  cumtime float,    {这个原因的等待累计时间}
  maxtime integer   {这个原因的等待最长时间}
);
grant select on sysseswts to public;

五、不支持的表(没有建档，可能在将来版本中改变)

create table "sysmaster".systrans {用户事务}
(
  tx_id integer,{事务表指针    }
  tx_logbeg integer,{事务开始的逻辑日志号    }
  tx_loguniq integer {事务中使用的当前逻辑日志号}
);
grant select on systrans to public;

create table "sysmaster".syssqexpalin {用户查询}
(
  sqx_sessionid integer, {SQL语句的对话ID，匹配onstat -u 输出 }
  sqx_bufreads integer, {SQL语句完成的缓冲区读次数}
  sqx_pagereads integer, {SQL语句完成的页面读次数}
  sqx_totsorts   integer, {SQL语句完成的排序次数}
  sqx_estcost integer, {这个查询的估计成本，应与SET EXPLAIN的输出相同。注：这个成本有时偏高，但可以作为寻找坏查询的参考}
  sqx_estrows integer, {检查这个查询返回的行，应与SET EXPALIN的输出相同}
  sqx_seqscan smallint,{查询是顺序表格扫描时返回1，通常表示有问题}
  sqx_srtscan smallint,{查询是排序扫描时返回1}
  sqx_autoindex smallint,{查询是表格自动索引时返回1}
  sqx_mrgjoin smallint,{查询是合并连接时返回1}
  sqx_dynhashjoin smallint,{查询是动态散列连接时返回1 }
  sqx_sqlstatement char(32000){SQL语句文本 }
);
grant select on syssqexplain to public;

Exploring the Sysmaster Database

flyinweb — 2009-6-9 14:22:23

Exploring the Sysmaster Database
by Lester Knutsen
lester@advancedatatools.com
When you list all the databases on your INFORMIX server, you will see one called "sysmaster". This is a special database and is one of the new features that first appeared in INFORMIX-OnLine DSA 6.x and 7.x. This is a database that contains tables that can be used for monitoring your system. These are referred to as the System Monitoring Interface (SMI) tables. In this chapter we will explore some of the tables and views that are in this database.
The sysmaster database is described as a pseudo database. That means most of its tables are not normal tables on disk, but pointers to shared memory structures in the OnLine engine. The sysmaster database contains over 120 tables. Only 18 of these tables are documented in the INFORMIX-OnLine Dynamic Server Administrator's Guide, Volume 2, Chapter 38. The rest are undocumented and described by Informix as for internal use. The examples and references in this article are based on OnLine 7.23. I have also tested some of the examples with versions 7.10, 7.12, and 7.22. There are some minor changes between versions in the undocumented features and structures of these tables.
A warning: Some of the features discussed in this article are based on undocumented SMI tables and may change or not work in future versions of INFORMIX OnLine DSA.
This article will focus on users, server configuration, dbspaces, chunks, tables, and monitoring IO using the sysmaster database. We will present how to create scripts to monitor the following:
List who is using each database.
Display information about your server configuration.
Display how much free space is available in each dbspace in a format like the Unix df command.
List the status and characteristics of each chunk device.
Display blocks of free space within a chunk. This allows you to plan where to put large tables without fragmenting them.
Display IO statistics by chunk devices.
Display IO usage of chunk devices as a percent of the total IO, and show which chunks are getting used the most.
Display tables and the number of extents, and number of pages used.
Present a layout of dbspace, databases, tables, and extents similar to the command "tbcheck -pe".
Show table usage statistics sorted by which tables have the most reads, writes, or locks.
Show statistics of users sessions.
Show locks and users who are waiting on locks.
1. A Practical Example - Who is Using What Database
Let's begin with a very practical example of the sysmaster database's value.
My interest in this database started a couple of years ago, while consulting on a project for a development group where I needed to know who had a database open and which workstation they were using to connect to the database. This was a development environment and there were continual changes to the database schemas. In order to make updates to the database schema, I would have to get the developers to disconnect from the database. The "onstat -u" utility would tell me which users were connected to the server, but not what database and what workstation they were using. "Onstat -g ses" told me the user and workstation, but not the database. "Onstat -g sql told me the session id and database, but not the user name and workstation. After some debugging, I found all the information I wanted in the sysmaster database. And, because it was a database, I could retrieve it with SQL queries. The following query shows the database, who has it open, the workstation they are connected from, and the session id.
Figure 1. Dbwho SQL script
-- dbwho.sql
select  sysdatabases.name database,             -- Database Name
                syssessions.username,           -- User Name
                syssessions.hostname,           -- Workstation
                syslocks.owner sid              -- Informix Session ID
from    syslocks, sysdatabases , outer syssessions
where   syslocks.tabname = "sysdatabases"       -- Find locks on sysdatabases
and             syslocks.rowidlk = sysdatabases.rowid -- Join rowid to database
and     syslocks.owner = syssessions.sid        -- Session ID to get user info
order by 1;
Every user that opens a database opens a shared lock on the row in the sysdatabases table of the sysmaster database that points to that database. First we need to find all the locks in syslocks on the sysdatabases table. This gives us the rowid in sysdatabase which has the database name. Finally, we join with the table syssessions to get the username and hostname. I put all this together in a shell script that can be run from the unix prompt and called it dbwho. Figure 2 contains the shell script.
Figure 2. Dbwho shell script
:
###########################################################################
# Program: dbwho
# Author:  Lester Knutsen
# Date:    10/28/1995
# Description: List database, user and workstation of all db users
###########################################################################
echo "Generating list of users by database ..."
dbaccess sysmaster -
One of the first things you will notice is that this script is slow. This led me to start digging into what was causing the slow performance. Running this query with set explain turned on (this shows the query optimizer plan) shows that there is a lot of work going on behind the scenes. Syslocks is a view, and it takes a sequential scan of six tables to produce the view. A temp table is created to hold the results of the syslocks view, and this is then joined with the other two tables. The tables sysdatabase and syssessions are also views. And the view syssessions uses a stored procedure, called bitval. Figure 3 contains the output from turning set explain on. In spite of these queries sometimes being a bit slow, these tables are a tremendous value and make it much easier to monitor your database server.
Figure 3: Output from "set explain on" for dbwho.sql
QUERY:
------
create view "informix".syslocks
(dbsname,tabname,rowidlk,keynum,type,owner,waiter)
as      select x1.dbsname ,x1.tabname ,x0.rowidr ,x0.keynum ,
        x4.txt [1,4] ,x3.sid ,x5.sid
        from    "informix".syslcktab x0 ,
                "informix".systabnames x1 ,
                "informix".systxptab x2 ,
                "informix".sysrstcb x3 ,
                "informix".flags_text x4 ,
                outer("informix".sysrstcb x5 )
        where ((((((x0.partnum = x1.partnum )
        AND (x0.owner = x2.address ) )
        AND (x2.owner = x3.address ) )
        AND (x0.wtlist = x5.address ) )
        AND (x4.tabname = 'syslcktab' ) )
        AND (x4.flags = x0.type ) ) ;
Estimated Cost: 713
Estimated # of Rows Returned: 51
1) informix.syslcktab: SEQUENTIAL SCAN
2) informix.flags_text: SEQUENTIAL SCAN
    Filters: informix.flags_text.tabname = 'syslcktab'
DYNAMIC HASH JOIN
    Dynamic Hash Filters: informix.syslcktab.type = informix.flags_text.flags
3) informix.systxptab: SEQUENTIAL SCAN
DYNAMIC HASH JOIN
    Dynamic Hash Filters: informix.syslcktab.owner =
informix.systxptab.address
4) informix.systabnames: SEQUENTIAL SCAN
    Filters: informix.systabnames.tabname = 'sysdatabases'
DYNAMIC HASH JOIN
    Dynamic Hash Filters: informix.syslcktab.partnum
informix.systabnames.partnum
5) informix.sysrstcb: SEQUENTIAL SCAN
DYNAMIC HASH JOIN (Build Outer)
    Dynamic Hash Filters: informix.systxptab.owner = informix.sysrstcb.address
6) informix.sysrstcb: SEQUENTIAL SCAN
DYNAMIC HASH JOIN
    Dynamic Hash Filters: informix.syslcktab.wtlist =
informix.sysrstcb.address
QUERY:
------
select  sysdatabases.name database,
        syssessions.username,
        syssessions.hostname,
        syslocks.owner sid
from  syslocks, sysdatabases, outer syssessions
where syslocks.rowidlk = sysdatabases.rowid
and   syslocks.tabname = "sysdatabases"
and   syslocks.owner = syssessions.sid
order by 1
Estimated Cost: 114
Estimated # of Rows Returned: 11
Temporary Files Required For: Order By
1) (Temp Table For View): SEQUENTIAL SCAN
2) informix.sysdbspartn: INDEX PATH
    (1) Index Keys: ROWID
        Lower Index Filter: informix.sysdbspartn.ROWID = (Temp Table For
View).rowidlk
3) informix.sysscblst: INDEX PATH
    (1) Index Keys: sid (desc)
        Lower Index Filter: informix.sysscblst.sid = (Temp Table For
View).owner
4) informix.sysrstcb: AUTOINDEX PATH
    Filters: informix.bitval(informix.sysrstcb.flags ,'0x80000' )= 1
    (1) Index Keys: scb
        Lower Index Filter: informix.sysrstcb.scb = informix.sysscblst.address
2. How the Sysmaster Database is Created
The sysmaster database keeps track of information about the database server just like the system tables keep track of information in each database. This database is automatically created when you initialize OnLine. It includes tables for tracking two types of information: the System Monitoring Interface (SMI) tables, and the On-Archive catalog tables. This article will focus on the SMI tables. There is a warning in the documentation not to change any information in these tables as it may corrupt your database server. Also there is a warning that OnLine does not lock these tables, and that all selects from this database will use an isolation level of dirty read. This means that the data can change dynamically as you are retrieving it. This also means that selecting data from the sysmaster tables does not lock any of your users from processing their data. As mentioned above, the SMI tables are described as pseudo-tables which point directly to the shared memory structures in OnLine where the data is stored. That means they are not actually on disk. However, because many of the SMI tables are really views, selecting from them does create temporary tables and generate disk activity.
A script located in your directory $INFORMIXDIR/etc. named sysmaster.sql contains the SQL statements to create the sysmaster database. The process of creating it is interesting and outlined as follows:
First the script creates real tables with the structures of the pseudo tables.
Then, the table structures of the real tables are copied to temp tables.
The real tables are then dropped.
The column in systables that contains partnum is updated to indicate they point to pseudo tables in shared memory.
The flags_text table is created which has the interpretations for all the text descriptions and flags used in the SMI tables.
The stored procedures are created that are used to create the views, two of which may be interesting:
- bitval() is a stored procedure for getting the boolean flag values
- l2date() is a stored procedure for converting unix time() long values to dates
Finally the script creates the SMI views.
After the sysmaster script is run the system will execute another script to create the on-archive tables and views in the sysmaster database.
Warning: The sysmaster database is created the first time you go into online mode after you first initialize your system. Do NOT start creating any other database until this process is complete or you may corrupt your sysmaster database. You will need 2000 KB of logical log space to create the sysmaster database. If there are problems creating the sysmaster database, shut your OnLine server down and restart it. This will re-create the sysmaster database. Monitor your online.log file until you see the messages showing the successful completion of building the sysmaster database in the online.log (Figure 4).
Figure 4. Online.log messages showing successful creation of sysmaster database
12:10:24  On-Line Mode
12:10:24  Building 'sysmaster' database ...
12:11:02  Logical Log 1 Complete.
12:11:03  Process exited with return code 1: /bin/sh /bin/sh -c
        /u3/informix7/log_full.sh 2 23 "Logical Log 1 Complete." "Logical Log 1 Complete."
12:11:22  Logical Log 2 Complete.
12:11:23  Process exited with return code 1: /bin/sh /bin/sh -c
        /u3/informix7/log_full.sh 2 23 "Logical Log 2 Complete." "Logical Log 2 Complete."
12:11:26  Checkpoint Completed:  duration was 3 seconds.
12:11:40  Logical Log 3 Complete.
12:11:41  Process exited with return code 1: /bin/sh /bin/sh -c
        /u3/informix7/log_full.sh 2 23 "Logical Log 3 Complete." "Logical Log 3 Complete."
12:11:59  Logical Log 4 Complete.
12:12:00  Process exited with return code 1: /bin/sh /bin/sh -c
        /u3/informix7/log_full.sh 2 23 "Logical Log 4 Complete." "Logical Log 4 Complete."
12:12:25  'sysmaster' database built successfully.
Supported SMI Tables
There are 18 supported SMI tables in release 7.23 of INFORMIX-OnLine DSA. We will discuss the more important ones and a few unsupported ones in this chapter.

Figure 5. Supported SMI tables
Supported tables and views:  (OnLine 7.23)
sysadtinfo              Auditing configuration table
sysaudit                Auditing event masks table
syschkio                Chunk I/O statistics view
syschunks               Chunk information view
sysconfig               Configuration information view
sysdatabases            Database information view
sysdbslocale            Locale information view
sysdbspaces             Dbspace information view
sysdri                  Data replication view
sysextents              Table extent allocation view
syslocks                Current lock information view
syslogs                 Logical Log status view
sysprofile              Current system profile view
sysptptof               Current table profile view
syssessions             Current user sessions view
sysseswts               Session wait times view
systabnames             Table information table
sysvpprof               Current VP profile view
Differences From Other Databases
There are several key differences between the sysmaster database and other databases you might create. Reminder that this is a database that points to the server's shared memory structures and not to tables that are stored on disk. Some of the differences are:
You cannot update the sysmaster database. Its purpose is to allow you to read information about the server. Trying to update its tables should generate an error message but may corrupt the server.
You cannot run dbschema on these table to get their structure. This will generate and error message.
You cannot drop the sysmaster database or any tables within it. Again, this should generate an error message.
The data is dynamic and may change while you are retrieving it. The sysmaster database has an effective isolation level of dirty read even though it looks like a database with unbuffered logging. This prevents your queries from locking users and slowing down their processing.
However, because the sysmaster database uses unbuffered logging, its temp tables are logged.
You can create triggers and stored procedures on the sysmaster database, but the triggers will never be executed. Again, this is because this is not a real database but pointers to shared memory.
The sysmaster database reads the same shared memory structures read by the command line utility "onstat". The statistical data is reset to zero when OnLine is shut down and restarted.
It is also reset to zero when the "onstat -z" command to reset statistics is used. Individual user statistical data is lost when a user disconnects from the server.
Now, let's examine some of the more interesting tables in the sysmaster database and what else can be done with them.
3. Server Information
This first section will look at how you determine the state and configuration of your INFORMIX-OnLine server from the sysmaster database. We will look at four tables and how to use them.
Server configuration and statistics tables:
sysconfig - ONCONFIG File
sysprofile - Server Statistics
syslogs - Logical Logs
sysvpprof - Virtual Processors
Server Configuration Parameters: sysconfig
The view sysonfig contains configuration information from the OnLine server. This information was read from the ONCONFIG file when the server was started. Have you ever needed to know from within a program how your server was setup? Or, what TAPEDEV is set to? View sysconfig
        Column          Data Type       Description
        cf_id           integer         unique numeric identifier
        cf_name         char(18)        config parameter name
        cf_flags        integer         flags, 0 = in view sysconfig
        cf_original     char(256)       value in ONCONFIG at boottime
        cf_effective    char(256)       value effectively in use
        cf_default      char(256)       value by default
Example queries:
To find out what the current tape device is:
select cf_effective from sysconfig where cf_name = "TAPEDEV";
To find the server name:
select cf_effective from sysconfig where cf_name =
"DBSERVERNAME";
To find out if data replication is turned on:
select cf_effective from sysconfig where cf_name = "DRAUTO";
Server Profile Information: sysprofile
The sysprofile table is a view based on values in a table called syshmhdr. Syshmhdr points to the same shared memory area as the onstat utility with the -p option. When you zero out the statistics with "onstat -z", all values in the syshmhdr table are reset to zero.View sysprofile
        Column          Data Type       Description
        name            char(16)        profile element name
        value           integer         current value
One of the best uses of this data is for developing alarms when certain values fall below acceptable levels. The Informix documentation says that tables in the sysmaster database do not run triggers. This is because the updates to these tables take place within OnLine shared memory and not through SQL which activates triggers. However, you can create a program to poll this table at specified intervals to select data and see if it falls below your expectations.
Logical Logs Information: syslogs
Syslogs is a view based on the table syslogfil. This is an example where the SMI views are a great tool in presenting the data in a more understandable format. Syslogfil has a field called flags which contains status information encoded in boolean smallint. The view syslogs decodes that data into six fields: is_used, is_current, is_backed_up, is_new, is_archived, and is_temp, with a 1 if true or a 0 if false.View syslogs
        Column          Data Type       Description
        number          smallint        logfile number
        uniqid          integer         logfile uniqid
        size            integer         pages in logfile
        used            integer         pages used in logfile
        is_used         integer         1 for used, 0 for free
        is_current      integer         1 for current
        is_backed_up    integer         1 for backuped
        is_new          integer         1 for new
        is_archived     integer         1 for archived
        is_temp         integer         1 for temp
        flags           smallint        logfile flags
Virtual Processor Information and Statistics: sysvpprof
Sysvpprof is another view that is more readable than the underlying table sysvplst. As with the view syslogs in the above paragraph, this view has data that is converted to make it more understandable. This time the flags are converted to text descriptions from the flags_text table.View sysvpprof
        Column          Data Type       Description
        vpid            integer         VP id
        txt             char(50)        VP class name
        usecs_user      float           number of unix secs of user time
        usecs_sys       float           number of unix secs of system time
The following query on the base table sysvplst achieves the same results as the view.
Figure 6. SQL script to display VP status
-- vpstat.sql
select  vpid,
        txt[1,5] class,
        pid,
        usecs_user,
        usecs_sys,
        num_ready
from    sysvplst a, flags_text b
where   a.flags != 6
and     a.class = b.flags
and b.tabname = 'sysvplst';

SQL Output
       vpid class         pid     usecs_user      usecs_sys   num_ready

          1 cpu           335         793.61          30.46           0
          2 adm           336           0.02           0.11           0
          3 lio           337           1.15           5.98           0
          4 pio           338           0.19           1.13           0
          5 aio           339           0.94           4.27           0
          6 msc           340           0.15           0.14           0
          7 aio           341           0.81           5.72           0
          8 tli           342           1.79           3.02           0
          9 aio           343           0.52           2.50           0
         10 aio           344           0.28           1.16           0
         11 aio           345           0.09           0.86           0
         12 aio           346           0.16           0.48           0
4. Dbspace and Chunk Information
Now let's look at the SMI tables that contain information about your disk space, chunks, and dbspace. There are four tables that contain this data.
sysdbspaces - DB Spaces
syschunks - Chunks
syschkio - I/O by Chunk
syschfree* - Free Space by Chunk
* Note: Syschfree is not a supported table.
Dbspace Configuration: sysdbspaces
The sysmaster database has three key tables containing dbspace and chunk information. The first one is sysdbspaces. This is a view that interprets the underlying table sysdbstab. Sysdbspaces serves two purposes: it translates a bit field containing flags into separate columns where 1 equals yes and 0 equals no, and, it allows the underlying table to change between releases without having to change code. The view is defined as follows:View sysdbspaces
        Column          Data Type       Description
        dbsnum          smallint        dbspace number,
        name            char(18)        dbspace name,
        owner           char(8)         dbspace owner,
        fchunk          smallint        first chunk in dbspace,
        nchunks         smallint        number of chunks in dbspace,
        is_mirrored     bitval          is dbspace mirrored, 1=Yes, 0=No
        is_blobspace    bitval          is dbspace a blob space, 1=Yes, 2=No
        is_temp         bitval          is dbspace temp, 1=Yes, 2=No
        flags           smallint        dbspace flags
The columns of type bitval are the flags that are extracted from the flags column by a stored procedure called bitval when the view is generated.
Chunk Configuration: syschunks
The syschunks table is also a view based on two actual tables, one for primary chunk information, syschktab, and one for mirror chunk information, sysmchktab. The following is the layout of syschunks:View syschunks
        Column          Data Type       Description
        chknum          smallint        chunk number
        dbsnum          smallint        dbspace number
        nxchknum        smallint        number of next chunk in dbspace
        chksize         integer         pages in chunk
        offset          integer         pages offset into device
        nfree           integer         free pages in chunk
        is_offline      bitval          is chunk offline, 1=Yes, 0=No
        is_recovering   bitval          is chunk recovering, 1=Yes, 0=No
        is_blobchunk    bitval          is chunk blobchunk, 1=Yes, 0=No
        is_inconsistent bitval          is chunk inconsistent, 1=Yes, 0=No
        flags           smallint        chunk flags converted by bitval
        fname           char(128)       device pathname
        mfname          char(128)       mirror device pathname
        moffset         integer         pages offset into mirror device
        mis_offline     bitval          is mirror offline, 1=Yes, 0=No
        mis_recovering  bitval          is mirror recovering, 1=Yes, 0=No
        mflags          smallint        mirror chunk flags
Displaying Free Dbspace
Now, we will take a look at several ways to use this dbspace and chunk information. One capability I have always wanted is a way to show the amount of dbspace used and free in the same format as the Unix "df -k" command. The sysmaster database contains information about the dbspaces and chunks, so this can be generated with an SQL script. The following is an SQL script to generate the amount of free space in a dbspace. It uses the sysdbspaces and syschunks tables to collect its information.
Figure 7. SQL script to display free dbspace
-- dbsfree.sql - display free dbspace like Unix "df -k " command
database sysmaster;
select  name[1,8] dbspace,              -- name truncated to fit on one line
        sum(chksize) Pages_size,        -- sum of all chunks size pages
        sum(chksize) - sum(nfree) Pages_used,
        sum(nfree) Pages_free,          -- sum of all chunks free pages
        round ((sum(nfree)) / (sum(chksize)) * 100, 2) percent_free
from    sysdbspaces d, syschunks c
where   d.dbsnum = c.dbsnum
group by 1
order by 1;
Sample output
dbspace        pages_size      pages_used       pages_free     percent_free
rootdbs             50000           13521            36479            72.96
dbspace1           100000           87532            12468            12.47
dbspace2           100000           62876            37124            37.12
dbspace3           100000             201            99799            99.80
Displaying Chunk Status
The next script lists the status and characteristics of each chunk device.
Figure 8. SQL script showing chunk status
-- chkstatus.sql - display information about a chunk
database sysmaster;
select
        name dbspace,           -- dbspace name
        is_mirrored,            -- dbspace is mirrored 1=Yes 0=No
        is_blobspace,           -- dbspace is blobspace 1=Yes 0=No
        is_temp,                -- dbspace is temp 1=Yes 0=No
        chknum chunknum,        -- chunk number
        fname  device,          -- dev path
        offset dev_offset,      -- dev offset
        is_offline,             -- Offline 1=Yes 0=No
        is_recovering,          -- Recovering 1=Yes 0=No
        is_blobchunk,           -- Blobspace 1=Yes 0=No
        is_inconsistent,        -- Inconsistent 1=Yes 0=No
        chksize Pages_size,     -- chunk size in pages
        (chksize - nfree) Pages_used, -- chunk pages used
        nfree Pages_free,       -- chunk free pages
        round ((nfree / chksize) * 100, 2) percent_free, -- free
        mfname mirror_device,   -- mirror dev path
        moffset mirror_offset,  -- mirror dev offset
        mis_offline ,           -- mirror offline 1=Yes 0=No
        mis_recovering          -- mirror recovering  1=Yes 0=No
from    sysdbspaces d, syschunks c
where d.dbsnum = c.dbsnum
order by dbspace, chunknum
Displaying Blocks of Free Space in a Chunk: syscchfree
In planning expansions, new databases, or when adding new tables to an existing server, I like to know what blocks of contiguous free space are available. This allows placing new tables in dbspaces where they will not be broken up by extents. One of the sysmaster tables tracks the chunk free list, which is the available space in a chunk. Table syschfree
        Column          Data Type       Description
        chknum          integer         chunk number
        extnum          integer         extent number in chunk
        start           integer         physical addr of start
        leng            integer         length of extent
The next script uses this table to create a list of free space and the size of each space that is available.
Figure 9. SQL script showing free space on chunks
-- chkflist.sql - display list of free space within a chunk
database sysmaster;
select
        name dbspace,   -- dbspace name truncated to fit
        f.chknum,               -- chunk number
        f.extnum,               -- extent number of free space
        f.start,                -- starting address of free space
        f.leng free_pages       -- length of free space
from    sysdbspaces d, syschunks c, syschfree f
where d.dbsnum = c.dbsnum
and      c.chknum = f.chknum
order by dbspace, chknum
Sample Output
dbspace                 chknum      extnum       start  free_pages
rootdbs                      1           0       11905        1608
rootdbs                      1           1       15129       34871
IO Statistics by Chunk Devices: syschkio
Informix uses a view, syschkio, to collect information about the number of disk reads and writes per chunk. This view is based on the tables syschktab and symchktab.View syschkio
        Column          Data Type       Description
        chunknum        smallint        chunk number
        reads           integer         number of read ops
        pagesread       integer         number of pages read
        writes          integer         number of write ops
        pageswritten    integer         number of pages written
        mreads          integer         number of mirror read ops
        mpagesread      integer         number of mirror pages read
        mwrites         integer         number of mirror write ops
        mpageswritten   integer         number of mirror pages written
The following script displays IO usage of chunk devices. It uses the base tables so the mirror chunks can be displayed on separate rows. It also joins with the base table that contains the dbspace name.
Figure 10. SQL script displaying chunk I/O
-- chkio.sql - displays chunk IO status
database sysmaster;
select
        name[1,10] dbspace,     -- truncated to fit 80 char screen line
        chknum,
        "Primary" chktype,
        reads,
        writes,
        pagesread,
        pageswritten
from    syschktab c, sysdbstab d
where   c.dbsnum = d.dbsnum
union all
select
        name[1,10]      dbspace,
        chknum,
        "Mirror"    chktype,
        reads,
        writes,
        pagesread,
        pageswritten
from    sysmchktab c, sysdbstab d
where   c.dbsnum = d.dbsnum
order by 1,2,3;
Sample Output
dbspace    chknum chktype       reads      writes   pagesread pageswritten
rootdbs        1  Primary       74209      165064      209177       308004
rootdbs        1  Mirror        69401      159832      209018       307985
A better view of your IO is to see the percent of the total IO that takes place per chunk. This next query collects IO stats into a temp table, and then uses that to calculate total IO stats for all chunks. Then each chunk's IO is compared with the total to determine the percent of IO by chunk. The following script uses the one above as a basis to show IO by chunk as a percent of the total IO.
Figure 11. SQL script chunk I/O summary
-- chkiosum.sql - calculates percent of IO by chunk
database sysmaster;
-- Collect chunk IO stats into temp table A
select
        name dbspace,
        chknum,
        "Primary" chktype,
        reads,
        writes,
        pagesread,
        pageswritten
from    syschktab c, sysdbstab d
where   c.dbsnum = d.dbsnum
union all
select
        name[1,10]      dbspace,
        chknum,
        "Mirror"    chktype,
        reads,
        writes,
        pagesread,
        pageswritten
from    sysmchktab c, sysdbstab d
where   c.dbsnum = d.dbsnum
into temp A;
-- Collect total IO stats into temp table B
select
        sum(reads) total_reads,
        sum(writes) total_writes,
        sum(pagesread) total_pgreads,
        sum(pageswritten) total_pgwrites
from A
into temp B;
-- Report showing each chunks percent of total IO
select
        dbspace,
        chknum,
        chktype,
        reads,
        writes,
        pagesread,
        pageswritten,
        round((reads/total_reads) *100, 2) percent_reads,
        round((writes/total_writes) *100, 2) percent_writes,
        round((pagesread/total_pgreads) *100, 2) percent_pg_reads,
        round((pageswritten/total_pgwrites) *100, 2) percent_pg_writes
from    A, B
order by 11;-- order by percent page writes
Sample output for 1 chunk
dbspace                 datadbs
chknum                  9
chktype                 Primary
reads                   12001
writes                  9804
pagesread               23894
pageswritten            14584
percent_reads           0.33
percent_writes          0.75
percent_pg_reads        37.59
percent_pg_writes       1.86
5. Database and Table Information
The next five tables we will look at store information on your tables and extents. They are:
sysdatabases - Databases
systabnames - Tables
sysextents - Tables extents
sysptprof - Tables I/O
Information on All Databases on a Server: sysdatabases
This view has data on all databases on a server. Have you ever needed to create a pop-up list of databases within a program? This table now allows programs to give users a list of databases to select from without resorting to ESQL/C. The following is the definition of this view:View sysdatabases
        Column          Data Type       Description
        name            char(18)        database name
        partnum         integer         table id for systables
        owner           char(8)         user name of creator
        created         integer         date created
        is_logging      bitval          unbuffered logging, 1=Yes, 0= No
        is_buff_log     bitval          buffered logging, 1=Yes, 0= No
        is_ansi         bitval          ANSI mode database, 1=Yes, 0= No
        is_nls          bitval          NLS support, 1=Yes, 0= No
        flags           smallint        flags indicating logging
The following is a script to list all databases, owners, dbspaces, and logging status. Notice the function dbinfo is used. This is a new function in 7.X with several uses, one of which is to convert the partnum of a database into its corresponding dbspace. This function will be used in several examples that follow.
Figure 12. SQL script listing all databases on the server
-- dblist.sql - List all databases, owner and logging status
database sysmaster;
select
        dbinfo("DBSPACE",partnum) dbspace,
        name database,
        owner,
        is_logging,
        is_buff_log
from sysdatabases
order by dbspace, name;
Sample Output
dbspace            database           owner     is_logging is_buff_log
rootdbs            central            lester             0           0
rootdbs            datatools          lester             0           0
rootdbs            dba                lester             0           0
rootdbs            roster             lester             0           0
rootdbs            stores7            lester             0           0
rootdbs            sunset             linda              0           0
rootdbs            sysmaster          informix           1           0
rootdbs            zip                lester             1           1
Information About Database Tables: systabnames, sysextents, and sysptprof
Three tables contain all the data you need from the sysmaster database about tables in your database. The first of these is a real table defined as follows:Table systabnames - All tables on the server
        Column          Data Type       Description
        partnum         integer         table id for table
        dbsname         char(18)        database name
        owner           char(8)         table owner
        tabname         char(18)        table name
        collate         char(32)        collation assoc with NLS DB
View sysextents - Tables and each extent on the server
        Column          Data Type       Description
        dbsname         char(18)        database name
        tabname         char(18)        table name
        start           integer         physical addr for this extent
        size            integer         size of this extent
The view sysextents is based on a table, sysptnext, defined as follows:Table sysptnext
        Column          Data Type       Description
        pe_partnum      integer         partnum for this partition
        pe_extnum       smallint        extent number
        pe_phys         integer         physical addr for this extent
        pe_size         integer         size of this extent
        pe_log          integer         logical page for start
View sysptprof  - Tables IO profile
        Column          Data Type       Description
        dbsname         char(18)        database name
        tabname         char(18)        table name
        partnum         integer         partnum for this table
        lockreqs        integer         lock requests
        lockwts         integer         lock waits
        deadlks         integer         deadlocks
        lktouts         integer         lock timeouts
        isreads         integer         reads
        iswrites        integer         writes
        isrewrites      integer         rewrites
        isdeletes       integer         deletes
        bufreads        integer         buffer reads
        bufwrites       integer         buffer writes
        seqscans        integer         sequential scans
        pagreads        integer         disk reads
        pagwrites       integer         disk writes
These tables allow us to develop scripts to display tables, the number of extents, and pages used. We can also present a layout of dbspace, databases, tables, and extents similar to the command "tbcheck -pe". And finally, we can show table usage statistics sorted by which tables have the most hits based on reads, writes, or locks. These scripts will enable a DBA to monitor and tune the database server.
Extents are created when a table's initial space has been filled up and it needs more space. OnLine will allocate additional space for a table. However, the table will no longer be contiguous, and performance will start to degrade. Informix will display warning messages when a table reaches more than 8 extents. Depending on a number of factors, at approximately 180-230 extents a table will not be able to expand and no additional rows can be inserted. The following script lists all tables sorted by the number of extents. The tables that show up with many extents may need to be unloaded and rebuilt.
Figure 13. SQL script showing tables and extents
-- tabextent.sql - List tables, number of extents and size of table.
database sysmaster;
select  dbsname,
        tabname,
        count(*) num_of_extents,
        sum( pe_size ) total_size
from systabnames, sysptnext
where partnum = pe_partnum
group by 1, 2
order by 3 desc, 4 desc;
Sample Output
dbsname            tabname              num_of_extents       total_size
rootdbs            TBLSpace                          8              400
sysmaster          syscolumns                        6               56
sunset             inventory                         3              376
sunset             sales_items                       3               96
sunset             sales_header                      3               48
sunset             parts                             3               48
sunset             customer                          3               40
sunset             syscolumnext                      3               32
sunset             employee                          3               32
Sometimes it is helpful to see how the tables are interspersed on disk. The following script lists by dbspace each table and the location of each extent. This is similar to the output from "oncheck -pe".
Figure 14. SQL script showing table layout on chunks
-- tablayout.sql - Show layout of tables and extents
database sysmaster;
select dbinfo( "DBSPACE" , pe_partnum ) dbspace,
        dbsname[1,10],
        tabname,
        pe_phys start,
        pe_size size
from    sysptnext, outer systabnames
where   pe_partnum = partnum
order by dbspace, start;
Sample output
dbspace            dbsname    tabname                  start        size
rootdbs            rootdbs    TBLSpace               1048589          50
rootdbs            sysmaster  sysdatabases           1050639           4
rootdbs            sysmaster  systables              1050643           8
rootdbs            sysmaster  syscolumns             1050651          16
rootdbs            sysmaster  sysindexes             1050667           8
rootdbs            sysmaster  systabauth             1050675           8
rootdbs            sysmaster  syscolauth             1050683           8
rootdbs            sysmaster  sysviews               1050691           8
rootdbs            sysmaster  sysusers               1050699           8
rootdbs            sysmaster  sysdepend              1050707           8
rootdbs            sysmaster  syssynonyms            1050715           8
IO Performance of Tables
Have you ever wanted to know which tables have the most reads, writes, or locks? The last script in this article shows the performance profile of tables. By changing the columns displayed and the sort order of the script, you can display the tables with the most reads, writes, or locks first.
Figure 15. SQL script show table I/O activity
-- tabprof.sql
database sysmaster;
select
        dbsname,
        tabname,
        isreads,
        bufreads,
        pagreads
        -- uncomment the following to show writes
        -- iswrites,
        -- bufwrites,
        -- pagwrites
        -- uncomment the following to show locks
        -- lockreqs,
        -- lockwts,
        -- deadlks
from sysptprof
order by isreads desc; -- change this sort to whatever you need to monitor.
Sample Output
dbsname            tabname                isreads    bufreads    pagreads
zip                zip                     334175    35876509        1111
sysmaster          sysviews                259712      634102        1119
sysmaster          systables                60999      240018        1878
zip                systables                 3491        8228         543
sysmaster          sysusers                  2406        8936          87
sysmaster          sysprocauth               1276        5104          12
sunset             systables                  705        2251          26
sysmaster          sysprocedures              640        2562          21
sysmaster          syscolumns                 637        1512          49
stores7            systables                  565        1361          16
sysmaster          sysdatabases               534        2073         902
6. User Session Information
This last set of SMI tables deals with users and information about their sessions. These tables were used in our example script "dbwho" at the beginning of this chapter.
syssessions - Session data
syssesprof - User statistics
syslocks - User Locks
syseswts - Wait times
User Session and Connection Information: syssessions
This view contains information from two shared memory structures, the user control and thread control table. This tells you who is logged in to your server and some basic data about their session.View syssessions
        Column          Data Type       Description
        sid             integer         Session id number
        username        char(8)         User name
        uid             smallint        User unix id
        pid             integer         User process id
        hostname        char(16)        Hostname
        tty             char(16)        TTY port
        connected       integer         Time user connected
        feprogram       char(16)        Program name
        pooladdr        integer         Pointer to private session pool
        is_wlatch       integer         Flag 1=Yes, 0=No, wait on latch
        is_wlock        integer         Flag 1=Yes, 0=No, wait on lock
        is_wbuff        integer         Flag 1=Yes, 0=No, wait on buffer
        is_wckpt        integer         Flag 1=Yes, 0=No, wait on checkpoint
        is_wlogbuf      integer         Flag 1=Yes, 0=No, wait on log buffer
        is_wtrans       integer         Flag 1=Yes, 0=No, wait on a transaction
        is_monitor      integer         Flag 1=Yes, 0=No, a monitoring process
        is_incrit       integer         Flag 1=Yes, 0=No, in crtical section
        state           integer         Flags
The following is a quick query to tell who is using your server.
Figure 16. SQL script showing user sessions
-- sessions.sql
select  sid,
        username,
        pid,
        hostname,
        l2date(connected) startdate -- convert unix time to date
from    syssessions
Sample Output
        sid username         pid hostname         startdate
         47 lester         11564 merlin           07/14/1997
This next query list all users and their session status. The objective is to show who is blocked waiting on another user, lock, or some other OnLine process. The five fields are yes/no flags where 1 = yes and 0 = no. If all the fields are 0, then none of the sessions are blocked. In the following example, one session is blocked waiting on a locked record.
Figure 17. SQL script users waiting on resources
-- seswait.sql
select  username,
        is_wlatch,      -- blocked waiting on a latch
        is_wlock,       -- blocked waiting on a locked record or table
        is_wbuff,       -- blocked waiting on a buffer
        is_wckpt,       -- blocked waiting on a checkpoint
        is_incrit       -- session is in a critical section of transaction
                        --      (e.g writting to disk)
from    syssessions
order by username;
Sample Output
username   is_wlatch    is_wlock    is_wbuff    is_wckpt   is_incrit
lester             0           1           0           0           0
lester             0           0           0           0           0
lester             0           0           0           0           0
User Session Performance Statistics: syssesprof
This view syssesprof provides a way to find out at a given point in time how much of your server resources each user is using. The view contains the following information.View syssesprof
        Column          Data Type       Description
        sid             integer,        Session Id
        lockreqs        decimal(16,0)   Locks requested
        locksheld       decimal(16,0)   Locks held
        lockwts         decimal(16,0)   Locks waits
        deadlks         decimal(16,0)   Deadlocks detected
        lktouts         decimal(16,0)   Deadlock timeouts
        logrecs         decimal(16,0)   Logical Log records written
        isreads         decimal(16,0)   Reads
        iswrites        decimal(16,0)   Writes
        isrewrites      decimal(16,0)   Rewrites
        isdeletes       decimal(16,0)   Deletes
        iscommits       decimal(16,0)   Commits
        isrollbacks     decimal(16,0)   Rollbacks
        longtxs         decimal(16,0)   Long transactions
        bufreads        decimal(16,0)   Buffer reads
        bufwrites       decimal(16,0)   Buffer writes
        seqscans        decimal(16,0)   Sequential scans
        pagreads        decimal(16,0)   Page reads
        pagwrites       decimal(16,0)   Page writes
        total_sorts     decimal(16,0)   Total sorts
        dsksorts        decimal(16,0)   Sorts to disk
        max_sortdiskspace decimal(16,0) Max space used by a sort
        logspused       decimal(16,0)   Current log bytes used
        maxlogsp        decimal(16,0)   Max bytes of logical logs used
This table contains data since the user logged on. Each time a user disconnects their data is lost so you cannot use this data for charging the user for server usage. Also, when a DBA resets the server statistics with the command "tbstat -z", all profile data is reset to zero.
I like to monitor the number of locks used by each user and their buffer usage. The following is an example query.
Figure 19. SQL script to monitor resource usage by user
-- sesprof.sql
select  username,
        syssesprof.sid,
        lockreqs,
        bufreads,
        bufwrites
from    syssesprof, syssessions
where   syssesprof.sid = syssessions.sid
order by bufreads desc
Active Locks on the Server: syslocks
This view contains information about all active locks on your server. It can be very large; if you have a lot of users and your server is configured to handle a large number of locks, you could end up with hundreds of thousands or more records in this view. This view is composed of six tables, and queries on this view will create a temp table which is logged to your logical log. The performance may be a bit slow because of the sheer volume of data produced by this view. However, the data this view contains can be very helpful to understanding how your system is performing.View syslocks
        Column          Data Type       Description
        dbsname         char(18)        Database name
        tabname         char(18)        Table name
        rowidlk         integer         Rowid for index key lock
        keynum          smallint        Key number of index key lock
        owner           integer         Session ID of lock owner
        waiter          integer         Session ID of first waiter
        type            char(4)         Type of Lock
        Types of Locks
        B       - byte lock
        IS      - intent shared lock
        S       - shared lock
        XS      - repeatable read shared key
        U       - update lock
        IX      - intent exclusive lock
        SIX     - shared intent exclusive
        X       - exclusive lock
        XR      - repeatable read exclusive
Basically there are three types of locks: a shared lock (S), an exclusive lock (X), and an update lock(U). A shared lock allows other users to also read the data but none may change it. An exclusive lock does not allow anyone else to lock that data even in shared mode. An update lock prevents other users from changing data while you are changing it.
There are six objects that can be locked in OnLine.
Database - Every user that opens a database places a shared lock on the database to prevent someone else from dropping the database while it is in use. This shows up as a lock on the sysmaster database and the sysdatabase tables, and the rowid will point to the record containing database name.
Table - A table lock shows up as a lock on a table with a rowid of 0 and a keynum of 0.
Page - A page level lock shows as a rowid ending in 00. This means all the rows on that page are locked.
Row - A row level lock will show with an actual rowid (not ending in 00).
Key - A key lock will show with a keynum. If a row has indexes that need to be updated this will place locks on the indexes for that row.
One of the key data elements missing from this view is the username and session id (sid) of the user who has a lock. The following query adds the user's name and session id and uses the underlying tables to improve performance. It also puts the data into a temp table from which you can select subsets of data much more quickly than if you were to repeat the query.
Figure 20. SQL script to show all locks
-- locks.sql
select  dbsname,
        b.tabname,
        rowidr,
        keynum,
        e.txt           type,
        d.sid           owner,
        g.username ownername,
        f.sid           waiter,
        h.username waitname
from    syslcktab a,
        systabnames b,
        systxptab c,
        sysrstcb        d,
        sysscblst g,
        flags_text e,
        outer ( sysrstcb f , sysscblst h  )
where   a.partnum = b.partnum
and     a.owner = c.address
and     c.owner = d.address
and     a.wtlist = f.address
and     d.sid = g.sid
and     e.tabname = 'syslcktab'
and     e.flags = a.type
and     f.sid = h.sid
into temp A;
select  dbsname,
        tabname,
        rowidr,
        keynum,
        type[1,4],
        owner,
        ownername ,
        waiter,
        waitname
from A;
Example SQL Output
dbsname    sysmaster
tabname    a
rowidr     0
keynum     0
type       X
owner      47
ownername  lester
waiter
waitname
The above example SQL output shows the row from syslocks that displays the exclusive lock I created on the temp table "A" while running the query.
A more important use of this query is to find out when one user is waiting on the lock owned by another user. When a user has a database object locked, the first user waiting on the object can be displayed. (This will only occur when a user has set lock mode to WAIT). The following script displays only the users that have locks where someone else is waiting on their process. There is one key difference between this script and the one above. The tables sysrstcb and sysscblst in this script do not use an outer join, so only rows that have waiters will be returned. In this example "linda" has an update lock on a row and "lester" is waiting for that update to complete.
Figure 21. SQL script to show users waiting on locks
-- lockwaits.sql
database sysmaster;
select  dbsname,
        b.tabname,
        rowidr,
        keynum,
        e.txt   type,
        d.sid   owner,
        g.username ownername,
        f.sid   waiter,
        h.username waitname
from    syslcktab a,
        systabnames b,
        systxptab c,
        sysrstcb d,
        sysscblst g,
        flags_text e,
        sysrstcb f , sysscblst h
where   a.partnum = b.partnum
and     a.owner = c.address
and     c.owner = d.address
and     a.wtlist = f.address
and     d.sid = g.sid
and     e.tabname = 'syslcktab'
and     e.flags = a.type
and     f.sid = h.sid
into temp A;
select  dbsname,
        tabname,
        type[1,4],
        owner,
        ownername ,
        waitname
from A;
SQL Output
dbsname            tabname            type       owner ownername waitname
stores7            items              U             29 linda     lester
Wait Status and Times on Objects: sysseswts
This is a supported view that shows all sessions that are blocked and waiting on a database object. It shows the amount of time a user has been waiting. On a well tuned system this table should be empty. However, when the table is not empty, it provides useful information on what is causing your performance to slow down.View sysseswts
        Column          Data Type       Description
        sid             integer         Session ID
        reason          char(50)        Description of reason for wait
        numwaits        integer         Number of waits for this reason
        cumtime         float           Cumulative wait time for this reason
        maxtime         integer         Max wait time for this reason
7. Some Unsupported Extras
Several of the SMI tables are not documented and not officially supported. These could change in future releases. Two additional unsupported tables I have found helpful are systrans and syssqexplain.
User Transactions: systrans
Three of the fields in systrans are very helpful to determine what logical log number a transaction began in, and the current logical log number in use by a transaction.Key systrans fields
        Column          Data Type       Description
        tx_id           integer         pointer to transaction table
        tx_logbeg       integer         transaction starting logical log
        tx_loguniq      integer         transaction current logical log number
This can be used to create a script to determine what logical log files have active transactions. The output of this will tell you what logical logs are free and available for reuse. This first script lists all user transactions and what logs they are using.
Figure 22. SQL script to display transactions and logs used
-- txlogpos.sql
select
        t.username,
        t.sid,
        tx_logbeg,
        tx_loguniq,
        tx_logpos
from    systrans x, sysrstcb t
where   tx_owner = t.address
SQL Output
username         sid   tx_logbeg  tx_loguniq   tx_logpos
informix           1           0          16      892952
informix           0           0           0           0
informix           8           0           0           0
lester            53           0           0           0
informix          12           0           0           0
lester            51          14          16           0
This shows that my logical logs numbered 14 to 16 are in use by transactions.
Another helpful use of this view is to summarize the transactions by logical logs. This next script show my transaction status by logical log.
Figure 23. SQL script to view logical logs status
-- logstat.sql
database sysmaster;
-- select transaction data into a temp table
select  tx_logbeg,   tx_loguniq
from    systrans
into temp b;
-- count how may transactions begin in each log
select tx_logbeg, count(*) cnt
from B
where tx_logbeg > 0
group by tx_logbeg
into temp C;
-- count how many transactions currently are in each log
select tx_loguniq, count(*) cnt
from B
where tx_loguniq > 0
group by tx_loguniq
into temp D;
-- join data from counts with syslogs
select
        uniqid,
        size,
        is_backed_up,   -- 0 = no, 1 = yes log is backed up
        is_archived,    -- 0 = no, 1 = yes log is on last archive
        c.cnt   tx_beg_cnt,
        d.cnt   tx_curr_cnt
from    syslogs, outer c, outer D
where   uniqid = c.tx_logbeg
and     uniqid = d.tx_loguniq
order by uniqid
SQL Output
     uniqid        size is_backed_up is_archived  tx_beg_cnt tx_curr_cnt
         10         500            1           1
         11         500            1           1
         12         500            1           1
         13         500            1           1
         14         500            1           1
         15         500            1           1
         16         500            0           1           1           2
This shows that all logs are backed up except the current one, and it has two active transactions.
User Queries: syssqexplain
Have you ever wanted to run a query to see what your users were doing? The view syssqexplain contains some of the data from a user's session, including the sql that they are currently executing. Try this query on your system sometime to see your user's SQL.
Figure 24. SQL to view current executing SQL

-- syssql.sql
select  username,
        sqx_sessionid,
        sqx_conbno,
        sqx_sqlstatement
from syssqexplain, sysscblst
where   sqx_sessionid = sid

SQL Output
username lester

sqx_sessionid     55
sqx_conbno        2
sqx_sqlstatement  select username,sqx_sessionid, sqx_conbno, sqx_sqlstatement
                                from syssqexplain, sysscblst
                                where   sqx_sessionid = sid
username          lester
sqx_sessionid     51
sqx_conbno        0
sqx_sqlstatement  update items set total_price = 300 where item_num = 1

Conclusion
The sysmaster database is a great tool for a DBA to monitor the Informix server. If you have any questions or suggestions please send me E-mail at lester@advancedatatools.com. Also, if you have any creative scripts for monitoring your server with the sysmaster database, please send them in and I may include them in the future publications.