Re: Packet sizes on transfers between client/server

Thanks for the detailed response. I've forwarded this on to our network
and server teams. There is one process that could be sending small
queries/data back and forth that we are already working to move to the
server. Once that's done we'll see if the small packets go away (the
only other process pulling data regularly should be pulling schedules
which should be fairly large).

-----Original Message-----
From: Michael Fuhr [mailto:mike@fuhr.org]
Sent: Friday, August 26, 2005 11:10 AM
To: Walker, Jed S
Cc: pgsql-novice@postgresql.org
Subject: Re: [NOVICE] Packet sizes on transfers between client/server

On Fri, Aug 26, 2005 at 10:02:55AM -0600, Walker, Jed S wrote:
> We are needing to cut-down network traffic between our PostgreSQL
> client and server. The network team says that PostgreSQL is
> transferring data in 256k packets with acks of around half that size.
> Is there a parameter or a connection string setting that can be
> changed to force the system to use larger packet sizes?

Are you sure those packet size figures are correct?  What link layer are
you using that allows 256k packet sizes?  Might the size be 256 instead
of 256k?  And what ACKs are they talking about?  In a TCP connection,
*all* segments except the first have the ACK flag set, and many of those
segments will be carrying data.  ACKs carrying no data should be small
-- just big enough for the IP and TCP headers (20 bytes + 20 bytes + 0
or more bytes for IP and/or TCP options; network engineers might also be
adding link-layer framing) -- and the operating system determines when
to send those.

If I'm reading the source correctly, PostgreSQL sends data in 8192-byte
chunks, but how those writes are broken up or aggregated into link-layer
packets is up to the operating system.  If you're seeing a lot of
packets smaller than the link layer's MTU then I'd guess the application
is doing a lot of small queries.  If that's the case, then maybe some of
that work could be moved into server-side functions.

Have you run a sniffer (tcpdump, ethereal, etc.) to verify what the
network team is telling you?  If so then it might be useful to see some
of that data.

--
Michael Fuhr