Wireshark mailing list archives
Re: Slow database access
From: John Hinckley <john () johnhinckley net>
Date: Tue, 1 Dec 2009 12:07:47 -0800
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 orgArchives: 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
Current thread:
- Re: Slow database access John Hinckley (Dec 01)