[THIN] Re: 64 bit experience - repost
- From: "Rick Mack" <Rick.Mack@xxxxxxxxxxxxxx>
- To: <thin@xxxxxxxxxxxxx>
- Date: Sat, 10 Jun 2006 08:16:54 +1000
Hi Alan,
Just adding my 2 cents worth.
Early on Microsoft were fairly careful to say that x64 would scale better only
where the system bottleneck was a kernel memory restriction or application
memory restriction. Then I think marketting might have got involved ;-)
We need to remember that in a lot of ways we've hit the wall with 32 bit
systems.
Apps keep getting bigger and need more system resources (file handles etc),
user profiles (registry memory footprint) have increased in size (unless you're
using flex profiles), virus checkers have got more aggressive (paged pool) so
the demands on kernel memory just keep increasing. There's a lot of stuff
that's been nibbling away at the system memory allocation. Faster CPUs and main
memory have also meant we desperately need more system cache so that disk i/o
operations can keep up. But we've only got 2 GB virtual memory.
With user memory we've got all the user's 2 GB virtual application mapped into
whatever is left. The dramatic effect of DLL remapping (TScale and APpsense
Performance manager [also with working set trimming]) on system user
scalability is really telling us that the limiting performance factor on a lot
of systems is paging activiy.
And why do we have paging? It's because we've fitted a 2GB+(number of
users)x2GB memory model into 4GB of physical memory.
There's a very important criterion that has to be accepted for any meaningful
x86/x64 testing. Unless there's a lot more memory available for x64 you've got
something much worse than the 2GB+Xx2GB model because the kernel will now use
more memory (64 bit code and address space is bigger!) causing even more paging.
If I'm running 2GB kernel+2GB Application space (per user, I know) and am
limited to 4GB total on a system, running on x64 with 4GB of RAM hasn't changed
anything significant because I'm still memory constrained and my kernel space
isn't constrained to 2GB any more. So I've actually made things harder for
applications, increased paging etc.
The only valid test of x86 vs x64 is on essentially the same hardware but with
than 4GB RAM for x64. For example, performance comparisons of the same system
with 4GB for x86 and 16 GB for x64 can start to give us some meaningful idea of
the benefits of 64bit vs 32 bit. Any comparisons of x86 and x64 on 4GB systems
can't help but be fundamentally flawed.
The only scenario I can think of at the moment is really lame, but here goes.
We've got 32 bit centipedes that can only use 4 of their legs and 64 bit
centipedes that can use all of their legs. But to make the contest fair we chop
off all but 4 of the 64 bit centipede's legs. Now let's race.
Addressing some of the other 32bit/64 bit issues, the appropriate use of
universal printer drivers removes most of the printer driver issues, "hard"
printers like barcode and label printers can use the x64 drivers from
www.seagullscientific.com. We've been repackaging legacy installer apps into
MSIs (or even Citrix Packager) for a while so the problem of 16 bit installer
components really doesn't matter.
16 bit apps? Gosh I'd love to get rid of the 16 bit subsystem. It's a security
and performance nightmare and it's one thing I'd love to relegate to a silo in
the back of the data center.
Will there be other issues? Of course.
It's new technology and until we get a lot of people using it, and a lot of
hotfixes/service packs, it's going to be real flakey. But then so was Windows
200 and Windows Server 2003 32 bit.
So am I pushing it for production systems?
No. I'm not that brave/stupid. But I think we'd be pretty short-sighted not to
at least test x64 (with lot's of memory) in our delopment environments.
Vista and Longhorn aren't that far away.
regards,
Rick
Ulrich Mack
Volante Systems
________________________________
From: thin-bounce@xxxxxxxxxxxxx on behalf of Hutchinson, Alan
Sent: Fri 9/06/2006 23:54
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: 64 bit experience - repost
Maybe I was understating when I said that I'm not sure I believe the
scalability figures - I should have said that not only do I not believe the
scalability figures, I never have believed these (for anything let alone x64).
That said, any further ino you have would be good - may as well overload me
brain even more.
Apart from scalability I think that the issue for me will things such as the
different add-ins for I.E. that Tim mentions, and miscellaneous drivers and
installers
Thanks to both you and Tim for your responses.
Alan.
________________________________
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf Of
Andrew Wood
Sent: 09 June 2006 09:55
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: 64 bit experience - repost
Alan,
Look hard at the performance figures - there are some instances where there are
actually *lower* numbers when migrating to x64 - I'll see if I can get my hands
on a copy of the presentation :)
________________________________
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf Of
Hutchinson, Alan
Sent: 08 June 2006 17:57
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: 64 bit experience - repost
Thanks for that Andrew - one of my motives for looking at 64 bit (apart from
the technical challenge) is that once we get an environment up and running
smoothly here we tend not to change it for a couple of years or so (except for
the usual patches and supplier software upgrades). By that time I'll be having
problems with not having gone 64 bit and virtually no experience of it. I am
resigned to running mainly 32 bits apps at the moment and have read of the
performance hit of running wow64 so I certainly won't be selling it as a way of
reducing the overall estate.
I've had a quick look at the pubforum web site and can only find "Citrix
Metaframe ala 64 bit - what does it give us"
http://www.pubforum.net/vip/PubForum_x64_Citrix.ppt#259,1,64 bit Presentation
Server
by Simon Frost from Citrix. Like you said I'm not sure I believe the
scalability figures given here either.
At the moment I'm leaning heavily towards a simultaneous 32 and 64 bit build
and see what breaks first - as I said above I'd like to get my hands dirty with
this whilst I've got the opportunity.
Thanks for your input - really useful.
Regards,
Alan.
________________________________
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf Of
Andrew Wood
Sent: 08 June 2006 15:09
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: 64 bit experience - repost
Alan,
Bernhard Tritsch did great presentation on 64 bit for TS at the last pubforum.
iirc the findings were essentially that the 64 bit environment didn't really
offer any additional benefit at present - in fact there could be more effort
involved in being an early adopter almost without gain. Issues identified
included getting device drivers for printers, and other hardware, anti-virus
support wasn't available from all vendors. He highlighted the fact that a lot
of existing apps are going to have to run in the windows on windows emulation
to allow the fact that they're 32 bit apps. You obviously can't have anything
older - 16bit apps won't run. This wow functionality for many apps increased
resource consumption. There were issues with the fact that they've messed
around with the system32/program files directories that can lead to some
applications not working correctly and being cumbersome to install or not
working at all.
More importantly, he load tested the same desktop app suite in a 32 and 64 bit
environment. While the 64 bit environment could allow more sessions to be
created the apps in those (extra) sessions did not work well and were very
unreliable. Getting a user count that was reliable meant that you were hitting
about the same user count as with win32. He showed that the testing M$ did to
get the large amount of sessions working was performed over a large amount of
time - when you tried to get many users on in a short time the environment did
not hold up as well.
I wish I had a copy of the powerpoint :( it was a very compelling argument to
sitting tight until more apps were available natively on the x64 platform.
hth
________________________________
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf Of
Michael Pardee
Sent: 08 June 2006 14:37
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: 64 bit experience - repost
very close here. As we build our new PS4 Farm I challenged the team to do as
much with the 64 bit version as possible. I think we are just rolling. I'll
report back anything we find.
On 6/8/06, Hutchinson, Alan <Alan.Hutchinson@xxxxxxxxxxxxxxxxxx> wrote:
No takers? I was hoping to provoke some discussion - either I'm way
behind the times and evrybody is using this or (and I can't believe
this) I'm slightly ahead of the game, or everybody has got one in their
labs and is keeping quiet ..........
Regards,
Alan.
-----Original Message-----
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx ] On
Behalf Of Hutchinson, Alan
Sent: 07 June 2006 16:17
To: thin@xxxxxxxxxxxxx
Subject: [THIN] 64 bit experience
Well, as far as I can see this hasn't been aired for a couple of months
so I'm wondering what the experience is out there. I have the
opportunity for a completely new build on a new infrastructure and am
toying with a simultaneous 32 and 64 PS server build to see how it goes.
I've seen the following :
CTX105744 - but this is dated October last year and can't immediately
see any updates to this and the only thing that puts me off under
functionality not supported is 'Oracle' without any further
explanation.
KB282423 - again a few months old. The bits that concern me with this
one relate to MDAC (but on re-reading may not be an issue), and '64 bit
I.E. cannot load 32-bit ActiveX controls' - which may be the killer.
I was encouraged by Brian Maddens article
http://www.brianmadden.com/content/content.asp?id=518 about 'dropping' a
64 bit PS server into an existing 32 farm. Although long term I don't
particularly fancy running a mixed farm.
Thoughts, discussions, opinions, real experience please.
Regards,
Alan.
************************************************
For Archives, RSS, to Unsubscribe, Subscribe or
set Digest or Vacation mode use the below link:
//www.freelists.org/list/thin
************************************************
************************************************
For Archives, RSS, to Unsubscribe, Subscribe or
set Digest or Vacation mode use the below link:
//www.freelists.org/list/thin
************************************************
--
Michael Pardee
www.blindsquirrel.org
#####################################################################################
This e-mail, including all attachments, may be confidential or privileged.
Confidentiality or privilege is not waived or lost because this e-mail has been
sent to you in error. If you are not the intended recipient any use,
disclosure or copying of this e-mail is prohibited. If you have received it in
error please notify the sender immediately by reply e-mail and destroy all
copies of this e-mail and any attachments. All liability for direct and
indirect loss arising from this e-mail and any attachments is hereby disclaimed
to the extent permitted by law.
#####################################################################################
Other related posts:
