• Suchandra prepared c++ root-macro to ruduce SiStrip files and sample python script to run it.
  • processed SiStrip files from run57498 to run58738.
  • But it seems no reportSummaryContents directory in the reduced files.


  • Merging one run (~10 files) takes about 10 min. It should be reduced to the level of a few min.
  • There are a few bottlenecks (none of which really sticks out):
    1. visDQMMergeFile takes longer than needed. update the release to CMSSW_2_1_4 + use tag DQMServices/Core V03-03-03
    2. copying of files form srv-c2d05-19 to cmsmon and back. That takes a while but is probably not much slower than if we did everything locally.
    3. copying of dqm.db into tmp and back. dqm.db is now 500 MB. Creation of temporary copies takes a while. Where can we avoid making a temporary copy ? *4) latencies between cronjobs. We might consider increasing the rate in the cronjobs. The danger is that than cronjobs overlap. Need for appropriate lock-files everywhere.


Answer from Lassi for the memory limit during merge process

Simply opening one of the ~200MB files (with DQMStore::open()) seems 
to use up lots of (2.2+ GB) memory.

In one of the files I looked at, there were 339'274 monitor 
elements.  I don't really know if 2+ GB memory is reasonable for 339k 
monitor elements, or if we should be looking for memory leaks somewhere.

Or put another way, I did look for leaks with igprof, and there are 
none.  But this could be again one of those ROOT things where it 
_eventually_ frees up all memory.  I am suspicious of the object 
cloning and ownership when we read in objects -- in the past I've 
seen leaks in that area, and am wondering just how correct the 
(inherited legacy) code in DQMStore really is.  Apart from trial and 
error to see how much TObject cloning/reuse/delete I can get away 
with, I have no way to find out what could be deleted earlier, so I 
leave it to Andreas to prioritise if/when to spend time in that area.

At any rate, there's nothing "wrong" right now, and for now I am 
afraid we have to stick with those O(200 MB) files.  Sorry.



Things to do
  • look for a way to increase memory limit in merging process
  • look for activities in DQM
    • current cadidate job is
      • development of the writing of summary information to OMDS (see programs in DQM/Integration/bin) and the retrieval of that information through WBM (cmsmon).


  • Modified the script to merge 10 files at once and repeat until one merged file remain.


Try to merge files upto 2GB
  • tried to merged 177 files at once using visDQMMergeFile corressponding to 2GB in total.
    • caused 'St9bad_alloc' error at run 43352. looks like memory allocation problem
    • possible solution --> merge less at once or try hadd (?)

-- HyunkwanSeo - 08 Aug 2008

Edit | Attach | Watch | Print version | History: r7 < r6 < r5 < r4 < r3 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r7 - 2008-08-28 - HyunkwanSeo
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding KoreaCmsWiki? Send feedback