www-builds mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gavin McDonald <ga...@16degrees.com.au>
Subject Re: Number of build prozessors on Lucene node
Date Thu, 20 Aug 2015 09:38:32 GMT

> On 20 Aug 2015, at 10:28 am, Uwe Schindler <uwe@thetaphi.de> wrote:
> 
> Hi,
> 
> The backlog of Lucene is generally large. That's wanted,

No problem, thanks for letting me know, I’ll take that into account in the future.

> 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,

I’m more concerned about the health of the services we provide and what to do about them
when they need fixing and|or improvement.
Stats are nice, they provide feedback for current and future improvements that can be made,
but I’m not in the habit of twisting stats 
just to make things look pretty and good, thats not my take on what stats are for.

Gav…

> 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 <gmcdonald@apache.org>:
>> 
>>> On 20 Aug 2015, at 9:17 am, Uwe Schindler <uschindler@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

Gav...

          (    (      (                                                                  
       
   (      )\ ) )\ )   )\ )       (                       )                    )          
       
   )\    (()/((()/(  (()/(       )\ )  (       )      ( /( (      (        ( /(   (   (  
   (   
((((_)(   /(_))/(_))  /(_)) (   (()/(  )(   ( /(  (   )\()))(    ))\   (   )\()) ))\  )( 
  ))\  
 )\ _ )\ (_)) (_))_| (_))   )\ ) /(_))(()\  )(_)) )\ (_))/(()\  /((_)  )\ (_))/ /((_)(()\
 /((_) 
 (_)_\(_)/ __|| |_   |_ _| _(_/((_) _| ((_)((_)_ ((_)| |_  ((_)(_))(  ((_)| |_ (_))(  ((_)(_))
  
  / _ \  \__ \| __|   | | | ' \))|  _|| '_|/ _` |(_-<|  _|| '_|| || |/ _| |  _|| || ||
'_|/ -_)  
 /_/ \_\ |___/|_|    |___||_||_| |_|  |_|  \__,_|/__/ \__||_|   \_,_|\__|  \__| \_,_||_| 
\___|  
                                                                                         
       





Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message