Re: Setting permissions pegs the processor
Finally found the problem. Thought I'd post it in case someone else runs
across this...
First, the caching settings were messed up for just that one LUN in our SAN.
That made all those reads and writes take MUCH longer (and an occasional
delayed write failure).
Next, the script that we had running XCACL commands was the biggest culprit.
They were being run remotely and had no sensitivity as to whether the last
command had finished or not. So, what happens is that after 5-10 minutes,
any permission sets that took longer than 20 seconds start piling up on the
data server. Since it processes them all in parallel, it more or less gives
itself a heart attack while trying to work on ALL of them at once.
Hooray! No more problems...
"Mathieu CHATEAU" wrote:
> interesting it only appears on one volume.
>
> Can you use process explorer to catch what's going on ?
> http://www.microsoft.com/technet/sysinternals/Utilities/ProcessExplorer.mspx
>
> If it's the "system" that eats, go it's properties, in the thread tab.
> Sort by CSwitch Delta to find the eater.
>
> Do you use the same HBA for all volume ? If different HBA, same driver ?
> Any difference on the SAN (zoning, path...) ?
>
> Maybe multimedia files where explorer may try to make thumbnail ?
>
> Did you try with subinacl ?
>
>
> --
> Cordialement,
> Mathieu CHATEAU
> http://lordoftheping.blogspot.com
>
>
> "drdoak" <drdoak@discussions.microsoft.com> wrote in message
> news:6C3CD9A8-93CE-4B75-953C-06B52B79AE4B@microsoft.com...
> > Don't have an exact count on the number of files, but it could potentially
> > be
> > several hundred thousand at once. The volume has millions of files, but
> > there are inheritance blocks all over so it could never set them all at
> > once.
> > It varies depending on where I'm setting the permissions at any given
> > time.
> > This occurs no matter where I change them on this volume so long as it
> > isn't
> > a very small change.
> >
> > Permissions are set from either my workstation or one of the cluster
> > nodes.
> >
> > No symatec. McAfee will go in shortly, but isn't there yet. Server is
> > still ramping up for production.
> >
> > It appears to be a symptom only of this one single SAN based cluster
> > volume.
> > Not a problem on the others.
> >
> > "Mathieu CHATEAU" wrote:
> >
> >> Hello,
> >>
> >> Are you setting the permission from the active node (console or RDP)?
> >> Any antivirus ? If it's symantec, is symevents really up-to-date ?
> >> How many files/folders concerned ?
> >>
> >>
> >>
> >> --
> >> Cordialement,
> >> Mathieu CHATEAU
> >> http://lordoftheping.blogspot.com
> >>
> >>
> >> "drdoak" <drdoak@discussions.microsoft.com> wrote in message
> >> news:1D75FDA7-6843-4FC3-8387-EF1BCA6B086A@microsoft.com...
> >> > Is it normal for the processor time to spike to 100% and stay there
> >> > while
> >> > setting permissions on files? We have a few changes to be made on our
> >> > newish
> >> > user data volume, but it makes it difficult when the server becomes
> >> > nearly
> >> > unresponsive while setting permissions. Particularly a problem since
> >> > it
> >> > might take half a day to set these.
> >> >
> >> > Is there no way to throttle it in some fashion? Almost seems like a
> >> > bug
> >> > when these large permissions changes can even cause that data volume to
> >> > roll
> >> > to another server.
> >> >
> >> > Running a 3 node Win2003 Enterprise R2 SP2 cluster with SAN attached
> >> > storage
> >> > for the data volumes.
> >> >
> >> > Thanks for any insights!
> >> > Chris
> >>
> >>
>
>