smbd: High CPU usage

Ralph Böhme slow at samba.org
Wed Jul 18 20:34:43 UTC 2018


On Wed, Jul 18, 2018 at 12:27:04PM -0700, Jeremy Allison 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.

hm, if you implement sendfile_send() with immediate events I guess that will
have higher priority then the out queue processing of SMBX response PDUs. Just
braindumping here, I'd have to take a closer look.

-slow

-- 
Ralph Boehme, Samba Team       https://samba.org/
Samba Developer, SerNet GmbH   https://sernet.de/en/samba/
GPG Key Fingerprint:           FAE2 C608 8A24 2520 51C5
                               59E4 AA1E 9B71 2639 9E46



More information about the samba-technical mailing list