[Samba] login to ms access db very slow on samba 3.x

[o.widmer at riskreturn.ch]

Hi Brian

Thanks for the hint. Unfortunately I am not at all familiar with doing 
this. Would that involve strace? I took a glimpse at the man pages of 
strace, but I don't know if I could produce some useful output with it. 
But maybe I got you wrong and there's an easier way? I must admit that 
although I'm not totally samba-illiterate, I'm no pro either (obviously :)

cheers 
Oli


Brian Cowan <brcowan at gmail.com> wrote on 25.07.2006 16:32:06:

> Have you tried running network traces with Samba 2.x and 3.x and 
> comparing the results. I suspect that at least one newer smb feature is 
> killing you...
> 
> o.widmer at riskreturn.ch wrote:
> > hi everybody
> >
> > we have been reading through the archives for quite some time now, and 

> > could not find a solution to our problem. please excuse if we 
overlooked 
> > something and our question was already answered elsewhere...
> >
> >
> > we have Samba version 3.0.14a-Debian running on (you guessed it) 
debian 
> > with kernel  2.6.8-2-386.
> >
> > ever since our migration from samba 2.x we have speed issues with an 
ms 
> > access database which gets accessed by multiple users through an 
> > access2000 runtime application running on windows clients (2000 and 
XP). 
> > when users log in to the database, it takes >3min until the 
login-window 
> > pops up and users can enter their credentials. since things are not 
slow 
> > for the first user, but for every user that tries to login afterwards, 
we 
> > are suspecting some problems with the lock file of the db or with file 

> > ownership... also, transactions seem to be going on at normal speed 
once 
> > after users are logged in (also for users who encounter the "slow 
login" 
> > problem). 
> >
> > after reading through old postings, we have disabled oplocks and 
level2 
> > oplocks, also Kernel oplocks, with no success. we made a new share 
> > containing only the database file (which is about 410MB in size), with 
no 
> > success. after comparing the old 2.x setup with the new one, we 
noticed 
> > that on 2.x (where everything ran smooth) guest access was enabled and 

> > everybody was accessing the DB as user "nobody" of group "nogroup", so 
we 
> > tried the same setup on our 3.x server,  forcing user "nobody"  and 
group 
> > "nogroup" on our new 3.x server, hoping that would solve the problem. 
> > nada. 
> >
> > we have tried changing the tcp send/receive buffer size after reading 
> > through tcpdump logs, but that was probably too far off. 
> >
> > it seemed to us that we were not the only ones with this specific 
problem, 
> > but every hint we found was pointing to disabling oplocks - which we 
did. 
> > maybe one of you guys can help us out? any hint or help will, of 
course, 
> > be highly appreciated. maybe we have misconfigured something?
> >
> > oli
> >
> >
> > relevant sections of
> > /etc/samba/smb.conf:
> > ****************************
> >
> > # Global parameters
> > [global]
> >
> >         [.......]
> >         veto oplock files = 
> > /*.doc/*.xls/*.pdf/*.mdb/*.bsd/*.MDB/*.BSD/*.bsa/*.BSA/*.lbd/*.
> LBD/*.ldb/*.LDB/
> >         veto files = 
> > /lost*found/.bash_profile/.bashrc/aquota.*/.ARK_NOBACKUP/
> >         lock spin time = 15
> >         lock spin count = 100
> >         socket options = TCP_NODELAY IPTOS_LOWDELAY SO_SNDBUF=2920
> >         sync always = no
> >         strict sync = no
> >         kernel oplocks = No
> >
> >
> > [.......]
> >
> > [dbs]
> >         path = /var/samba/dbs
> >         read only = no
> >         guest ok = yes
> >         oplocks = no
> >         level2 oplocks = no
> >         strict locking = no
> >         fake oplocks = no
> >         create mask = 0777
> >         directory mask = 0770
> >         force create mode = 0777
> >         force user = nobody
> >         force group = nogroup
> >         veto oplock files = 
> > /*.MDB/*.mdb/*.bsd/*.BSD/*.bsa/*.BSA/*.lbd/*.LBD/*.ldb/*.LDB/
> >
> > [.......]
> >
> > 
>