On Wed, Nov 12, 2014 at 12:59 PM, Rob Mandeville
<rmandevi...@dekaresearch.com> wrote:
> There are some hairy reasons for running a job on the master, specifically if
> you need to mess with Jenkins internals. If you don't need to do that (and
> if you have to ask, you don't), just reduce the number of executors on the
> master node to zero and see what breaks ;^>.
I'm not messing with jenkins internals in jobs, but I thought a
'system' groovy script could do that from a slave anyway. Is that not
the case? I did at one point set up an executor on the master with
the intent of forcing build_flow jobs there but haven't used it yet.
All of our jobs are restricted by label so nothing runs there.
> Also (and you probably know this) you may have to explicitly set the memory
> settings on the JVM as well as the VM; Java won't take all your memory by
> default, and you might want to leave a GB or so free so that the OS can do
> its OS-y things. Basically, if the JVM gives an out of memory complaint,
> think about the JVM settings first--adding 64GB to your host won't help if
> Java is only taking 4GB of it.
>
I never understand how to interpret the way 'top' shows java
processes. Mine shows 2.3g as RES for jenkins but it also shows 4.9g
as SWAP for the process while at the same time showing 0 Swap used in
the global part. Does that mean it has memmap'd some other file but
not paged it in - or is it in the 'casched' portion of swap?
--
Les Mikesell
lesmikes...@gmail.com
--
You received this message because you are subscribed to the Google Groups
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
