Claudio Jeker([email protected]) on 2019.06.17 22:38:00 +0200:
> On Mon, Jun 17, 2019 at 05:00:32PM -0300, Martin Pieuchot wrote:
> > On 17/06/19(Mon) 21:43, Claudio Jeker wrote:
> > > I noticed that by default the send and recv socket buffers for
> > > socketpair(2) is rather low (4k IIRC). The result is a fairly inefficent
> > > write/read behaviour on the imsg sockets. Increasing SO_SNDBUF and
> > > SO_RCVBUF seems to help increase the data sent and received per syscall.
> > > 
> > > Another option would be to make the default socketbuffer watermarks for
> > > socketpair(2) a bit less limited. Then all imsg users would benefit at the
> > > same time.
> > 
> > What's the downside of making the default socketbuffer watermarks
> > bigger?  Wasting resources?  How did you figure out that the socket
> > buffers were too small?  Is that something we could apply to other
> > daemons?
> > 
> 
> First about the how I found it. Looking at ktrace output and noticing that
> write is only pushing 4k of data and read is also only pulling 4k data.
> Afterwards I used netstat -vP to verify the socketbuffer limits.
> 
> Bigger watermarks could cause higher pressure on the mbuf/mcluster pools.
> Now as long as the receiver is processing the data there should not be a
> problem but once the reader stops more data queues up in the socketbuffer.
> It would make sense to use something similar to pipe(2)'s method of big
> and small buffers for socketpair(2). It would also be possible to auto
> scale the buffers but that is a fair bit harder to implement.
> 
> I guess a lot of processes could benefit from increased buffers. For
> example firefox and chrome are heavy users of unix sockets. I remember
> that we already added something in Xorg to bump the buffer size.
> A quick check tells me that most unix sockets have sb_hiwat set to 4096.
> 
> Makes me wonder what the other BSD use for buffer sizes for the different
> UNIX socket types.

FreeBSD: sysctl
net.local.stream.recvspace: 8192
net.local.dgram.recvspace: 4096
net.local.seqpacket.recvspace: 8192
net.local.stream.sendspace: 8192

Linux: 212992 (/proc/sys/net/core/[rw]mem_default)


> -- 
> :wq Claudio
> 

Reply via email to