[THIN] Re: No Pagefile for TS?
- From: "Steve Greenberg" <steveg@xxxxxxxxxxxxxx>
- To: <thin@xxxxxxxxxxxxx>
- Date: Mon, 15 Mar 2004 10:56:34 -0700
> consider whether efforts are best spent making paging as optimal as
possible, or reducing / eliminating paging.
Yes, that is ideal. What kinds of things can be done to eliminate =
paging?
Steve Greenberg
Thin Client Computing
34522 N. Scottsdale Rd. suite D8453
Scottsdale, AZ 85262
(602) 432-8649
(602) 296-0411 fax=20
steveg@xxxxxxxxxxxxxx
-----Original Message-----
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On =
Behalf
Of Braebaum, Neil
Sent: Monday, March 15, 2004 8:48 AM
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: No Pagefile for TS?
Comments inline...
> -----Original Message-----
> From: thin-bounce@xxxxxxxxxxxxx
> [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf Of Steve Greenberg
> Sent: 15 March 2004 15:26
> To: thin@xxxxxxxxxxxxx
> Subject: [THIN] Re: No Pagefile for TS?
>=20
> Neil,=3D20
>=20
> Except the whole issue of both paging and virtual memory swap
> is =3D predicated on RAM being at a premium.
Agreed - fair point.
> RAM has been cheap
> and abundant for a long =3D time.
Again, fair point.
However, the secondary storage concept allows a (perhaps) bigger amount =
of
leeway in "graceful" space, before the OS either crashes, or refuses to
allow any new processes.
It still has to somehow deal with the scenario of processes increasing =
their
memory usage.
And to be fair, for most of the Windows OSs there is a ceiling for =
memory
usage - there always is.
> If pre-emptive paging tasks
> are still ideal for overall system =3D performance (counter=20
> intuitive- but I can accept that it may be necessary)
I guess where I was going with that line of argument, is that Windows is =
a
general purpose OS, and covers quite a variety of implementations. The
fundamental architecture isn't often redesigned - but has to cope with a
multitude of different scenarios, implementation scales, and levels of
usage.
As such, for a very general purpose architecture, I guess it fits a =
need.
When you get to specific scenarios, or selected peak performance, =
general
purpose exposes the compromises of form.
> the =3D
> option to do them in RAM is really quite logical.
Clearly that's based on the "If" from above, though. I guess what I'm =
saying
is that that aspect, when you consider bespoke scenarios, maybe =
something of
an undesirable.
Sure you can make it faster - but in general, such attacking the
bottlenecks, *tends* to just shift them around.
Creating less need, or asking the fundamental question of whether it can =
be
avoided, seem the best overall approach to that dilemma.
> So, if you
> are running as system =3D and you are quite sure that you have=20
> 1 or 2 GB (!!) of RAM free there really ought to be a way to=20
> put the solid state response times of RAM to work =3D for=20
> "required" paging activitie.
Working on the basis of the initial question you posed (the "If" from
above) seems a reasonably logical conclusion.
One which I've personally tested using solid-state devices for page file
usage. But if the pagefile usage is just really of the pre-emptive type =
(in
the main), I'd say there's little to be gained.
If the pagefile usage is pretty heavy, either more RAM would likely be =
of
use - or if you've reached limitations of the OS, where this is =
concerned,
making this paging significantly quicker, would likely just shift more =
to
CPUs to deal with much more of this on a shorter timescale
- and I'd say for most TSs (and perhaps most server implementations, =
albeit
not all) it's normal for this to be already reasonably high, if memory =
usage
is (because you've likely got a lot of activity creating the need for =
the
RAM, unless it's just a monolithic app that simply has huge memory
requirements).
Don't get me wrong, I appreciate the logical flow of your argument - but
taking a step back, for a second, you'd have to consider whether efforts =
are
best spent making paging as optimal as possible, or reducing / =
eliminating
paging.
Neil
***********************************************
This e-mail and its attachments are confidential
and are intended for the above named recipient
only. If this has come to you in error, please=20
notify the sender immediately and delete this=20
e-mail from your system.
You must take no action based on this, nor must=20
you copy or disclose it or any part of its contents=20
to any person or organisation.
Statements and opinions contained in this email may=20
not necessarily represent those of Littlewoods.
Please note that e-mail communications may be monitored.
The registered office of Littlewoods Limited and its subsidiaries is 100 =
Old
Hall Street, Liverpool, L70 1AB. Registered number of Littlewoods =
Limited is
262152.
************************************************
********************************************************
This weeks sponsor Emergent Online.
Emergent OnLine is the leading server-based computing consulting =
integration
firm in the nation. Emergent OnLine delivers expert=20
consulting services you can depend on.
http://www.go-eol.com
**********************************************************
Useful Thin Client Computing Links are available at:
http://thin.net/links.cfm
***********************************************************
For Archives, to Unsubscribe, Subscribe or=20
set Digest or Vacation mode use the below link:
http://thin.net/citrixlist.cfm
********************************************************
This weeks sponsor Emergent Online.
Emergent OnLine is the leading server-based computing consulting integration
firm in the nation. Emergent OnLine delivers expert
consulting services you can depend on.
http://www.go-eol.com
**********************************************************
Useful Thin Client Computing Links are available at:
http://thin.net/links.cfm
***********************************************************
For Archives, to Unsubscribe, Subscribe or
set Digest or Vacation mode use the below link:
http://thin.net/citrixlist.cfm
Other related posts:
