| Thanatos 2004-05-30, 11:11 am |
| Hi Mark,
Good info - this does make sense.
NetApp use an unusual method for dealing with large directory performance -
they maintain a full filesystem directory name cache in RAM - more
appropriately called a hash table as it is a complete map of the directory
structure. As long as there is sufficient RAM to deal with this the
performance gains compared to using a more traditional name cache can be
significant. The problem you have hit is that since you have run out of RAM,
the re-reads bring the performance back down to what you would expect from a
more traditional UFS-style filesystem.
They have an excellent white paper on this here:
http://www.netapp.com/tech_library/3006.html
Note that the benchmarking in this paper is based on very old platforms for
both the UFS and WAFL testing, but if you scale them forward to current
technologies the comparitive results should be similar between comparable
hardware configurations.
In your particular circumstance extra RAM should help as you have surmised.
Bear in mind that if you were to move your filesystems in their current
structure to a Unix box of similar hardware spec to your filer you would
expect much worse performance than you are seeing now, as described in the
paper above.
NTFS uses an interesting btree style search algorithm for large directory
lookups that should yeild better performance that a linear search or name
cache method as well. However, in practice other issues with NTFS layout
(MFT lookup seeks etc.) mean that the general performance for complex
directory structures is so bad that the btree search method is necessary
just to bring it's performance levels back to what would be considered
acceptable for most Unix filesystems (UFS, JFS, AdvFS, XFS etc.)
WAFL is absolutely the right filesystem technology for the applications you
describe - you're simply running an underpowered box as they have suggested.
I used to work for a systems integrator who was a NetApp reseller (the
company I work for now does much more with HDS), and last year most of our
clients who were running 700 series filers upgraded to 800 series filers
(810's and 825's) simply because they were hitting the upward curve on cost
of support. This situation is not unique to NetApp- IBM, HDS, EMC, Stotek
etc all do the same thing as maintaining support for older hardware starts
to become cost prohibitive for the vendor. Most enterprise class storage
solutions are aged out after ~3-4 years due to obsolescence - i.e. there
aren't many 5 year old Symm's out there running in live environments. The
fact that a five year old F720 can still keep up with most new server
platforms in most situations is nothing short of amazing, but really you
should have been looking at an upgrade before now anyway.
I'm surprised at the cost you mentioned - most of my clients who upgraded
last year did it for well under AUD$80K (or less than US$50K) to go to an
810 or 825.
"Mark" <mark.wooldridge@camNOSPAMcon.co.uk> wrote in message
news:4072c9ee$0$3309$ed9e5944@reading.news.pipex.net...
>
> "Thanatos" <dgahan@europe.com> wrote in message
> news:407285a5@dnews.tpgi.com.au...
> fact
486[vbcol=seagreen]
workload[vbcol=seagreen]
little[vbcol=seagreen]
optimal[vbcol=seagreen]
was[vbcol=seagreen]
> have
> all
> lousy
Windows[vbcol=seagreen]
> however
> applications?
>
> Hi, Thanks for the historical info,
> The bottleneck as confirmed by NetApp Engineers is that we have far too
many
> files/directories in each directory.
> IE: we have too many very large directories.
> Netapps explanation was that the memory was running out of room to put the
> directory cache and therefore had to re-read the directory for almost
every
> file read.
>
> Symptoms show it is reading 4 times more data off disk than it is
outputing
> to the network.
>
> Data is a mixture of Lotus Notes Databases ( 8,000 dbs per directory ) (
> each also has a full text index.directory!!!)
> and general small flat files ( 1k - 100k )
>
> Basically , we went to Netapp and said the performance of the filers were
> crap!
> They came and checked it out and said nothing. They would not agree nor
> disagree.
> They were more interested in doing us out of another 100 grand.
>
> Mark.
>
>
>
>
|