memory thread ... VIP status ?
Mark saw the internal "memory" thread repeatedly sitting at the top of a long ready queue on a busy 11.70.FC7W3 instance (16 CPU VPs, AIX Power7, 1000+ users) and worried it was blocking sqlexec threads. John Miller explained the thread only runs when the VP memory cache has excess memory to return to the global free list, suggesting the cache was too small to reach steady state; Ben noted the STATIC/DYNAMIC cache option needs fix IC95684. Jacques suggested checking actual CPU time via onstat -g cpu, and Mark confirmed the thread ran often but consumed few cycles, so the concern was dropped (no tuning change made).
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
11.70.FC7W3. Yesterday I was profiling our clients very busy instance where the ready queue was getting very long at times. What I did notice was that the memory thread was consistently getting back on top of the ready queue no matter what while it was long. It would vanish momentarily (into a run state I assume ) then pop back in "ready" but back on top. To me this seems to be having a blocking effect on the other cpuvp's ability to run. FYI there are 16 cpuvps allocated on a 8x4 AIX Power 7 server, 1000+ users. Application is also on the same server. anyone aware of any issues regarding this behavior ? I am bit reluctant to turn off the vp_memory_cache (I am aware of the memory issue regarding the vpcache but so far memory usage is fine). Mark
What thread name specifically? Art Art S. Kagel, President and Principal Consultant ASK Database Management www.askdbmgt.com Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Wed, Mar 4, 2015 at 2:46 PM, MARK JALKIEWICZ <mark.jalkiewicz@verizon.net > wrote: > 11.70.FC7W3. > > Yesterday I was profiling our clients very busy instance where the ready > queue > was getting very long at times. What I did notice was that the memory > thread > was consistently getting back on top of the ready queue no matter what > while > it was long. It would vanish momentarily (into a run state I assume ) then > pop > back in "ready" but back on top. To me this seems to be having a blocking > effect on the other cpuvp's ability to run. FYI there are 16 cpuvps > allocated > on a 8x4 AIX Power 7 server, 1000+ users. Application is also on the same > server. > > anyone aware of any issues regarding this behavior ? > > I am bit reluctant to turn off the vp_memory_cache (I am aware of the > memory > issue regarding the vpcache but so far memory usage is fine). > > Mark > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --089e013a114ed1a85e05107c969e
memory. see below. Ready threads: tid tcb rstcb prty status vp-class name 137 7000001c4ded0f0 7000001c1feffe8 3 ready 12cpu* memory 232 7000001c8ac2028 7000001c8484b70 1 ready 24cpu sqlexec 237 7000001c8c935a0 7000001c8487488 1 ready 14cpu sqlexec 241 7000001c8e0a620 7000001c8489568 1 ready 15cpu sqlexec 263 7000001c9622028 7000001c8494a38 1 ready 16cpu sqlexec 599 7000001cc104028 7000001ceef9418 1 ready 13cpu sqlexec 651 7000001d00b0b80 7000001cef0f580 1 ready 1cpu sqlexec 1199679 7000001da121028 7000002027257b0 1 ready 9cpu sqlexec 2816548 700000211907ae8 7000001c849ee98 1 ready 21cpu sqlexec
What this generally means is that you are freeing more memory than can fit into you vp cache. The memory thread runs to remove excessive memory out of the vp cache to return to the global free memory list. The "memory" thread only runs when at least one bucket in the vpcache has excess memory to cleaned. I am not sure if you are running in static mode or dynamic mode. My guess is your cache is so small that you are not able to maintain a steady state. John F. Miller III STSM, Lead Architect miller3@us.ibm.com 503-747-1366 IBM Informix Dynamic Server (IDS) ids-bounces@iiug.org wrote on 03/04/2015 02:28:15 PM: > From: "MARK JALKIEWICZ" <mark.jalkiewicz@verizon.net> > To: ids@iiug.org > Date: 03/04/2015 02:30 PM > Subject: Re: memory thread ... VIP status ? [34780] > Sent by: ids-bounces@iiug.org > > memory. see below. > > Ready threads: > tid tcb rstcb prty status vp-class name > 137 7000001c4ded0f0 7000001c1feffe8 3 ready 12cpu* memory > > 232 7000001c8ac2028 7000001c8484b70 1 ready 24cpu sqlexec > 237 7000001c8c935a0 7000001c8487488 1 ready 14cpu sqlexec > 241 7000001c8e0a620 7000001c8489568 1 ready 15cpu sqlexec > 263 7000001c9622028 7000001c8494a38 1 ready 16cpu sqlexec > 599 7000001cc104028 7000001ceef9418 1 ready 13cpu sqlexec > 651 7000001d00b0b80 7000001cef0f580 1 ready 1cpu sqlexec > 1199679 7000001da121028 7000002027257b0 1 ready 9cpu sqlexec > 2816548 700000211907ae8 7000001c849ee98 1 ready 21cpu sqlexec > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. >
Hi John, I am pretty sure that unless Mark has fix IC95684 by special build, 11.70.FC7W3 does not offer the choice of STATIC or DYNAMIC mode. He will be using DYNAMIC mode by default. Ben.
Ben, Your correct, I would need to upgrade/special build. I can always turn off the vp_memory_cache or increase it's size but that looks to be a trial and error process in gauging a proper sizing .I am also concerned if this thread can affect overall performance if/when it runs and the instance gets very busy which it can do at times due to the nature of the business. Thanks, Mark
Original post:
Ben,
Your correct, I would need to upgrade/special build. I can always turn off the
vp_memory_cache or increase it's size but that looks to be a trial and error
process in gauging a proper sizing .I am also concerned if this thread can
affect overall performance if/when it runs and the instance gets very busy
which it can do at times due to the nature of the business.
Thanks,
Mark
Response:
Well, you could use onstat -g cpu output to see how much cpu time the memory
thread is getting over a time interval. I suspect that while you might see it
running often, it is possible that it's not accumulating a lot of cpu cycles.
Jacques Renaut
IBM Informix Advanced Support
APD Team
Jacques,
pretty much spot on... it does run often but as you state does not consume a
lot of cycles.
this is over 60 seconds:
iter 'onstat -g cpu | grep memory ' 60
137 memory 8cpu* 03/05 12:50:11 378.2938 66475974 sle
eping forever
137 memory 8cpu* 03/05 12:51:11 378.4646 66507210 sle
eping forever
I guess this put this concern to rest.
Thanks,
Mark