[THIN] Re: No Pagefile for TS?
- From: "Braebaum, Neil" <Neil.Braebaum@xxxxxxxxxxxxxxxxx>
- To: <thin@xxxxxxxxxxxxx>
- Date: Mon, 15 Mar 2004 15:47:46 -0000
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?
>
> Neil,=20
>
> Except the whole issue of both paging and virtual memory swap
> is = predicated on RAM being at a premium.
Agreed - fair point.
> RAM has been cheap
> and abundant for a long = 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 = performance (counter
> 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 =
> 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 = and you are quite sure that you have
> 1 or 2 GB (!!) of RAM free there really ought to be a way to
> put the solid state response times of RAM to work = for
> "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
notify the sender immediately and delete this
e-mail from your system.
You must take no action based on this, nor must
you copy or disclose it or any part of its contents
to any person or organisation.
Statements and opinions contained in this email may
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
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:
