John Bland wrote:
> On 15/02/2010 15:09, Wahid Bhimji wrote:
> [snip]
>> This varies depending on how the file is accessed and (considerably)
>> if the file is reordered.
The DDM operations talks at:
http://indico.cern.ch/conferenceDisplay.py?confId=50977
give some details and explanation of all this.
>> The summary in terms of CPU efficiency is
>>
>> Local (Ext3) - 17%
>> Remote (Rfio) - 15%
>> Remote (GPFS) - 31%
>> TTreeCache (Local) - 48%
>> Reordered File (local) - 96%
>> Reordered File (Rfio) - 41%
>> Reordered File (GPFS) - 50%
>
Some idea of the errors on these numbers would be useful.
> One thing that would be interesting for the local reordered file access
> is how many jobs you are running, the machine RAM and the size of the
> files. It's certainly possible to get job efficiencies in the high 90s
> with unordered files if they are wholly cached in RAM eg running a
> single job on a 16GB machine would fall into this.
Indeed. I believe that the reason Lustre performs well is because it
caches (unlike rfio which only has readahead).
Can you try
cat file >/dev/null
before running some of your tests - just to get a baseline with the file
mostly cached in RAM.
I have long held that with the inefficient access pattern, life would be
much better if the files were somewhat smaller (say 0.5Gig). Graeme told
me last week I was the first person to ask for that, so I haven't been
shouting loud enough. I suspect this will become moot with the reordered
file.
Also, for rfio, what readahead buffer did you use (and does it make a
difference)?
Chris
|