2007 年 7 月 30 日

如今，开发人员不断地开发和部署使用 LAMP（Linux®、Apache、MySQL 和 PHP/Perl）架构的应用程序。但是，服务器管理员常常对应用程序本身没有什么控制能力，因为应用程序是别人编写的。这份 共三部分的系列文章 将讨论许多服务器配置问题，这些配置会影响应用程序的性能。本文是本系列文章的第三部分，也是最后一部分，将重点讨论为实现最高效率而对数据库层进行的调优。

关于 MySQL 调优

有 3 种方法可以加快 MySQL 服务器的运行速度，效率从低到高依次为：

1. 替换有问题的硬件。
   
2. 对 MySQL 进程的设置进行调优。
   
3. 对查询进行优化。

替换有问题的硬件通常是我们的第一考虑，主要原因是数据库会占用大量资源。不过这种解决方案也就仅限于此了。实际上，您通常可以让中央处理器（CPU）或磁盘速度加倍，也可以让内存增大 4 到 8 倍。

第二种方法是对 MySQL 服务器（也称为 mysqld）进行调优。对这个进程进行调优意味着适当地分配内存，并让 mysqld 了解将会承受何种类型的负载。加快磁盘运行速度不如减少所需的磁盘访问次数。类似地，确保 MySQL 进程正确操作就意味着它花费在服务查询上的时间要多于花费在处理后台任务（如处理临时磁盘表或打开和关闭文件）上的时间。对 mysqld 进行调优是本文的重点。

最好的方法是确保查询已经进行了优化。这意味着对表应用了适当的索引，查询是按照可以充分利用 MySQL 功能的方式来编写的。尽管本文并没有包含查询调优方面的内容（很多著作中已经针对这个主题进行了探讨），不过它会配置 mysqld 来报告可能需要进行调优的查询。

虽然已经为这些任务指派了次序，但是仍然要注意硬件和 mysqld 的设置以利于适当地调优查询。机器速度慢也就罢了，我曾经见过速度很快的机器在运行设计良好的查询时由于负载过重而失败，因为 mysqld 被大量繁忙的工作所占用而不能服务查询。

记录慢速查询

在一个 SQL 服务器中，数据表都是保存在磁盘上的。索引为服务器提供了一种在表中查找特定数据行的方法，而不用搜索整个表。当必须要搜索整个表时，就称为表扫描。通常来说，您可能只希望获得表中数据的一个子集，因此全表扫描会浪费大量的磁盘 I/O，因此也就会浪费大量时间。当必须对数据进行连接时，这个问题就更加复杂了，因为必须要对连接两端的多行数据进行比较。

当然，表扫描并不总是会带来问题；有时读取整个表反而会比从中挑选出一部分数据更加有效（服务器进程中查询规划器用来作出这些决定）。如果索引的使用效率很低，或者根本就不能使用索引，则会减慢查询速度，而且随着服务器上的负载和表大小的增加，这个问题会变得更加显著。执行时间超过给定时间范围的查询就称为慢速查询。

您可以配置 mysqld 将这些慢速查询记录到适当命名的慢速查询日志中。管理员然后会查看这个日志来帮助他们确定应用程序中有哪些部分需要进一步调查。清单 1 给出了要启用慢速查询日志需要在 my.cnf 中所做的配置。

[mysqld]

; enable the slow query log, default 10 seconds

log-slow-queries

; log queries taking longer than 5 seconds

long_query_time = 5

; log queries that don’t use indexes even if they take less than long_query_time

; MySQL 4.1 and newer only

log-queries-not-using-indexes

这三个设置一起使用，可以记录执行时间超过 5 秒和没有使用索引的查询。请注意有关 log-queries-not-using-indexes 的警告：您必须使用 MySQL 4.1 或更高版本。慢速查询日志都保存在 MySQL 数据目录中，名为 hostname-slow.log。如果希望使用一个不同的名字或路径，可以在 my.cnf 中使用 log-slow-queries = /new/path/to/file 实现此目的。

阅读慢速查询日志最好是通过 mysqldumpslow 命令进行。指定日志文件的路径，就可以看到一个慢速查询的排序后的列表，并且还显示了它们在日志文件中出现的次数。一个非常有用的特性是 mysqldumpslow 在比较结果之前，会删除任何用户指定的数据，因此对同一个查询的不同调用被计为一次；这可以帮助找出需要工作量最多的查询。

对查询进行缓存

很多 LAMP 应用程序都严重依赖于数据库，但却会反复执行相同的查询。每次执行查询时，数据库都必须要执行相同的工作 —— 对查询进行分析，确定如何执行查询，从磁盘中加载信息，然后将结果返回给客户机。MySQL 有一个特性称为查询缓存，它将（后面会用到的）查询结果保存在内存中。在很多情况下，这会极大地提高性能。不过，问题是查询缓存在默认情况下是禁用的。

将 query_cache_size = 32M 添加到 /etc/my.conf 中可以启用 32MB 的查询缓存。

监视查询缓存

在启用查询缓存之后，重要的是要理解它是否得到了有效的使用。MySQL 有几个可以查看的变量，可以用来了解缓存中的情况。清单 2 给出了缓存的状态。

mysql> SHOW STATUS LIKE ‘qcache%’;

+————————-+————+

| Variable_name           | Value      |

+————————-+————+

| Qcache_free_blocks      | 5216       |

| Qcache_free_memory      | 14640664   |

| Qcache_hits             | 2581646882 |

| Qcache_inserts          | 360210964  |

| Qcache_lowmem_prunes    | 281680433  |

| Qcache_not_cached       | 79740667   |

| Qcache_queries_in_cache | 16927      |

| Qcache_total_blocks     | 47042      |

+————————-+————+

8 rows in set (0.00 sec)

这些项的解释如表 1 所示。

通常，间隔几秒显示这些变量就可以看出区别，这可以帮助确定缓存是否正在有效地使用。运行 FLUSH STATUS 可以重置一些计数器，如果服务器已经运行了一段时间，这会非常有帮助。

使用非常大的查询缓存，期望可以缓存所有东西，这种想法非常诱人。由于 mysqld 必须要对缓存进行维护，例如当内存变得很低时执行剪除，因此服务器可能会在试图管理缓存时而陷入困境。作为一条规则，如果 FLUSH QUERY CACHE 占用了很长时间，那就说明缓存太大了。

强制限制

您可以在 mysqld 中强制一些限制来确保系统负载不会导致资源耗尽的情况出现。清单 3 给出了 my.cnf 中与资源有关的一些重要设置。

set-variable=max_connections=500

set-variable=wait_timeout=10

max_connect_errors = 100

连接最大个数是在第一行中进行管理的。与 Apache 中的 MaxClients 类似，其想法是确保只建立服务允许数目的连接。要确定服务器上目前建立过的最大连接数，请执行 SHOW STATUS LIKE ‘max_used_connections’。

第 2 行告诉 mysqld 终止所有空闲时间超过 10 秒的连接。在 LAMP 应用程序中，连接数据库的时间通常就是 Web 服务器处理请求所花费的时间。有时候，如果负载过重，连接会挂起，并且会占用连接表空间。如果有多个交互用户或使用了到数据库的持久连接，那么将这个值设低一点并不可取！

最后一行是一个安全的方法。如果一个主机在连接到服务器时有问题，并重试很多次后放弃，那么这个主机就会被锁定，直到 FLUSH HOSTS 之后才能运行。默认情况下，10 次失败就足以导致锁定了。将这个值修改为 100 会给服务器足够的时间来从问题中恢复。如果重试 100 次都无法建立连接，那么使用再高的值也不会有太多帮助，可能它根本就无法连接。

缓冲区和缓存

MySQL 支持超过 100 个的可调节设置；但是幸运的是，掌握少数几个就可以满足大部分需要。查找这些设置的正确值可以通过 SHOW STATUS 命令查看状态变量，从中可以确定 mysqld 的运作情况是否符合我们的预期。给缓冲区和缓存分配的内存不能超过系统中的现有内存，因此调优通常都需要进行一些妥协。

MySQL 可调节设置可以应用于整个 mysqld 进程，也可以应用于单个客户机会话。

服务器端的设置

每个表都可以表示为磁盘上的一个文件，必须先打开，后读取。为了加快从文件中读取数据的过程，mysqld 对这些打开文件进行了缓存，其最大数目由 /etc/mysqld.conf 中的 table_cache 指定。清单 4 给出了显示与打开表有关的活动的方式。

mysql> SHOW STATUS LIKE ‘open%tables’;

+—————+——-+

| Variable_name | Value |

+—————+——-+

| Open_tables   | 5000  |

| Opened_tables | 195   |

+—————+——-+

2 rows in set (0.00 sec)

清单 4 说明目前有 5,000 个表是打开的，有 195 个表需要打开，因为现在缓存中已经没有可用文件描述符了（由于统计信息在前面已经清除了，因此可能会存在 5,000 个打开表中只有 195 个打开记录的情况）。如果 Opened_tables 随着重新运行 SHOW STATUS 命令快速增加，就说明缓存命中率不够。如果 Open_tables 比 table_cache 设置小很多，就说明该值太大了（不过有空间可以增长总不是什么坏事）。例如，使用 table_cache = 5000 可以调整表的缓存。

与表的缓存类似，对于线程来说也有一个缓存。 mysqld 在接收连接时会根据需要生成线程。在一个连接变化很快的繁忙服务器上，对线程进行缓存便于以后使用可以加快最初的连接。

清单 5 显示如何确定是否缓存了足够的线程。

mysql> SHOW STATUS LIKE ‘threads%’;

+——————-+——–+

| Variable_name     | Value  |

+——————-+——–+

| Threads_cached    | 27     |

| Threads_connected | 15     |

| Threads_created   | 838610 |

| Threads_running   | 3      |

+——————-+——–+

4 rows in set (0.00 sec)

此处重要的值是 Threads_created，每次 mysqld 需要创建一个新线程时，这个值都会增加。如果这个数字在连续执行 SHOW STATUS 命令时快速增加，就应该尝试增大线程缓存。例如，可以在 my.cnf 中使用 thread_cache = 40 来实现此目的。

关键字缓冲区保存了 MyISAM 表的索引块。理想情况下，对于这些块的请求应该来自于内存，而不是来自于磁盘。清单 6 显示了如何确定有多少块是从磁盘中读取的，以及有多少块是从内存中读取的。

mysql> show status like ‘%key_read%’;

+——————-+———–+

| Variable_name     | Value     |

+——————-+———–+

| Key_read_requests | 163554268 |

| Key_reads         | 98247     |

+——————-+———–+

2 rows in set (0.00 sec)

Key_reads 代表命中磁盘的请求个数， Key_read_requests 是总数。命中磁盘的读请求数除以读请求总数就是不中比率 —— 在本例中每 1,000 个请求，大约有 0.6 个没有命中内存。如果每 1,000 个请求中命中磁盘的数目超过 1 个，就应该考虑增大关键字缓冲区了。例如，key_buffer = 384M 会将缓冲区设置为 384MB。

临时表可以在更高级的查询中使用，其中数据在进一步进行处理（例如 GROUP BY 字句）之前，都必须先保存到临时表中；理想情况下，在内存中创建临时表。但是如果临时表变得太大，就需要写入磁盘中。清单 7 给出了与临时表创建有关的统计信息。

mysql> SHOW STATUS LIKE ‘created_tmp%’;

+————————-+——-+

| Variable_name           | Value |

+————————-+——-+

| Created_tmp_disk_tables | 30660 |

| Created_tmp_files       | 2     |

| Created_tmp_tables      | 32912 |

+————————-+——-+

3 rows in set (0.00 sec)

每次使用临时表都会增大 Created_tmp_tables；基于磁盘的表也会增大 Created_tmp_disk_tables。对于这个比率，并没有什么严格的规则，因为这依赖于所涉及的查询。长时间观察 Created_tmp_disk_tables 会显示所创建的磁盘表的比率，您可以确定设置的效率。 tmp_table_size 和 max_heap_table_size 都可以控制临时表的最大大小，因此请确保在 my.cnf 中对这两个值都进行了设置。

每个会话的设置

下面这些设置针对于每个会话。在设置这些数字时要十分谨慎，因为它们在乘以可能存在的连接数时候，这些选项表示大量的内存！您可以通过代码修改会话中的这些数字，或者在 my.cnf 中为所有会话修改这些设置。

当 MySQL 必须要进行排序时，就会在从磁盘上读取数据时分配一个排序缓冲区来存放这些数据行。如果要排序的数据太大，那么数据就必须保存到磁盘上的临时文件中，并再次进行排序。如果 sort_merge_passes 状态变量很大，这就指示了磁盘的活动情况。清单 8 给出了一些与排序相关的状态计数器信息。

mysql> SHOW STATUS LIKE “sort%”;

+——————-+———+

| Variable_name     | Value   |

+——————-+———+

| Sort_merge_passes | 1       |

| Sort_range        | 79192   |

| Sort_rows         | 2066532 |

| Sort_scan         | 44006   |

+——————-+———+

4 rows in set (0.00 sec)

如果 sort_merge_passes 很大，就表示需要注意 sort_buffer_size。例如， sort_buffer_size = 4M 将排序缓冲区设置为 4MB。

MySQL 也会分配一些内存来读取表。理想情况下，索引提供了足够多的信息，可以只读入所需要的行，但是有时候查询（设计不佳或数据本性使然）需要读取表中大量数据。要理解这种行为，需要知道运行了多少个 SELECT 语句，以及需要读取表中的下一行数据的次数（而不是通过索引直接访问）。实现这种功能的命令如清单 9 所示。

mysql> SHOW STATUS LIKE “com_select”;

+—————+——–+

| Variable_name | Value  |

+—————+——–+

| Com_select    | 318243 |

+—————+——–+

1 row in set (0.00 sec)

mysql> SHOW STATUS LIKE “handler_read_rnd_next”;

+———————–+———–+

| Variable_name         | Value     |

+———————–+———–+

| Handler_read_rnd_next | 165959471 |

+———————–+———–+

1 row in set (0.00 sec)

Handler_read_rnd_next / Com_select 得出了表扫描比率 —— 在本例中是 521:1。如果该值超过 4000，就应该查看 read_buffer_size，例如 read_buffer_size = 4M。如果这个数字超过了 8M，就应该与开发人员讨论一下对这些查询进行调优了！

3 个必不可少的工具

尽管在了解具体设置时，SHOW STATUS 命令会非常有用，但是您还需要一些工具来解释 mysqld 所提供的大量数据。我发现有 3 个工具是必不可少的；在 参考资料 一节中您可以找到相应的链接。

大部分系统管理员都非常熟悉 top 命令，它为任务所消耗的 CPU 和内存提供了一个不断更新的视图。 mytop 对 top 进行了仿真；它为所有连接上的客户机以及它们正在运行的查询提供了一个视图。mytop 还提供了一个有关关键字缓冲区和查询缓存效率的实时数据和历史数据，以及有关正在运行的查询的统计信息。这是一个很有用的工具，可以查看系统中（比如 10 秒钟之内）的状况，您可以获得有关服务器健康信息的视图，并显示导致问题的任何连接。

mysqlard 是一个连接到 MySQL 服务器上的守护程序，负责每 5 分钟搜集一次数据，并将它们存储到后台的一个 Round Robin Database 中。有一个 Web 页面会显示这些数据，例如表缓存的使用情况、关键字效率、连接上的客户机以及临时表的使用情况。尽管 mytop 提供了服务器健康信息的快照，但是 mysqlard 则提供了长期的健康信息。作为奖励，mysqlard 使用自己搜集到的一些信息针对如何对服务器进行调优给出一些建议。

搜集 SHOW STATUS 信息的另外一个工具是 mysqlreport。其报告要远比 mysqlard 更加复杂，因为需要对服务器的每个方面都进行分析。这是对服务器进行调优的一个非常好的工具，因为它对状态变量进行适当计算来帮助确定需要修正哪些问题。

Linux 技巧: 用 cron 和 at 调度作业

如何轻松地管理系统

2007 年 8 月 27 日

系统管理员需要在系统负载低的午夜运行作业，或者需要每天或每月运行作业，同时又不愿意牺牲睡眠时间或假期。调度任务的其他原因包括自动执行日常任务或者确保每次都以相同的方式处理任务。本文帮助您使用 cron 和 at 功能调度作业定期运行或在指定的时间运行一次。

Linux® 和 UNIX® 系统允许调度任务在以后执行一次，或者重复运行。本文是从 developerWorks 教程 “LPI 102 考试准备：管理任务” 摘录的，讲解如何调度作业定期运行，或在指定的时间运行一次。

在 Linux 系统上，许多管理任务必须频繁地定期执行。这些任务包括轮转日志文件以避免装满文件系统、备份数据和连接时间服务器来执行系统时间同步。上面提到的教程更详细地介绍了这些管理任务。在本文中，学习 Linux 中提供的调度机制，包括 cron 和 anacron 设施以及 crontab 和 at 命令。即使系统常常关机，anacron 也可以帮助调度作业。

以一定的时间间隔运行作业

以一定的时间间隔运行作业需要使用 cron 设施进行管理，它由 crond 守护进程和一组表（描述执行哪些操作和采用什么样的频率）组成。这个守护进程每分钟唤醒一次，并通过检查 crontab 判断需要做什么。用户使用 crontab 命令管理 crontab。crond 守护进程常常是在系统启动时由 init 进程启动的。

为了简单，假设希望定期运行清单 1 所示的命令。这个命令实际上只报告日期和时间，其他什么事都不做，但是它可以说明如何使用 crontab 设置 cron 作业，而且还可以通过输出看到作业运行的时间。设置 crontab 条目需要一个包含转义的 shell 元字符的字符串，所以适合于简单的命令和参数。在这个示例中，将从脚本 /home/ian/mycrontab.sh 运行 echo 命令，这个脚本不需要参数。 这可以减少处理转义字符的工作。

清单 1. 一个简单的命令示例

[ian@lyrebird ~]$ cat mycrontest.sh #!/bin/bash echo “It is now $(date +%T) on $(date +%A)” [ian@lyrebird ~]$ ./mycrontest.sh It is now 18:37:42 on Friday

创建 crontab

使用 crontab 命令和 -e（表示 “edit”）选项创建 crontab。这会打开 vi 编辑器，除非在 EDITOR 或 VISUAL 环境变量中指定了另一种编辑器。

每个 crontab 条目包含六个字段：

1. 分钟
   
2. 小时
   
3. 日
   
4. 月
   
5. 星期
   
6. 由 sh 执行的字符串

分钟和小时的范围分别是 0-59 和 0-12，日和月的范围分别是 1-31 和 1-12。星期的范围是 0-6，0 表示星期日。星期也可以指定为 sun、mon、tue 等等。第 6 个字段包含前 5 个字段之后的所有内容，它是要传递给 sh 的字符串。百分号（%）将转换为空行，所以如果要使用 % 或其他任何特殊字符，就要在前面加上反斜线（\）。第一个 % 之前的一行传递给 shell，这个 % 之后的所有行都作为标准输入传递。

各个与时间相关的字段可以指定一个单独的值、值的范围（比如 0-10 或 sun-wed）或者以逗号分隔的单独值和范围列表。清单 2 给出一个 crontab 条目示例。

清单 2. 一个简单的 crontab 示例

0,20,40 22-23 * 7 fri-sat /home/ian/mycrontest.sh

在这个示例中，我们的命令在 7 月的每个星期五和星期六晚上 10 点到午夜之间的第 0、20、40 分钟（每 20 分钟）执行。关于指定时间的其他方式的细节，参见 crontab(5) 的手册页。

输出

您可能想知道对来自命令的输出会如何处理。为使用 cron 而设计的大多数命令会使用 syslog 在日志中记录输出（参见教程 “LPI 102 考试准备：管理任务” 中的讨论）。但是，定向到 stdout 的输出会通过电子邮件发送给用户。清单 3 给出我们的命令示例可能产生的输出。

清单 3. 通过电子邮件发送的 cron 输出

From ian@lyrebird.raleigh.ibm.com Fri Jul 6 23:00:02 2007 Date: Fri, 6 Jul 2007 23:00:01 -0400 From: root@lyrebird.raleigh.ibm.com (Cron Daemon) To: ian@lyrebird.raleigh.ibm.com Subject: Cron <ian@lyrebird> /home/ian/mycrontest.sh Content-Type: text/plain; charset=UTF-8 Auto-Submitted: auto-generated X-Cron-Env: <SHELL=/bin/sh> X-Cron-Env: <HOME=/home/ian> X-Cron-Env: <PATH=/usr/bin:/bin> X-Cron-Env: <LOGNAME=ian> X-Cron-Env: <USER=ian> It is now 23:00:01 on Friday

crontab 存储在哪里？

suid 程序 suid 程序以程序文件的所有者的权限运行，而不是采用运行程序的用户的权限。关于 suid 的更多信息，参见教程 “LPI 101 考试准备：设备、Linux 文件系统和 Filesystem Hierarchy Standard”；关于 passwd 命令的更多信息，参见教程 “LPI 102 考试准备：管理任务”。

用 crontab 命令创建的 crontab 存储在 /etc/spool/cron 下面的一个子目录中，这个子目录与创建 crontab 的用户同名，所以上面的 crontab 存储在 /etc/spool/cron/ian 中。因此，与 passwd 命令一样，crontab 命令是一个用根权限运行的 suid 程序。

/etc/crontab

除了 /var/spool/cron 中的用户 crontab 文件之外，cron 还会检查 /etc/crontab 文件和 /etc/cron.d 目录中的文件。在这些系统 crontab 中，在第五个时间字段（星期）和命令之间增加了一个字段。这个字段指定哪个用户应该运行这个命令，一般情况下是根用户。清单 4 给出一个 /etc/crontab 文件示例。

清单 4. /etc/crontab

SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root HOME=/ # run-parts 01 * * * * root run-parts /etc/cron.hourly 02 4 * * * root run-parts /etc/cron.daily 22 4 * * 0 root run-parts /etc/cron.weekly 42 4 1 * * root run-parts /etc/cron.monthly

在这个示例中，真正的工作由 run-parts 命令执行，它运行 /etc/cron.hourly、/etc/cron.daily 等目录中的脚本；/etc/crontab 仅仅控制执行作业的时间。注意，这里的所有命令都作为根用户运行。还要注意，crontab 可以包含 shell 变量赋值，这些赋值会在运行命令之前执行。

anacron

cron 适合那些连续运行的系统。对于那些常常不开机的系统，比如笔记本计算机，可以使用另一个实用程序 anacron（表示 “anachronistic cron”）调度每日、每周或每月执行的作业。anacron 不处理每小时执行的作业。

anacron 在 /var/spool/anacron 中保留时间戳文件，记录作业运行的时间。当 anacron 运行时，它检查自作业上一次运行以来是否已经经过了所需的天数，如果需要，就运行作业。anacron 的作业表存储在 /etc/anacrontab 中，文件格式与 /etc/crontab 略有不同。与 /etc/crontab 一样，/etc/anacrontab 可以包含环境设置。每个作业有四个字段：

1. 周期
   
2. 延迟
   
3. 作业标识符
   
4. 命令

周期是天数，但是可以指定为 @monthly，这确保作业每个月只运行一次（无论这个月中有多少天）。延迟是在作业符合运行条件之后，到实际启动它之前等待的分钟数。可以使用这个设置防止在系统启动时集中执行作业。作业标识符可以包含除了斜线（/）之外的所有非空白字符。

/etc/crontab 和 /etc/anacrontab 都通过直接编辑进行更新。不使用 crontab 命令更新这些文件或 /etc/cron.d 目录中的文件。

在指定的时间运行作业

有时候，需要只运行作业一次而不是定期运行。为此，应该使用 at 命令。要运行的命令是从 -f 选项指定的文件读取的，如果没有使用 -f，那么从 stdin 读取。-m 选项向用户发送邮件，即使命令没有 stdout。-v 选项显示运行作业的时间。这个时间也显示在输出中。

清单 5 给出一个运行 mycrontest.sh 脚本的示例。清单 6 显示在运行作业之后通过邮件发送给用户的输出。注意，这里的输出比对应的 cron 作业输出要简单一些。

清单 5. 使用 at 命令

[ian@lyrebird ~]$ at -f mycrontest.sh -v 10:25 Sat Jul 7 10:25:00 2007 job 5 at Sat Jul 7 10:25:00 2007

清单 6. 来自 at 的作业输出

From ian@lyrebird.raleigh.ibm.com Sat Jul 7 10:25:00 2007 Date: Sat, 7 Jul 2007 10:25:00 -0400 From: Ian Shields <ian@lyrebird.raleigh.ibm.com> Subject: Output from your job 5 To: ian@lyrebird.raleigh.ibm.com It is now 10:25:00 on Saturday

时间的设置可以非常复杂。清单 7 给出几个示例。参见 at 的手册页、/usr/share/doc/at/timespec 文件或 /usr/share/doc/at-3.1.10/timespec 这样的文件（这个示例中的 3.1.10 是 at 包的版本号）。

清单 7. at 命令使用的时间值

[ian@lyrebird ~]$ at -f mycrontest.sh 10pm tomorrow job 14 at Sun Jul 8 22:00:00 2007 [ian@lyrebird ~]$ at -f mycrontest.sh 2:00 tuesday job 15 at Tue Jul 10 02:00:00 2007 [ian@lyrebird ~]$ at -f mycrontest.sh 2:00 july 11 job 16 at Wed Jul 11 02:00:00 2007 [ian@lyrebird ~]$ at -f mycrontest.sh 2:00 next week job 17 at Sat Jul 14 02:00:00 2007

nice 值 nice 值表示一个作业对于其他用户的优先程度。关于 nice 和 renice 命令的更多信息，参见教程 “LPI 101 考试准备：GNU 和 UNIX 命令”。

at 命令还有一个 -q 选项。随着队列的增长，作业的 nice 值也会增长。 还有一个 batch 命令，它与 at 命令相似，但是作业只在系统负载足够低时运行。这些特性的细节参见手册页。

管理调度的作业

列出调度的作业

可以管理 cron 和 at 作业。使用 crontab 命令和 -l 选项列出 crontab，使用 atq 命令显示用 at 命令加入队列中的作业，见清单 8。

清单 8. 显示调度的作业

[ian@lyrebird ~]$ crontab -l 0,20,40 22-23 * 7 fri-sat /home/ian/mycrontest.sh [ian@lyrebird ~]$ atq 16 Wed Jul 11 02:00:00 2007 a ian 17 Sat Jul 14 02:00:00 2007 a ian 14 Sun Jul 8 22:00:00 2007 a ian 15 Tue Jul 10 02:00:00 2007 a ian

如果希望查看 at 调度执行的实际命令，那么可以使用 at 命令并加上 -c 选项和作业号。您会注意到，在发出 at 命令时生效的大多数环境设置会随调度的作业一起保存。清单 9 给出清单 7 和清单 8 中作业 15 的部分输出。

清单 9. 使用 at -c 并加上作业号

#!/bin/sh # atrun uid=500 gid=500 # mail ian 0 umask 2 HOSTNAME=lyrebird.raleigh.ibm.com; export HOSTNAME SHELL=/bin/bash; export SHELL HISTSIZE=1000; export HISTSIZE SSH_CLIENT=9.67.219.151\ 3210\ 22; export SSH_CLIENT SSH_TTY=/dev/pts/5; export SSH_TTY USER=ian; export USER … HOME=/home/ian; export HOME LOGNAME=ian; export LOGNAME … cd /home/ian || { echo ‘Execution directory inaccessible’ >&2 exit 1 } ${SHELL:-/bin/sh} << `(dd if=/dev/urandom count=200 bs=1 \ 2>/dev/null|LC_ALL=C tr -d -c ‘[:alnum:]’)` #!/bin/bash echo “It is now $(date +%T) on $(date +%A)”

注意，我们脚本文件的内容已经复制在一个 here-document 中，这个 here-document 将由 SHELL 变量指定的 shell 执行（如果没有设置 SHELL 变量，就使用 /bin/sh）。关于 here-document 的信息参见教程 “LPI 101 考试准备，主题 103：GNU 和 UNIX 命令”。

删除调度的作业

可以使用 cron 命令和 -r 选项删除所有调度的 cron 作业，见清单 10。

清单 10. 显示并删除 cron 作业

[ian@lyrebird ~]$ crontab -l 0,20,40 22-23 * 7 fri-sat /home/ian/mycrontest.sh [ian@lyrebird ~]$ crontab -r [ian@lyrebird ~]$ crontab -l no crontab for ian

要删除系统 cron 或 anacron 作业，应该编辑 /etc/crontab、/etc/anacrontab 或者编辑或删除 /etc/cron.d 目录中的文件。

可以使用 atrm 命令加作业号删除用 at 命令调度的一个或多个作业。多个作业应该用空白分隔。清单 11 给出一个示例。

清单 11. 用 atq 和 atrm 显示并删除作业

[ian@lyrebird ~]$ atq 16 Wed Jul 11 02:00:00 2007 a ian 17 Sat Jul 14 02:00:00 2007 a ian 14 Sun Jul 8 22:00:00 2007 a ian 15 Tue Jul 10 02:00:00 2007 a ian [ian@lyrebird ~]$ atrm 16 14 15 [ian@lyrebird ~]$ atq 17 Sat Jul 14 02:00:00 2007 a ian

配置用户对作业调度的访问

如果文件 /etc/cron.allow 存在，那么非根用户必须在其中列出，才能使用 crontab 和 cron 设施。如果 /etc/cron.allow 不存在，但是 /etc/cron.deny 存在，那么其中列出的非根用户不能使用 crontab 或 cron 设施。如果这两个文件都不存在，那么只允许超级用户使用这个命令。空的 /etc/cron.deny 文件允许所有用户使用 cron 设施，这是默认情况。

/etc/at.allow 和 /etc/at.deny 文件对 at 设施起相似的作用。

了解更多信息

如果想了解关于 Linux 管理任务的更多信息，请阅读教程 “LPI 102 考试准备：管理任务”，或者参见下面的 参考资料。不要忘记 rate 这个页面。

参考资料

学习

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文。
  
  
  
• 回顾教程 “LPI 102 考试准备：管理任务”（developerWorks，2007 年 7 月），了解关于 Linux 上其他管理任务的信息，包括用户管理、备份、系统日志和 Network Time Protocol。它是 LPI 考试准备教程系列 的一部分，这个系列覆盖 Linux 基础知识，帮助您准备系统管理员认证。本教程还引用了这个系列中的两个教程 “LPI 101 考试准备：GNU 和 UNIX 命令” 和 “LPI 101 考试准备：设备、Linux 文件系统和 Filesystem Hierarchy Standard”。
  
  
  
• Linux Documentation Project 有很多非常有用的文档，尤其是其中的 HOWTO 指导。
  
  
  
• 在 developerWorks Linux 专区 中可以找到为 Linux 开发人员准备的更多教程，包括 Linux 教程，以及最近几个月 读者最喜爱的 Linux 文章和教程。
  
  
  
• 随时关注 developerWorks 技术活动和网络广播。

获得产品和技术

• 索取 SEK for Linux，这套 DVD（两张）包含来自 DB2®、Lotus®、Rational®、Tivoli® 和 WebSphere® 的最新 IBM 试用版 Linux 软件。
  
  
  
• 使用 IBM 试用软件 构建您的下一个 Linux 开发项目，这些软件可以从 developerWorks 直接下载。
  
  

讨论

• 参与论坛讨论。
  
  
  
• 通过新的 developerWorks spaces 中的开发人员 blog、论坛、podcast 和社区主题，加入 developerWorks 社区。
  
  

关于作者

		Ian Shields 为 developerWorks Linux 专区的许多 Linux 项目工作。他是 IBM 北卡罗莱那州 Research Triangle Park 的一名高级程序员。他于 1973 年作为一名系统工程师加入 IBM 位于澳大利亚堪培拉的子公司。之后，在加拿大蒙特利尔和北卡罗莱那州 RTP 从事通信系统和普及运算。他拥有多项专利并发表了若干篇论文。他毕业于 Australian National University，本科学位是纯数学和哲学。他拥有北卡罗来纳州立大学的计算机硕士和博士学位。您可以通过 ishields@us.ibm.com 与 Ian 联系。

如何在initrd.img中添加驱动

2007 年 9 月 20 日

本文通过将网卡驱动加入到 initrd.img 中，使 Linux 内核在启动的过程中能正确识别并加载网卡驱动，从而使网络安装得以进行。

前言

网络安装 Linux 并不是一个新鲜的话题，其过程也不是一个轻松的体验。为了让机器能通过网络来安装 Linux，如果还需要配合 kickstart 来自动化 Linux 的安装过程的话，用户需要做大量的配置工作。众所周知，用户需要挑选一台机器作为服务器，然后在这台机器上配置 DHCP, TFTP, NFS/Http/Ftp, pxelinux, kickstart 等一系列的东西。

但是所有的这一切能成功运作都至少有一个前提条件：我们所安装的 Linux 能正确的识别并驱动所有客户机的网卡。如果网卡驱动不了，客户机根本无法通过网络从服务器取到所需要的东西，网络安装 Linux 就无从谈起了。

本文通过将网卡驱动加入到 initrd.img 中，使 Linux 内核在启动的过程中能正确识别并加载网卡驱动，从而使网络安装得以进行。本文并不讲述网络安装 Linux 的背景知识（如为什么需要网络安装，网络安装的好处等）、具体配置和操作步骤（也就是配置 DHCP，TFTP，pxelinux 等内容）。此外，本文需要读者有熟练的 Linux 操作经验和 Shell 编程的基本知识，而且对 Linux 启动过程和驱动程序有基本的了解。

注：所有被安装的机器我们称之为客户机，提供网络安装服务的机器我们称之为服务器

开始之前的建议

建议：如果您碰到了前言中所描述的问题的话，最好的解决方法是 – 找一个能驱动客户机网卡的 Linux Distribution，这样能省却很多麻烦。

但在现实环境下，很多原因会导致我们无法选择安装一个新的 Linux 发行版。原因有很多，比如：

• 客户不同意我们选用其他的 Linux 版本，因为客户有大量的应用程序已经在某个Linux 版本上编译，运行良好了，更换 Linux 发行版会带来应用的移植问题
  
• 客户拥有一些特殊的硬件，而这些硬件只有基于某个 Linux 发行版的驱动。更换 Linux 发行版，会导致这些硬件无法正常工作
  
• 没有一个 Linux 发行版能驱动客户机的网卡。网卡厂商只给我们提供了某个 Linux 发行版上的驱动，一切都要 DIY
  
• 您有着强烈的DIY情感，面对问题不是寻求别人的解决方案而是一切都要自己克服 – 毫无疑问，您就是本文最适合的读者

解决思路

如果熟悉 Linux 的启动过程和驱动程序，那么要解决本文的问题，基本上有两条路可走。第一就是将网卡驱动编译进内核（静态链接进内核），第二种方法就是将网卡驱动做成模块，然后想办法在 Linux 启动的时候让 Linux 内核能找到并挂载该驱动。面对这两种方案，第二种方法有更好的可行性和扩展性。因为首先有些网卡驱动本身就不能被静态链接进入内核，而只能被编译成一个模块，例如下文要举的例子 – e1000 网卡驱动；其次，驱动做成模块的方式，可以适应多个内核版本，用方法 1，更换一个内核版本就要重新编译一次内核；最后，等会会看到，相比编译内核，方法 2 更简单和可操作。

方法 2 的实现手段就是定制 initrd.img，将我们的网卡驱动加进去。initrd.img 是一个小型的根文件系统，在 Linux 内核没有挂载硬盘上的根分区的时候，initrd.img 将在内存中展开。一般情况下，initrd.img 中将包含一些必需的命令和驱动，如 insmod 命令和磁盘驱动。有了 insmod，才能将磁盘驱动挂载进内核，有了磁盘驱动，内核才能挂载位于磁盘上的根文件系统。

大部分的 Linux 发行版都提供了用于网络安装 Linux 的 initrd.img，一般位于第一张安装光盘的 images/pxeboot 目录下。在一台已经装好 Linux 的机器中，在 /boot 目录下我们也能找到 initrd.img，比较一下这两个 initrd.img，会发现 pxeboot 目录下的 initrd.img 会比 /boot 下的大很多，这是因为在网络安装的情况下，Linux 不会尝试去挂载位于磁盘上的根分区（事实上，在没有安装Linux的机器上，此时磁盘中可能什么数据都没有），所以此时的 initrd.img 需要包含大量的驱动，使 Linux 能识别大量的硬件。位于 /boot 下的 initrd.img，基本上唯一需要的东西就是磁盘驱动，只要内核能访问磁盘，那么其余所需的东西都可以从磁盘取得而不需要依赖 initrd.img。

具体操作和实例

从安装光盘中取得 initrd.img 之后，就可以开始对其进行定制。这里要感谢 Jeremy Mates，他写的 initrd-util.sh 能很好的解开和生成一个 initrd.img。脚本可以在http://sial.org/howto/linux/initrd/initrd-util下载到。

下面我们以RedHat Enterprise Linux Advance Server 4 Update 2 x86_64，Intel e1000网卡驱动为例，讲述具体的操作过程（在本例中，服务器和客户机拥有相同的Intel e1000网卡，而且我们已经手动在服务器上安装完成了正确的e1000驱动）：

首先从光盘取到initrd.img，登录到服务器，然后用initrd-util.sh解开：

[root@ericvm ~]# cd `./initrd-util.sh unpack initrd.img |tail -1`

info: initrd unpack expanded into: /var/tmp/initrd-util.workdir.DA29317

[root@ericvm initrd-util.workdir.DA29317]# pwd

/var/tmp/initrd-util.workdir.DA29317

[root@ericvm initrd-util.workdir.DA29317]# ls

2.6.9-22.EL  bin  dev  etc  linuxrc  lost+found  modules

proc  sbin  selinux  sys  tmp  var

initrd-util.sh很简单，利用gunzip, mount和cpio这些工具将initrd.img解开，其中驱动包位于modules目录下，名为modules.cgz，将这个文件解开后，生成了2.6.9-22.EL目录，进入该目录，就能找到包含在initrd.img中的驱动。本例中，RedHat已经包含了一个e1000的驱动，但是这个驱动不能驱动我们新的Intel e1000网卡。为此，我们在e1000网站下载新版的驱动，然后在服务器上编译完成，生成ko模块文件，然后拷贝到2.6.9-22.EL目录下，覆盖原文件即可。

驱动更新完毕后，现在我们需要将2.6.9-22.EL这个目录重新制作成modules.cgz，这个功能initrd-util.sh不能为我们完成，所以我们手动操作：

[root@ericvm initrd-util.workdir.DA29317]# find 2.6.9-22.EL | cpio -o -H crc > newmodules

16582 blocks

[root@ericvm initrd-util.workdir.DA29317]# gzip -n -9 newmodules

[root@ericvm initrd-util.workdir.DA29317]# mv newmodules.gz modules

[root@ericvm initrd-util.workdir.DA29317]# cd modules

[root@ericvm modules]# rm -f modules.cgz

[root@ericvm modules]# mv newmodules.gz modules.cgz

[root@ericvm modules]# pwd

/var/tmp/initrd-util.workdir.DA29317/modules

驱动包重新生成了并不意味着Linux就可以识别网卡了，因为Linux必须依靠一种逻辑，将硬件设备和驱动模块文件对应起来。这个逻辑就被定义在modules目录下的除modules.cgz之外的文件中：

[root@ericvm modules]# ls

module-info  modules.cgz  modules.dep  modules.pcimap  modules.usbmap  pci.ids  pcitable

如上所示，pcitable, modules.pcimap中定义了PCI设备和驱动模块之间的对应关系，modules.dep中定义了模块和模块之间的依赖关系（比如，各种SCSI设备都会依赖一个基础的SCSI驱动模块），module-info中定义了驱动的静态描述信息……

要填写这些文本文件，也很简单，首先我们必须要知道这块e1000网卡的PCI设备信息，由于在服务器上e1000这块网卡已经安装完成了，所以我们可以在服务器上取到我们想要的信息：

[root@ericvm ~]# lspci

…………  ignore some outputs

04:00.0 Ethernet controller: Intel Corporation Enterprise Southbridge DPT LAN Copper

04:00.1 Ethernet controller: Intel Corporation Enterprise Southbridge DPT LAN Copper

…………  ignore some outputs

lspci列出了服务器上两块网卡的设备信息，根据网卡设备的ID号码（04:00.0, 04:00.1），我们就可以在lspci –n的输出中找到设备的vendor code和device code（请参考lspci的manual了解lspci）：

[root@ericvm ~]# lspci –n

…………  ignore some outputs

04:00.0 Class 0200: 8086:1096 (rev 01)

04:00.1 Class 0200: 8086:1096 (rev 01)

…………  ignore some outputs

在lspci –n的输出中，我们找到了两块网卡的vendor code和device code – 8086和1096。得到了vendor code和device code之后，就可以更新initrd.img中modules目录下的pcitable, modules.pcimap等这些文件了。举例来说，在pcitable中查找e1000，能发现很多设备和e1000这个驱动关联，但是唯独没有8086:1096的组合，这就是为什么Linux无法驱动这块e1000网卡的原因了，我们需要手动将8086, 1096这两个code加入到pcitable中，并将这个设备对应到e1000驱动上。照此方法，更新其余的文件，如module-info, modules.pcimap等。

这样我们就完成了对initrd.img的完全修改，用initrd-util.sh重新将目录打包，生成一个新的initrd.img：

[root@ericvm ~]# ./initrd-util.sh pack /var/tmp/initrd-util.workdir.DA29317/

notice: new initrd size: 6144K

6144+0 records in

6144+0 records out

mke2fs 1.35 (28-Feb-2004)

info: initrd packed into: /var/tmp/initrd-util.initrd-new.IV29439.gz

/var/tmp/initrd-util.initrd-new.IV29439.gz

[root@ericvm ~]# ls -lh /var/tmp

total 3.7M

-rw-r–r–   1 root root 3.7M Jun 20 17:10 initrd-util.initrd-new.IV29439.gz

drwxr-xr-x  12 root root 4.0K Jun 20 17:10 initrd-util.workdir.DA29317

drwxr-xr-x  13 root root 4.0K Jun 20 15:53 initrd-util.workdir.ID29288

initrd-util.sh首先创建一个“空洞文件”，然后在这个文件中建立ext2 文件系统，然后将这个文件mount到一个目录中，最后用rsync这种方式将我们更新过的文件“拷贝”到了mount的目录下，这样“空洞”文件中就有了内容，最后对文件进行压缩，生成最终的img文件。

将/var/tmp/initrd-util.initrd-new.IV29439.gz改名成initrd.img，放到tftp配置的目录下，就可以让客户机在网络启动的时候取到新的initrd.img了，从而识别网卡开始网络安装。

到此为止了么？

到目前为止，一切看起来都很好。客户机通过网络启动，能把网卡驱动起来并从服务器上得到所有需要的东西，并开始安装。但是，如果没有做特殊处理的话，客户机上Linux安装完成后，启动进入Linux，会发现网卡依旧驱动不了，典型的出错信息就是“无法成功挂载XXX驱动”，“ethX的MAC地址和预计的不一样”等。出现这样问题的原因很简单，这是因为正确的网卡驱动只存在于服务器上的 initrd.img 中，而没有体现到客户机的硬盘上。客户机在网络启动的时候得到了服务器上的 initrd.img，但 Linux 还没有智能到能自动解开这个 initrd.img 并将里面的驱动拷贝到客户机的硬盘上。一旦客户机完成安装重启，从硬盘启动之后，所有的驱动文件和信息就都从硬盘读取了。

还举刚才的例子，e1000 网卡驱动在 RedHat 中其实自带就有一个，但不适用于我们的 Intel e1000 网卡，用 rpm 命令可以查到安装在硬盘上的这个 e1000 驱动属于哪个RPM包：

# rpm -qf /lib/modules/2.6.9-42.ELsmp/kernel/drivers/net/e1000/e1000.ko

kernel-smp-2.6.9-42.EL

所以，很明显的就是，要解决这样的问题，我们需要重新生成这个 kernel RPM 包。但是要在 RPM 包中替换一个文件，或是加入一个文件，可不像在 RAR 文件中用鼠标直接拖拽那么简单。有兴趣的可以参考 RPM 的相关资料。

除了重新生成 RPM 之外，还有一些简单的办法也是可行的，但不如重新生成 RPM 来的中规中矩。有兴趣的读者可以和我交流，这里就不赘述了。

参考资料

• Jeremy Mates的initrd-utils, http://sial.org/howto/linux/initrd/initrd-util ，帮助我们创建/解开 initrd.img
  
  
  
• Adding driver modules to a Fedora Core 2 CD for kickstart install: http://www.cs.umass.edu/~olc/pub/fc2bootiso.txt
  
  
  
• Linux lspci manual page: http://linux.die.net/man/8/lspci

jetty resin tomcat 測試報告:http://www.strongd.net/blog/show/255

       一直以來使用jetty作為我的web開發配置服務器，開始的時候和所有的初學者一様使用tomcat作為開發服務器，可用着用着，感覺tomcat越來越繁瑣以及龐大。後來，用了jboss，知道jboss使用jetty作為其web應用服務器，所以就開始試着使用jetty。從那開始後，jetty就成為我的開發配置服務器了，從最初的4.0，到現在的6.0一直在使用着。

   喜歡jetty的原因，在于其的方便，簡單的配置文件，簡單的啓動脚本，而且在elipse或者其他ide中，進行調試，運行都很方便。

   不想多説什麽，讓事實來説話吧。在開始之前，先下載jetty。目前最新的版本為6.1:
   http://docs.codehaus.org/display/JETTY/Downloading+and+Installing#download

   以前的版本文件是比較小的，現在的版本增加了很多東東，主要是很多例子應用，以及源碼，經過删减只有，整個應用還是比較小的，大概也就10m多了。如果只是需要運行web應用，并且只是需要jsp 2.1規範的話，只有7m多了。以前4.0的時候只有2m多，現在也已經增加了那麽多了，時代在進步，没有辦法。

   jetty主要的jar為jetty-6.1.1.jar，servlet-api-2.5-6.1.1.jar，jetty-util-6.1.1.jar。啓動的jar 為start.jar。還有jsp規範的jar。jsp2.1,好像已經减了不少的jar了，只有4個文件core-3.1.1.jar，ant-1.6.5.jar，jsp-2.1.jar，jsp-api-2.1.jar。core是使用eclipse的jdt，進行jsp編譯。

   jetty的主要配置文件為etc/jetty.xml，當然你可以自己指定彆的文件。在start.jar中有個start.config文件是默認的環境配置，以及指定默認的配置文件。可以手工替换。

   啓動jetty很簡單，在命令行下面java -jar start.jar
   如果需要指定start.config，使用java -DSTART=start.config -jar start.jart
   配置web 應用也非常的簡單：
   更改jetty.xml就行了，增加web應用的方式包括，直接放置應用在webapps下面，或者配置以下的context

  

This morning, I did some comparisons between Jetty 5.1.5rc1, Tomcat 5.5.9 and Resin 3.0.14 (OS version). I ran AppFuse’s “test-canoo” target, which tests all the JSPs using Canoo WebTest. I did this as a Servlet 2.4 application, and had to tweak some stuff in my web.xml to make it work on Jetty and Resin. Nothing big, just stuff that Tomcat let pass through and these servers didn’t. One interesting thing to note that Resin requires you to use “http://java.sun.com/jstl/fmt” for JSTL’s “fmt” tag URI, while Jetty and Tomcat require “http://java.sun.com/jstl/fmt_rt”. This is with Resin’s “fast-jstl” turned off – b/c everything blows up if it’s turned on (I don’t feel like coding my JSTL to Resin’s standards, that’s why I turn it off).

Below is a list of the average time it took to run “test-canoo” after I ran it once to compile all the JSPs.

• Jetty: 19 seconds
  
• Tomcat: 19 seconds
  
• Resin: 29 seconds

In addition, I tested how long it took for each server to startup – including the initialization of AppFuse.

• Jetty: 7 seconds
  
• Tomcat: 8 seconds
  
• Resin: 13 seconds

So what does all this mean? A number of things:

• I need to clean up AppFuse’s web.xml a bit for 2.4 applications.
  
• Putting the database connection pool configuration in a Spring context file (vs. JNDI) makes AppFuse much more portable.
  
• Jetty isn’t as fast as Jetty-lovers say it is (or maybe Tomcat just caught up).
  
• The open source version of Resin is much slower than the other open source servlet containers.
  
• I should restructure the build.xml to pull out Tomcat stuff and allow users to specify server deployment settings (i.e. in a ${servername}.xml file).
  
• Orion still doesn’t support the Servlet 2.4 or JSP 2.0 specifications.

 軟體：AVS Disc Creator(版本：2.1.5.100)
類別：燒錄程式
性質：Freeware(5.6 M)

【編輯/高啟唐】

AVS Disc Creator是一個免費的光碟燒錄軟體，不但支援CD、DVD光碟燒錄機，就連最新的藍光燒錄機也都支援了，所用者完全不必擔心相容性上的問題。

所有常用的燒錄功能，AVS Disc Creator可說是全具備了，像是資料光碟、影片光碟、MP3光碟與製作光碟映像檔等功能，AVS Disc Creator都可以燒錄，功能不比其他付費燒錄軟體遜色。

另外，AVS Disc Creator還支援抹除可複寫式光碟與專案排程等燒錄輔助功能。還在煩惱找不到合用且免費的燒錄軟體嗎？建議你來試試AVS Disc Creator！


下載：http://www.avsmedia.com/download/AVSDiscCreator.exe

Are you running an Intel Linux system with at least one (E)IDE hard drive?

Wouldn’t it be neat if there were a magical command to instantly double the I/O performance of your disks? Or, in some cases, show 6 to 10 times your existing throughput?

Did you ever just wonder how to tell what kind of performance you’re getting on your “tricked-out” Linux box?

Don’t overlook hdparm(8). If you’ve never heard of it, don’t worry. Most people I’ve talked to haven’t either. But if you’re running an IDE/Linux system (as many folks are,) you’ll wonder how you ever got this far without it. I know I did.

What’s the big deal?

So, you’ve got your brand-new UltraATA/66 EIDE drive with a screaming brand-new controller chipset that supports multiple PIO modes and DMA and the leather seat option and extra chrome… But is your system actually taking advantage of these snazzy features? The hdparm(8) command will not only tell you how your drives are performing, but will let you tweak them out to your heart’s content.

Now before you get too excited, it is worth pointing out that under some circumstances, these commands CAN CAUSE UNEXPECTED DATA CORRUPTION! Use them at your own risk! At the very least, back up your box and bring it down to single-user mode before proceeding.

With the usual disclaimer out of the way, I’d like to point out that if you are using current hardware (i.e. your drive AND controller AND motherboard were manufactured in the last two or three years), you are at considerably lower risk. I’ve used these commands on several boxes with various hardware configurations, and the worst I’ve seen happen is the occasional hang, with no data problems on reboot. And no matter how much you might whine at me and the world in general for your personal misfortune, we all know who is ultimately responsible for the well-being of YOUR box: YOU ARE. Caveat Fair Reader.

Now, then. If I haven’t scared you away yet, try this (as root, preferably in single-user mode):

hdparm -Tt /dev/hda

You’ll see something like:

/dev/hda:
 Timing buffer-cache reads:   128 MB in  1.34 seconds =95.52 MB/sec
 Timing buffered disk reads:  64 MB in 17.86 seconds = 3.58 MB/sec

What does this tell us? The -T means to test the cache system (i.e., the memory, CPU, and buffer cache). The -t means to report stats on the disk in question, reading data not in the cache. The two together, run a couple of times in a row in single-user mode, will give you an idea of the performance of your disk I/O system. (These are actual numbers from a PII/350 / 128M Ram / newish EIDE HD; your numbers will vary.)

But even with varying numbers, 3.58 MB/sec is PATHETIC for the above hardware. I thought the ad for the HD said something about 66MB per second!!?!? What gives?

Well, let’s find out more about how Linux is addressing your drive:

hdparm /dev/hda

/dev/hda:
 multcount    =  0 (off)
 I/O support  =  0 (default 16-bit)
 unmaskirq    =  0 (off)
 using_dma    =  0 (off)
 keepsettings =  0 (off)
 nowerr       =  0 (off)
 readonly     =  0 (off)
 readahead    =  8 (on)
 geometry     = 1870/255/63, sectors = 30043440, start = 0

These are the defaults. Nice, safe, but not necessarily optimal. What’s all this about 16-bit mode? I thought that went out with the 386! And why are most of the other options turned off?

Well, it’s generally considered a good idea for any self-respecting distribution to install itself in the kewlest, slickest, but SAFEST way it possibly can. The above settings are virtually guaranteed to work on any hardware you might throw at it. But since we know we’re throwing something more than a dusty, 8-year-old, 16-bit multi-IO card at it, let’s talk about the interesting options:

• multcount: Short for multiple sector count. This controls how many sectors are fetched from the disk in a single I/O interrupt. Almost all modern IDE drives support this. The man page claims:
  
  
  

  When this feature is enabled, it typically reduces operating system overhead for disk I/O by 30-50%. On many systems, it also provides increased data throughput of anywhere from 5% to 50%.

  
  
• I/O support: This is a big one. This flag controls how data is passed from the PCI bus to the controller. Almost all modern controller chipsets support mode 3, or 32-bit mode w/sync. Some even support 32-bit async. Turning this on will almost certainly double your throughput (see below.)
  
  
  
• unmaskirq: Turning this on will allow Linux to unmask other interrupts while processing a disk interrupt. What does that mean? It lets Linux attend to other interrupt-related tasks (i.e., network traffic) while waiting for your disk to return with the data it asked for. It should improve overall system response time, but be warned: Not all hardware configurations will be able to handle it. See the manpage.
  
  
  
• using_dma: DMA can be a tricky business. If you can get your controller and drive using a DMA mode, do it. But I have seen more than one machine hang while playing with this option. Again, see the manpage (and the example on the next page)!

Turbocharged

So, since we have our system in single-user mode like a good little admin, let’s try out some turbo settings:

hdparm -c3 -m16 /dev/hda

/dev/hda:
 setting 32-bit I/O support flag to 3
 setting multcount to 16
 multcount    =  16 (on)
 I/O support  =  3 (32-bit w/sync)

Great! 32-bit sounds nice. And some multi-reads might work. Let’s re-run the benchmark:

hdparm -tT /dev/hda


/dev/hda:
 Timing buffer-cache reads:   128 MB in  1.41 seconds =90.78 MB/sec
 Timing buffered disk reads:  64 MB in  9.84 seconds = 6.50 MB/sec

WOW! Almost double the disk throughput without really trying! Incredible.

But wait, there’s more: We’re still not unmasking interrupts, using DMA, or even a using decent PIO mode! Of course, enabling these gets riskier. (Why is it always a trade-off between freedom and security?) The man page mentions trying Multiword DMA mode2, so:

hdparm -X34 -d1 -u1 /dev/hda

…Unfortunately this seems to be unsupported on this particular box (it hung like an NT box running a Java app.) So, after rebooting it (again in single-user mode), I went with this:

hdparm -X66 -d1 -u1 -m16 -c3 /dev/hda

/dev/hda:
 setting 32-bit I/O support flag to 3
 setting multcount to 16
 setting unmaskirq to 1 (on)
 setting using_dma to 1 (on)
 setting xfermode to 66 (UltraDMA mode2)
 multcount    = 16 (on)
 I/O support  =  3 (32-bit w/sync)
 unmaskirq    =  1 (on)
 using_dma    =  1 (on)

And then checked:

hdparm -tT /dev/hda

/dev/hda:
 Timing buffer-cache reads:   128 MB in  1.43 seconds =89.51 MB/sec
 Timing buffered disk reads:  64 MB in  3.18 seconds =20.13 MB/sec

20.13 MB/sec. A far cry from the miniscule 3.58 we started with…

By the way, notice how we specified the -m16 and -c3 switch again? That’s because it doesn’t remember your hdparm settings between reboots. Be sure to add the above line (not the test line with -tT flags!) to your /etc/rc.d/* scripts once you’re sure the system is stable (and preferably after your fsck runs; having an extensive fs check run with your controller in a flaky mode may be a good way to generate vast quantities of entropy, but it’s no way to administer a system. At least not with a straight face…)

Now, after running the benchmark a few more times, reboot in multi-user mode and fire up X. Load Netscape. And try not to fall out of your chair.

In conclusion

This is one of those interesting little tidbits that escapes many “seasoned” Linux veterans, especially since one never sees any indication that the system isn’t using the most optimal settings. (Gee, all my kernel messages have looked fine….) And using hdparm isn’t completely without risk, but is well worth investigating.

And it doesn’t stop at performance: hdparm lets you adjust various power saving modes as well. See the hdparm(8) for the final word.

Many thanks to Mark Lord for putting together this nifty utility. If your particular distribution doesn’t include hdparm (usually in /sbin or /usr/sbin), get it from the source at http://metalab.unc.edu/pub/Linux/system/hardware/

Happy hacking!