On Tuesday 06 June 2006 14:57, Malcolm Rowe wrote:
> On Tue, Jun 06, 2006 at 01:47:48PM +0200, Ph. Marek wrote:
> > There you'll find this part (around line 126):
> > svn_boolean_t svn_ra_svn__input_waiting(svn_ra_svn_conn_t *conn,
> > apr_pool_t *pool)
> >
> > HERE> return ((apr_poll(&pfd, 1, &n, 0) == APR_SUCCESS) && n);
> >
> > May I suggest using a non-zero timeout (eg. 1000us) or possibly -1
> > (infinite)? I only ask because it's a bit inconvinient currently:
> > $ top
> > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> > 4038 flip 18 0 62144 44m 3196 R 53.4 8.8 6:54.89 svnserve
>
> That function is working as designed: if returns immediately, signalling
> whether there is any input waiting on the connection. We use it during
> a pipelined editor drive to determine if there's an error return we need
> to deal with, so a non-zero timeout would be inappropriate.
>
> That said, if your svnserve isn't actually handling a connection, could
> you try to find out what it _is_ doing? It shouldn't be busywaiting
> like that, and it _really_ shouldn't be using that much memory.
>
> $ top
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 17248 svn 9 0 1308 1308 988 S 0.0 0.3 0:00.01 svnserve
>
> (1.3.2; running for almost a week now).
I seem to have sent incomplete data again.
This is a running svnserve, connected via ssh+svn://, doing a status of a
directory tree with about 200 000 entries (directories + files).
During the processing it busy-waits for new data; I can see that via strace.
It does many, many poll()s one after the other - every few microseconds, until
there is data to process (or maybe until the network socket has been
emptied - is that important to find out where it loops?).
So maybe a caller should be modified to sleep a small bit?
Regards,
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jun 7 07:10:29 2006