Samba Speed Question - Please Help!

[Justen Marshall]

Hi

David Collier-Brown <David.Collier-Brown at canada.sun.com> writes:

> If the poster could describe the size and contents of the directory,
> we could do a little experiment with ufs and samba to see if the
> problem lies in the OS or Samba...

That would be excellent.
  
I created a 1Gb file and used both FTP and Samba to copy it. I made
sure I was using the fastest possible disks at the destination end,
since my first test only really tested my disk speed.

Copying the file with Samba resulted in 15% or so CPU use, and the
speed was about 85% that of FTP. It took about 2.5 mins to copy that
file.

Then I ran "mkfile 10k test.1" and copied it 9999 times for a total of
10,000 10k files. 

Copying those using Samba took nearly 15 minutes, using and avg of 50%
cpu (peak was about 75%, minimum 10%). If this simulates normal use
(which it generally does, "normal" being relative to my users' habits
of course :) then obviously a dual CPU machine will handle serving
five or six users at most. However, batch rendering gives us access to
up to 20 CPUs at once... 

Thus I need to reduce CPU usage to about 1/5 of what it currently is
if I want to be able to meet my needs without maxing out my server.

FTP took a little less time than Samba, but only a little. I'd like to
point out that I DO expect that! It's not the SPEED of the copy that
I'm concerned about, it's the amount of CPU that gets used. The FTP
daemon used a maximum of 10% cpu (peaked while resolving the wildcard
from "mget *"), and once it got over that hurdle, it never went above
2%. Average was around 1%.

Since FTP is a pretty simplistic (and inherently low cpu) protocol, I
decided to test against NFS as well. The "nfsd" process hung around at
0.3% cpu use, apart from a momentary peak at 5% at wildcard expansion.
Using NFS, it took about 11 mins to copy the files. Correct me if I'm
wrong but I think NFS is running partly inside the kernel? Whcih means
I probably didn't track all of the cpu use generated by my test. But
there wasn't any significant activity registering on the system
anyway, so whatever fraction I missed wasn't too important.

And just for control, I tried rcp as well, that took about 13 minutes
to copy. Server CPU use was about 1%, however there was an extra 5%
also being used on my client.

> Older Solaris systems were slow updating heavily-hit directories,
> which hits the Windows "rename, copy/edit, save, delete" sequence
> right between the eyes, but didn't hurt "copy *" operations, so the
> data and the use of it are relevant.

Hmm. Good point.

However, I have been seeing the same loading characteristics during
loading of a 3D scene as when I did the copy operations. If the
problem is bad during copies, it's only going to be worse during real
use scenarios :)

> And, as always, if the data is structured like 27july1944.jsmit.23,
> it should be changed to a layout like july1944/27/jsmit.23, so as to
> keep the directoiry sizes small and bounded...

I totally agree with that. Unfortunately, the 3D software we are using
(Softimage) chooses where and how it saves it's files. Our scene
complexity is very high, which results in Softimage saving literally
hundreds of material, texture and model files. All of those are saved
in separate directories in a Softimage "database" (which is really
just a regular dir structure) without any kind of user control. If you
save the scene a few times in the same database (absolutely necessary)
then you can easily go over the "nice dir size" limits... each scene
may have 1500 files or more, even divided amongst 10 dirs, it only
takes a few scene saves and your up in the thousands.

That was never particularly a problem on Irix/NFS, but now that we've
brought NT boxes into the mix, using Samba, our file server load has
gone from virtually idle, to a routine load of 7 or 8 (on a dual CPU
machine!)

Justen
-- 
.-----------------------.------------.--------------------------.
| Justen Marshall       |            | e-mail: justen at al.com.au |
| Technical Director    |            | phone:   +61-2-9383-4831 |
| Animal Logic Pty Ltd  |            | fax:     +61-2-9383-4801 |
|-----------------------^------------^--------------------------|
| Athiesm is a non-prophet organization.                        |
`---------------------------------------------------------------'