smbd: High CPU usage
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
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.
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