progress db - Openedge 10.2B08 lruskips overhead -

i'm writing business case implementing lruskips parameter. know benefits (and sizeable). don't know performance overhead in terms of memory etc should consider downsides. need balanced viewpoint after all! openedge 10.2b08 various flavours of windows have not been patched linux.

the feature eliminates overhead avoiding housekeeping associated maintaining lru chain. using not add memory requirements , reduces cpu consumption.

instead of moving block head of lru chain every time referenced every x references. rather evicting block absolutely "least used" block "probably not used" evicted.

the potential downside there could, theoretically, perverse case setting high might result in poor eviction decisions. iow "probably" part of things turns out untrue because aren't checking enough (you have converted -b management fifo queue).

for instance, setting 1000000 -b of 1000 might not smart. (but bigger issue probably-b 1000)

suppose did (set -lruskips 1000000 -b 1000) , application has mix of "normal" access along few background processes doing sort of sequential scan support reporting.

the reporting stuff going read lots of data looks @ once (or few times). data going placed @ mru end of queue , move towards lru end new data read.

even though being accessed working set of "normal" data pushed lru end because access counter update being skipped. smallish -b going fall off end pretty , evicted. , next access cause io occur , cycle restart.

the higher set -lruskips more sensitive become sort of thing. -lruskips 10 eliminate 90% of lru housekeeping , should very, low risk setting. -lruskips 100 eliminate 99% of housekeeping , should still awfully low risk (unless -b crazy small). unless have special set of circumstances setting higher 100 seems pointless. "diminishing returns" , possibly pushing luck vis vis perverse outcomes.