荔园在线

荔园之美,在春之萌芽,在夏之绽放,在秋之收获,在冬之沉淀

[回到开始] [上一篇][下一篇]


发信人: Lg (创造人生的传奇), 信区: WinNT
标  题: [转载] How Mindcraft could have made a better Linux file
发信站: BBS 荔园晨风站 (Thu Apr 22 20:40:56 1999), 站内信件

【 以下文字转载自 Linux 讨论区 】
【 原文由 Lg 所发表 】
 FUD debunking

Trust no one (with apologies to 'The
X-Files')

   How Mindcraft could have made a better Linux file server

Summary
If you use Apache or Samba and Linux, you may be scratching your head at some
recent Mindcraft, Inc. benchmark numbers. Their recent Microsoft-sponsored
study found that Windows NT is 2.5 times faster than Linux/Samba as a file
server, and 3.7 times faster than Apache/Linux as a Web server. Why? As
Samba developer Jeremy Allison explainsheir test systems, the Mindcraft people
did a stellar job on NT, but weren't quite
up to the task on the Linux platform. This analysis focuses on the file-serving
aspects of the study. (2,500 words)

By Jeremy Allison



'There are three kinds of lies: lies, damn lies, and statistics.'

                  --Benjamin Disraeli

  n our business the three kinds of lies are lies, damn lies, and benchmarks.
By now I'm sure
  you will have read about the provocative benchmark test funded by Microsoft
and published
by Mindcraft. It trumpets the following claim:

"Microsoft Windows NT Server 4.0 is 2.5 times faster than Linux as a File
Server and 3.7 times faster as a Web Server"

Before I go into an analysis of this paper, I'd like to make an important point
about benchmark
results. The only valid benchmark is one that you run yourself, using the
applications you will be
running in a production environment, on your own network setup. Any other
benchmarks do not
reflect what you will see in your own environment and should be discounted.

Having said all that and being guilty, myself, of promoting Samba benchmarks,
let's take a look
at the claims in the Mindcraft paper and speculate on why the results turned
out the way they
did.

There have been many excellent rebuttals of the Apache figures that may be
found at such Web
sites as Linux Today and Linux Weekly News. Over 50 percent of all Web servers
on the
Internet are Apache servers. Apache is the server of choice for high-volume Web
sites.
Therefore the Apache figures in the Mindcraft article are so unbelievable that
they are rather
easy to discount.

On the other hand, the Samba numbers in this paper are much more insidious. The
total number
of Samba servers in active use is not easy to determine. One reason for this is
that most
SMB/CIFS servers live safely behind firewalls, where the total numbers of each
kind of server
(Samba or NT) is not easily externally surveyed.

The file-serving SMB/CIFS protocol that Samba and Windows NT implement is not a
secure
Internet protocol, despite Microsoft's attempts to position it as such. Even
Microsoft no longer
runs an anonymous internet SMB/CIFS server at ftp.microsoft.com after several
embarrassing
incidents involving blue screens of death.

FUD, glorious FUD!

Scully: 'Why are you so paranoid, Mulder?'

Mul             -- 'The X Files,' Ascension

The Mindcraft benchmark provides an excellent example of a well-tuned Windows
NT system.
Unfortunately, it also provides an excellent example of an untuned Linux and
Samba system.

In fact, the Mindcraft team has performed a notable service to NT sysadmins
worldwide. Their
Windows NT 4.0 system was so well tuned that the paper stands as a wonderful
reference on
how best to tune a Windows NT 4.0 system for optimal file serving performance.
This
information wasn't easily accessible in one place before, and Windows NT
administrators who
are suffering performance problems should definitely read this paper for
advice.

Some of the NT tuning performed was obvious (click on the "Maximize throughput
for file
serving" button in the tuning dialog, set the scheduler to not boost foreground
application
performwere several NIC card tuning parameters changed), or very advanced
settings (modifications to
the processor affinity mask, increasing the log space on the NTFS drive,
binding each NIC card
to each CPU).

What is very interesting about the NT tuning performed is how similar it was to
the tuning that
was performed on UNIX servers at SGI (my employer) when we published a Samba
benchmark on SGI's proprietary IRIX server systems. Like Mindcraft, we also
bound the
interrupts from each network card to a processor. This allows concurrent
interrupts not to cause
a processor cache flush, which is an expensive operation. And we set the
transaction log file up
especially for SGI's XFS filesystem, (which is also a transaction log-based
filesystem, like
NTFS).

The difference, though, was that the SGI Samba benchmark was published as an
SGI press
release, not presented as an independent analysis. It is clear that Mindcraft
had extensive
Microsoft help in tuning the server used in this benchmark. Yet the Mindcraft
results were
published as an independent work.

Help, I've fallen and I can't get up
So why didn't Mindcraft get help from the Linux community ? Well, their paper
claims that they
tried to do just that. They tried RedHat:

'We contacted RedHat for technical support after we saw that Linux was
getting such poor performance. They told us that they only provided
installation support and that they did not provide any support for the Linux
2.2.2 kernel.'

It's not surprising that RedHat technical support couldn't help them. One does
not call a vendor
technical support line -- one that is explicitly -- and ask for help for an
explicitly unsupported configuration.
Try asking for performance tuning help from standard Microsoft technical
support with the
Windows 2000 beta release and see how far you get.

Had Mindcraft requested the same level of help that they were getting from
Microsoft by
contacting RedHat public relations, then (as RedHat stated at
http://www.zdnet.com/sr/stories/news/0,4538,2242246,00.html), the response
would have
been significantly different.

Mindcraft also tried the Web and newsgroups:

'We posted notices on various Linux and Apache newsgroups and received no
relevant responses. Also, we searched the various Linux and Apache
knowledge bases on the Web and found nothing that we could use to improve
the performance we were observing.'

Now one of the nice things about the Samba team is that we have our own open
source
bugtracking database, Jitterbug, written by Andrew Tridgell, Samba's creator.
We also archive
all the Samba mailing lists at http://samba.org

After reading Mindcraft's statement, I searched all the Samba lists and the
Samba bugs
database to find Mindcraft's request for tuning help. I found nothing. I then
searched the Samba
newsgroup comp.protocols.smb (thank heavens for DejaNews). No requests for
help. I don't
think Mindcraft tried very hard to get Samba help for their benchmark.

Absence of malice?

Never attribute to malice that which can be adequately explained by
stupidity.

     -- Robert Heinlein, 'Logic of Empire'

It seems that Mindcraft did attempt to do some tuning work on the Linux and
Samba side, it's
just that they didn't know how to do it. Some of the changes they made to the
Samba
compilation were obviously done in a belief that they would improve performance
(setting the
MMAP parameters in the compilation and the "read prediction" parameter, for
example).

However, some of the changes they made were disastrous. Their main mistake was
to set the
"wide links" Samba parameter to "no". "Wide links = no" tells Samba not to
follow symbolic
links outside of an area designated as being exported as a share point.

It isn't really a security parameter, more a convenience for the administrator
to stop users from
wandering outside the designated exported area by adding a symbolic link that
points elsewhere
on the filesystem. (Determined users with logon access to the Samba server can
easily break out
of this "prison.")

In order to determine if a link points outside the shared area, Samba has to
follow the link and
then do a directory path lookup to determine where on the filesystem the link
ended up. This
ends up adding a total of six extra system calls per filename lookup, and Samba
looks up
filenames a lot. Tests done at SGI since the Mindcraft paper was published show
that setting
this parameter will cause a 25- to 30-percent slowdown in Samba performance.

Mindcraft's decision not to use Windows NT clients also had a profound effect
on the
benchmark results. Our tests at SGI show that Microsoft optimizes Windows NT
for serving
Windows 95 and Windows 98 clients -- a bit of a surprise, really, when you
consider that NT is
supposed to be Microsoft's "business" client. In fact, Windows NT Server
suffers a significant
performance drop when serving Windows NT clients.

Samba, by contrast, performs best with Windows NT clients. I should know. SGI
sells
Windows NT client machines and pays me to work on Samba. So I have concentrated
my
performance optimization work on Windows NT clients.

Another important benchmark modifier was the selection of RAID 0 for the disk
subsystem.
The Samba and Linux benchmark I helped out the folks at PC Week measure has
lower
reported numbers than the peak NT performance reported in the Mindcraft paper.
However,
the VA Research server that PC Week used was configured by VA to use RAID 5, as
this
provides the most security for the data. That is also how most of their
customers would run the
system in a production environment.

Using RAID 0 significantly improves performance but provides no data
protection. Level 0 is
mere striping of the data across the disks, whereas level 5 provides striping
and parity data. It is
not how real users would run a server.

Tuning the buffer cache for a benchmark

Scotty, I need warp speed in three minutes or we're all dead.

    --Captain Kirk, 'The Wrath of Kahn'

The biggest Samba-related performance tuning improvement that was missed by
Mindcraft was
the lack of modification of the filesystem cache tuning parameters.

Linux will attempt to use memory not being used for any other purpose for
filesystem cache. A
special daemon, called bdflush, will periodically flush "dirty" buffers
(buffers that contain
modified filesystem data or metadata) to the disk.

The secret to good benchmark performance is to keep as much of the benchmark
data in
memory for as long as possible. Writing to the disk is the slowest part of any
filesystem. If you
know that the filesystem will be heavily used in a benchmark, then you can tune
this process for
Linux. As with many kernel tuneables this can be done on the fly by writing to
special files in the
/proc filesystem.

The system used in the benchmark had 4 GB of memory, but the Linux kernel used
by
Mindcraft only detected 960 MB of this (in fairness, they restricted Windows NT
to use 1024
MB also). The Linux kernel will actually use up to 2 GB, but 1 GB should still
be enough to
efficiently cache most of the filesystem activity in the buffer cache. The
trick is that you have to
tell Linux you want it to do that. You do this by executing the following
command for a Linux
2.2 kernel (I usually put it in rc.local in the SysV init script directories):

echo "80 500 64 64 80 6000 6000 1884 2" >/proc/sys/vm/bdflush

This line tells bdflush not to worry about writing out dirty blocks to the disk
until the filesystem
buffer cache is 80 percent full. The other values tune such things as the
number of buffers to
write out in one disk operation, how long to allow dirty buffers to age in the
kernel, etc. You can
find full details in the 2.2 kernel documentation in the file
linux/Documentation/sysctl/vm.txt.

Another helpful tuning hint is to tell Linux the following: Use a minimum of 60
percent of memory
for the buffer cache; only prune when the percentage of memory used for the
buffer cache gets
over 80 percent; and allow the buffer cache to grow to 80 percent of all
memory. This should
leave enough room for the 144 Samba smbd daemons needed by the benchmark on a
1-GB
system. To do this, simply run the command:

echo "60 80 80" >/proc/sys/vm/buffermem

From the data I obtained preparing for the PC Week benchmark, I learned that
these changes
can significantly improve the Linux file serving performance, up to a factor of
two.

What can we learn from this?

Writing a new OS only for the 386 in 1991 gets you your second 'F' for this
term.

  -- Prof. Andrew S. Tanenbaum, author of Minix, in a newsgroup posting to
                      Linus Torvalds

One of the good things that has come out of the Mindcraft paper is the
recognition that
knowledge such as the effect of the "wide links" parameter is not widely known.
Nor is it well
documented in the Samba documentation. I will be fixing this for the next Samba
release (2.0.4).

The study has also shown that the knowledge of how to tune the filesystem
performance in
Linux is equally obscure. We need to do a better job of educating Linux
administrators about
how to get the most out of their systems. Microsoft has a multimillion-dollar
"education" industry
training NT Administrators what Microsoft wants thenm to know about how to work
NT. Linux
needs similar educational training materials.

The other really positive thing about this Mindcraft study is that the
Mindcraft report puts
Samba, Apache, and Linux in some very august company. Other Microsoft-funded
Mindcraft
reports have found that NT's file-serving also outperforms Sun Solaris and
Novell Netware.

In fact, last week's paper marks a coming of age of Linux, as it is now
obviously important
enough to have serious Microsoft marketing dollars spent against it.

I'm sure there'll be other benchmark disappointments in store for us. After all,
 how else do we
learn what we need to fix? But the strength of open source is that we can face
the errors without
trying to deny them. We just fix 'em and go on.

'We'll have no more off the record comments, no more lobby briefings, we'll
stand up on our own two feet and tell t'truth'

                --Harry Perkins, prime minister, in 'A Very British Coup'
--
寂寞每个人都有 只是 说不说得出口
我的寂寞 写在心中
在繁华的都市里 让它永久的停留

※ 来源:.BBS 荔园晨风站 bbs.szu.edu.cn.[FROM: 210.39.0.66]
--
※ 转载:.BBS 荔园晨风站 bbs.szu.edu.cn.[FROM: 192.168.0.198]


[回到开始] [上一篇][下一篇]

荔园在线首页 友情链接:深圳大学 深大招生 荔园晨风BBS S-Term软件 网络书店