The issue is that with 75M files, it's paramount to keep the metadata
in something faster than spinning disk.
Windows 2003 32-bit uses 36-bit memory addressing. You can use 32G of
RAM. That might help, but what you WANT in cache never seems to STAY
in cache. Bulk data pushes your MFT out of cache.
What I'd recommend is using something like IBM's Easy Tier, though
most SAN manufacturers have something similar.
Basically, you have a bunch of spinning disk for your bulk data, and a
small number of enterprise grade SSDs installed. The array code will
figure out where your IOPS bottlenecks are, and will move just the
offending blocks into the faster media. This amounts to having your
MFT and a few small hotspots on flash.
It would probably take one or two filesystem scans for optimal
performance to be reached.
While Enterprise SSD is not as fast as being in RAM, it's much faster
than being on spinning disk. Don't confuse with consumer grade SSD
which just won't have the IOPS performance for what you're doing.
For IBM, the lowest cost way to get into EasyTier is the "StorWize
V7000". It's a combination storage drawer and SVC. I'm not sure
about EMC, Hitachi and NetApp's comparable products.
With friendly Regards,
Josh-Daniel S. Davis
On Mon, Feb 28, 2011 at 9:51 AM, Strand, Neil B. <NBStrand AT leggmason DOT
com> wrote:
> Wanda,
> If it is a 32 bit system, the most memory that can be addressed is
> 4G.
> 2^32 = 4,294,967,296 bytes
> 4,294,967,296 / (1,024 x 1,024) = 4,096 MB = 4GB
>
> Moving to a 64bit system would allow additional memory to be fed to the
> beast.
>
> If the windows servers are not running the application but simply
> providing filespace to the application that is running on another
> server, see if the following is possible:
> - Implement DFS and provide a virtual tree that is composed of multiple
> physical data repositories. Each repository could be backed up using a
> proxy - recovery may be a bit convoluted, but possible. Identify the
> problem not as a backup problem but a data management problem that
> requires some level of granularity to be introduced to the environment.
>
> Cheers,
> Neil Strand
> Storage Engineer - Legg Mason
> Baltimore, MD.
> (410) 580-7491
> Whatever you can do or believe you can, begin it.
> Boldness has genius, power and magic.
>
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of
> Prather, Wanda
> Sent: Friday, February 25, 2011 2:35 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] Windows servers with a kazillion files and
> Win2K8...
>
> Thanks for the reply and the reference; I'll read that.
> It's a 32 bit system.
> Do you think adding RAM will help with the issues navigating the file
> tree?
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of
> Storer, Raymond
> Sent: Friday, February 25, 2011 2:22 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] Windows servers with a kazillion files and
> Win2K8...
>
> Wanda, is this a 32 or 64 bit system? An NTFS file system will support
> about 4 Billion files on a single volume
> http://technet.microsoft.com/en-us/library/cc781134(WS.10).aspx . If you
> are having performance issues with this and you can switch it to a 64bit
> platform and add loads of RAM, I would do it.
>
> Ray
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of
> Prather, Wanda
> Sent: Friday, February 25, 2011 2:03 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: [ADSM-L] Windows servers with a kazillion files and Win2K8...
>
> I have a site with an application that generates kazillions of tiny
> files that are stored forever.
> I've already yelled about it, but it's a purchased, customer-facing
> black-box app that they really can't change.
> (Naturally, when it was bought umpty years ago, nobody thought about the
> problem reaching this size or what the ramifications would be.) Every
> day the app creates more files.
>
> They have multiple Win2K3 servers that already have multiple luns
> containing over 35M files each, one is over 75M files.
>
> We are using journaling to back them up successfully (most days).
> But it's a struggle just to expand the file tree with Windows explorer,
> and there are exposures on the days when the journal gets overrun (takes
> 72 hours for TSM to scan the filesystem and revalidate the journal).
>
> Looking for anything that might help save our bacon.
>
> Has anybody had experience with this issue and Win2K8?
> Does Win2K8 do any better than Win2K3 at handling huge numbers of files
> in 1 NTFS directory?
> Upgrading the OS is something application-independent we might be able
> to do.
>
> Thanks for any insight!
> W
>
>
> Wanda Prather | Senior Technical Specialist |
> wprather AT icfi DOT com<mailto:wprather AT icfi DOT com> |
> www.jasi.com<www.jasi.com%20> ICF Jacob & Sundstrom | 401 E. Pratt St,
> Suite 2214, Baltimore, MD 21202 | 410.539.1135
>
>
> CONFIDENTIALITY NOTICE: This email and any attachments are for the
> exclusive and confidential use of the intended recipient. If you are
> not the intended recipient, please do not read, distribute or take
> action in reliance upon this message. If you have received this in
> error, please notify us immediately by return email and promptly delete
> this message and its attachments from your computer system. We do not
> waive attorney-client or work product privilege by the transmission of
> this message.
>
> IMPORTANT: E-mail sent through the Internet is not secure. Legg Mason
> therefore recommends that you do not send any confidential or sensitive
> information to us via electronic mail, including social security numbers,
> account numbers, or personal identification numbers. Delivery, and or timely
> delivery of Internet mail is not guaranteed. Legg Mason therefore recommends
> that you do not send time sensitive
> or action-oriented messages to us via electronic mail.
>
> This message is intended for the addressee only and may contain privileged or
> confidential information. Unless you are the intended recipient, you may not
> use, copy or disclose to anyone any information contained in this message. If
> you have received this message in error, please notify the author by replying
> to this message and then kindly delete the message. Thank you.
>
|
