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