[THIN] Re: Disk I/O problem
- From: "Joe Shonk" <joe.shonk@xxxxxxxxx>
- To: <thin@xxxxxxxxxxxxx>
- Date: Tue, 19 Dec 2006 13:01:08 -0700
I think he mean DC=Data Collector not Domain Controller.
As far as PNAgent on a Citrix Desktop: Actually, this is quite common.
Especially with customers that use old or cheap thin clients. Also,
PNAgent on a Published Desktop gives users access to siloed apps as well as
LOCAL apps. It's a nice ways to deliver icons on a published desktop as
everyone may not have access to all apps.
Joe
_____
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf
Of TSguy92 Lan
Sent: Tuesday, December 19, 2006 12:44 PM
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: Disk I/O problem
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/processmo
nitor.mspx> to find out.
Regards,
Michel.
www.thincomputing.net <http://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: <mailto:thin-bounce@xxxxxxxxxxxxx>
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
<mailto: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
<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-68
5ee3e858fe>
Other related posts:
