[PATCH] SMB2_FIND improvement for clustered environments

Ralph Böhme slow at samba.org
Fri Mar 31 18:09:14 UTC 2017


On Thu, Mar 30, 2017 at 05:13:21PM +1100, Amitay Isaacs wrote:
> Hi,
> 
> On Thu, Mar 23, 2017 at 8:54 PM, Ralph Böhme via samba-technical <
> samba-technical at lists.samba.org> wrote:
> 
> > Hi!
> >
> > Attached is a patchset that improves SMB2_FIND performance in a ctdb
> > cluster by
> > making records fetching from locking.tdb asynchronous.
> >
> > This has three parts:
> >
> > - add a seperate IPC channel to ctdb for asynchrous processing
> >
> > - new async dbwrap API: dbwrap_parse_record_send|recv()
> >
> > - making use of it in smbd_smb2_query_directory_send()
> >
> > Some numbers follow.
> >
> > The time it takes to enumerate a directory with 50k files, current code:
> >
> > $ time bin/smbclient -U FAST\\slow%x -m smb3 //localhost/share -c "ls
> > dir\50kfiles\*" > /dev/null | grep real
> >
> > 3 runs:
> > real    0m10.693s
> > real    0m10.608s
> > real    0m10.710s
> >
> > Using the new async API this becomes:
> >
> > 4 runs:
> > real    0m3.903s
> > real    0m2.809s
> > real    0m3.869s
> > real    0m3.894s
> >
> > Some more implementation details shamelessly copied from the commit
> > messages:
> >
> > ---8<---
> > dbwrap: add dbwrap_parse_record_send/recv
> >
> > The req_state parameter tells the caller whether the async request is
> > blocked in a full send queue:
> >
> > req_state >= DBWRAP_REQ_DISPATCHED := request is dispatched
> > req_state < DBWRAP_REQ_DISPATCHED := send queue is full
> >
> > This is useful in a clustered Samba environment where the async dbwrap
> > request is sent over a socket to the local ctdbd.
> >
> > If the send queue is full and the caller was issuing multiple async
> > dbwrap requests in a loop, the caller knows it's probably time to stop
> > sending requests for now and try again later.
> >
> > This will be used in subsequent commits in
> > smbd_smb2_query_directory_send() when implementing async write time
> > updates. Directories may contain umpteen files so we send many requests
> > to ctdb without going through tevent and reading the responses which has
> > the potential to deadlock.
> > ---8<---
> >
> >
> Looking at the code, it seems to duplicate a lot of functionality in the
> CTDB client (new) code.  May be it's time to start using CTDB client code
> to avoid duplication of effort and keep separate implementation of CTDB
> protocol.  All of the CTDB client code has async API already.
> 
> May be something worth discussing at SambaXP?

yup. :) Afaict all I need is ctdb_client_call_send()/recv(), but we'll see.

Cheerio!
-slow



More information about the samba-technical mailing list