为什么现在用cluster(计算集群)都用linux?

每个任务一个进程（面向进程的）——运行程序的很多复本，每个复本每次只处理一个任

务。有时候，每次创建一个新任务都需要相应地创建一个新的进程（如inetd、Sendmail

），但有些也设计成可以重用进程（如Apache）。这种体系结构在低负载的情况下会产生

很好的性能。在运行中等程度的负载时，如果进程影象比较小（如qmail）、已经实现了

针对该应用程序的效率改进或者该类型的应用程序不会创建太多的同时任务时，其性能也

还可以。如果采用了进程缓冲技术并且同时运行的进程总数不是很多（如中低程度的负载

），就可以采用多CPU来解决问题。这种技术在所有的操作系统上都可以实现，然而，从

实现的的角度讲，UNIX明显地要比Windows更有效。（Windows没有fork()系统调用，很少

有Windows应用程序采用这种技术，因为它在Windows上实在太慢了）。

每个任务一个线程（多线程）——只运行该程序的一个复本，在这个复本中，每个任务都

由一个单独的执行线程来处理。多线程应用程序在低-中负载情况下的性能非常好，在更

高的负载下，其性能就明显下降了（但通常也是可以接受的）。然而，超高负载会将多线

程应用程序带入死亡旋涡（death-spiral）。通常情况下操作系统unix，多线程应用程序最多可以处理

500到1000个并发的任务。这在大多情况下是可以接受的。每个新认为使用一个新的线程

，相对于新进程而言，新线程消耗更少的内存和更少的CPU处理能力。仅仅最流行的UNIX

变种（通常是商用操作系统）才能够在沉重的多线程负载下保持稳定，所以很少有开放源

码工程采用多线程技术。这种技术在多CPU上的性能可能比在单CPU上的性能还要差，因为

多处理器计算机上的信号量（semaphore）锁处理的代价非常高。（多线程软件的例子有

Netscape Web server和Apache on Windows）

一个线程处理多个任务（异步处理）——程序的一个复本运行固定数量的线程（通常每种

类型的任务对应一个线程），每个线程通过一种称为异步（非阻塞）TCP/IP的技术处理大

量的同类型任务。因为大多数程序根本不需要处理高负载，并且异步编程非常困难，所以

很少有支持这种技术的程序出现。异步程序可以在多CPU计算机上平滑扩展，因为它们大

多采用彼此独立的长效线程。这种技术很少需要跨CPU的锁，因此每个线程都可以永久且

有效地分配给一个单独的CPU（如DNS BIND守侯进程daemon）

TCP/IP调用体系结构

第二个影响性能的主要因素是TCP/IP调用体系结构。在操作系统级，有多种方法可以实现

相同的网络操作。TCP/IP的速度与优化程序设计之间存在着权衡的问题（更快的技术对编

程人员来说意味着更多的工作）。加之，更快的技术并不是对所有的平台都可用；更高的

性能需求可能会限制平台选择的自由度。

阻塞式TCP/IP调用

阻塞式TCP/IP调用等待所有被请求的操作完成后立即对结果进行操作。在任务数量比较少

时，操作结果会在事件发生时立即予以响应；但在任务数量比较大的情况下，会导致操作

系统的巨量上下文切换系统开销，这时的效率相当低。在低负载的情况下，阻塞（同步）

TCP/IP调用产生很少的等待时间，这对低负载的Web服务器一类的应用来说非常理想（页

面响应非常迅速，条件是负载永远不会太高）。然而，如果使用的是面向进程的体系结构

，且每一个新的网络连接都要建立一个相应的新进程（如inetd）时，阻塞TCP/IP所带来

的等待时间上的性能就会被运行一个新进程所导致的显著的系统调用迅速抵消。

非阻塞TCP/IP调用

非阻塞（异步）TCP/IP调用发起一个操作后就转而进行其它的工作。当操作完成或者发生

了一个事件，这个进程就会获得通知并进行相应的响应。这种两不处理模式需要更多的编

程工作，有时响应新事件会花费少量的时间（增加了等待延时）。在中-高负载的情况下

，这种非阻塞技术会产生更好的执行性能，并且可以避免讨厌的高负荷，但同阻塞TCP/IP

调用相比，等待延时可能稍微长了点儿。

上述的每一个任务处理体系结构都与相应的TCP/IP系统调用模型相匹配。面向进程和多线

程的程序可能会趋向于采用阻塞TCP/IP调用，因为这是编程的最简单方法并且大多数情况

下只需要处理低负载。然而采用异步任务体系结构的应用程序就必需使用非阻塞的TCP/IP

操作以处理多任务了：根本不能选择阻塞TCP/IP。因此，如果您发现一个网络应用程序采

用了高度可扩展的异步任务体系结构，您当然也是从其所采用的最具扩展性的TCP/IP调用

体系结构（非阻塞）上获得了不少好处。

真实环境测试

为了评估不同操作系统和网络应用程序的性能，我们进行了三类不同的测试：真实环境、

磁盘I/O和任务体系结构比较。我们检测的操作系统包括Linux (Red Hat 7.0, kernel

2.2.16-22)、Solaris 2.8 for Intel、FreeBSD 4.2和Windows 2000 Server。这些操作

系统都是可获得的商业版本中最新的，并且没有重新编译（或者说我们将操作系统软件开

包安装后就进行了测试）。我们在相同的4-GB SCSI-3驱动器上(IBM 型号是 DCAS-34330)

安装了上述操作系统，并且在相同的机器（ASUS P3B主板、Intel Pentium III 550-MHz

处理器、384-MB SDRAM、Adaptec 2940UW SCSI控制器、ATI Rage Pro 3D显卡、Intel

EtherExpress Pro 10/100 Ethernet网卡）上进行测试。

我们采用测试我们自己开发的MailEngine软件的邮件发送速度来进行真实环境测试。

MailEngine是一个邮件发送服务器，它可以移植到所有要进行测试的平台上（其实还包括

Sparc上的Solaris），它采用的是异步体系结构（带有采用poll()系统调用的非阻塞

TCP/IP）。为了不将电子邮件真的发送到具有200,000个成员的测试列表，我们是在测试

模式下运行的MailEngine。在这种模式下，MailEngine实现发送邮件的所有步骤但是最后

使用RSET命令而不是DATA命令。这样就在真正发送数据之前退出QUIT了SMTP连接，这样就

不会向接收者发送任何电子邮件了。我们的工作量是将一条消息发送到分布在9113个域下

的200,000个电子邮件地址。因为是同一条消息在内存中为所有的接收者进行排队，所以

磁盘I/O并不是影响性能的主要因素。我们缓慢地提高同时连接的数量，以便观察负载的

提升对性能的影响。

图1 操作系统的比较

图1（操作系统的比较）显示了在MailEngine的测试模式中，不同操作系统上一定范围的

同时连接数量下的电子邮件传输速度的测试结果。Linux在速度上占有明显的优势，它比

排在第二位的Solaris快约35%。总体上来说，性能随着连接数量的增加而提高，这张图也

显示速度的增长边际超过1500个连接。FreeBSD在加到多于1500个连接时的性能会有些下

降。

在UNIX风格的操作系统上，需要适当的调整内核以便允许在一个进程中使用如此多的连接

。除内核调整外，当负载超过2500个连接时，FreeBSD还会给出资源不足的警告并且停止

运行。

文件系统测试

许多网络应用程序同样需要将信息在硬盘上进行排队以便以后处理（如Sendmail的邮件队

列）或处理溢出情况的能力。为了模仿在典型情况文件系统的效率，我们写了一个在单个

目录下创建、写入和读回10,000个文件的C++程序，它每次只操作一个文件。为了全面测

试文件系统对不同种类文件的整体效率，测试文件的大小从4 KB到128 KB递增。

图2 创建、写和读10,000个文件所需要的时间

图2显示了文件系统的测试结果。Linux和Windows的速度基本相同，它们都比另外两个明

显地快得多：是FreeBSD的6倍、Solaris的10倍。每个操作系统所使用的文件系统分别是

：Linux - EXT2, Solaris - UFS, Windows 2000 - NTFS, FreeBSD - UFS。其它的文件

系统无疑将会产生不同的性能结果。如果您的软件应用程序严重依赖于磁盘，我建议您使

用Linux或Windows或者其它运行于FreeBSD或Solaris上的替代文件系统。

应用程序体系结构测试

最后，我们不同的网络应用程序体系结构在每一操作系统上的表现进行了测试。我们写了

一个简单的C++服务程序，它对每一个连接请求都给出一个"450 too busy"的响应消息。

我们程序测试的三个体系结构是：（1）基于进程的体系结构，对每个连接都产生一个新

的进程予以处理；（2）多线程体系结构，为每个进程分配一个线程；（3）异步体系结构

，所有连接都使用非阻塞的TCP/IP予以应答。一个独立的C++程序运行在另外一台计算机

（使用Linux操作系统）上，它试图以最快的速度连接我们的服务器，缓慢增加同时的连

接负载并且计算成功接收的响应信息。对于本文来说，这么多的测试结果图（12个）显然

太多了，因此我们绘制了每个任务体系结构的平均值以便显示大体上的性能差异。

图3 每种网络结构的平均吞吐量

图3显示了每种类型的任务体系结构在所有操作系统平台上的平均性能。虽然不同平台上

性能的差异是非常明显的，但其显著性与体系结构的选择所造成的显著性差异还是相去甚

远。最慢的网络应用体系结构是基于进程的结构，它对连接的处理能力只有异步方法的5%

。在1000个同时连接的情况下，同基于线程的方法相比，异步方法的负载能力要高出35%

。趋势线显示，随着负载的增长，多线程方法与异步方法之间的性能差异将拉大。

为高性能应用进行内核调整

在缺省配置中，我们测试的UNIX风格的操作系统并不支持多线程和异步程序所需要的如此

大量的同时TCP/IP连接。这种限制严重地限制了应用程序的性能，甚至错误地规劝系统管

理员不要采用这些高性能体系结构。值得庆幸的是，这些限制可以容易地通过内核调整来

克服。在UNIX上，每个TCP/IP连接使用一个文件描述符，所以您必需提高操作系统上可以

提供的文件描述符的总量，同时也要提高每个进程允许使用的描述符的最大值。所有的

UNIX风格的操作系统都有一个ulimit的shell命令（sh和bash），这个命令可以让使用它

进行了适当的内核调整之后的shell上运行的命令可以打开更多的文件描述符。我们建议

使用ulimit -n 8192。这里是我们推荐的内核调整过程：

在Linux上： echo 65536 > /proc/sys/fs/file-max改变系统可提供的文件描述符的数量

。

在FreeBSD上：将下面这些内容追加到 /etc/sysctl 文件的末尾（或者，您可以使用

sysctl -w 命令来填加这些内容）：

kern.maxfiles=65536

kern.maxfilesperproc=32768

在Solaris上：将下面的内容加入 /etc/system 文件后reboot：

set rlim_fd_max=0x8000

set rlim_fd_cur=0x8000

提要

我们的真实环境测试显示，操作系统最好与最差的性能差距达到了75%，Linux拥有比排在

第二位的Solaris还要高出35%的卓越性能。更重要的是，异步应用程序比基于进程的应用

程序平均快12倍，比多线程的应用程序快35%。如果磁盘I/O占用了应用程序运行时间的主

要部分，那么在Linux和Windows 2000上的磁盘I/O任务的处理速度要比Solaris快10倍以

上，比FreeBSD也要快出6倍之多！

如果您正在评估一个网络应用软件，并且它的最终性能对您来说至关重要，那么软件的体

系结构将是一个关键的评估准则（或者说，你应该选择多线程或异步结构）。

--

（编辑：上海站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!