Re: disk or RAM
- From: AL <lithar@xxxxxxxxxxxxxxx>
- Date: Mon, 02 Mar 2009 18:28:50 -0600
Roedy Green wrote:
Early in my career I learned the throwing more RAM at a problem
sometimes hurt. Back then when a computer was sold, the vendor had to
run a benchmark to prove the mettle of his machine, with the benchmark
provided by the customer. The vendor was allowed to tweak it to suit
that machine. These bencharks were less a matter of the mettle of the
machine as the teams of tweakers.
So what are some of the rules of thumb. When should you put something
in RAM and when on disk? How big should you make buffers?
I recall with fondness skunking IBM by a factor of seven on a
benchmark when their computer cost twice as much. They asked for
another turn. To their great embarrassment, the new results were
worse! They did not understand these principles.
This is primarily a question for students, but old timers are welcome
to toss in their nuggets of wisdom.
Well, an "old timer" might tell you the buffer in RAM is simply a multiple of the record blocking of the data file which is largely determined by the track/sector mapping of the particular disk. If the file was read sequentially it was necessary to provide enough buffering that the disk read could stay a block or two ahead of the sequential read through the buffer in RAM - most times 3-4 blocks worth of buffering was enough for each file being processed sequantially. If random access was used, a single block's worth of buffering was usually enough for the data file - multiple buffers were desirable for the index file so all of it could reside in RAM. Since all this was continually being paged in & out of RAM as 30-40+ other programs were running with varying levels of compute priorities, tuning the system was a near impossibility without performance monitoring.
Regarding large tables or arrays in memory - I almost always opted for disk I/O unless I was programming closer to the metal, which I rarely bothered to do.
Benchmark? Good luck! My only benchmark was running the same 30-40+
processes in one system with a stopwatch, then in the proposed system.
Simply running a benchmark on a single job yielded worthless info.
I will say I never had the budgetary luxury of throwing too much RAM at
a problem. Every increment I did manage to add was always money well spent.
Well, that's what one "old timer" *might* say - not exactly a nugget of
wisdom would you say?
.
- Prev by Date: Log4j logging cases...
- Next by Date: Waiting for end after calling BAT file
- Previous by thread: Re: disk or RAM
- Next by thread: Re: oo design books
- Index(es):
Relevant Pages
|
