[LON-CAPA-admin] Issues

James Mueller mueller at pitt.edu
Tue Nov 15 18:49:06 EST 2011


Mark and Stuart,
	This reply has nothing to do with debug modes, but as to memory usage, occasionally we see processes with memory leaks that slowly eat up more and more memory.  Ours are slow leaks, so they probably have nothing to do with yours.  Currently one machine has a process that has grown from nothing to 3 GB of resident memory since the first of October. The machine will be going down for maintenance over Thanksgiving, so I am not worried, but thought I would take this opportunity to put the info on it out there.

top says:
  PID USER     %MEM  PR  NI  VIRT  RES  SHR S %CPU    TIME+  COMMAND                                                   
12420 www      18.2  15   0 3027m 2.8g 1972 S  0.3  29:58.36 loncnew                                                    

And a little more detail:
$ ps vp 12420
  PID TTY      STAT   TIME  MAJFL   TRS   DRS   RSS %MEM COMMAND
12420 ?        S     29:58      0     0 3100400 2967932 18.2 lonc: loncapa10.fsu.edu Connection count: 1 Retries remaining

Again, this probably has nothing to do with your problem, so feel free to ignore it.  I don't want to hijack the thread.

-Jim

On Nov 15, 2011, at 6:20 PM, Lucas, Mark wrote:

> Hmm ... It's set to 0, and I don't see anything strange in the Debug
> subroutine.
> 
> I thought I remembered the loncnew has a way to toggle the debug on
> and off. Is there a comparable behavior upon an interrupt to lond?
> I didn't think there was.
> 
> Mark
> 
> On Nov 15, 2011, at 6:11 PM, Stuart Raeburn wrote:
> 
>> Hi,
>> 
>>> Tue Nov 15 05:26:57 2011 (21584): Command received: ekey, encoded = 0
>>> Tue Nov 15 05:26:57 2011 (21584): Matched dispatch hash: mustencode:
>> 
>> That is odd.
>> You should only see that level of detail in lond.log if you have:
>> 
>> my $DEBUG=1;
>> 
>> set in /home/httpd/perl/lond
>> 
>> I don't see it showing up in /home/httpd/perl/lond.log otherwise.
>> 
>> If you are sure that:
>> 
>> my $DEBUG-0;
>> 
>> is set (and you have restarted loncontrol), then it seems you should  
>> look at the Debug subroutine in lond, which should be:
>> 
>> sub Debug {
>>     my $message = shift;
>>     if($DEBUG) {
>> 	&logthis($message);
>>     }
>> }
>> 
>> To stop the excessive logging, regardless of the value of $DEBUG you  
>> could change it to:
>> 
>> sub Debug {
>>     my $message = shift;
>>     return;
>> }
>> 
>> and restart loncontrol
>> 
>> Stuart Raeburn
>> MSU LON-CAPA group
>> 
>> 
>> Quoting "Lucas, Mark" <lucasm at ohio.edu>:
>> 
>>> I'm having some issues here I may need help with.
>>> 
>>> We're working towards finals starting tomorrow, and last night I had  
>>> one of my machines
>>> go catatonic regarding LON-CAPA and httpd. I was still able to get   
>>> in via ssh.
>>> This seems to be correlated with memory problems.
>>> 
>>> I restarted LON-CAPA (loncontrol and httpd) on that machine and did   
>>> the same on
>>> my balancer, and it seemed to be fine.
>>> 
>>> Just about an hour ago I started having problems again. There seems   
>>> to be a significant
>>> increase in memory usage - the slope changed pretty dramatically as   
>>> usage picked up.
>>> 
>>> While the machines are being used pretty steadily, I'm wondering if   
>>> there's anything regarding
>>> downloading of large pdf files or the like that may somehow be   
>>> causing grief. They're not
>>> working on homework as much as they are pouring over lecture notes.
>>> 
>>> I also found the lond.log file on my library to be huge (3Gb+?) last  
>>> night. While there typically
>>> isn't much in lond.log, and I have debug set to zero, I'm getting a   
>>> bunch of messages like those shown
>>> below. Is this a sign of poor communications between the machines   
>>> developing under the load?
>>> Is debug somehow getting turned on?
>>> 
>>> I'm at a bit of a loss for the behavior, and I definitely have some   
>>> students pissed at me right
>>> now.
>>> 
>>> Mark
>>> 
>>> 
>>> ============================================================
>>> Tue Nov 15 05:26:57 2011 (21584): Command received: sethost, encoded = 0
>>> Tue Nov 15 05:26:57 2011 (21584): Matched dispatch hash: mustencode:  
>>> 0 ClientType 1Tue Nov 15 05:26:57 2011 (21584): Dispatching to   
>>> handler sethost oucapa2
>>> Tue Nov 15 05:26:57 2011 (21584): Request was sethost:oucapa2  Reply was ok
>>> Tue Nov 15 05:26:57 2011 (21584): get_request: Request = ekey
>>> 
>>> Tue Nov 15 05:26:57 2011 (21584): Main: Got ekey
>>> Tue Nov 15 05:26:57 2011 (21584): process_request: ekey
>>> 
>>> Tue Nov 15 05:26:57 2011 (21584): Command received: ekey, encoded = 0
>>> Tue Nov 15 05:26:57 2011 (21584): Matched dispatch hash: mustencode:  
>>> 0 ClientType 3Tue Nov 15 05:26:57 2011 (21584): Dispatching to   
>>> handler ekey
>>> Tue Nov 15 05:26:57 2011 (21584): Request was ekey:  Reply was   
>>> 7643ACBACEB8A7BAE8DBCE811563Tue Nov 15 05:26:57 2011 (21584):   
>>> get_request: Request =   
>>> sethost:oucapa2:put:ohiou:OUp200lib:nohist_resevaldata:author%2fmeap%2fcalculus%2fprecalcreview%2ftrig02%2dRadiansToDegrees%2eprobl
>>> em___ohiou%2fOUp200lib%2fmath%2ftriangle_comp1%2eproblem___comefrom=1
>>> 
>>> Tue Nov 15 05:26:57 2011 (21584): Main: Got   
>>> sethost:oucapa2:put:ohiou:OUp200lib:nohist_resevaldata:author%2fmeap%2fcalculus%2fprecalcreview%2ftrig02%2dRadiansToDegrees%2eproblem___ohiou%2f
>>> OUp200lib%2fmath%2ftriangle_comp1%2eproblem___comefrom=1
>>> 
>>> Tue Nov 15 05:26:57 2011 (21584): process_request:   
>>> put:ohiou:OUp200lib:nohist_resevaldata:author%2fmeap%2fcalculus%2fprecalcreview%2ftrig02%2dRadiansToDegrees%2eproblem___ohiou%2fOUp200lib
>>> %2fmath%2ftriangle_comp1%2eproblem___comefrom=1
>>> 
>>> Tue Nov 15 05:26:57 2011 (21584): Command received: put, encoded = 0
>>> Tue Nov 15 05:26:57 2011 (21584): Matched dispatch hash: mustencode:  
>>> 0 ClientType 1
>>> Tue Nov 15 05:26:57 2011 (21584): Dispatching to handler put   
>>> ohiou:OUp200lib:nohist_resevaldata:author%2fmeap%2fcalculus%2fprecalcreview%2ftrig02%2dRadiansToDegrees%2eproblem___ohiou%2fOUp
>>> 200lib%2fmath%2ftriangle_comp1%2eproblem___comefrom=1
>>> Tue Nov 15 05:26:57 2011 (21584): Request was   
>>> put:ohiou:OUp200lib:nohist_resevaldata:author%2fmeap%2fcalculus%2fprecalcreview%2ftrig02%2dRadiansToDegrees%2eproblem___ohiou%2fOUp200lib%2fma
>>> th%2ftriangle_comp1%2eproblem___comefrom=1  Reply was ok
>>> Tue Nov 15 05:27:09 2011 (21508): get_request: Request = exit
>>> 
>>> Tue Nov 15 05:27:09 2011 (21508): Main: Got exit
>>> ========================================================================
>>> 
>>> 
>>> 
>>> --
>>> Mark Lucas  email: lucasm at ohiou.edu<mailto:lucasm at ohiou.edu>
>>> 252D Clippinger Lab phone: (740)597-2984
>>> Department of Physics and Astronomy fax: (740)593-0433
>>> Ohio University
>>> Athens, OH 45701
>>> 
>> 
>> _______________________________________________
>> LON-CAPA-admin mailing list
>> LON-CAPA-admin at mail.lon-capa.org
>> http://mail.lon-capa.org/mailman/listinfo/lon-capa-admin
> 
> -- 
> Mark Lucas 								email: lucasm at ohiou.edu
> 252D Clippinger Lab						phone: (740)597-2984
> Department of Physics and Astronomy		fax: (740)593-0433
> Ohio University
> Athens, OH 45701
> 
> _______________________________________________
> LON-CAPA-admin mailing list
> LON-CAPA-admin at mail.lon-capa.org
> http://mail.lon-capa.org/mailman/listinfo/lon-capa-admin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.lon-capa.org/pipermail/lon-capa-admin/attachments/20111115/f6e96ddd/attachment.html>


More information about the LON-CAPA-admin mailing list