[Discuss] I need a recommendation for a Linux-compatible high-end PC builder

[Andrew Burgess]

Can you not set up a script that safely reboots the system once a week at
like 2am?

On Jan 28, 2018 1:14 PM, "Alan W. Irwin" <irwin at beluga.phys.uvic.ca> wrote:

> On 2018-01-28 12:17-0800 Alan W. Irwin wrote:
>
> [...]
>
>> I just
>> don't get for large RAM systems why there is any major speed gain at all
>> from an SSD that is dedicated to system files (with the exclusions you
>> mentioned above to keep the write wear down).  The size of the "/"
>> partition on my current system is "only" 18G.  Let's make the
>> ridiculous assumption that all those files are actually used (rather
>> than just there in case of need which is likely true for the vast
>> majority of them). Then if you had large amounts of RAM
>> (such as the 64GB I am about to buy) Linux would automatically cache
>> all those files in RAM to give you essentially instantaneous access to
>> them.  So on large RAM systems the SSD would speed up access to the
>> system files the first time you used them after a boot, but then after
>> that the SSD would never be used again for that file until the next
>> boot.  Of course, I am making the assumption here that most system
>> files are only read and not written, but an attempt is made with SSD's
>> to exclude the parts of the "/" partitition that are written in any
>> case so I don't think this can be an important argument against this
>> interpretation.
>>
>> The above mental model jibes with my own practical experience which is
>> for a system with "only" 4GB of RAM, I do get what I call "morning
>> sickness".  That is overnight jobs (the normal ones and also an
>> additional one in my case that builds and tests CMake and PLplot on a
>> nightly basis) completely exhaust the cache of files that Linux keeps
>> in RAM (and the disk cache that is part of the HDD hardware) so the
>> initial access by me each day tends to be slow.  But from then on that
>> day, the relevant file is cached in RAM so access is quick for a
>> system without an SSD.  What I am arguing above is for RAM large
>> enough, this morning sickness would go completely away (because the
>> overnight tasks would not exhaust the RAM cache), and be turned into
>> "boot sickness".  And I just don't think the complexity (e.g., special
>> configuration measures required to avoid writes) and cost of SSD's is
>> justified just to reduce (not remove) morning sickness, and the
>> argument becomes even stronger if an SSD is only going to reduce boot
>> sickness.
>>
>
> I should have also mentioned another major assumption in the above
> mental mode which is there are no memory leakers (processes that
> require more and more memory as time progresses because they forget to
> free memory that is no longer required). Such memory leakers starve
> systems for memory as time progresses so in this case SSD's would give
> noticeably better performance than HDD's.  Note that even if your
> operating system is free of memory leakers poorly implemented
> javascript files distributed from badly maintained or malignant
> websites can also create memory leaks.  For example, I have recently
> used the "noscript" Firefox extension to look at the large hierarchy
> of different domains used for javascript by complex websites such as
> The Weather Network, and even with the best will in the world it must
> be difficult for them to eliminate all javascript memory leaks
> considering the large number of different companies involved.  But I
> am going to start watching that closely since a google search found at
> least one instance where a major javascript memory leak occurred for
> one of the users of The Weather Network.
>
> Of course, ideally you do manage to avoid running memory leakers
> (either from your operating system or via javascript) in which case I
> think the above mental model of why SSD's don't help system
> performance that much must still be correct.
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
>
> _______________________________________________
> Discuss mailing list
> Discuss at vlug.org
> http://vlug.org/mailman/listinfo/discuss_vlug.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://vlug.org/pipermail/discuss_vlug.org/attachments/20180128/7f47a6f8/attachment.html>