[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: svnadmin verify performance issue (was: Re: How long do your svn dumps take)

From: Bert Huijben <rhuijben_at_sharpsvn.net>
Date: Wed, 22 Apr 2009 17:51:19 +0200

> -----Original Message-----
> From: kmradke_at_rockwellcollins.com [mailto:kmradke_at_rockwellcollins.com]
> Sent: woensdag 22 april 2009 17:44
> To: Bert Huijben
> Cc: dev_at_subversion.tigris.org; 'Stefan Sperling'
> Subject: RE: svnadmin verify performance issue (was: Re: How long do your
svn
> dumps take)
>
> Bert Huijben <rhuijben_at_sharpsvn.net> wrote on 04/22/2009 10:32:00 AM:
> > > > granularity: each sample hit covers 4 byte(s) for 0.00% of 296.19
> > seconds
> > > >
> > > > called/total parents
> > > > index %time self descendents called+self name index
> > > > called/total children
> > > >
> > > > <spontaneous>
> > > > [1] 26.2 77.59 0.00 apr_hash_next [1]
> >
> > Are you sure your debug symbols are ok. I would be very, very surprised
> if
> > this function would take 26% of your time:
>
> I just rebuilt svn 1.6.1 from scratch with "-pg" and ran gprof on
> the resultant gmon.out file... Haven't profiled anything on
> Solaris 10 x86 before, but have no reason to believe it isn't working.
>
> > APR_DECLARE(apr_hash_index_t *) apr_hash_next(apr_hash_index_t *hi)
> > {
> > hi->this = hi->next;
> > while (!hi->this) {
> > if (hi->index > hi->ht->max)
> > return NULL;
> >
> > hi->this = hi->ht->array[hi->index++];
> > }
> > hi->next = hi->this->next;
> > return hi;
> > }
> >
> > Unless you have an application containing an insane large hashtable,
> > containing nothing.. and doing nothing with the keys.
>
> The repository has a directory with almost 8000 subdirectories at one
> level. This was an investigation to see why svnadmin verify is
> taking over 40 hours to verify the 3GB repo...

The report doesn't show any disk io. Is this only the CPU time spend inside
the process?

Can you add a column to the report that presents actual time spend in the
methods and the methods it calls?

It could be the case that we don't do more than reading all the data (Which
I'm sure we do) and a tiny bit of processing.. In that case optimizing the
processing wouldn't help us at all.

        Bert

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1862218
Received on 2009-04-22 17:51:47 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.