All right, to sum things up, here is the situation:
Server: Sun sparc 20 Solaris 2.5
Client: Dell Pentium 200 with Win95
Microsoft Visual C++ 4 or 5
Samba: 1.9.17p[234] or 1.9.18alpha3
Opening files in Visual C++ is ok (slower than I would expect though).
Saving files (one at a time at the rate of the user) takes generally
10 seconds (Visual C++ removes the '*' next to the file name almost
immediately and then Visual C++ is 'stuck' for 10 seconds).
Furthermore, smbd takes up 30% of the cpu on the sparc server.
I tried running two PC clients and the two smbd processes take up 60-65%
of the cpu (that's really not viable) with horrible performance on the PC
side.
This does not happen when the files are opened with wordpad/notepad/write.
Curiously, I had already used samba in this kind of situation on an IBM
RS6000 AIX 4.1 and didn't have any performance problems (neither on the PC
nor on the Unix box).
> That sounds like a problem I've seen in another life: the client
>(MS C++) knows it can depend upon certain features/behaviors of
>the server (MS NT), and mysteriously fails or slows down when conected
>to another brand of server.
Ok, so I have to solve this or stop using samba :-(
> I speculate we're seeing opportunistic locking going on: it's
>recommended/designed for just such things as source code control
>systems, compilers and shared-file mini-databases.
> Try turning oplock emulation on in your current system, plus fast
>locks and anything else that sounds like locks, and measure again.
Absolutely no change in performance with samba-1.9.17p[234]
> If that's actually the problem, the newest release has full oplock
>support built in, to solve problems like yours.
Absolutely no change in performance with samba-1.9.18alpha3 on the PC
side, however smbd now seems to take up 40% of the cpu...
Using smbstatus, I can see that Visual C++ is effectively performing
opportunistic locking. However, the files that are locked by one client
are still available for the other client (they are not locked and both
clients can write them), this must be a bug.
Thanks for any suggestions,
Gilles
----------------------------------------------------------------------
Gilles Depeyrot <mailto:Gilles.Depeyrot@wanadoo.fr>
Those who can do, those who can't simulate !