smbd: High CPU usage
jra at samba.org
Wed Jul 18 19:32:13 UTC 2018
On Wed, Jul 18, 2018 at 12:27:04PM -0700, Jeremy Allison via samba-technical wrote:
> On Wed, Jul 18, 2018 at 09:21:43PM +0200, Ralph Böhme wrote:
> > On Wed, Jul 18, 2018 at 12:12:05PM -0700, Jeremy Allison via samba-technical wrote:
> > > Now all our socket calls are tevent based, I think we should probably
> > > change the SMB1 code to match the SMB2 code and make the primary socket
> > > non-blocking, then fix the sendfile internal implementation to change to
> > > make the socket temporarily blocking, and back to non-blocking after the
> > > sendfile completes.
> > hm, I think we should avoid such hacks. Can't we just somehow go back to the
> > event loop if the fd returns EAGAIN or similar for a sendfile() ?
> No. The reply may be in a partially sent state.
> There's nothing we can do until we've finished sending
> the full read reply and there's no internal buffer
> to store it as there is with a normal async or sync
> read reply.
> That's why we have the same hacks in recvfile.
To explain more, sendfile()/recvfile() are special
cases, as they leave the data in-flight (that's
kind of the point) so the read/write socket can
be in a partially completed request or reply state.
The good news is we can hide the uglyness inside
the lowest level implementation of sendfile() as
we already do with recvfile() so the outer code
doesn't have to deal with whatever changes we have
to make to make sendfile()/recvfile() work
More information about the samba-technical