Re: Slow database access **RESOLVED**

[John Hinckley <john () johnhinckley net>]

It was, in fact, Opportunistic Locking that was causing the latency.  Odd
because it didn't start happening until after I installed Symantec Antivirus
on the server.  The clients were already running SAV but just pointing to a
diff server so nothing really changed there.

At any rate, I disabled Opportunistic Locking on the clients (regedit),
rebooted and the problem went away.  It was the "status_sharing_violation"
in packet 2279 that tipped me off so another win for Wireshark!

Thanks for the information Martin, I would have missed it w/o your review of
my capture!

Best Regards,
- John

On Tue, Dec 1, 2009 at 12:07 PM, John Hinckley <john () johnhinckley net>wrote:

> Martin,
>
> Could the SMB errors be related to "opportunistic locking"?  If so, would
> there be a way to find that in a capture?
>
> Thanks,
> John
>
> On Mon, Nov 23, 2009 at 8:21 PM, Martin Visser <martinvisser99 () gmail com>wrote:
>
> > I don't think your issue is network (IP layer or lower) related. The TCP
> > checksum errors are purely due to the smart & fast TCP offloading done by
> > your NIC. (In your Wirehark Preferences and the Protocol section turn off
> > the checksum verification option for TCP). If you were getting real physical
> > errors you would see TCP retransmissions of even TCP header issues, which
> > aren't
> >
> > It is difficult to determine the issue from what you have give,
> > especicially not knowing the intricacies of your application.
> >
> > Some things I have noted is that that there a few points at which your
> > client requests SMB resources but does not obtain them causing a short
> > timeouts. For instance the SMB requests responded to in  frames 2279, 2282
> > and 2286 result in a sharing violation. Between each seems to be an *exact*
> > 1 second timeout at the server. Each query is asking in a different way
> > (with different access requirements), I guess in order to probe for the
> > right resource access. But this definitely would "lock" your client app
> > while it gets the answer. But this possibly doesn't explain the 3 - 10
> > second lockups you are seeing.
> > .
> > The other thing I see (which has the "btrieve" TCP port 3351 ) is lots of
> > small transactions. While I don't think it is broken, it is probably
> > inefficient. You may find that part of it can be fine tuned (in the
> > application)
> >
> > You have provided a 2 minute long capture, and it is hard to determine
> > exactly where the user level interactions occur - and where they match the
> > network traffic. For this scenario, particular if the app isn't well
> > understood, I use a bit of a logged time and motion study. To do this
> >
> > 1. Run wireshark in a capture mode - but only display "capture info
> > dialog"
> > 2. When the user starts a transaction (clicks on button, presses enter,
> > etc) note the packet total/ seconds from the capture info dialog
> > 3. When you see an appropriate response on the client screen (data
> > displayed, etc), note the related packet number/time
> > 4. Repeat as necessary with different scenarios. I try to vary the
> > transactions that help characterise the applications. You might find some
> > user level queries/transactions have quick responses, and others can
> > generate a long response time. These will help show up whether there is a
> > network bandwidth issue, or server related problems.
> > 5. From what you have you can try and bracket what network activity
> > matches different transactions. Looking at the IO graph on wireshark can
> > also help visualise this.
> >
> > If you want to do this and effectively annotate the capture again we could
> > look at it some more.
> >
> >
> > Regards, Martin
> >
> > MartinVisser99 () gmail com
> >
> >
> >
> > On Tue, Nov 24, 2009 at 12:02 PM, John Hinckley <john () johnhinckley net>wrote:
> >
> > > Thanks Tal and Joan!  I'm pretty sure it has something to do with the tcp
> > > checksum errors but I'm going to keep digging.
> > >
> > > Regards,
> > > John
> > >
> > >
> > > On Mon, Nov 23, 2009 at 3:54 PM, j.snelders <j.snelders () telfort nl>wrote:
> > >
> > > > Hi,
> > >
> > > Hopefully this information is useful:
> > > > Slow Network Write Speeds via SMB & CIFS
> > > > <snip>
> > > > File Transfer Benchmarks:
> > > > Windows XP to Windows Server (SMB Writing): ~ 25 Mbps
> > > > Windows XP to Windows Server (SMB Reading): ~ 75 Mbps
> > > > Windows 7 to Windows Server (SMB2 Writing): ~ 90 Mbps
> > > > Windows 7 to Windows Server (SMB2 Reading): ~ 90 Mbps
> > > > <snip>
> > > >
> > > >
> > > > http://social.technet.microsoft.com/Forums/en/winserverfiles/thread/46898c7f-92e0-4c99-98d2-18a7458a7d2d
> > > >
> > > > Best regards
> > > > Joan
> > > >
> > > >
> > > >
> > > > From: Tal Bar-Or <tbaror@xxxxxxxxx>
> > > > On Mon, 23 Nov 2009 23:43:53 +0200 Tal Bar-Or wrote:
> > > > just from first look it seems that your DB server is having some kind
> > > > file
> > > > system delay (smb) 4 sec approx, although i saw it also  from client
> > > > side
> > > > in the system part.
> > > >
> > > >  On Mon, Nov 23, 2009 at 8:47 AM, John Hinckley <john@xxxxxxxxxxxxxxxx>
> > > > wrote:
> > > >    I'm not sure whether it was a windows update or a symantec update but
> > > > something caused my customer's pervasive database to start dragging.  I
> > > > took
> > > > a capture from a workstation client and it only seems slow when
> > > > retrieving
> > > > the data but once the data is retrieved, manipulating seems normal.
> > > >  There
> > > > are 3-10 second delays in accessing tables etc.
> > > >
> > > >    The workstation IP: 192.168.0.13 (windows xp pro sp3)
> > > >    Database Server IP: 192.168.0.3 (windows server 2008 standard)
> > > >    Application Name: Agris (pervasive database)
> > > >
> > > >    I've completely disabled symantec on both the client and the server
> > > > and
> > > > it hasn't made a bit of difference.  I'm having a hard time sifting
> > > > through
> > > > the capture I took.  All I did was have the client login and access a
> > > > report
> > > > during the capture.  Maybe 20 seconds tops.
> > > >
> > > >    I've attached the capture file; if anyone can see anything useful, I
> > > > would appreciate you sharing it.
> > > >
> > > >    TIA,
> > > >    John
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > ___________________________________________________________________________
> > > > Sent via:    Wireshark-users mailing list <
> > > > wireshark-users () wireshark org>
> > > > Archives:    http://www.wireshark.org/lists/wireshark-users
> > > > Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
> > > >             mailto:wireshark-users-request () wireshark org
> > > > ?subject=unsubscribe
> > >
> > >
> > >
> > > ___________________________________________________________________________
> > > Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org
> > > >
> > > Archives:    http://www.wireshark.org/lists/wireshark-users
> > > Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
> > >             mailto:wireshark-users-request () wireshark org
> > > ?subject=unsubscribe
> >
> >
> >
> > ___________________________________________________________________________
> > Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
> > Archives:    http://www.wireshark.org/lists/wireshark-users
> > Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
> >             mailto:wireshark-users-request () wireshark org
> > ?subject=unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request () wireshark org?subject=unsubscribe