At first, check the proof/root log, it is located in /var/log/Root.log or Root.log.1 (for older log) in every machine with rootd/proofd For example, I can see Mar 22 13:12:15 rcas0055 proofslave[8161]: ebj:slave 0.0:Error:<TFile::Init>:file /brahms/data21/data/run04/auau/200/r10844/dst/dst010844v2p3.root is truncated at 147895193 bytes: should be 149235656, trying to recover or, tigist:master0:Error:<TPacketizer::ValidateFiles>:cannot get entries for /brahms/data21//data/run05/cucu/200/r14123/dst/dst014123v3p2.root ( Mar 22 19:11:50 rcas0055 proofserv[31758]: tigist:master0:*** Break ***:segmentation violation etc.. also, clean up your package (or make one) to make sure that you don't get warning. Log is full of warning about missing dictionary of class from dst. You just need to load them in your SETUP.C of package. Hiro Johnson, Erik B wrote: >Brahms, > I have not been invloved in any discussions about proof, but we do have a major problem with memory. Last night I ran a proof session which died on me because it used up all the available memeory. Now there was nothing special about this session other than I was testing out my code. Now there could be somehting wrong with my code, but this does not explain why a proof session uses up more and more memory when I do NOTHING!!! >Now if I want to load in a number of libraries, I'm using up more memory at the start. > >Yesterday I ran over all the auau 200GeV data filling a number of histograms. I created 8622 histograms (a good number of them were not filled with any events) in a proof session. The session ran fine. > >Last night, I ran another session to test some code and I tried to process all of the auau 200GeV data. I created 11 histograms, loaded in a library, and the proof session hung with a memory leak. Here is the responce I got from RCF > >OK - I'll reboot some of the nodes that are still down but Brahms >needs to come to grips with how to run proofserv. You can't >expect to run multiple proofserv processes >1.7GB each without >driving swap down to ZERO, even with 2G of memory, possibly crashing it. >If this occurs on a weekend, you will have to wait until Monday. > >Open to suggestions if there is anything we can do at this end. > >--Richard Hogue > > >Now does anyone have a good idea on how one can approach and fix this problem? >Erik >_______________________________________________ >Brahms-dev-l mailing list >Brahms-dev-l@lists.bnl.gov >http://lists.bnl.gov/mailman/listinfo/brahms-dev-l > > _______________________________________________ Brahms-dev-l mailing list Brahms-dev-l@lists.bnl.gov http://lists.bnl.gov/mailman/listinfo/brahms-dev-lReceived on Fri Mar 24 16:46:24 2006
This archive was generated by hypermail 2.1.8 : Fri Mar 24 2006 - 16:46:37 EST