[THIN] Re: Disk I/O problem
- From: "TSguy92 Lan" <tsguy92@xxxxxxxxx>
- To: thin@xxxxxxxxxxxxx
- Date: Tue, 19 Dec 2006 11:43:45 -0800
*3 PS4 servers* - ok
*1 of them acting as a DC* - what?! why? is this to give you a seperate
domain for your testing? Generally not a good practice to have an
application terminal server be a DC too. But I'm guessing you're using this
box as your control system for your test, so I'll assume your DC is also the
IMA DB, and PNagent / web interface server.
*Users login to the "desktop" of one of the PS4 servers* - ok
*From this desktop connection users then launch applications from the
PNagent that are hosted on the 3rd server* - huh? While I've seen similar
setups in very very rare cases (usually for siloing apps), this again seems
an odd setup choice to me. Why not install the PNagent directly on the
client systems and just let them run the apps from there as opposed to
hitting a terminal server desktop first. If don't want to install the
PNagent to client desktops then have the users login via the web interface
you would have had to setup anyways to support the PNagent.
*You're redirecting the Application Data folder for user profiles to a
network'd location* - ugh. Again, there's times when this type of setup is
required, but it can get ugly fast. Some applications regularly write / read
directly from \userprofile\application data, when you re-direct this to a
network share, you're no longer dealing with a local server "disk I/O"
issue, you're dealing with a network I/O issue. As you add in users to this
setup your I/O will only get worse. 100mb or even GB networks are not yet
the equivilent of a servers local SCSI/SATA/SAS drives for fast I/O
purposes.
Even with all this said, I've run into applications which wrote 50+mb data
files into \appdata in user roaming profiles, and in that case the hard
choice for us was:
'make the users wait the extra seconds on login / logoff for those 50+mb
profiles to copy to and from the TS server each time they login / logoff'
or
're-direct the \appdata folder and add network access latency to any
function on the terminal server which requests a read / write to the remote
\appdata share for a logged in user'.
A hard choice to be sure, in our particular case the choice was made (before
my time here) to use a network share for \appdata, and the citrix
application which utilized the remote appdata directory would lock
up regularly due to delays in it's remote I/O calls.
I'm still in the process of re-tooling the environment here to get rid of
the redirected appdata folder for our user profiles, but I wouldn't wish the
setup of a network accessed appdata folder (as was setup in our environment
- I can't speak for anyone elses) on my worst enemy. As Joe and Michel have
already suggested, if in anyway the setup of a redirected \appdata folder
could be averted with your new build you should look into it.
HTH
Lan
On 12/18/06, Michel Roth <mrdizzz@xxxxxxxxx> wrote:
Hi Michael,
My first hunch the same as Joe is expressing although it might seem
confusing. Your log shows that it's writing to K:\Documents and
Settitng....\Application Data\. So K: is a local disk but the Application
Data is being redirected?
I've never seen a modern (RAID 1 / SCSI ) Terminal Server have a local
Disk I/O bottleneck. Except of course I you put the company database on the
D: drive ;-).
What proces(es) is/are taking the bulk of the File I/O? You can use ProcMon
<http://www.microsoft.com/technet/sysinternals/ProcessesAndThreads/processmonitor.mspx>to
find out.
Regards,
Michel.
www.thincomputing.net
On 12/18/06, Joe Shonk <joe.shonk@xxxxxxxxx> wrote:
>
> Try turning off App Data redirection and see what happens.
>
>
>
> Joe
>
>
> ------------------------------
>
> *From:* thin-bounce@xxxxxxxxxxxxx [mailto: thin-bounce@xxxxxxxxxxxxx] *On
> Behalf Of *Michael Boggan
> *Sent:* Monday, December 18, 2006 10:57 AM
> *To:* thin@xxxxxxxxxxxxx
> *Subject:* [THIN] Re: Disk I/O problem
>
>
>
> We monitor them with NetIQ and other utils. The CPU and Memory useage
> are minimal but the Disk I/O is through the roof.
>
>
> Thanks,
> Michael Boggan
> ------------------------------
>
> Date: Mon, 18 Dec 2006 17:48:16 +0100
> From: mrdizzz@xxxxxxxxx
> To: thin@xxxxxxxxxxxxx
> Subject: [THIN] Re: Disk I/O problem
>
> How are you certain that local disk I/O is your bottleneck?
>
> On 12/18/06, *Michael Boggan* < mboggan@xxxxxxxxxxx > wrote:
>
> We do redirect the application data. It is redirected to a network share
> so that should eliminate some local disk I/o, not create more.
>
>
> Thanks,
> Michael Boggan
> ------------------------------
>
> Date: Mon, 18 Dec 2006 11:24:33 +0100
> From: mrdizzz@xxxxxxxxx
> To: thin@xxxxxxxxxxxxx
>
>
> Subject: [THIN] Re: Disk I/O problem
>
> Hi Michael,
>
> Make sure that appplication data is not being "folder redirected"?
>
> Regards,
> Michel.
>
> On 12/12/06, *Michael Boggan* < mboggan@xxxxxxxxxxx> wrote:
>
> It would appear that pnagent is constantly writing to this folder. Here
> is a sample of what filemon returned. Any idea what this is? This is just
> a very small sample from a few seconds of data. PNAgent appears to be
> hammering the disk.
>
>
>
-----------------------------------------------------------------------------------------------------------------------
>
> 10:40:13 AM pnagent.exe:11624 WRITE K:\Documents and
> Settings\gsmith\Local Settings\Application
> Data\Microsoft\Windows\UsrClass.dat SUCCESS Offset: 110592 Length: 4096
>
> 10:40:13 AM pnagent.exe:11624 WRITE K:\Documents and
> Settings\gsmith\Local Settings\Application
> Data\Microsoft\Windows\UsrClass.dat SUCCESS Offset: 114688 Length: 4096
>
> 10:40:13 AM pnagent.exe:11624 WRITE K:\Documents and
> Settings\gsmith\Local Settings\Application
> Data\Microsoft\Windows\UsrClass.dat SUCCESS Offset: 118784 Length: 4096
>
> 10:40:13 AM pnagent.exe:11624 WRITE K:\Documents and
> Settings\gsmith\Local Settings\Application
> Data\Microsoft\Windows\UsrClass.dat SUCCESS Offset: 4096 Length: 65536
>
> 10:40:13 AM pnagent.exe:11624 WRITE K:\Documents and
> Settings\gsmith\Local Settings\Application
> Data\Microsoft\Windows\UsrClass.dat SUCCESS Offset: 69632 Length: 53248
>
> 10:40:14 AM pnagent.exe:11624 WRITE K:\Documents and
> Settings\gsmith\Local Settings\Application
> Data\Microsoft\Windows\UsrClass.dat SUCCESS Offset: 0 Length: 512
>
> 10:40:14 AM pnagent.exe:11624 WRITE K:\Documents and
> Settings\gsmith\Local Settings\Application
> Data\Microsoft\Windows\UsrClass.dat SUCCESS Offset: 0 Length: 4096
>
>
>
>
-----------------------------------------------------------------------------------------------------------------------
>
>
> Thanks,
> Michael Boggan
>
> ------------------------------
>
> Subject: [THIN] Re: Disk I/O problem
> Date: Tue, 12 Dec 2006 10:27:50 -0500
> From: MShrewsbury@xxxxxxxxxxxxxxx
> To: thin@xxxxxxxxxxxxx
>
>
>
> I'd try running filemon to determine what task is causing the I/O. Also
> as a hunch I'd check your AV.
>
>
> Matthew Shrewsbury
> Network Manager
>
>
> -----Original Message-----
> *From:* thin-bounce@xxxxxxxxxxxxx [mailto: thin-bounce@xxxxxxxxxxxxx] *On
> Behalf Of *Michael Boggan
> *Sent:* Tuesday, December 12, 2006 10:19 AM
> *To:* thin list
> *Subject: *[THIN] Disk I/O problem
>
>
>
> We are in the process of doing a proof of concept with PS4 and new
> hardware, etc. We have 3 PS4 servers built. 1 as the DC, 1 as a published
> desktop server and 1 as the published applications server. Users login to a
> published desktop and get there icons via the PNAgent running for each
> desktop. The applications are all published from the 3rd server. We have
> roaming profiles and the desktop and application data folders are mapped to
> individual folders on the network so that they follow them around.
>
> We are having problems with disk writes on the desktop server. For some
> reason the disk I/O is going crazy on that server alone. SO much so that
> the server lags tremendously. ANy have any idea why this might be
> happening? If anyone knows of a way to determine what is actually being
> written too, that would help as well. We have tried NetIQ and other
> monitors but cannot find anything that tells us what is actually being
> written too on the disk.
>
>
> Thanks,
> Michael Boggan
> ------------------------------
>
> Search from any Web page with powerful protection. Get the FREE Windows
> Live Toolbar Today! Try it now! <http://get.live.com/toolbar/overview>
>
>
> ------------------------------
>
> All-in-one security and maintenance for your PC. Get a free 90-day
> trial! Learn
more!<http://www.windowsonecare.com/purchase/trial.aspx?sc_cid=wl_wlmail>
>
>
>
>
> ------------------------------
>
> Check the weather nationwide with MSN Search Try it
now!<http://search.msn.com/results.aspx?q=weather&FORM=WLMTAG>
>
>
>
>
> ------------------------------
>
> Use Messenger to talk to your IM friends, even those on Yahoo! Talk
now!<http://ideas.live.com/programpage.aspx?versionId=7adb59de-a857-45ba-81cc-685ee3e858fe>
>
Other related posts:
