Messages in this thread |  | | Date | Sat, 29 Jun 1996 21:28:02 +0300 (EET DST) | From | Linus Torvalds <> | Subject | Re: My two cents on network performance |
| |
On Sat, 29 Jun 1996, Christopher A. Smith wrote: > > System Size of file Time Bytes/second > HPUX 9.05 on HP 9000/712 548053 1.07 512199 > Solaris 2.4 on Sparc 5 543184 1.03 527363 > AIX 4.1.3 on PowerPC 604 544525 1.24 439133 > Linux 2.0 on Pentium 133 539398 12.77 42239 > > (The time was found by doing "time cp <local file> <NFS directory>")
Umm.. "cp" should really do copies in wsize chunks, so Linux NFS shouldn't actually be any worse than others when you just do a "cp". The Linux NFS deficiencies show up in other things: programs that do lots of small writes like the linker etc (and there aren't really that many programs that do it, because the stdio library works pretty well in doing the write merging itself - but as/ld do fseek's that counteract the Linux stdio implementation).
Are you _sure_ you have "rsize=8192,wsize=8192" in your /etc/fstab for the NFS mountpoint options? You should _really_ see a lot better performance than you do with plain "cp".
> Normally, our Linux users are dealing with small files or are working on > the local disk, so NFS is hardly a variable. However, when we try to > compile our project software on a Linux system, whereby the object files, > libraries, and executables are written back to the NFS server, the delay > is quite noticeable.
Yes. as/ld really shows the problem. Especially with NFS servers that do (correctly) synchronous NFS writes. Then the stdio library isn't able to do large write system calls, and the current Linux NFS client will do a lot of small writes.
Most(?) NFS servers can be configured to do NFS writes asynchronously: that's not good if the server goes down in the middle of a write, but with NFS not being exactly 100% reliable anyway it can often be worth it, especially if you feel safe about your server (ie don't do this if your NFS server is running Solaris 2.1 ;-). Check your NFS server setup..
> Or when a user quits out of Netscape, and it fiddles > with the cache directory, which is done via NFS, the delay is VERY > noticeable. We began the practice a long time ago of compiling the project > software locally and then moving the objects, libraries, and executables > back to the NFS server with ftp or something similar.
You should be able to use "cp" to move them back, but for some reason your cp performance is bad too. Check your wsize setting..
> I've thought about potential hardware problems and just don't see what it > could be. When the project software is compiled locally, the compile is > VERY quick, competing with or even beating the HP, Solaris, and AIX > systems. NFS reading and other network activities seem -- from the user > perspective -- to be just as fast as our other systems. It's just NFS > writing which is the bottleneck, from the "data" above and the user > perspective.
NFS reading is pretty fast, and indeed NFS write performance should these days be the only performance bottleneck. You seem to be hit worse by it than most places, though, so I suspect you also have something not configured optimally.
> I can't imagine that Linux is that slow on NFS writing; I can't imagine > that the developers would tolerate it. If anyone has any ideas or feedback > on this, I'd appreciate it.
Linux NFS writes really _are_ slower than other UNIXes, no question about it. Linux does no write merging at all, and Linux also does all writes totally synchronously. The lack of write merging means that linux performs very badly for lots of small "write()" requests. The synchronous nature of Linux NFS writes also means that Linux does very badly if the NFS server latency is high (even if the throughput of the server would be ok, if the latency for individual requests is bad the Linux client NFS performance suffers a lot).
Linus
|  |