Re: Optimizing NTFS Performance
- From: "Kevin Weilbacher [SBS-MVP]" <kweilbacMVP@xxxxxxx>
- Date: Thu, 24 Nov 2005 18:48:19 -0500
Lar,
SMB signing *is* enabled by default. Turning it off, as Jesper suggests, can
improve the situation. Furthermore, IMO, since disabling SMB is a lot less
intrusive change to your server than disabling short file names, etc.-- why
wouldn't you want to try the easier solution first?
Frankly, in my years with this newsgroup, I have never seen anyone post that
they have ever needed to or tried disabling the 8.3 short file names. If you
really wanted to try it, I would strongly advise doing it first on a test
SBS server or SBS environment, so you are sure of the process, the outcome,
and the possible side issues by doing it.
Good luck!
--
Kevin Weilbacher [SBS-MVP]
"The days pass by so quickly now, the nights are seldom long"
"Uncle Lar''" <UncleLar@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:367EA41E-D8BC-4862-9D28-C583158039EE@xxxxxxxxxxxxxxxx
> Susan, why should I cancel that? Have you had experience with disabling
> 8.3
> file names or last access times?
>
> My first thought was also the network. The client was moving from a
> peer-to-peer network to a server-client network so we took the opportunity
> to
> upgrade them to a giga-bit network. That didn't resolve the problem.
> Looking
> at the network usage on the server and client, the bottleneck certainly
> isn't
> the network. On the client side, network usage doesn't go above 5% usage
> which translates to 50Mb.
>
> I appreciate the reference to the article on SMB. I've seen the KB article
> but that doesn't accurately describe the problem. The only access problems
> is
> to one particular directory on the share and not the other directories or
> other shares. The problem existed back when the files were coming from an
> WXP
> SP2 machine. I never enabled SMB so unless SMB was enabled by default with
> SP2, then SMB isn't the problem.
>
> The directory that's causing the problem contains scanned paper work that
> comes and goes from the office and is in mostly PaperPort format (.max) or
> PDF. Do to the nature of their business, the client organizes their paper
> work by property address. As of the 14th, the directory had 87,321 files
> and
> 10,826 folders for total size on disk of 10.1GB.
> When opening the directory from the client, the heaviest hit resources is
> the CPU (2.8GHz P4) and RAM (1GB).
>
> Obviously their's a tremendous amount of I/O Read activity and I'm
> thinking
> the heavy CPU hit comes from reading the directory table.
>
> "Susan Bradley, CPA aka Ebitz - SBS Rocks" wrote:
>
>> Ixnay that.
>>
>> Mess around with
>>
>> Nic card speed [set to autosense/100 speed]
>>
>> Wack off smb signing
>>
>> Jesper's Blog : Exceptions to the rule - When you may WANT to turn off
>> SMB message signing:
>> http://blogs.technet.com/jesper_johansson/archive/2005/11/22/414976.aspx
>>
>>
>> Uncle Lar'' wrote:
>> > I'm trying to solve a problem that the users are having. Performance
>> > accessing one of the directories in a share is really slow because of
>> > the
>> > volume of data in that directory (around 10GB of .max & .pdf). The
>> > share is
>> > on an SBS2K3 machine and the clients are WXP SP2. The network is Gb and
>> > the
>> > server and clients have decent hardware.
>> >
>> > The WXP Resouce Kit describes disabling short file names and disabling
>> > last
>> > access time. I can't find this same subject in the Server 2003 Resource
>> > Kit.
>> >
>> > What I'm wondering is:
>> > 1) If done on the clients, will this apply to a mapped share or only
>> > local
>> > files?
>> > 2) Can this be done on the server side and will it matter to the
>> > clients?
>> > 3) Are there any risks or negatives I need to consider before take such
>> > action?
>> >
>>
.
- References:
- Re: Optimizing NTFS Performance
- From: Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]
- Re: Optimizing NTFS Performance
- Prev by Date: Re: SBS 2003 Anti Virus Solution
- Next by Date: RE: Windows XP Pro error message at logon: can't find roaming prof
- Previous by thread: Re: Optimizing NTFS Performance
- Next by thread: Re: Optimizing NTFS Performance
- Index(es):
Relevant Pages
|