戌狗』。『花花的世界

Martin C. Brown (questions@mcslp.com), 自由作家兼顾问, MC

2008 年 4 月 15 日

在典型的 UNIX® 或 Linux® 计算机操作过程中会创建许多日志文件。其中一些日志文件包含有用的信息；还有一些可帮助您进行容量和资源规划。本文重点介绍不同日志文件中记录的基本信息、它们的位置以及如何使用该信息确定系统的运行情况。

关于本系列

典型的 UNIX 管理员拥有一套经常用于辅助管理过程的关键实用工具、诀窍和系统。有一些重要的实用程序、命令行以及脚本可用来简化各种处理过程。其中一些工具来自于操作系统，而大部分的诀窍则来源于长期的经验积累和减轻系统管理员工作压力的要求。本系列文章主要专注于最大限度地利用各种 UNIX 环境中可用的工具，包括简化异构环境中的管理任务的方法。

日志文件

所有系统都会生成不同数量的日志文件，这些文件用于跟踪和记录关于计算机的不同信息。这些文件的内容和效用因系统而异，但是文件提供的核心信息通常是一致的。

例如，所有的 UNIX 和 Linux 计算机都使用 syslog（操作系统、应用程序和服务用来记录信息的通用日志记录系统）来记录信息。syslog 一般会记录大量的数据，其中包括由不同硬件和系统报告的登录、性能信息和故障。除 syslog 外，系统还有用来记录关于计算机及其操作信息的各种服务、环境和应用程序日志。

尽管分析和提取日志文件内容的信息可能非常耗时和复杂，但是不能忽略这些日志中信息的价值。日志文件可以提供关于潜在问题、错误和安全漏洞等方面的提示，如果使用正确，甚至可以提供关于服务器负载和容量方面的警告。

日志位置

各种日志文件的位置因系统而异。在大多数的 UNIX 和 Linux 系统上，大部分日志文件都位于 /var/log 中。例如，清单 1 显示了 Gentoo Linux 系统上的日志文件列表。

清单 1. Linux /var/log 目录内容

                 $ ll /var/log total 3312 -rw-r----- 1 root    root       8218 2007-11-03 06:21 dmesg -rw-rw---- 1 portage portage  650111 2008-02-02 13:01 emerge.log -rw------- 1 root    root      24024 2007-11-05 07:26 faillog -rw-r--r-- 1 root    root     386032 2007-09-28 14:39 genkernel.log drwxr-xr-x 2 root    root       4096 2007-11-03 06:47 iptraf/ -rw-r--r-- 1 root    root     292292 2008-02-03 08:07 lastlog -rw------- 1 root    root    1346931 2008-02-03 08:50 messages drwxr-xr-x 2 root    root       4096 2006-08-30 17:04 news/ drwxr-xr-x 3 root    root       4096 2007-09-28 13:22 portage/ drwxrwx--- 2 root    portage    4096 2007-11-03 06:40 sandbox/ drwxrwx--- 2 snort   snort      4096 2007-10-13 11:34 snort/ -rw-rw-r-- 1 root    utmp     496896 2008-02-03 08:07 wtmp -rw-rw-rw- 1 root    mc        61189 2007-06-10 11:37 Xorg.0.log -rw-rw-rw- 1 root    root      61189 2007-06-10 10:40 Xorg.0.log.old 

在 Solaris®、IBM® AIX® 和 HP-UX® 上，主要 syslog 和其它大多数日志文件都写入 /var/adm 目录中的文件（清单 2）。

清单 2. 传统 UNIX /var/adm 内容

                 $ ls -al /var/adm total 230 drwxrwxr-x   9 root     sys          512 Feb  3 15:30 . drwxr-xr-x  48 root     sys         1024 Feb  3 15:32 .. drwxrwxr-x   5 adm      adm          512 Feb  2 16:13 acct -rw-------   1 uucp     bin            0 Jan 12 18:49 aculog drwxr-xr-x   2 adm      adm          512 Feb  2 16:03 exacct -r--r--r--   1 root     root        2856 Feb  3 16:10 lastlog drwxr-xr-x   2 adm      adm          512 Feb  2 16:03 log -rw-r--r--   1 root     root       69065 Feb  3 16:08 messages drwxr-xr-x   2 root     sys          512 Feb  2 16:09 pool drwxrwxr-x   2 adm      sys          512 Feb  2 16:13 sa drwxr-xr-x   2 root     sys          512 Feb  2 17:03 sm.bin -rw-rw-rw-   1 root     bin            0 Jan 12 18:47 spellhist drwxr-xr-x   2 root     sys          512 Feb  2 16:03 streams -rw-------   1 root     root          93 Feb  3 16:08 sulog -rw-r--r--   1 root     bin         3720 Feb  3 16:14 utmpx -rw-r--r--   1 adm      adm        29760 Feb  3 16:10 wtmpx 

另外，某些非系统级别的消息和信息都写入位于 /var/log 中的日志中（清单 3）。例如，在 Solaris 上，邮件调试项在缺省情况下写入 /var/log/syslog。

清单 3. Solaris 上 /var/log 中的其他日志

                 $ ls -al /var/log/ total 48158 drwxr-xr-x   7 root     sys          512 Feb  3 16:07 . drwxr-xr-x  48 root     sys         1024 Feb  3 15:32 .. -rw-------   1 root     sys            0 Jan 12 18:48 authlog -rw-r--r--   1 root     other         27 Feb  2 16:17 brlog drwxr-xr-x   2 root     root         512 Feb  2 16:39 gdm drwxr-xr-x   2 root     sys          512 Feb  2 16:09 pool -rw-r--r--   1 root     sys      24480410 Feb  3 12:51 postrun.log drwxr-xr-x   2 root     sys          512 Feb  2 16:41 swupas -rw-r--r--   1 root     other        635 Feb  2 17:25 sysidconfig.log -rw-r--r--   1 root     sys         3967 Feb  3 16:08 syslog drwxr-xr-x   3 root     sys          512 Feb  2 17:25 webconsole drwxr-xr-x   2 root     sys          512 Feb  2 16:37 xen -rw-r--r--   1 root     root       66171 Feb  3 16:07 Xorg.0.log -rw-r--r--   1 root     root       66256 Feb  3 16:06 Xorg.0.log.old 

当然，找到文件是最起码的问题。您需要知道文件包含哪些有用的信息。

根据 UNIX 的变体，一些日志在其他地方可能比较杂乱，但是，已对标准化文件位置进行了一些有意义的尝试，使日志文件都归入前文已经提及的目录之一。

日志类型和数据

日志类型共分为两种：文本日志文件（包含简单的文本格式的消息和信息）和用二进制格式编码的文件。前者用于典型系统中的大多数日志，因为它们易于编写，而且（也许是更重要的）它们易于阅读。文本文件的不足之处是有时难以通过结构化方式提取信息，因为文件的文本格式允许使用任何方式或结构编写信息。

后者的格式对于非常结构化的信息或需要以特定方式或格式编写的信息更为实用。例如，以二进制数据的固定块的形式将 utmp 和 wtmp 数据写入文件，这样可以用快速有效的格式读取和写入信息。遗憾的是，这意味着如果不使用特定的工具将难以读取信息。

系统日志 (syslog)

syslog 服务是在后台运行的守护进程，可接受日志输入并将其写入到一个或多个单独文件。报告给 syslog 的所有消息都标有日期、时间和主机名，并且可以让单个主机从许多主机接受所有日志消息，并将信息写入单个文件。

提出问题的服务（例如，邮件、dhcp 和内核）和指示消息严重性的类也可以标识消息。可以将严重性标记为信息（纯信息）、警告、错误、重要（需要解决的严重问题）甚至紧急（系统需要紧急帮助）。

服务非常容易配置（通常通过 /etc/syslog.conf 或等效项进行配置），并允许您选择要记录的信息类和记录信息的位置。例如，您可以将所有的标准信息写入文件。但是，对于重要消息，如果管理员立刻需要相关信息，则可以立即将这些消息发送到控制台。清单 4 显示了 Solaris 10 安装中的缺省 syslog.conf 文件的主配置内容。

清单 4. 示例 syslog.conf 文件

                 *.err;kern.notice;auth.notice                   /dev/sysmsg *.err;kern.debug;daemon.notice;mail.crit        /var/adm/messages  *.alert;kern.err;daemon.err                     operator *.alert                                         root  *.emerg                                         *  ...  mail.debug                      ifdef('LOGHOST', /var/log/syslog, @loghost)  ...  ifdef('LOGHOST', , user.err                                        /dev/sysmsg user.err                                        /var/adm/messages user.alert                                      'root, operator' user.emerg                                      * ) 

因为 syslog 是 UNIX/Linux 中的标准日志记录机制，所以它用于记录大量的不同信息。其中包括启动消息、登录和授权信息，以及服务的启动/关闭。另外，syslog 通常还用于记录电子邮件消息传递、文件系统问题，甚至 DHCP 租期、DNS 问题和 NFS 问题。因为 syslog 可以将数据写入不同的区域，所以 syslog 在写入信息时并不总是十分明显。

在磁盘上复制 syslog 的主要目的地与在 UNIX 变体之间不同。许多 Linux 版本将信息写入 /var/log/messages。在 AIX、Solaris 和 HP-UX 上，syslog 被写入 /var/adm/messages。

在清单 5 中可以看到 Solaris 计算机的 /var/adm/messages 示例。

清单 5. 示例系统日志输出

                 Feb  3 16:06:58 solaris2 ata: [ID 496167 kern.info] cmdk2 at ata1 target 0 lun 0 Feb  3 16:06:58 solaris2 genunix: [ID 936769 kern.info] cmdk2 is                                              /pci@0,0/pci-ide@1f,1/ide@1/cmdk@0,0 Feb  3 16:06:59 solaris2 asy: [ID 267298 kern.notice] asy0: UART @                                            3f8 scratch register: expected 0x5a, g ot 0xff Feb  3 16:06:59 solaris2 asy: [ID 702181 kern.notice] Cannot identify UART chip at 3f8 Feb  3 16:06:59 solaris2 asy: [ID 267298 kern.notice] asy1: UART @ 2f8 scratch register:                                                                  expected 0x5a, got 0xff Feb  3 16:06:59 solaris2 asy: [ID 702181 kern.notice] Cannot identify UART chip at 2f8 Feb  3 16:07:01 solaris2 genunix: [ID 314293 kern.info] device            pciclass,030000@2(display#0) keeps up device sd@1,0(sd#1), but the latter is            not power managed Feb  3 16:07:01 solaris2 /usr/lib/power/powerd: [ID 387247 daemon.error]                                                                    Able to open /dev/srn Feb  3 16:07:08 solaris2 /sbin/dhcpagent[164]: [ID 778557 daemon.warning]                  configure_v4_lease: no IP broadcast specified for ni0, making best guess Feb  3 16:07:31 solaris2 sendmail[503]: [ID 702911 mail.crit] My unqualified host name                                                    (solaris2) unknown; sleeping for retry Feb  3 16:07:32 solaris2 sendmail[507]: [ID 702911 mail.crit] My unqualified host name                                                    (solaris2) unknown; sleeping for retry Feb  3 16:07:48 solaris2 svc.startd[7]: [ID 652011 daemon.warning]             svc:/system/webconsole:console: Method "/lib/svc/method/svc-webconsole start"         failed with exit status 95. Feb  3 16:07:48 solaris2 svc.startd[7]: [ID 748625 daemon.error]               system/webconsole:console failed fatally: transitioned to maintenance         (see 'svcs -xv' for details) Feb  3 16:07:55 solaris2 pseudo: [ID 129642 kern.info] pseudo-device: devinfo0 Feb  3 16:07:55 solaris2 genunix: [ID 936769 kern.info] devinfo0 is /pseudo/devinfo@0 Feb  3 16:08:31 solaris2 sendmail[503]: [ID 702911 mail.alert] unable to qualify                                      my own domain name (solaris2) -- using short name Feb  3 16:08:32 solaris2 sendmail[507]: [ID 702911 mail.alert] unable to qualify my                                         own domain name (solaris2) -- using short name 

在示例输出中可以看到大量的信息，范围从硬件设备中的问题一直到邮件服务的当前配置中的问题。

文件的格式非常简单：它包含日期、主机名、服务名称、唯一 ID（使系统记录多行消息并标识它们）和条目的标识符和类。每行上的其余文本只是系统记录错误消息的自由格式文本。

文件的该格式使提取所需信息变得更加方便。文件中的所有行都是使用唯一 ID 标记的，并且所有的行都标有错误消息的标识符和类。

例如，您可以使用邮件系统提取关键问题的信息，方法是使用 grep 挑选使用 mail.crit 标记的项： $ grep mail.crit /var/adm/messages.

处理日志中个别行的详细信息比较复杂。尽管文件的前几列是标准化的（它们由 syslog 守护进程写入），但是，行的其余格式完全依赖于报告错误消息的组件。

它使阅读和分析文件的内容变得非常复杂，因为您需要根据标识符和报告工具来处理每行。更有甚者，有些行不符合某个格式。

内核日志（dmesg 和 alog）

所有 UNIX 和 Linux 系统的日志实际上是内核的一部分。日志实际上是内核中内存的一部分，用于记录无法写入磁盘的有关内核的信息，这是因为该信息是加载文件系统之前生成的。

例如，在启动过程中，不能以写入方式访问文件系统（大多数内核以读取模式启动文件系统，直到认为系统足够安全，能够切换到读/写模式为止）。此日志中的数据包含关于连接到系统的设备的信息，以及在启动和操作过程中系统记录的任何错误和问题的信息。

在一些系统上，信息会定期写入文件 (/var/log/dmesg)；而在另一些系统上，只有使用 alog 命令 (AIX) 或 dmesg（所有其他 UNIX/Linux 变体）才可获得信息。

内核生成的信息并不总是写入另一个文件，如 syslog。这意味着某些信息（如关于设备和硬件的内部数据）只能通过 dmesg 日志提供。

例如，清单 6 显示了 Gentoo Linux 系统上 dmesg 的一些示例输出。为简单起见，此处仅显示了主要启动信息。

清单 6. dmesg 日志内容

                 $ dmesg Linux version 2.6.22-gentoo-r8 (root@gentoo2.vm) (gcc version 4.1.2                  (Gentoo 4.1.2 p1.0.1)) #1 SMP Fri Sep 28 14:22:07 GMT 2007 BIOS-provided physical RAM map:  BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)  BIOS-e820: 0000000000100000 - 0000000020000000 (usable) 0MB HIGHMEM available. 512MB LOWMEM available. Entering add_active_range(0, 0, 131072) 0 entries of 256 used Zone PFN ranges:   DMA             0 ->     4096   Normal       4096 ->   131072   HighMem    131072 ->   131072 early_node_map[1] active PFN ranges     0:        0 ->   131072 On node 0 totalpages: 131072   DMA zone: 32 pages used for memmap   DMA zone: 0 pages reserved   DMA zone: 4064 pages, LIFO batch:0   Normal zone: 992 pages used for memmap   Normal zone: 125984 pages, LIFO batch:31   HighMem zone: 0 pages used for memmap DMI not present or invalid. Allocating PCI resources starting at 30000000 (gap: 20000000:e0000000) Built 1 zonelists.  Total pages: 130048 Kernel command line: root=/dev/ram0 init=/linuxrc ramdisk=8192 real_root=/dev/hda3 udev Local APIC disabled by BIOS -- you can enable it with "lapic" mapped APIC to ffffd000 (0140c000) Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 CPU 0 irqstacks, hard=c054e000 soft=c052e000 PID hash table entries: 2048 (order: 11, 8192 bytes) Detected 2295.874 MHz processor. Console: colour VGA+ 80x25 Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 511616k/524288k available (3150k kernel code, 12100k reserved,                                                         818k data, 264k init, 0k highmem) virtual kernel memory layout:     fixmap  : 0xffe17000 - 0xfffff000   (1952 kB)     pkmap   : 0xff800000 - 0xffc00000   (4096 kB)     vmalloc : 0xe0800000 - 0xff7fe000   ( 495 MB)     lowmem  : 0xc0000000 - 0xe0000000   ( 512 MB)       .init : 0xc04e7000 - 0xc0529000   ( 264 kB)       .data : 0xc0413884 - 0xc04e0364   ( 818 kB)       .text : 0xc0100000 - 0xc0413884   (3150 kB) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 4674.89 BogoMIPS (lpj=23374475) Mount-cache hash table entries: 512 CPU: After generic identify, caps: 0f80b9b9 00000000 00000000 00000000 00000001                                                                        00000000 00000000 CPU: L1 I cache: 32K, L1 D cache: 32K CPU: L3 cache: 4096K CPU: After all inits, caps: 0f80b9b9 00000000 00000000 00000140 00000001                                                                        00000000 00000000 ... 

清单 7 显示了来自运行 Gentoo Linux 的另一台计算机的输出，在本例中，您可以看到运行的文件系统报告的一些错误。

清单 7. dmesg 的磁盘错误

                 EXT3-fs: mounted filesystem with ordered data mode. sd 7:0:1:0: [sdf] Result: hostbyte=0x00 driverbyte=0x08 sd 7:0:1:0: [sdf] Sense Key : 0x3 [current]  sd 7:0:1:0: [sdf] ASC=0x4b ASCQ=0x0 end_request: I/O error, dev sdf, sector 894959703 EXT3-fs error (device sdf1): ext3_get_inode_loc: unable to read                           inode block - inode=55935010, block=111869955 sd 7:0:1:0: [sdf] Result: hostbyte=0x00 driverbyte=0x08 sd 7:0:1:0: [sdf] Sense Key : 0x3 [current]  sd 7:0:1:0: [sdf] ASC=0x4b ASCQ=0x0 end_request: I/O error, dev sdf, sector 894959703 

从清单 7 可以看到，您可能需要检查文件系统，因为其中显示文件系统或磁盘上存在错误。

在本例中，syslog 中也报告了该信息（清单 8）。

清单 8. syslog 中的磁盘错误

                  messages:Feb  3 12:17:53 bear sd 7:0:1:0: [sdf] Result: hostbyte=0x00 driverbyte=0x08 messages:Feb  3 12:17:53 bear sd 7:0:1:0: [sdf] Sense Key : 0x3 [current]  messages:Feb  3 12:17:53 bear sd 7:0:1:0: [sdf] ASC=0x4b ASCQ=0x0 messages:Feb  3 12:17:53 bear end_request: I/O error, dev sdf, sector 894959703 messages:Feb  3 12:17:53 bear EXT3-fs error (device sdf1): ext3_get_inode_loc: unable                                   to read inode block - inode=55935014, block=111869955 

但是，在出现严重错误或故障的情况下，dmesg 有时可能是系统上所发生情况的唯一良好的信息源。

用户记录（utmp/x、wtmp/x 和 lastlog）

这些文件包含用户登录和系统数据日志。这些文件中的信息是以特殊的 utmp 格式编写的，所以您需要特殊的工具才能提取该信息。

这些日志中的数据记录登录次数和系统启动/关闭次数，即登录的历史记录和对登录过程中使用的上一次启动或登录时间的快速访问。

有关系统管理工具包中包含的介绍如何分析这些文件的其他文章，请参阅参考资料。

cron 日志

cron 时间守护进程负责定期在后台运行许多服务，并生成自已的信息日志。

在某些系统上，cron 日志是使用 syslog 记录的，而在 Solaris 和一些传统 UNIX 变体上，信息则写入文件 /var/cron/log。日志中包含的信息包括所执行命令的详细信息和作业开始和终止的时间。

有关日志内容的示例，请参见清单 9。

清单 9. cron 活动的日志

                 ! *** cron started ***   pid = 283 Sun Feb  3 16:07:10 2008 >  CMD: /usr/local/bin/logmanage >/dev/null 2>&1 >  root 946 c Sun Feb  3 17:10:00 2008 <  root 946 c Sun Feb  3 17:10:00 2008 >  CMD: /usr/local/bin/backup >/dev/null 2>&1 >  root 949 c Sun Feb  3 17:11:00 2008 <  root 949 c Sun Feb  3 17:11:01 2008 

分析日志的内容是确定可能未正确执行的作业中存在某些问题的有效方法。它也是检查作业的执行时间的好方法。长时间运行的作业或似乎从未完成的作业可能指示应该调查某个问题。

日志文件管理

应确保能够管理系统上的日志。日志文件可能变得很大，在许多情况下，您需要保存计算机上事件的历史记录，以便解决问题。

例如，应该调查系统的非正常重启或关闭，而系统日志通常是唯一的信息源。尽管它无法告诉您在发生故障时发生的一切，但是可以从中得到一些有帮助的信息，如故障发生的准确时间或关于导致问题的事件的信息。潜在的安全问题和登录尝试可能指示计算机遭到了攻击，该攻击可能导致了此问题甚至就是导致此问题的原因。

长年累月地保存日志可能没有必要（但在某些情况下，这是法律要求的）。在一个繁忙的系统中，您每天都可能很容易地将 25MB 或更多信息记录到系统日志中，日志量太大经常是导致磁盘空间不足错误的原因。

一些 UNIX/Linux 变体包括自动化日志管理进程（Solaris 包括 /usr/sbin/logadm 命令），但是创建自已的日志管理经常并不困难。典型的功能就是短期（例如四周）内保留个别日志，并按顺序对它们编号。例如，如果您具有文件消息，上一周的文件位于 messages.1，则两周前的文件位于 messages.2 等等。这使文件的迁移变得非常容易。

不过，您必须确保能够成功复制和重新创建文件，这样在迁移和存档过程中才不会丢失任何重要信息。对于旧文件，为节省空间，您还可以存档内容。清单 10 显示了一个简单的脚本，它将个别文件复制并存档到原始位置中指定的目录。

清单 10. 简单日志归档工具

                 #!/bin/bash  # Manage logs and archive them if necessary # Keeps 4 copies of logs  cd /var/log for type in cyrus dmesg emerge.log faillog genkernel.log messages do         mkdir -p $type.d         cp $type.d/$type.3.bz2 $type.d/$type.4.bz2         cp $type.d/$type.2.bz2 $type.d/$type.3.bz2         cp $type.d/$type.1.bz2 $type.d/$type.2.bz2         cp $type $type.d/$type.1 && cat </dev/null >$type         bzip2 -vf9 $type.d/$type.1 done 

运行脚本副本可重新创建和存档日志文件。请注意如何迁移文件；对于每种情况，我们仅将当前文件移动到一周前。最后，我们将存档并重新创建原始文件。


日志文件可能包含大量的信息，但是深入了解文件的信息和格式对诊断和解决问题非常有帮助。本文介绍了日志文件的基础知识、并介绍了日志文件位置和这些文件内容的详细信息，以及它们如何帮助您诊断问题并在成为问题之前识别问题。本文还介绍了不同文件的格式，以及不同文件和它们的内容之间的关系。

转自:

http://www.ibm.com/developerworks/cn/aix/library/au-satlogfilebasics/index.html?ca=drs-cn#main

用simplexml处理atom数据

很多博客使用atom来输出数据，但是atom使用了名称空间(namespace)，所以现在请求被命名的元素和本地名称时必须指定名称空间统一资源标识符（URI），还有一点就是simplexml的xpath方法无法直接query这个xml tree。

从 PHP 5.1 版开始，SimpleXML 可以直接对带名称空间的文档使用 XPath 查询。和通常一样，XPath 位置路径必须使用名称空间前缀，即使搜索的文档使用默认名称空间也仍然如此。registerXPathNamespace() 函数把前缀和后续查询中使用的名称空间 URL 联系在一起。

下面是使用xpath查询atom文档title元素的例子：

用simplexml处理rss数据

wordpress可以输出rss2的数据源，这里面也有一些不同的namespace，比如dc。一个使用simplexml解析rss2的例子：

这个例子中，使用children方法来获得名称空间中的数据：

Performance tuning is one of the top disciplines (if not THE top discipline) that database professionals want to excel at. Being able to take a system that's running sluggish and turn it into one that's running as fast as a scalded dog is a talent that's part art and part science, but whatever the combination necessary to make it happen, there will always be strong demand for folks who are good at it.

When a database performance analyst begins to look at a poorly performing database, there are usually several forms of analysis that they will use:

• Bottleneck analysis – this concerns itself with answering the question "what is my database waiting on?" Perhaps it's a case of lock contention or other I/O bottleneck that's causing a database to slow down, but whatever the issue, the end goal is to get things "unclogged" so the database can get back up to speed.
• Workload analysis – this type of analysis deals with two things: who is logged on and what are they doing?  Here you are looking at user load (active, idle, etc.), physical and logical I/O activity, and the SQL code that is being executed along with how many times various statements are executed.  Anyone familiar with database tuning knows it only take one well-timed bad query from hell to send everything down the drain in short order.
• Ratio analysis – this is the least useful form of analysis, but it can be somewhat helpful to get some basic rule of thumb measurements.  Using various SQL scripts, you can get measurements such as memory vs. disk reads (cache hit ratios) and other like statistics.

If you've been using MySQL for a while, you know that – sadly – MySQL doesn't have as rich a performance management interface as some of the other proprietary databases like Oracle, so doing a thorough diagnostic analysis of a slow-running system can be challenging.  Fortunately, new versions of MySQL are introducing more and improved diagnostic objects to help you better troubleshoot MySQL servers.

One of the new performance management enhancements is found in the new Falcon transactional storage engine that was introduced in MySQL 6.0. The Falcon team has designed a set of new Information Schema tables to help you understand how well Falcon is performing and where issues may be developing.  Let's take a quick look at some of these new tables and see how you can make use of them when you're working with Falcon.

Falcon Diagnostic Tables Overview

In MySQL 5.0, the Information Schema (IS) was introduced to help MySQL users get metadata on objects, security privileges, and more info that exists on a particular MySQL server.  In MySQL 6.0, the Falcon storage engine adds the following new tables to the IS:

mysql> use information_schema Database changed mysql> show tables like 'FAL%'; +-------------------------------------+ | Tables_in_information_schema (FAL%) | +-------------------------------------+ | FALCON_TABLES                       | | FALCON_RECORD_CACHE_SUMMARY         | | FALCON_SYSTEM_MEMORY_DETAIL         | | FALCON_SERIAL_LOG_INFO              | | FALCON_VERSION                      | | FALCON_TRANSACTION_SUMMARY          | | FALCON_DATABASE_IO                  | | FALCON_SYNCOBJECTS                  | | FALCON_TRANSACTIONS                 | | FALCON_RECORD_CACHE_DETAIL          | | FALCON_SYSTEM_MEMORY_SUMMARY        | +-------------------------------------+ 11 rows in set (0.00 sec) 

Some of the new Falcon tables only provide information when the server is in debug mode – these include the FALCON_RECORD_CACHE_SUMMARY, FALCON_RECORD_CACHE_DETAIL, FALCON_SYSTEM_MEMORY_SUMMARY, and FALCON_SYSTEM_MEMORY_DETAIL tables. But the others contain valuable diagnostics that you can access to determine the health of Falcon-related database performance.  

The most basic Falcon table is the FALCON_TABLES object, which simply shows the various Falcon objects in a MySQL instance and their database and tablespace assignments: 

mysql> select * from information_schema.falcon_tables; +-------------+--------------------+-----------+-------------+--------------------+ | SCHEMA_NAME | TABLE_NAME         | PARTITION | TABLESPACE  | INTERNAL_NAME      | +-------------+--------------------+-----------+-------------+--------------------+ | GIMF        | BROKER             |           | FALCON_USER | BROKER             | | GIMF        | CLIENT             |           | FALCON_USER | CLIENT             | | GIMF        | CLIENT_TRANSACTION |           | FALCON_USER | CLIENT_TRANSACTION | | GIMF        | INVESTMENT         |           | FALCON_USER | INVESTMENT         | | GIMF        | INVESTMENT_TYPE    |           | FALCON_USER | INVESTMENT_TYPE    | | GIMF        | OFFICE_LOCATION    |           | FALCON_USER | OFFICE_LOCATION    | +-------------+--------------------+-----------+-------------+--------------------+ 

The other tables are more performance-related and less concerned with general database metadata.

Looking at Falcon I/O Performance

Suppose we have a Falcon database that resembles the following model (which, by the way, was created in MySQL Workbench, MySQL's new data modeling tool that you can download at: http://dev.mysql.com/downloads/workbench/5.0.html):

As Falcon doesn't support foreign keys yet, ignore the FK relationships you see in the above model.  The model/database is a simple design centered around an investment firm.  If the MySQL server was just started, that would mean no data has been accessed on the system yet; as a result, the Falcon diagnostic tables would be empty:

mysql> select * from information_schema.falcon_database_io; Empty set (0.00 sec) 

But once we access a Falcon object, then the system contains data we can analyze:  

mysql> select count(*) from gimf.client_transaction; +----------+ | count(*) | +----------+ |    18675 | +----------+ 1 row in set (0.56 sec)  mysql> select * from information_schema.falcon_database_io; +------------------+-----------+---------+----------------+--------+---------------+-------+ | TABLESPACE       | PAGE_SIZE | BUFFERS | PHYSICAL_READS | WRITES | LOGICAL_READS | FAKES | +------------------+-----------+---------+----------------+--------+---------------+-------+ | FALCON_MASTER    |      4096 |    2560 |             51 |      1 |          1041 |     0 | | FALCON_TEMPORARY |      4096 |    2560 |              1 |      0 |             0 |     1 | | FALCON_USER      |      4096 |    2560 |            299 |      0 |         56028 |     3 | +------------------+-----------+---------+----------------+--------+---------------+-------+ 

Tables such as the FALCON_DATABASE_IO table can be used for both workload and ratio-based analysis.  For example, to get an overall cache hit rate for falcon, you could use this SQL:

mysql> select 100 * 1-(sum(physical_reads) / sum(logical_reads)) falcon_hit_rate     -> from information_schema.falcon_database_io; +-----------------+ | falcon_hit_rate | +-----------------+ |         99.9938 | +-----------------+ 

So 99+% of the Falcon I/O has been memory-based (logical) vs. physical, which is good by a simple rule of thumb but in no way indicates things are performing well overall.  You can also get per tablespace statistics by using this query:

mysql> select tablespace,     -> 100 * 1-(sum(physical_reads) /     -> sum(if(logical_reads > 1, logical_reads,1))) falcon_hit_rate     -> from information_schema.falcon_database_io     -> group by tablespace; +------------------+-----------------+ | tablespace       | falcon_hit_rate | +------------------+-----------------+ | FALCON_MASTER    |         99.9510 | | FALCON_TEMPORARY |         99.0000 | | FALCON_USER      |         99.9947 | +------------------+-----------------+ 

Again, don't confuse high hit rates with being able to nod off on your DBA job.  Plenty of systems have been brought to a crawl with excessive logical I/O that wreaks havoc.  Instead, you should focus your attention on reducing all forms of I/O – both logical and physical – as well as the number of SQL statement executions as best you can.  And don't forget about the MySQL query cache; if used in the right scenarios, it can greatly help reduce the I/O strain on a MySQL server.

If, however, you see great volumes of physical reads, you do have fairly low hit rates, and you've done your research on minimizing overall executions and feel confident about your indexing strategy, then it's a fair bet you want to look into increasing the Falcon record and page cache sizes (falcon_record_memory_max, falcon_page_cache_size).

Another I/O area to review is Falcon log performance. The serial log is used during normal operation as a performance boost for write operations, and after a crash for database recovery.  During normal operation, the serial log allows Falcon to write out many data changes at once when a transaction commits, rather than writing out pages scattered in different parts of the database file. When a transaction commits, it creates a log entry saying it is committing, then writes log entries with the final state of every record it modified to the log file in memory. It then flushes the log file to disk.  That write makes the transaction durable (the D in ACID).

Falcon has a diagnostic table to view how busy the log has been:  

mysql> select * from information_schema.falcon_serial_log_info; +---------------+--------------+--------+---------+---------+ | DATABASE      | TRANSACTIONS | BLOCKS | WINDOWS | BUFFERS | +---------------+--------------+--------+---------+---------+ | FALCON_MASTER |            0 |      0 |      34 |      20 | +---------------+--------------+--------+---------+---------+ 

You can also check the parameter setting for the Falcon log with this command: 

mysql> show global variables like '%falc%ser%buf%'; +---------------------------+-------+ | Variable_name             | Value | +---------------------------+-------+ | falcon_serial_log_buffers | 20    | +---------------------------+-------+ 

So the diagnostic table tells us that all buffers have been accessed and that no current transactions are open at this time. When you first view the table, there may be a point of confusion since there is both a WINDOWS and BUFFERS column.  WINDOWS is the number of windows in to the serial log being tracked by internal Falcon code objects and this number may be higher than the falcon_serial_log_buffers setting.  The BUFFERS column shows how many of those code objects actually have 1 MB buffers and the statistic never gets larger than the falcon_serial_log_buffers setting.

When the serial log is opened, all the buffers requested are allocated initially and they are handed out to the internal code objects on an as-needed basis.  When they are all in use, they are switched between windows when they are not in use by another.  Finally, note that this diagnostic table reports how many internal code objects are active in regards to windows and how many of them have buffers; it does not currently indicate whether those buffers are in use.

If you see that the BUFFERS column never reaches that amount you've set for the falcon_serial_log_buffers parm, then you can likely reduce that value as you could be wasting memory.

Looking at Falcon Transaction Bottlenecks

One key to understating database performance is getting a handle on transactional activity and bottlenecks in a busy system. To help with this, Falcon supplies two tables that help with the analysis of global transaction traffic and detailed transactional work. Let's create a blocking lock situation and see what these tables tell us:

*** first session ***

mysql> set autocommit=0; Query OK, 0 rows affected (0.00 sec) mysql> update investment_type set investment_type_name = 'hi'    -> where investment_type_id = 1; Query OK, 1 row affected (0.03 sec) Rows matched: 1  Changed: 1  Warnings: 0 

*** second session ***

mysql> set autocommit=0; Query OK, 0 rows affected (0.00 sec) mysql> use gimf Database changed mysql> update investment_type set investment_type_name = 'hi2'    -> where investment_type_id = 1; 

*** back to first session ***

mysql> select a.id thread, a.user,b.id txn_id,a.db,b.waiting_for, substr(statement,1,30)     -> from   information_schema.processlist a,     -> information_schema.falcon_transactions b     -> where  a.id = b.thread_id; +--------+------+--------+------+-------------+--------------------------------+ | thread | user | txn_id | db   | waiting_for | substr(statement,1,30)         | +--------+------+--------+------+-------------+--------------------------------+ |      2 | root |      6 | gimf |           0 |                                | |      3 | root |      7 | gimf |           6 | update investment_type set inv | +--------+------+--------+------+-------------+--------------------------------+ 

Falcon helps us easily see what transactions are blocking other work on the system via the FALCON_TRANSACTIONS table, which can be joined to another IS table – the PROCESSLIST table.  We can see both connections involved in the block along with the SQL statement being blocked. If we rollback both transactions, we can then look at the global Falcon transaction table and see what's happened on the system:

mysql> select * from information_schema.falcon_transaction_summary; +---------------+-----------+-------------+--------+----------------+--------------------+ | DATABASE      | COMMITTED | ROLLED_BACK | ACTIVE | PENDING_COMMIT | PENDING_COMPLETION | +---------------+-----------+-------------+--------+----------------+--------------------+ | FALCON_MASTER |         0 |           2 |      0 |              0 |                  0 | +---------------+-----------+-------------+--------+----------------+--------------------+ 

Being able to quickly see transaction bottlenecks, such as the above, that are occurring inside Falcon can be a big help when things suddenly seem to freeze up on a system.

Conclusions

Performance tuning will always be a top priority for database pro's, and being able to separate the wheat from the chaff in terms of knowing what to focus on vs. knowing what to disregard will be a coveted skill in this discipline.  With Falcon, you have a number of good, new diagnostic aids to help you when you start your analysis in the area of bottlenecks, workloads, and ratios.

Keep in mind that the new Falcon diagnostic tables are still in beta form right now, so you may encounter bugs and such when using them.  The Falcon team would certainly appreciate you logging any bugs you find in our bug system at http://bugs.mysql.com/.

You can download a copy of the current Falcon beta at: http://dev.mysql.com/downloads/mysql/6.0.html (Note: the 6.0 binary may be labeled ‘alpha' but it does contain the Falcon transaction engine beta).  Please give Falcon a try and let us know what you think.  

As always, thanks for your support of MySQL!

基于Eclipse和PDT，加入了ZendStudio的专用特性，支付ZF框架，ZendCore Zend Platform。
Zend Studio一直是很多PHP开发者的首选工具，它与Java的关系一向甚为亲密，Zend Studio 5一直都是基于Java Swing的，现在好了，Zend Studio直接改投Eclipse了,它的主要功能如下：

编辑器和文件管理功能

• PHP4和PHP5支持
• 语法高亮，代码辅助
• 模板（PHP, PHPDoc, New File）
• 代码折叠（类，函数和PHP文档）
• 实时错误检测
• 书签
• 智能源代码+当前代码跳转支持
• 自动插入（括号，PHPDoc）
• 括号匹配
• 注释/非注释PHP代码
• PHP（项目）浏览器
• 打开资源（文件/函数）
• PHP手册集成
• 查找PHP元素
• 文件/项目/PHP检测（概况）
• 高级代码格式化（缩进，括号，空字符和空行）
• 文件中查找替换
• 任务
• 项目包含路径
• 问题查看
• 拖拽或在文件浏览器中打开文件
• 简易的新文件创建
• 头文件代码辅助

代码生成

• Getter/Setter函数
• 覆盖/实现函数
• 新建PHP类/接口

JavaScript支持

• 语法高亮
• 基本JavaScript块的代码辅助
• 在PHP/HTML视图中查看JS元素

HTML支持

• 所见即所得编辑
• 语法高亮
• 代码辅助
• 代码折叠
• 拖拽HTML组建
• 设计和源代码视图切换
• 属性查看 源代码控制
• 本地历史
• CVS
• Subversion

PHPUnit测试支持

• 测试代码支持
• 可视化测试结果支持
• 栈轨迹和过滤

Debugging

• 本地Debug
• Web服务器Debug
• 本地部署
• 字符集支持
• 管道支持
• Web服务器管理
• 文件内容传输（使用本地/服务器拷贝）
• SSL通信
• 浏览器工具栏支持
• PHP可执行效率
• Web服务器性能
• 代码覆盖

远程系统部署支持

• FTP
• SFTP

SQL/数据库支持

• 查询编辑器 - 语法高亮，代码语法辅助
• 新建连接探测向导
• 可编辑表视图
• 对象树 - 表，视图
• JDBC驱动

杂项

• 高级PHP代码分析
• RSS阅读器
• Web Services编辑器
• Web Services支持（向导和分析器）
• PHP文档支持
• BIRT集成（代码辅助，样例项目，模板）
• Java桥接 - Java类和包的代码辅助

Zend Platform集成

• 基本集成（开放平台GUI）
• 事件列表查看
• Debug/性能事件
• 自动允许服务器Debug/管道（使用WSDL）
• 平台API

Zend框架集成

• 代码辅助
• 框架工程
• 代码模板
• 样例工程
• MVC视图
• MVC代码生成

其他集成

• Zend代码片段查看器
• Zend代码片段交互（建议，投票）
• Zend Guard集成

Zend Studio 5.5移植

• Zend Studio键映射
• 导入Zend Studio工程

安装程序/文档/支持

• 包/安装程序
• 多语言支持
• 每日一贴
• 网页和电话支持
• 自动更新

Zend Studio for Eclipse 正式版下载地址

Linux 版：
http://downloads.zend.com/studio-eclipse/6.0.0/ZendStudioForEclipse-6_0_0.tar.gz

Windows 版：
http://downloads.zend.com/studio-eclipse/6.0.0/ZendStudioForEclipse-6_0_0.exe

下载文件

点击这里下载文件