[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: BD-Uninstallable performance.



On Mon, Aug 03, 2009 at 09:45:17PM +0200, Joachim Breitner wrote:
> Hi,
> 
> Am Montag, den 03.08.2009, 09:45 +0200 schrieb Philipp Kern:
> > am Mon, Aug 03, 2009 at 12:43:15AM +0200 hast du folgendes geschrieben:
> > > It seems that for the few days this has been running now, all
> > > arches started to pick up alot of the BD-Uninstallable state,
> > > some around 30-50, which is great.
> > > But it seems the time of "trigger.often" has gone up alot because
> > > of this, starting to take around 11-12 minutes to run, from the 2-3
> > > minutes it used to take before the patch and 7-8 when the patch started.
> > 
> > that's why I initially (i.e. about one year back) wanted some daemon thing
> > from the debcheck folks to keep the data structures in memory and just update
> > them with the current data and then query the result.  This would even be
> > helpful for britney (maybe).
> > 
> > The trigger could run detached but that's probably worse at the moment as
> > we'll get a pain when they collide multiple times...
> 
> I assume that most of the time is spent generating the fake source file
> (in wanna-build), then feeding that to edos-builddebcheck (perl) which
> uses add_sources (python) to transform it to a Packages file. The
> actualy edos-debcheck run is not the bottle neck. This should be easily
> verifiable by observing "ps -A".

It takes about 2 minutes to run the keep-latest script
for all arches.

It seems edos-debcheck takes about 18 seconds cpu time per arch,
which is about:
- 4 seconds "Parsing package file"
- 9 seconds "Generating constraints"
- 5 seconds "Checking packages"

It seems that armel takes about 10 seconds instead of 5
to check the packages.

Which 13 arches, this takes about 4 minutes, which leaves
about 3 additional minutes over the original.  I'm not sure yet
how long each step of that takes.


Kurt


Reply to: