[OPEN-ILS-GENERAL] Client 2.3.0 grabbing and not releasing memory

Mon Dec 3 12:22:44 EST 2012

Hi Bob,

Unfortunately this is not the first time I've heard of issues with 
Evergreen 2.3+ and memory management.

Previously, memory problems had been reported sporadically even while we 
were on 2.0, but since our upgrade to 2.3 the number of reports from 
libraries has jumped significantly.  We're still attempting to replicate 
/ look for the source of the problem, but it seems (from stories 
reported) that higher circulating library PCs are hitting memory issues 
sooner than other departments. Alternatively, we've observed that other 
departments in the libraries tend to close out of Evergreen on a more 
regular basis and doing so sometimes resets Evergreen's memory usage 
down to a proper level.  At present time, we've asked libraries affected 
to institute some sort of regular restarting process to their workflows 
to try keeping usage down, but it is definitely still a problem.  It's 
also affecting only a small subset of machines in the libraries, so only 
1 or 2 circ machines break down while the others are just fine.

Curious to hear from other Evergreen systems running 2.3 (or greater) 
experiencing issues, but if we haven't already I think it's time we 
filed an official Evergreen bug on the subject to track 
discussion/troubleshooting efforts.

-- Ben

On 12/03/2012 11:38 AM, Bob Neeper wrote:
> Our two front desk CIRC  PC's are:
> Windows XP-Pro 32bit Core2 Duo E4600, 2.4GHz,  1024MB PC2-5300 SDRAM,  
> 80gb 7200RPM HD
> Purchased August 2008
> They  worked fine with the previous Evergreen version.
>
> The consortium was upgraded to version 2.3.0 (client also) November 
> 18, 2012
> Staff has been complaining they need to reboot the CIRC PC's as they 
> get slow, stop etc.
>
> Not being able to talk my way out, I started observing the problem.
>
> Watching Windows Task Manager, the Evergreen.exe process is not 
> releasing memory.
> At one point it had grabbed over 650mb of ram on our East CIRC
>
> A simple log in /out test showed the client kept grabbing large chunks 
> of ram.
>
> Also learned another COOL library is having the same problem with 
> their XP PC's.
>
> It was suggested to try the next client 2.3.1 which I put on a third 
> PC to test.
> This PC was recently rebuilt  and not yet in service.
> Running the same log in /our test, produced the same memory grab.
>
> This morning I observed another creeping memory problem in a static 
> situation.
>
> So I ran the same tests on a Windows7 PC for comparison.
> PC is i5-650 3.2GHz 4096MB PC3-10600 SDRAM 640GB 7200RPM HD
>
> Simple Log in / out test
> 22,404k  Opened client login screen
> 52,272k After login and main screen opened
> 28,140k After Clicking on X to close main screen
> 49,448k After Clicking log off
> 61,412k After log in and main screen opened again
> 59,024k After Clicking on X to close main screen
> 59,028k After Clicking log off
> 71,176k After log in and main screen opened again
> 68,268k After Clicking on X to close main screen
> 68,288k After Clicking log off
> 79,752k After log in and main screen opened again
>
> Simple Static test.
> Clicked checkout on tab1
> Entered patron card number and clicked submit
> Clicked + for new tab and clicked Check In
> Clicked + for new tab and clicked Item Status
> Made tab2 'Item Check In' active and watched the Task Manager
> 114,240k at 09:20 AM and started climbing
> 158,832k at 10:08 AM
> 126,244k at 10:15 AM Went down since last check
> 140,060k at 10:24 AM
> 150,300k at 10:31 AM
> 154,764k at 10:33 AM
> 164,732k at 10:40 AM
> 120,068k at 10:47 AM Went down since last check
> 153,872k at 11:07 AM
>
> Two main XP CIRC's, during normal check in / out use this morning
> West CIRC  East CIRC
> 326,280k   207,400k   at 10:45 AM
> 343,720k   258,304k   at 10:56 AM
> 379,300k   300,676k   at 11:07 AM
>
> Cataloging PC from yesterday (Same specs as Windows 7 PC)
> 11/30/12 09:44    327,900k
> 11/30/12 12:16    340,256k
> 11/30/12 05:21    427,412k
>
> The only solution so far has been to completely exit the client many, 
> many times during the day.
> Our director said Saturday, the East CIRC (Has the most activity) 
> client took so much ram he had to kill the process.
>
> Suggestions ?
>
> -- 
> -- 
> Email Signature
> R. W. (Bob) Neeper
> Community Library  <http://sunbury.cool-cat.org>
> 44 Burrer Dr.Map  <http://maps.google.com/maps?q=40.243961,+-82.863007>
> Sunbury, Oh 43074
> Tel:  (740)-965-3901
>
> cool-cat.org  <http://info.cool-cat.org>

-- 
Benjamin Shum
Open Source Software Coordinator
Bibliomation, Inc.
32 Crest Road
Middlebury, CT 06762
203-577-4070, ext. 113

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20121203/c5d7e1ed/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 7840 bytes
Desc: not available
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20121203/c5d7e1ed/attachment.jpeg>