Question about Network Packet Size

Question

Post reply

Question about Network Packet Size

Scott Ohar

Hall of Fame

Points: 3607
More actions
February 7, 2011 at 8:28 am

#388794

Hey all, here is my question what are the pros and cons to changing the network packet size. Are there any best practices for SQL Server running on a 10g network?
current setup
A/A Cluster sql 2008 r2 x64
with 10g network connection
2.5 TB OLTP
I've been doing research on it and can't find a good answer and I really dont wanna test in production.:w00t:

Viewing 5 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply

dmmaxwell Old Hand Points: 382 More actions · Answer 1

I usually don't, unless I see that it's causing a very significant performance issue. If it were me, I'd start by :

1. Checking wait stats and seeing if NETWORKIO is showing up a lot, or has long wait times.

2. Do a trace (server side, of course) of login / existing connection events, and include the integerdata column. That should tell you what packet sizes your applications are connecting with.

I would say, as long as your network packet size is at or above what your apps are requesting, and the network supports it, leave it alone. 😀

hth,

-David.

Scott Ohar Hall of Fame Points: 3607 More actions · Answer 2

hey thanks for the reply, we aren't seeing any issues. Its the little kid and red button syndrome. I am just wonder would there be any huge gains by making the changes? 😉

dmmaxwell Old Hand Points: 382 More actions · Answer 3

Scott,

Well, like most things, I'm gonna say, "It depends." 🙂 Unless you changed your parameters all around, meaning applications, network and SQL Server, then I'd guess you're still going to only move as fast as the slowest component. So the most likely scenario is that you'd see no gains. On a test system, I'd say go for it, and see what you get. 🙂

Anyone else got some experience with this?

Thanks,

-David.

Jonathan Kehayias One Orange Chip Points: 26778 More actions · Answer 4

Even if you have ASYNC_NETWORK_IO waits that's not generally a sign that the network is the problem. The most common cause of this wait type is client code that is inefficiently consuming data. Very rarely have I seen where the network to the SQL Server is the issue. Increasing the network packet size is not likely to solve any problems unless you have other changes in the physical network like jumbo frames enabled since the MTU is 1500 bytes per packet so packet fragmentation has to occur for packets larger than 1500 bytes. However, Jumbo Frames isn't something you just go turn on, there's a lot that has to be considered as covered in my blog postSQL Server and Jumbo Frames.

TDS was never really designed to move large amounts of data fast, thats part of the reason why Database Mirroring uses the Service Broker network stack.