o.widmer@riskreturn.ch
2006-Jul-25 14:10 UTC
[Samba] login to ms access db very slow on samba 3.x
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/ [.......]
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@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/ > > [.......] > >