Slow access database behaviour on netapp CIFS share

[vanhelvoort]

Hello,

We have a application written on a access database (Yes, we are looking to replace the database, but it will take a while.) which works rather poor at the moment, we used to have this database on a novell OES machine and there the performance was bareable. The access database resides on a netapp cifs volume now. Since this migration the performance is judged as poor at best by the users.

During a Wireshark network sniff, the long waiting times always come back to the following SMB Sequence:

Time    Operation

0.00     NT Create AndX Request, Path:\path\to\our\database.ldb

0.10     microsoft-ds ACK on the previous comand.

1.03     NT Create andX Response: FID:0x0000, Error: Status_Shareing_Violation

These operations take almost 1 second. And on some screens you open you have 4 operations like this. So the user has to wait almost 5 seconds to switch screens.

The .ldb however always has a lot of locks: at the moment every user has 36 locks on the file with 12 users.

- The netapp is busy but not overloaded (CPU under the 10%, cache time: around 30 minutes and disk utilisations around the 20%)

- The application used to work desent on a novell server, so i can get little support from the application engineer.

The netapp is a fas3020 in a metrocluster solution with ontap version 7.2.4 running on it.

Any thoughts on troubleshooting this issue?

[watan]

You may want to look at the oplock settings of the client and Netapp array  to see if this improves the performance of the database.

More about Oplocks here.

http://now.netapp.com/NOW/knowledge/docs/ontap/rel7311/html/ontap/filesag/accessing/task/t_oc_accs_improving_client_performance_with_oplocks.html#t_oc...

Array options -

options cifs.oplocks.enable

[pascalduk]

watan wrote:
 
Array options -
options cifs.oplocks.enable 

It is probably better to disable oplocks on qtree level then on filer level.

qtree oplocks <path> [ enable | disable ]

[amiller_1]

It's possible that setting no_atime on the volume might help (I'd research that first though).

[vanhelvoort]

Hello,

A long time has passed and all the suggestions have been tried. Non have helped though.

We managed to recreate this exact problem on a windows server. And it seems the problem lies within Access.

The solution for us: accepting the slowness and put the effort in moving the access databases to decent database servers.

Thanks a lot for thinking along.

[jerome_barrelet]

We had the same performance issue with Microsoft Access file on Volume CIFS, I did a new volume dedicated for Access file only, with the parameter :

vol options vol1 no_atime_update on

Now it works fine, no performance problems anymore.

Thanks Andrew.

Regards

[jiss]

priv set advanced 

options cifs.SharingViolationDelay   0
options cifs.SharingViolationRetries 0

do a cifs restart 

[IPSITAAMAL]

Is it mandatory to restart CIFS for the changes to take effect?