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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
