[Samba] Re: How Samba let us down

[Chris de Vidal]

Thank you for responding.  You win a gold star for
actually reading my email and not jumping to
conclusions (-:

--- Tristan Ball <tb at vsl.com.au> wrote:
> I think the 7580 might be a mistake. The card has
> only 2meg of cache (read: f*ck all).

The amount of RAM is not an apples-to-apples
comparison.  The RAM isn't SDRAM like on other
hardware RAID cards but SRAM... no latency, and the
controller uses a non-blocking switched fabric.*  I'm
too tired to remember what that means, but we saw that
the 3ware cards did about as well as other RAID cards
with much more RAM.  I don't recall, however, looking
over RAID 5 performance (regarding your next reply),
which could have been our mistake.  Still, the primary
problem is corruption, not performance, but they could
be related.

* Something about that here:
http://www.matrixlist.com/pipermail/pc_support/2002-July/001737.html

> Raid 5 writes are _slow_, with 4 physical IO's
> required for every 1 io 
> from the OS or client. Thats why they try to buffer
> them up and write full 
> stripes at a time, or to keep parity blocks cached
> in ram. That means if your 
> clients are sending lots of small-ish random writes
> (I bet yours would be if 
> they are DB developers), that 5 disk array will
> probably sustain no more than 
> about 100-200 writes a sec.  Only a scratch more 
> than a single disk.

You could be right here.  The author in the link above
indicated that it might be a problem with small RAID 5
random read/writes.  Know how to see I/Os/sec on
Linux, by chance?  Bonnie++?  I'm still learning about
Linux through experience, reading, and asking
questions (:

The biggest problem is not performance but corruption,
but they could be related.  Anyway, if the problem is
the card, we should see the same problem when we put
NT on the server.  I'll let you and the list know.

> You also didn't mention what the CPU utilisation
> looked like, particularly as a 
> user/system/io breakdown. :-)

Load averages < 0.50 most of the time, free memory -
caches + buffers is around 350MB out of 2GB. 
sysctl.conf has been tuned for a large file server
setup using recommendations from "Securing And
Optimizing Linux 2.0" (only in hardback from
OpenNA.com).  I can post a copy of the file if you'd
like.

I'm still learning about Linux.. how would a
user/system/io breakdown be done?  Some flag of ps?

> Actually, while they can improve performance, they
> are an inherently less 
> reliable option than no-oplocks. Even on pure MS
> networks there are special 
> cases where they can cause trouble. (it does require
> other things to go wrong to 
> trigger them tho).

So.. it is safe to turn them off?

> I generally find level 3 debugs are the lowest level
> usefull for tracing, but 
> that enabling them for all processes will massively
> affect performance - 
> particularly if your logs go to that raid-5 volume
> :-)

Seperate drive for the OS + logs.  I'd heard level 3
was too slow so I didn't go that high.  I'll take it
up that high on a client basis using your next advice.

> I generally selectively enable logs using smbcontrol
> for particular clients, and 
> use a level of 3-5.

We couldn't determine how to set the debug level
individually.  Thanks!

> >         veto files                = /lost+found/
> 
> This will slow performance.

Our problem wasn't performance but corruption, but
they could be related.  I'll take this option out as
it doesn't matter if the user sees those directories. 
Thanks for catching that.

> >         debuglevel                = 2
> 
> Again, this will affect performance.

It was on 1 most of the time but on 2 when I copied it
to the list.

> Sorry you had such a rough time of it tho..

Thank you very much!  There is still a chance we will
use Samba again for this, and I'll take your advice
with me when we do.

By chance, do you use ACLs?

/dev/idal

__________________________________________________
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/