Hi, The backlog of Lucene is generally large. That's wanted, because we don't trigger builds based on commits; just to always have one build of everything in the queue we do it time-based. Because of our pseudorandomized test infrastructure, the build slave should never be out of work because every run may trigger a bug in Lucene or the Java VM. Because Jenkins never triggers the same job multiple times, it's perfectly fine to have at least one job of all in the queue.
If you don't want your statistics broken, you may exclude the lucene slave from counting towards queue size. It's completely on its own and only allows ecplicitely assigned jobs. You can always remove triggered builds from queu (I sometimes do this for testing puposes or to trigger a special build manually). They get queued anyways a while later if deleted. Uwe Am 20. August 2015 11:15:17 MESZ, schrieb Gavin McDonald <gmcdon...@apache.org>: > >> On 20 Aug 2015, at 9:17 am, Uwe Schindler <uschind...@apache.org> >wrote: >> >> Hi, >> >> could someone please change back the number of "build processors" for >the "lucene" Jenkins node to 1? Currently it executes always 2 Jobs in >parallel. The underlying server only has 4 cpu cores and the Lucene Job >configuration is done in a way that it uses all available CPU nodes, so >running 2 builds in parallel on is in most cases not a good idea. There >are in fact some jobs, that don't require much CPU or are not >multithreaded (like artifact builds), but those are generally quick. >The main tasks taking several hours to execute are very CPU intensive - >the reason why we have an own slave. >> >> Any information why this was changed? Unfortunately I don't have the >power to configure this correctly. > >I changed it short term to help with backlog. >When I did this (2 days ago) there were 166 builds in the queue, over >30 of those were waiting on the Lucene node. > >Will change it back now. > >HTH > >Gav… > >> >> Uwe >> -- Uwe Schindler H.-H.-Meier-Allee 63, 28213 Bremen http://www.thetaphi.de
