<div dir="ltr">Hi Jennifer,<div><br></div><div>Thank you for the 'q mem' command...that has helped in seeing what you've described. I did some more testing with the 'flush' command and it does seem to work. However, I already 'clear' after each display yet memory continues to rise. Should all "mbufbuff" entries in the memory query disappear after a 'clear' command? If so, they aren't. I trimmed mbufbuff entries in the middle of each result below but they were identical in each case.</div><div><br></div><div>-Brandon</div><div><br></div><div>
<p class=""><span class="">ga-> q mem </span></p>
<p class=""><span class="">pos=0 ptr=0x5ef8580 len=7 type=setmpds </span></p>
<p class=""><span class="">pos=1 ptr=0x5ef8840 len=24 type=gxmbuf </span></p>
<p class=""><span class="">pos=2 ptr=0x7f3ca256c010 len=1000000 type=mbufbuff</span></p>
<p class=""><span class="">pos=3 ptr=0x7582a60 len=7 type=cmd </span></p>
<p class=""><span class="">pos=5 ptr=0x5f11090 len=23416 type=pfi </span></p>
<p class=""><span class="">pos=6 ptr=0x5f10020 len=57 type=mnam </span></p>
<p class=""><span class="">pos=7 ptr=0x5f10360 len=48 type=vals1 </span></p>
<p class=""><span class="">pos=8 ptr=0x5f103a0 len=48 type=vals1 </span></p>
<p class=""><span class="">pos=9 ptr=0x5f103e0 len=64 type=tvals5 </span></p>
<p class=""><span class="">pos=10 ptr=0x5f10430 len=80 type=vals2 </span></p>
<p class=""><span class="">pos=11 ptr=0x5f16c20 len=50505 type=pvar2 </span></p>
<p class=""><span class="">pos=12 ptr=0x5f0fbd0 len=48 type=evals3 </span></p>
<p class=""><span class="">pos=13 ptr=0x5f0fc10 len=60 type=ens5 </span></p>
<p class=""><span class="">pos=14 ptr=0x5f0fc60 len=40 type=g2indx </span></p>
<p class=""><span class="">pos=15 ptr=0x5f106d0 len=568 type=g2intpnt</span></p>
<p class=""><span class="">pos=16 ptr=0x5f23180 len=20024 type=rbuf1 </span></p>
<p class=""><span class="">pos=17 ptr=0x5f27fd0 len=20024 type=pbuf1 </span></p>
<p class=""><span class="">pos=18 ptr=0x5f2ce20 len=20024 type=ubuf1 </span></p>
<p class=""><span class="">pos=19 ptr=0x7f3c99c61010 len=11563860 type=ppi0 </span></p>
<p class=""><span class="">pos=20 ptr=0x7f3c98652010 len=23127720 type=ppf0 </span></p>
<p class=""><span class="">pos=21 ptr=0x7f3c97043010 len=23127720 type=ppf1 </span></p>
<p class=""><span class="">pos=22 ptr=0x7f3c95a34010 len=23127720 type=ppw </span></p>
<p class=""><span class="">pos=24 ptr=0x5f32d20 len=24 type=gxmbuf </span></p>
<p class=""><span class="">pos=25 ptr=0x69f5c80 len=1000000 type=mbufbuff</span></p>
<p class=""><span class="">pos=26 ptr=0x5f32590 len=24 type=gxmbuf </span></p>
<p class=""><span class="">pos=27 ptr=0x6e38ed0 len=1000000 type=mbufbuff</span></p>
<p class="">...</p>
<p class=""><span class="">pos=181 ptr=0x7b3ca90 len=24 type=gxmbuf </span></p>
<p class=""><span class="">pos=182 ptr=0xd2f2bb0 len=1000000 type=mbufbuff</span></p>
<p class=""><span class="">pos=183 ptr=0x7b3c240 len=24 type=gxmbuf </span></p>
<p class=""><span class="">pos=184 ptr=0xd3e6e00 len=1000000 type=mbufbuff</span></p>
<p class=""><span class="">ga-> clear</span></p>
<p class=""><span class="">ga-> q mem</span></p>
<p class=""><span class="">pos=0 ptr=0x5ef8580 len=7 type=setmpds </span></p>
<p class=""><span class="">pos=1 ptr=0x5ef8840 len=24 type=gxmbuf </span></p>
<p class=""><span class="">pos=2 ptr=0x7f3ca256c010 len=1000000 type=mbufbuff</span></p>
<p class=""><span class="">pos=3 ptr=0x7b3c330 len=7 type=cmd </span></p>
<p class=""><span class="">pos=5 ptr=0x5f11090 len=23416 type=pfi </span></p>
<p class=""><span class="">pos=6 ptr=0x5f10020 len=57 type=mnam </span></p>
<p class=""><span class="">pos=7 ptr=0x5f10360 len=48 type=vals1 </span></p>
<p class=""><span class="">pos=8 ptr=0x5f103a0 len=48 type=vals1 </span></p>
<p class=""><span class="">pos=9 ptr=0x5f103e0 len=64 type=tvals5 </span></p>
<p class=""><span class="">pos=10 ptr=0x5f10430 len=80 type=vals2 </span></p>
<p class=""><span class="">pos=11 ptr=0x5f16c20 len=50505 type=pvar2 </span></p>
<p class=""><span class="">pos=12 ptr=0x5f0fbd0 len=48 type=evals3 </span></p>
<p class=""><span class="">pos=13 ptr=0x5f0fc10 len=60 type=ens5 </span></p>
<p class=""><span class="">pos=14 ptr=0x5f0fc60 len=40 type=g2indx </span></p>
<p class=""><span class="">pos=15 ptr=0x5f106d0 len=568 type=g2intpnt</span></p>
<p class=""><span class="">pos=16 ptr=0x5f23180 len=20024 type=rbuf1 </span></p>
<p class=""><span class="">pos=17 ptr=0x5f27fd0 len=20024 type=pbuf1 </span></p>
<p class=""><span class="">pos=18 ptr=0x5f2ce20 len=20024 type=ubuf1 </span></p>
<p class=""><span class="">pos=19 ptr=0x7f3c99c61010 len=11563860 type=ppi0 </span></p>
<p class=""><span class="">pos=20 ptr=0x7f3c98652010 len=23127720 type=ppf0 </span></p>
<p class=""><span class="">pos=21 ptr=0x7f3c97043010 len=23127720 type=ppf1 </span></p>
<p class=""><span class="">pos=22 ptr=0x7f3c95a34010 len=23127720 type=ppw </span></p>
<p class=""><span class="">pos=24 ptr=0x5f32d20 len=24 type=gxmbuf </span></p>
<p class=""><span class="">pos=25 ptr=0x69f5c80 len=1000000 type=mbufbuff</span></p>
<p class=""><span class="">pos=26 ptr=0x5f32590 len=24 type=gxmbuf </span></p>
<p class=""><span class="">pos=27 ptr=0x6e38ed0 len=1000000 type=mbufbuff</span></p>
<p class="">.........</p>
<p class=""><span class="">pos=181 ptr=0x7b3ca90 len=24 type=gxmbuf </span></p>
<p class=""><span class="">pos=182 ptr=0xd2f2bb0 len=1000000 type=mbufbuff</span></p>
<p class=""><span class="">pos=183 ptr=0x7b3c240 len=24 type=gxmbuf </span></p>
<p class=""><span class="">pos=184 ptr=0xd3e6e00 len=1000000 type=mbufbuff</span></p></div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 19, 2015 at 12:00 PM, <span dir="ltr"><<a href="mailto:gradsusr-request@gradsusr.org" target="_blank">gradsusr-request@gradsusr.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Send gradsusr mailing list submissions to<br>
<a href="mailto:gradsusr@gradsusr.org">gradsusr@gradsusr.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://gradsusr.org/mailman/listinfo/gradsusr" target="_blank">http://gradsusr.org/mailman/listinfo/gradsusr</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:gradsusr-request@gradsusr.org">gradsusr-request@gradsusr.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:gradsusr-owner@gradsusr.org">gradsusr-owner@gradsusr.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of gradsusr digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: 'flush' command does not work (Jennifer Adams)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Thu, 19 Mar 2015 10:40:22 -0400<br>
From: Jennifer Adams <<a href="mailto:jma@cola.iges.org">jma@cola.iges.org</a>><br>
Subject: Re: [gradsusr] 'flush' command does not work<br>
To: GrADS Users Forum <<a href="mailto:gradsusr@gradsusr.org">gradsusr@gradsusr.org</a>><br>
Message-ID: <<a href="mailto:DCBDC890-E502-4901-8579-949C454BE3DF@cola.iges.org">DCBDC890-E502-4901-8579-949C454BE3DF@cola.iges.org</a>><br>
Content-Type: text/plain; charset="windows-1252"<br>
<br>
Hi, Brandon ?<br>
There is some code built into GrADS to help us developers track memory use. It is accessible with the undocumented ?q mem? command. We keep a list of memory blocks that have been allocated (not all, but most), and ?q mem? prints the list. The output from ?q mem? includes the address, the size, and the type of the memory block ? the type is really a name that makes it convenient for finding the place in the code where that block was allocated, and also for knowing what that block of memory is for. If you compare the output from ?q mem? on startup and then after opening a file, and then again after displaying a variable, you will get a sense for what is responsible for the size of your executable as it is running. Items associated with the grib2 cache have names g2buff1, anchor, g2fld1, and g2mask1. If you invoke ?flush? and then check ?q mem? you can see immediately whether or not the flush command has done its job.<br>
<br>
I tried a sequence of commands similar to what you showed using the 0.25-degree GFS output, and could not see any problems with ?flush?. (Aside ? thanks for teaching me about ?pgrep?!) I suspect that the memory use in your case is not due to an ever-increasing grib2 cache, but to increasing allocations of metabuffer blocks (named mbufbuff in the ?q mem? output). The metabuffer contains all the instructions for drawing a graphic, and if your graphic is very detailed with shaded plots and contour overlays, the use of shapefiles or the basemap script, or if it contains many panels, then the metabuffer expands accordingly and additional blocks are allocated, and you will see lots of ?mbufbuff? entries when checking ?q mem?. The metabuffer blocks are not released on ?reinit? ? we assume if you needed them once, you may need them again, so we leave them chained up, ready to be re-used. A ?clear? command will flush the metabuffer and reset the pointer to the beginning of the first !<br>
block; it may be that all your script needs is a ?clear? at the beginning of each loop.<br>
<br>
?Jennifer<br>
<br>
On Mar 19, 2015, at 2:01 AM, Brandon Schmidt <<a href="mailto:admin@wilmingtonwx.com">admin@wilmingtonwx.com</a>> wrote:<br>
<br>
> Through extensive debugging, I've found that the GrADS flush function does not work properly. This first came to my realization when I began to automate my GrADS scripts. Each script processes a single hour by downloading a GRIB file, creating a control file, opening the control file, and displaying/outputting the needed data. The scripts initialize with right around 100 MB of memory but through execution, they can rack up as much as 1.4 GB. Of course when processing multiple hours, this slowed my server to a crawl and in some cases caused crashes (especially with high-res HRRR data for example). Anyway, I traced the excessive memory usage to the display commands. I am aware that with each display command, the displayed variable is stored to the GrADS GRIB2 cache to eliminate further decompression overhead. This is all well given the flush command but it seems to only work half of the time. One can easily see this by noting the initial memory, displaying a few variables, f!<br>
lushing, and then noting the final memory. Seemingly randomly, the memory following a flush will slowly creep up. The behavior memory-wise that I expected from flush can only be obtained with reinit but calling that function thousands of times is not an option. Any ideas as to a work-around or fix? I am using the latest 2.1.a3 version. The first flush below works but the second does not.<br>
><br>
> -Brandon<br>
><br>
> ---------------------------------------------------------------------------------<br>
> ga-> !pgrep grads<br>
><br>
> 7879<br>
><br>
> ga-> ! ps -p 7879 -o %mem,size<br>
><br>
> %MEM SZ<br>
><br>
> 1.3 87276<br>
><br>
> ga-> d tmp2m<br>
><br>
> Notice: Automatic Grid Interpolation Taking Place<br>
><br>
> Contouring: 255 to 305 interval 5<br>
><br>
> ga-> ! ps -p 7879 -o %mem,size<br>
><br>
> %MEM SZ<br>
><br>
> 1.7 108024<br>
><br>
> ga-> d capesfc<br>
><br>
> Notice: Automatic Grid Interpolation Taking Place<br>
><br>
> Contouring: 0 to 3500 interval 500<br>
><br>
> ga-> set lat 50 70<br>
><br>
> LAT set to 50 70<br>
><br>
> ga-> d gustsfc<br>
><br>
> Notice: Automatic Grid Interpolation Taking Place<br>
><br>
> Contouring: 1 to 13 interval 1<br>
><br>
> ga-> set lat 20 90<br>
><br>
> LAT set to 20 90<br>
><br>
> ga-> d tmp2m<br>
><br>
> Notice: Automatic Grid Interpolation Taking Place<br>
><br>
> Contouring: 255 to 305 interval 5<br>
><br>
> ga-> flush<br>
><br>
> grib2 cache cleared<br>
><br>
> ga-> ! ps -p 7879 -o %mem,size<br>
><br>
> %MEM SZ<br>
><br>
> 1.7 108024<br>
><br>
> ga-> d tmp2m<br>
><br>
> Notice: Automatic Grid Interpolation Taking Place<br>
><br>
> Contouring: 255 to 305 interval 5<br>
><br>
> ga-> ! ps -p 7879 -o %mem,size<br>
><br>
> %MEM SZ<br>
><br>
> 1.9 122908<br>
><br>
> ga-> flush<br>
><br>
> grib2 cache cleared<br>
><br>
> ga-> ! ps -p 7879 -o %mem,size<br>
><br>
> %MEM SZ<br>
><br>
> 1.9 122908<br>
><br>
> ga-><br>
><br>
> _______________________________________________<br>
> gradsusr mailing list<br>
> <a href="mailto:gradsusr@gradsusr.org">gradsusr@gradsusr.org</a><br>
> <a href="http://gradsusr.org/mailman/listinfo/gradsusr" target="_blank">http://gradsusr.org/mailman/listinfo/gradsusr</a><br>
<br>
--<br>
Jennifer M. Adams<br>
Center for Ocean-Land-Atmosphere Studies (COLA)<br>
111 Research Hall, Mail Stop 2B3<br>
George Mason University<br>
4400 University Drive<br>
Fairfax, VA 22030<br>
<br>
<br>
<br>
<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <a href="http://gradsusr.org/pipermail/gradsusr/attachments/20150319/82b935a5/attachment-0001.html" target="_blank">http://gradsusr.org/pipermail/gradsusr/attachments/20150319/82b935a5/attachment-0001.html</a><br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
gradsusr mailing list<br>
<a href="mailto:gradsusr@gradsusr.org">gradsusr@gradsusr.org</a><br>
<a href="http://gradsusr.org/mailman/listinfo/gradsusr" target="_blank">http://gradsusr.org/mailman/listinfo/gradsusr</a><br>
<br>
<br>
End of gradsusr Digest, Vol 61, Issue 23<br>
****************************************<br>
</blockquote></div><br></div></div></div>