smbd: High CPU usage

Jeremy Allison jra at samba.org
Wed Jul 18 19:34:44 UTC 2018


On Wed, Jul 18, 2018 at 09:30:21PM +0200, Timur I. Bakeyev wrote:
> On 18 July 2018 at 21:27, Jeremy Allison via samba-technical <
> samba-technical at lists.samba.org> 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() ?
> 
> 
> There is also a long hanging in the PRs queue WRONG(IMHO) patch that tries to
> address sendfile() problem:
> 
> https://github.com/samba-team/samba/pull/76
> 
> Still, possibly, worth looking at.

Just did - that's wrong. I'm fixing it by changing the
low-level sendfile to store previous state, set the socket
to blocking, do the sendfile() then restore.

The Linux fix is easy, I'll have to rely on vendors to
test changes in the other sendfile implementations.

Jeremy.



More information about the samba-technical mailing list