<div dir="ltr">It is the only check_ps we&#39;re using, but after your explanation, I&#39;m going to stick more in :)<div><br></div><div style>Thanks again,</div><div style> - Matt</div><div style><br></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Thu, Jan 24, 2013 at 3:51 PM, Michael Jennings <span dir="ltr">&lt;<a href="mailto:mej@lbl.gov" target="_blank">mej@lbl.gov</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Thursday, 24 January 2013, at 15:26:14 (-0500),<br>
<div class="im">Matt Britt wrote:<br>
<br>
&gt; Thanks Michael - that got me pointed in the right direction.  We&#39;re<br>
&gt; just using /etc/passwd, and it should be up to date.  The function<br>
&gt; using the time was &#39;check_ps_daemon sshd root&#39;:<br>
&gt;<br>
&gt; [root@nyx5506 msbritt]# time nhc        (with check_ps_daemon)<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; real    0m5.785s<br>
&gt; user    0m5.565s<br>
&gt; sys     0m0.101s<br>
&gt; [root@nyx5506 msbritt]# !vim<br>
&gt; vim /etc/nhc/nhc.conf<br>
&gt; [root@nyx5506 msbritt]# time nhc  (without check_ps_daemon)<br>
&gt;<br>
&gt; real    0m0.185s<br>
&gt; user    0m0.109s<br>
&gt; sys     0m0.055s<br>
<br>
</div>Wow, that&#39;s quite a difference.  :-)<br>
<br>
Is that the only check_ps_* check in your configuration?  I&#39;m guessing<br>
it is based on the time delay.<br>
<br>
What happens is this:  the first time you use one of the process-based<br>
checks, NHC will run the &quot;ps&quot; command to gather information on all<br>
your system processes.  This can, as you&#39;re seeing, take quite a bit<br>
of time on a heavily-loaded compute node.  However, it only needs to<br>
do this once; if you use one ps-based check, you can use as many as<br>
you want because you&#39;ve already &quot;taken the hit&quot; of the subprocess<br>
overhead.  Subsequent checks will used the cached data instead of<br>
launching &quot;ps&quot; again.<br>
<br>
Glad you found the culprit!  NHC tries to be as efficient as possible<br>
in everything it does, but it&#39;s up to each site to determine how they<br>
want to balance the tradeoffs between longer/shorter execution time<br>
for NHC and more/less comprehensive assessments of node health.  I<br>
tried to make it as easy as possible to measure and evaluate those<br>
tradeoffs; hopefully I succeeded.  :-)<br>
<div class="HOEnZb"><div class="h5"><br>
Michael<br>
<br>
--<br>
Michael Jennings &lt;<a href="mailto:mej@lbl.gov">mej@lbl.gov</a>&gt;<br>
Senior HPC Systems Engineer<br>
High-Performance Computing Services<br>
Lawrence Berkeley National Laboratory<br>
Bldg 50B-3209E        W: <a href="tel:510-495-2687" value="+15104952687">510-495-2687</a><br>
MS 050B-3209          F: <a href="tel:510-486-8615" value="+15104868615">510-486-8615</a><br>
_______________________________________________<br>
torqueusers mailing list<br>
<a href="mailto:torqueusers@supercluster.org">torqueusers@supercluster.org</a><br>
<a href="http://www.supercluster.org/mailman/listinfo/torqueusers" target="_blank">http://www.supercluster.org/mailman/listinfo/torqueusers</a><br>
</div></div></blockquote></div><br></div>