Re: ARC Memory Usage analysis - Mailing list pgsql-hackers
From | Jan Wieck |
---|---|
Subject | Re: ARC Memory Usage analysis |
Date | |
Msg-id | 41796115.2020501@Yahoo.com Whole thread Raw |
In response to | ARC Memory Usage analysis (Simon Riggs <simon@2ndquadrant.com>) |
Responses |
Re: ARC Memory Usage analysis
Re: [PATCHES] ARC Memory Usage analysis Re: ARC Memory Usage analysis |
List | pgsql-hackers |
On 10/22/2004 2:50 PM, Simon Riggs wrote: > I've been using the ARC debug options to analyse memory usage on the > PostgreSQL 8.0 server. This is a precursor to more complex performance > analysis work on the OSDL test suite. > > I've simplified some of the ARC reporting into a single log line, which > is enclosed here as a patch on freelist.c. This includes reporting of: > - the total memory in use, which wasn't previously reported > - the cache hit ratio, which was slightly incorrectly calculated > - a useful-ish value for looking at the "B" lists in ARC > (This is a patch against cvstip, but I'm not sure whether this has > potential for inclusion in 8.0...) > > The total memory in use is useful because it allows you to tell whether > shared_buffers is set too high. If it is set too high, then memory usage > will continue to grow slowly up to the max, without any corresponding > increase in cache hit ratio. If shared_buffers is too small, then memory > usage will climb quickly and linearly to its maximum. > > The last one I've called "turbulence" in an attempt to ascribe some > useful meaning to B1/B2 hits - I've tried a few other measures though > without much success. Turbulence is the hit ratio of B1+B2 lists added > together. By observation, this is zero when ARC gives smooth operation, > and goes above zero otherwise. Typically, turbulence occurs when > shared_buffers is too small for the working set of the database/workload > combination and ARC repeatedly re-balances the lengths of T1/T2 as a > result of "near-misses" on the B1/B2 lists. Turbulence doesn't usually > cut in until the cache is fully utilized, so there is usually some delay > after startup. > > We also recently discussed that I would add some further memory analysis > features for 8.1, so I've been trying to figure out how. > > The idea that B1, B2 represent something really useful doesn't seem to > have been borne out - though I'm open to persuasion there. > > I originally envisaged a "shadow list" operating in extension of the > main ARC list. This will require some re-coding, since the variables and > macros are all hard-coded to a single set of lists. No complaints, just > it will take a little longer than we all thought (for me, that is...) > > My proposal is to alter the code to allow an array of memory linked > lists. The actual list would be [0] - other additional lists would be > created dynamically as required i.e. not using IFDEFs, since I want this > to be controlled by a SIGHUP GUC to allow on-site tuning, not just lab > work. This will then allow reporting against the additional lists, so > that cache hit ratios can be seen with various other "prototype" > shared_buffer settings. All the existing lists live in shared memory, so that dynamic approach suffers from the fact that the memory has to be allocated during ipc_init. What do you think about my other theory to make C actually 2x effective cache size and NOT to keep T1 in shared buffers but to assume T1 lives in the OS buffer cache? Jan > > Any thoughts? > > > > ------------------------------------------------------------------------ > > Index: freelist.c > =================================================================== > RCS file: /projects/cvsroot/pgsql/src/backend/storage/buffer/freelist.c,v > retrieving revision 1.48 > diff -d -c -r1.48 freelist.c > *** freelist.c 16 Sep 2004 16:58:31 -0000 1.48 > --- freelist.c 22 Oct 2004 18:15:38 -0000 > *************** > *** 126,131 **** > --- 126,133 ---- > if (StrategyControl->stat_report + DebugSharedBuffers < now) > { > long all_hit, > + buf_used, > + b_hit, > b1_hit, > t1_hit, > t2_hit, > *************** > *** 155,161 **** > } > > if (StrategyControl->num_lookup == 0) > ! all_hit = b1_hit = t1_hit = t2_hit = b2_hit = 0; > else > { > b1_hit = (StrategyControl->num_hit[STRAT_LIST_B1] * 100 / > --- 157,163 ---- > } > > if (StrategyControl->num_lookup == 0) > ! all_hit = buf_used = b_hit = b1_hit = t1_hit = t2_hit = b2_hit = 0; > else > { > b1_hit = (StrategyControl->num_hit[STRAT_LIST_B1] * 100 / > *************** > *** 166,181 **** > StrategyControl->num_lookup); > b2_hit = (StrategyControl->num_hit[STRAT_LIST_B2] * 100 / > StrategyControl->num_lookup); > ! all_hit = b1_hit + t1_hit + t2_hit + b2_hit; > } > > errcxtold = error_context_stack; > error_context_stack = NULL; > ! elog(DEBUG1, "ARC T1target=%5d B1len=%5d T1len=%5d T2len=%5d B2len=%5d", > T1_TARGET, B1_LENGTH, T1_LENGTH, T2_LENGTH, B2_LENGTH); > ! elog(DEBUG1, "ARC total =%4ld%% B1hit=%4ld%% T1hit=%4ld%% T2hit=%4ld%% B2hit=%4ld%%", > all_hit, b1_hit, t1_hit, t2_hit, b2_hit); > ! elog(DEBUG1, "ARC clean buffers at LRU T1= %5d T2= %5d", > t1_clean, t2_clean); > error_context_stack = errcxtold; > > --- 168,187 ---- > StrategyControl->num_lookup); > b2_hit = (StrategyControl->num_hit[STRAT_LIST_B2] * 100 / > StrategyControl->num_lookup); > ! all_hit = t1_hit + t2_hit; > ! b_hit = b1_hit + b2_hit; > ! buf_used = T1_LENGTH + T2_LENGTH; > } > > errcxtold = error_context_stack; > error_context_stack = NULL; > ! elog(DEBUG1, "shared_buffers used=%8ld cache hits=%4ld%% turbulence=%4ld%%", > ! buf_used, all_hit, b_hit); > ! elog(DEBUG2, "ARC T1target=%5d B1len=%5d T1len=%5d T2len=%5d B2len=%5d", > T1_TARGET, B1_LENGTH, T1_LENGTH, T2_LENGTH, B2_LENGTH); > ! elog(DEBUG2, "ARC total =%4ld%% B1hit=%4ld%% T1hit=%4ld%% T2hit=%4ld%% B2hit=%4ld%%", > all_hit, b1_hit, t1_hit, t2_hit, b2_hit); > ! elog(DEBUG2, "ARC clean buffers at LRU T1= %5d T2= %5d", > t1_clean, t2_clean); > error_context_stack = errcxtold; > > > > ------------------------------------------------------------------------ > > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
pgsql-hackers by date: