syspools

IDS11.10 UC2, AIX 5.3 Run the following query on syspools, and attached the partial result list. po_name "mt" occupied much of the memory. what "mt" means? what is the major jobs of "mt"? Thanks, Frank select po_name,po_freeamt, po_usedamt from syspools where po_class=2 order by 2 desc po_name po_freeamt po_usedamt mt 603422008 8610504 DDR 5735816 4655736 rsam 3929376 9718496 aio 1200672 9756128 global 944816 9839952 grouper 576600 377768 CDR 333288 97540632 36 84352 280192 37 76936 283512

>IDS11.10 UC2, AIX 5.3 > >Run the following query on syspools, and attached the partial result list. > >po_name "mt" occupied much of the memory. > >what "mt" means? what is the major jobs of "mt"? > >Thanks, Frank I belive the "mt" stands for Multi-Thread. That pool would be used for things related to the threading in the engine, like structures for conditions, mutexes, thread control blocks, etc... Probably a lot of other stuff as well that is required for the threading the engine performs. Jacques

Jacques, Thanks very much for the response! We are wondering if it can be reused for other purposes if needed. The concern is, we have total around 800M Virtual segment size, the "mt" occupied more than 600M( see below). We have had some "out of Memory" problems . It sounds lot better after we moved some memory from BUFFERPOOL to SHMVIRTSIZE, but the available Virtual segment size is getting smaller and smaller.... when we see the "mt" occupied so much there. Comments/advices are appreciated and welcome! Thanks, Frank IDS11.10 UC2, AIX 5.3 Pool Summary: name class addr totalsize freesize #allocfrag #freefrag mt V 904bc020 612032512 599064800 43018 10080 IBM Informix Dynamic Server Version 11.10.UC2 -- On-Line -- Up 23 days 00:52:02 -- 2120080 Kbytes Segment Summary: id key addr size ovhd class blkused blkfree 3145787 1382041603 30000000 1081344 7328 M 262 2 5242886 1382041601 40000000 1331019776 8023712 R* 324953 3 5242937 1382041602 90000000 838860800 4916408 V 193884 10916 Total: - - 2170961920 - - 519099 10921 (* segment locked in memory) On Wed, Jan 7, 2009 at 12:12 PM, JACQUES RENAUT <jrenaut@us.ibm.com> wrote: > >IDS11.10 UC2, AIX 5.3 > > > >Run the following query on syspools, and attached the partial result list. > > > >po_name "mt" occupied much of the memory. > > > >what "mt" means? what is the major jobs of "mt"? > > > >Thanks, Frank > > I belive the "mt" stands for Multi-Thread. That pool would be used for > things > related to the threading in the engine, like structures for conditions, > mutexes, thread control blocks, etc... Probably a lot of other stuff as > well > that is required for the threading the engine performs. > > Jacques > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > >

>Jacques, > >Thanks very much for the response! > >We are wondering if it can be reused for other purposes if needed. The >concern is, we have total around 800M Virtual segment size, the "mt" >occupied more than 600M( see below). We have had some "out of Memory" >problems . It sounds lot better after we moved some memory from BUFFERPOOL >to SHMVIRTSIZE, but the available Virtual segment size is getting smaller >and smaller.... when we see the "mt" occupied so much there. > >Comments/advices are appreciated and welcome! > >Thanks, >Frank > >IDS11.10 UC2, AIX 5.3 > >Pool Summary: >name class addr totalsize freesize #allocfrag #freefrag >mt V 904bc020 612032512 599064800 43018 10080 Frank, Once memory is assigned to a pool, it can not be reused for any other purpose while it's part of that pool. Most pools that the engine creates will drain free blocks (remove them from being assigned to that pool) automatically as the memory is freed. However, certain pools, like the mt pool, is not one of them. So at the time of your onstat output the mt pool is over 600mb, but almost all of it is free. You should be able to force free blocks of that pool back out to the engine for other virtual memory usage by running onmode -F. In general running onmode -F is best done at non-busy times as it goes through the entire list of pools draining free blocks from them, and it grabs some important memory mutexes to do so. This would block other threads from being able to access the pools while the onmode command is processing that pool. So you could see some temporary memory mutex/spinlock congestion while the onmode -F runs to completion. Jacques

Thank you very much, Jacques!! Frank On Wed, Jan 7, 2009 at 4:02 PM, JACQUES RENAUT <jrenaut@us.ibm.com> wrote: > >Jacques, > > > >Thanks very much for the response! > > > >We are wondering if it can be reused for other purposes if needed. The > >concern is, we have total around 800M Virtual segment size, the "mt" > >occupied more than 600M( see below). We have had some "out of Memory" > >problems . It sounds lot better after we moved some memory from BUFFERPOOL > >to SHMVIRTSIZE, but the available Virtual segment size is getting smaller > >and smaller.... when we see the "mt" occupied so much there. > > > >Comments/advices are appreciated and welcome! > > > >Thanks, > >Frank > > > >IDS11.10 UC2, AIX 5.3 > > > >Pool Summary: > >name class addr totalsize freesize #allocfrag #freefrag > >mt V 904bc020 612032512 599064800 43018 10080 > > Frank, > > Once memory is assigned to a pool, it can not be reused for any other > purpose > while it's part of that pool. Most pools that the engine creates will drain > free blocks (remove them from being assigned to that pool) automatically as > the memory is freed. However, certain pools, like the mt pool, is not one > of > them. So at the time of your onstat output the mt pool is over 600mb, but > almost all of it is free. You should be able to force free blocks of that > pool > back out to the engine for other virtual memory usage by running onmode -F. > In > general running onmode -F is best done at non-busy times as it goes through > the entire list of pools draining free blocks from them, and it grabs some > important memory mutexes to do so. This would block other threads from > being > able to access the pools while the onmode command is processing that pool. > So > you could see some temporary memory mutex/spinlock congestion while the > onmode> -F runs to completion. > > Jacques > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > >