FSR – frustrating summary records

Rob Lambert, NIKHEF Core Soft, 10th October 2012 1

FSR – frustrating summary records

Update

R. Lambert

file

^

Possible Solution


10,000 FSRs Sparse Trees in TES

ROOT can’t handle sparse trees

Sparse Trees Persisted

ROOT Tree used

Fixing any of these will fix FSRs for good

8. Get sparse trees in Root to work properly• Have basket size and optimization tuneable tree-by-tree• Markus realized this is possible in LHCb code

• Available in head or Online/RootCnv … let’s try it …

Two Parameters Buffer:

Reserved memory for each leaf in the Tree

Basket: Supposed sizes of

all the leaves


Test Cases


A B

Lxplus 135Only me using itMy code on local diskLHCb code on cvmfsWrite to local diskRead from Castor

Verified stability of CPU/Vmem

CPU : 10%Vmem: 0.5%File size: 0%

MC Filtered

40 FSRs, 7 levels

Real Data

13475 FSRs, 4 levels

Buffer


A B

Buffer


Original RootCnv

A B

Buffer


Markus/Ivan optimized

A B

Buffer


Suggested optimum

A B

Basket


Completelynot relevantA B

Only minor improvements possible!

Results


SetupProject DaVinci v32r2p1time gaudirun.py ~rlambert/public/forMarkus/fsrMemLeak/options.py#100 files with one event each, but 13475 FSRs in total

Version Time (usr+sys) / s VMEM / MiB File Size / MiBOld RootCnv 2834 2209 18.7

Markus/Ivan 2620 1303 18.7

Rob 1942 1276 18.7

Version Time (usr+sys) / s VMEM / MiB File Size / MiBNo FSRs 55 527 7.3

Merged FSRs 88 722 9.4

All FSRs 3067 1276 18.7

Summary Re-optimizing for FSRs not as good as we hoped

Writing *any* FSRs causes a leap in Vmem and CPU time

Need to keep merging, such that we never have 10k FSRs

Even 40 FSRs are a problem if buried under many levels

Again we can turn to these other options, but they are all very difficult … Automatic merging Event-like FSRs Flattening (Three possible directions) Abandon trees altogether


End Backups are often required


Discussion


FSR – frustrating summary records

Documents

Transcript of FSR – frustrating summary records