 | |
timestamp for peak memory usage
comp.databases.ibm-db2 comp.databases.ibm-db2
 |
| | Thread Tools | Display Modes |
#1
 
| |||
| |||
|
timestamp for peak memory usage -
10-20-2010
, 03:35 PM
#2
| |||
| |||
|
|
DB2 V9.7/AIX, Is there a place to get the timestamp of when wee hit peak memory usage for an instance/database? For instance, I can see the PEAK_PARTITION_MEM value here but want to know when it reached this HWM: db2 "SELECT * FROM TABLE (SYSPROC.ADMIN_GET_DBP_MEM_USAGE()) as t" DBPARTITIONNUM MAX_PARTITION_MEM * *CURRENT_PARTITION_MEM PEAK_PARTITION_MEM -------------- -------------------- --------------------- -------------------- * * * * * * *0 * * * * *14210637824 * * * * * *3440771072 7687176192 * 1 record(s) selected. |
you want to narrow down when this happens in the future, you would
need to run this query periodically and keep track of the time each
query was issued ('db2pd -dbptnmem' will also report this, including a
timestamp, with less impact on the engine if you don't want to run
this query too frequently).
If your database(s) have remained activated for the entire time, you
can try to narrow down what may have led up to the HWM.... If you run
that db2pd command, it will show you the individual HWMs for several
different memory regions. If you have multiple databases configured,
this could narrow down the bulk of the HWM to one particular database,
and from there, you could run 'db2pd -db <dbname> -mempools', which
can further narrow down which particularly memory pool/heap may have
contributed significantly to this HWM. With that information, you
might be able to track down the HWM to a few particular operations....
for instance, if you see the utility heap is currently very small, but
had a very large HWM, then the overall instance_memory HWM may have
been a result of some operations involving the utility heap (backup,
restore, load, etc).
Cheers,
Liam.
#3
| |||
| |||
|
|
On Oct 20, 4:35*pm, shorti <lbrya... (AT) juno (DOT) com> wrote: DB2 V9.7/AIX, Is there a place to get the timestamp of when wee hit peak memory usage for an instance/database? For instance, I can see the PEAK_PARTITION_MEM value here but want to know when it reached this HWM: db2 "SELECT * FROM TABLE (SYSPROC.ADMIN_GET_DBP_MEM_USAGE()) as t" DBPARTITIONNUM MAX_PARTITION_MEM * *CURRENT_PARTITION_MEM PEAK_PARTITION_MEM -------------- -------------------- --------------------- -------------------- * * * * * * *0 * * * * *14210637824 * * ** * *3440771072 7687176192 * 1 record(s) selected. Unfortunately, timestamps for this type of event are not gathered. *If you want to narrow down when this happens in the future, you would need to run this query periodically and keep track of the time each query was issued ('db2pd -dbptnmem' will also report this, including a timestamp, with less impact on the engine if you don't want to run this query too frequently). If your database(s) have remained activated for the entire time, you can try to narrow down what may have led up to the HWM.... *If you run that db2pd command, it will show you the individual HWMs for several different memory regions. *If you have multiple databases configured, this could narrow down the bulk of the HWM to one particular database, and from there, you could run 'db2pd -db <dbname> -mempools', which can further narrow down which particularly memory pool/heap may have contributed significantly to this HWM. *With that information, you might be able to track down the HWM to a few particular operations.... for instance, if you see the utility heap is currently very small, but had a very large HWM, then the overall instance_memory HWM may have been a result of some operations involving the utility heap (backup, restore, load, etc). Cheers, Liam. |
Did you check the STMM logs? You should be able to find "Current DBMem
size" every few minutes.
Kind regards,
Frederik
#4
| |||
| |||
|
|
On Oct 21, 3:52*pm, Liam <lemonfin... (AT) gmail (DOT) com> wrote: On Oct 20, 4:35*pm, shorti <lbrya... (AT) juno (DOT) com> wrote: DB2 V9.7/AIX, Is there a place to get the timestamp of when wee hit peak memory usage for an instance/database? For instance, I can see the PEAK_PARTITION_MEM value here but want to know when it reached this HWM: db2 "SELECT * FROM TABLE (SYSPROC.ADMIN_GET_DBP_MEM_USAGE()) as t" DBPARTITIONNUM MAX_PARTITION_MEM * *CURRENT_PARTITION_MEM PEAK_PARTITION_MEM -------------- -------------------- --------------------- -------------------- * * * * * * *0 * * * * *14210637824 * * * * * *3440771072 7687176192 * 1 record(s) selected. Unfortunately, timestamps for this type of event are not gathered. *If you want to narrow down when this happens in the future, you would need to run this query periodically and keep track of the time each query was issued ('db2pd -dbptnmem' will also report this, including a timestamp, with less impact on the engine if you don't want to run this query too frequently). If your database(s) have remained activated for the entire time, you can try to narrow down what may have led up to the HWM.... *If you run that db2pd command, it will show you the individual HWMs for several different memory regions. *If you have multiple databases configured, this could narrow down the bulk of the HWM to one particular database, and from there, you could run 'db2pd -db <dbname> -mempools', which can further narrow down which particularly memory pool/heap may have contributed significantly to this HWM. *With that information, you might be able to track down the HWM to a few particular operations.... for instance, if you see the utility heap is currently very small, but had a very large HWM, then the overall instance_memory HWM may have been a result of some operations involving the utility heap (backup, restore, load, etc). Cheers, Liam. Hi, Did you check the STMM logs? You should be able to find "Current DBMem size" every few minutes. Kind regards, Frederik |
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.