Old Dual Pentium III 500Mhz Servers

[Bryn M. Reeves]

On Wed, 2009-11-11 at 03:50 +1030, Tim wrote:
> On Tue, 2009-11-10 at 23:47 +1100, David Timms wrote:
> > Things to think about:
> > - if you are talking about the same machine, disk drive tiredness
> > would have reduced the access speed that you can achieve, when r/w to
> > disk.
> 
> Beg yours...  drive tiredness?  The old gray mare not what she used to
> be?  Since when do drives become old age pensioners with blankets on
> their laps, day dreaming about the old days, instead of doing the same
> as they were doing last week?

Since they use sector remapping to recover failed errors and ECC/parity
codes to recover data errors. As sectors have to be remapped elsewhere
on disk seek overheads will increase. There may also be further
penalties as the recoverable media error rate rises, i.e. the disk has
to issue repeated reads to correctly retrieve the data for a particular
sector.

Sometimes you'll see this acutely when a sector is failing - the drive
will appear to go out to lunch for a moment when the tricky sector is
accessed. If spare sectors are still available a write to the offending
location may cause the drive to spare it out and avoid the problem for a
while.

Looking at the S.M.A.R.T. reports for the drive can help you understand
if this is the problem for a particular system.

Often though I've seen users diagnose a problem like this as "old
hardware getting slow" when in fact it's a software or file system
issue.

> > - more stuff relying on storage/retrieval of information from 
> > inefficient storage formats like xml
> 
> Reminds me of back when I was using an Amiga - any program that stored
> its configuration in a text file took ages to parse it as the program
> started up.  Whereas those that stored their data in the programs binary
> format were very nippy.
> 
> Even now, on fast GHz CPUs, I've noticed that you can get Apache or
> Squid to start up much quicker if you purged the masses of comments out
> of the configuration file, so the program had less to parse.
> 
> Yes, the programs do parse the comments, they've got to find the end of
> the comment to find the next instructions that they're going to use, the
> whole file is parsed.

Depends how you look at it - most comment notations have a
line-delimiter (e.g. # in apache). This only requires examining the
first character of the line to know that the rest must be ignored (of
course the entire line must still be read into memory which does impose
overhead especially if there are many lines of commentary as is often
the case for default config files). Block comments do require consuming
characters until the end-of-comment token is reached.
 
> Computer users nightmare number 9:  Part way through the installation
> process, a message pops up, "You're going to need a bigger boat"

Nice way of putting it!

Regards,
Bryn.