[THIN] Re: Hyperthreading and effect on network i/o
- From: "Ron Oglesby" <roglesby@xxxxxxxxxxxx>
- To: <thin@xxxxxxxxxxxxx>
- Date: Thu, 25 Sep 2003 08:21:31 -0500
To add to this I had a client make a change to a Dell server with
hyperthreading enabled. This server was changed and the rest left alone
(since that morning of the post). Looking at his perflogs we have see no
signifigant change in the network i/o but have seen that the servers
uses about 10% processor time than it had been with what seems to me
like some processor queue "jumpieness" for lack of a better term.
Ron Oglesby
Senior Technical Architect
RapidApp
Office 312.372.7188
Mobile 815.325.7618
email roglesby@xxxxxxxxxxxx
-----Original Message-----
From: Erik Blom [mailto:erik.blom@xxxxxxxxxx]
Sent: Thursday, September 25, 2003 4:57 AM
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: Hyperthreading and effect on network i/o
Rick,
In your post ("Hyperthreading and effect on network i/o") you mention 8
IBM X335 systems and a file/print cluster. I have a client with exactly
the same setup (15 X335 servers and a file/print cluster) who is
experiencing exactly the same problem: temporary hangs when more than 30
users are logged on. We contacted MS, Citrix -- all to no avail. Now I
agree with you that it probably is network related: at the time where
the hangs were a serious problem, everyone was working with Outlook and
an AS/400 as a mail server. Probably due to the excessive i/o which was
caused by the frequent .pst file access, the system hung frequently.
Now this company is in a later stadium of their IT project, which
involves migrating the mail from the AS/400 to a native Exchange server
solution. Result: the hangs seem to be disappearing as more and more
users are migrated to Exchange.
Now I don't know if this is an IBM problem, a MS problem or a Citrix
problem. I'm starting to think I should re-address IBM 'cause no one in
this newsgroup seems to be having the same problems, except now you and
a few months earlier someone else (I may be wrong but I think he had
IBM's also).
In the meantime, could you be so kind to tell what tuning you did on the
back-end file/print server? If I cannot solve the problem completely,
maybe I would be able to at least alleviate it.
tx!
Erik Blom
PS 1 difference: this client runs W2K server and not W2003 server
Mack, Rick wrote:
> Hi People,
>
> I've been having some ongoing fun on one of our sites where 2003
> servers are hanging, luckily infrequently, when a bunch of users are
> logging on.
>
> We've found quite a few things that needed sorting out including
> tuning a back-end file/print cluster that have improved things
markedly.
>
> Nevertheless, we've been monitoring and playing with just about
> everything to try and get a handle on the hangs. This has included
> debug dumps to Microsoft, Citrix etc.
>
> All that aside, one very interesting thing did crop up. We have a
> total of 8 new IBM X-series model 335 systems, (and a bunch of older
> systems as well) running Windows server 2003. These new systems
> support hyperthreading and in an attempt to deal with the hangs, one
> of the things we did was to disable hyperthreading on a couple of the
> 335s.
>
> Since we had a suspicion that the hangs could be network i/o related,
> one of the things (amongst many!) that we've been monitoring is the
> local redirector (redirector > current commands). The 2 systems with
> hyperthreading disabled were consistently running with a current
> commands queue length that was 50%-60% of that is seen on the systems
> with hyprthreading enabled.
>
> Stated simply, the redirector's pending i/o request queue length
> (current commands) was much shorter on non-hyperthreaded systems
> compared to hyperthreaded systems with the same application and user
> load. The non-hyperthreaded systems were handling network i/o requests
> more efficiently
>
> Now this kind of makes sense in a scenario where a single-threaded NIC
> driver latches on to a logical CPU rather than a physical CPU.
> Certainly, a logical CPU is going to have less resources available
> than a physical CPU in terms of interrupt handling capability.
>
> This observation, if it's real, has some interesting ramifications if
> the effect of hyperthreading benefits cpu intensive processes at the
> expense of i/o intensive processes. Do I really want my file/print
> servers to go slower than they could?
>
> I guess the bottom line for me is that I'm going to be very cautious
> about recommending or using hyperthreading on our TS or file/print
> systems for a while until the effect of hyperthreading on i/o has been
> clarified. Terminal server systems are way too dependent on network
> i/o responsiveness for their good health for me to risk anything
> screwing up the works.
>
> regards,
>
> Rick
>
> Ulrich Mack
> rmack@xxxxxxxxxxxxxx
> Volante Systems
> 18 Heussler Terrace
> Milton 4064 Queensland, Australia
> tel +61 7 32467704
>
>
>
------------------------------------------------------------------------
--------------------------------------------
> The information contained in this e-mail is confidential and may be
> subject
> to legal professional privilege. It is intended solely for the
addressee.
> If you receive this e-mail by mistake please promptly inform us by
reply
> e-mail and then delete the e-mail and destroy any printed copy. You
must
> not disclose or use in any way the information in the e-mail. There is
no
> warranty that this email or any attachment or message is error or
> virus free. It may be a private
> communication, and if so, does not represent the views of Volante
> group Limited.
********************************************************
This Week's Sponsor - RTO Software / TScale
What's keeping you from getting more from your terminal servers? Did you
know, in most cases, CPU Utilization IS NOT the single biggest
constraint to scaling up?! Get this free white paper to understand the
real constraints & how to overcome them. SAVE MONEY by scaling-up rather
than buying more servers.
http://www.rtosoft.com/Enter.asp?ID=147
**********************************************************
Useful Thin Client Computing Links are available at:
http://thethin.net/links.cfm
New! Online Thin Computing Magazine Site
http://www.OnDemandAccess.com
For Archives, to Unsubscribe, Subscribe or
set Digest or Vacation mode use the below link:
http://thethin.net/citrixlist.cfm
********************************************************
This Week's Sponsor - RTO Software / TScale
What's keeping you from getting more from your terminal servers? Did you know,
in most cases, CPU Utilization IS NOT the single biggest constraint to scaling
up?! Get this free white paper to understand the real constraints & how to
overcome them. SAVE MONEY by scaling-up rather than buying more servers.
http://www.rtosoft.com/Enter.asp?ID=147
**********************************************************
Useful Thin Client Computing Links are available at:
http://thethin.net/links.cfm
New! Online Thin Computing Magazine Site
http://www.OnDemandAccess.com
For Archives, to Unsubscribe, Subscribe or
set Digest or Vacation mode use the below link:
http://thethin.net/citrixlist.cfm
Other related posts:
