Hi Lukasz,
So, if we use TTreeCache on any tree on the file, read-ahead is turned off?
I would say this is simply wrong, and we're paying a huge penalty for it. The TTreeCache hit rates are simply not high enough on non-toy examples. Even with TTreeCache turned on, during its training period I'd expect hundreds of extremely small reads.
Brian
On Jan 27, 2011, at 11:30 AM, Lukasz Janyst wrote:
> The thing is that the opaque URL is interpreted only on the TFile
> construction time, so the settings might have been overwritten if the
> same file handle was used to fill a TTreeCache.
>
> Lukasz
>
> On Thu, Jan 27, 2011 at 5:20 PM, Brian Bockelman <[log in to unmask]> wrote:
>> Hi Lukasz,
>>
>> This is not happening during a ReadV operation, if that's what you're asking.
>>
>> There's a lot of trees here and several TTreeCaches present. At this point, we're not in the middle of filling the TTreeCache.
>>
>> Brian
>>
>> On Jan 27, 2011, at 11:14 AM, Lukasz Janyst wrote:
>>
>>> Are you reading a tree via ttreecache?
>>>
>>> Lukasz
>>>
>>> On Thu, Jan 27, 2011 at 5:04 PM, Brian Bockelman <[log in to unmask]> wrote:
>>>> Hi Lukasz,
>>>>
>>>> Here's a bit higher of a level of debug:
>>>>
>>>> 110127 16:57:13 001 Xrd: Read: Read(offs=2664306755, len=104)
>>>> 110127 16:57:13 001 Xrd: Read: Cache response: got 104@2664306859 bytes. Holes= 0 Outstanding= 0
>>>> 110127 16:57:13 001 Xrd: Read: Found data in cache. len=104 offset=2664306755
>>>> 110127 16:57:13 001 Xrd: Read: Read(offs=2664371953, len=1149)
>>>> 110127 16:57:13 001 Xrd: Read: Cache response: got 0@2664371953 bytes. Holes= 1 Outstanding= 0
>>>> 110127 16:57:13 001 Xrd: Read: Hole in the cache: offs=2664371953, len=1149
>>>> 110127 16:57:13 001 Xrd: Read_Async: Requesting to read 16384 bytes of data at offset 2664366080
>>>> 110127 16:57:13 001 Xrd: Read_Async: Requesting pathid 0
>>>> 110127 16:57:13 001 Xrd: Read: Waiting 1outstanding blocks.
>>>> 110127 16:57:13 16248 Xrd: ProcessUnsolicitedMsg: Incoming unsolicited response from streamid 3
>>>> 110127 16:57:13 16248 Xrd: ProcessUnsolicitedMsg: Processing async response from streamid 3 father=2
>>>> 110127 16:57:13 16248 Xrd: ProcessUnsolicitedMsg: Putting kXR_read data into cache. Offset=2664366080 len 16384
>>>>
>>>> This is the URL used:
>>>>
>>>> root://xrootd.unl.edu//store/data/Run2010B/BTau/AOD/Dec4ReReco_v1/0007/B26C2B64-E101-E011-9C89-002481E14F38.root?readaheadsz=32768&cachesz=3276800&readaheadstrategy=1&readtrimblksz=16384
>>>>
>>>> So, it seems readtrimblksz works and cachesz/readaheadsz doesn't.
>>>>
>>>> Brian
>>>>
>>>> On Jan 27, 2011, at 10:46 AM, Lukasz Janyst wrote:
>>>>
>>>>> Hi Brian,
>>>>>
>>>>> it looks like there are two possibilities:
>>>>>
>>>>> * if you're not using a ttreecache: you have disabled the readahead by
>>>>> configuring an unknown readahead strategy in the environment
>>>>> * if you're reading from a ttree through a ttreecache: the readahead is disabled
>>>>>
>>>>> Cheers,
>>>>> Lukasz
>>>>>
>>>>> On Thu, Jan 27, 2011 at 4:20 PM, Brian Bockelman <[log in to unmask]> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I'm opening a file with the following opaque data:
>>>>>>
>>>>>> root://xrootd.unl.edu:1094//store/data/Run2010B/BTau/AOD/Dec4ReReco_v1/0007/B26C2B64-E101-E011-9C89-002481E14F38.root?readaheadsz=32768&cachesz=327680
>>>>>>
>>>>>> I.e., I would expect the minimal read size is 32KB. However, I see the following read pattern:
>>>>>>
>>>>>> 110127 16:11:34 001 Xrd: Read: Hole in the cache: offs=2673920000, len=55
>>>>>> 110127 16:11:34 001 Xrd: Read: Hole in the cache: offs=2673920512, len=145
>>>>>> 110127 16:11:34 001 Xrd: Read: Hole in the cache: offs=2673921024, len=70
>>>>>> 110127 16:11:34 001 Xrd: Read: Hole in the cache: offs=2673921536, len=154
>>>>>> 110127 16:11:34 001 Xrd: Read: Hole in the cache: offs=2673922048, len=24
>>>>>> 110127 16:11:35 001 Xrd: Read: Hole in the cache: offs=2673922560, len=162
>>>>>>
>>>>>> I would have expected all these reads to be handled by the cache. This is with ROOT 5.27.06b.
>>>>>>
>>>>>> Brian
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
|