[Discuss] I need a recommendation for a Linux-compatible high-end PC builder
Cy Schubert
Cy.Schubert at cschubert.com
Sun Jan 28 21:16:16 PST 2018
In message <CACZuhdvXHA1zdjYMDty+p3UxcEPH4NTFcdn_2EKcP8YnzGERjg at mail.gma
il.com>
, Andrew Burgess writes:
> --===============0270033715595614946==
> Content-Type: multipart/alternative; boundary="001a1140c7ea7d7d120563dce0b3"
>
> --001a1140c7ea7d7d120563dce0b3
--
Cheers,
Cy Schubert <Cy.Schubert at cschubert.com>
FreeBSD UNIX: <cy at FreeBSD.org> Web: http://www.FreeBSD.org
The need of the many outweighs the greed of the few.
> Content-Type: text/plain; charset="UTF-8"
>
> Can you not set up a script that safely reboots the system once a week at
> like 2am?
Memory leaks should be fixed. As an O/S developer I appreciate bug
reports, especially detailed bug reports. It all helps.
Report the bug to your distro provider. Even if you don't have the
details now a developer should be able to ask you to run the commands
needed to gather the information needed to pinpoint and fix the bug.
Did you know you can use top to discover which processes are using swap
and how much they use? On older Linux top you can use the o and O
commands to rearrange columns and change the sort order. On new Linux
top it's the f command. (And for FreeBSD users here it's the w and o
commands.)
>
> 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
> >
>
> --001a1140c7ea7d7d120563dce0b3
> Content-Type: text/html; charset="UTF-8"
> Content-Transfer-Encoding: quoted-printable
>
> <div dir=3D"auto">Can you not set up a script that safely reboots the syste=
> m once a week at like 2am?</div><div class=3D"gmail_extra"><br><div class=
> =3D"gmail_quote">On Jan 28, 2018 1:14 PM, "Alan W. Irwin" <<a =
> href=3D"mailto:irwin at beluga.phys.uvic.ca">irwin at beluga.phys.uvic.ca</a>>=
> wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"=
> margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2018-01-2=
> 8 12:17-0800 Alan W. Irwin wrote:<br>
> <br>
> [...]<br>
> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
> x #ccc solid;padding-left:1ex">
> I just<br>
> don't get for large RAM systems why there is any major speed gain at al=
> l<br>
> from an SSD that is dedicated to system files (with the exclusions you<br>
> mentioned above to keep the write wear down).=C2=A0 The size of the "/=
> "<br>
> partition on my current system is "only" 18G.=C2=A0 Let's mak=
> e 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.=C2=A0 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.=C2=A0 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 a=
> ny<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 "m=
> orning<br>
> sickness".=C2=A0 That is overnight jobs (the normal ones and also an<b=
> r>
> 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.=C2=A0 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.=C2=A0 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".=C2=A0 And I just don't think the complexity =
> (e.g., special<br>
> configuration measures required to avoid writes) and cost of SSD's is<b=
> r>
> 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.=C2=A0 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.=C2=A0 For example, I have recently<b=
> r>
> used the "noscript" Firefox extension to look at the large hierar=
> chy<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.=C2=A0 But I<b=
> r>
> 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=3D"http://astrowww.phys.uvic.ca" rel=3D"nor=
> eferrer" target=3D"_blank">astrowww.phys.uvic.ca</a>).<br>
> <br>
> Programming affiliations with the FreeEOS equation-of-state<br>
> implementation for stellar interiors (<a href=3D"http://freeeos.sf.net" rel=
> =3D"noreferrer" target=3D"_blank">freeeos.sf.net</a>); the Time<br>
> Ephemerides project (<a href=3D"http://timeephem.sf.net" rel=3D"noreferrer"=
> target=3D"_blank">timeephem.sf.net</a>); PLplot scientific plotting<br>
> software package (<a href=3D"http://plplot.sf.net" rel=3D"noreferrer" targe=
> t=3D"_blank">plplot.sf.net</a>); the libLASi project<br>
> (<a href=3D"http://unifont.org/lasi" rel=3D"noreferrer" target=3D"_blank">u=
> nifont.org/lasi</a>); the Loads of Linux Links project (<a href=3D"http://l=
> oll.sf.net" rel=3D"noreferrer" target=3D"_blank">loll.sf.net</a>);<br>
> and the Linux Brochure Project (<a href=3D"http://lbproject.sf.net" rel=3D"=
> noreferrer" target=3D"_blank">lbproject.sf.net</a>).<br>
> __________________________<br>
> <br>
> Linux-powered Science<br>
> __________________________<br>
> <br>
> ______________________________<wbr>_________________<br>
> Discuss mailing list<br>
> <a href=3D"mailto:Discuss at vlug.org" target=3D"_blank">Discuss at vlug.org</a><=
> br>
> <a href=3D"http://vlug.org/mailman/listinfo/discuss_vlug.org" rel=3D"norefe=
> rrer" target=3D"_blank">http://vlug.org/mailman/listin<wbr>fo/discuss_vlug.=
> org</a><br>
> </blockquote></div></div>
>
> --001a1140c7ea7d7d120563dce0b3--
>
>
> --===============0270033715595614946==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
>
> _______________________________________________
> Discuss mailing list
> Discuss at vlug.org
> http://vlug.org/mailman/listinfo/discuss_vlug.org
>
> --===============0270033715595614946==--
>
More information about the Discuss
mailing list