<div dir="ltr"><div>Sorry I missed the meeting, but had a probable COVID exposure and so it wasn't worth the risk.</div><div><br></div><div>Brian</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 10, 2022 at 7:56 PM Bob Proulx <<a href="mailto:bob@proulx.com">bob@proulx.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">j dewitt wrote:<br>
> When: Tuesday May 10th, 2022, 6pm<br>
<br>
As typical we started with general discussion.<br>
<br>
VMS seems to have produced an actual supported release on 64-bit<br>
amd64.  Wow.  Will wonders never cease.<br>
<br>
    <a href="https://www.theregister.com/2022/05/10/openvms_92/" rel="noreferrer" target="_blank">https://www.theregister.com/2022/05/10/openvms_92/</a><br>
<br>
Phil started out probing to see if anyone would like to swap a server<br>
between houses on the FC city fiber and then they could use the<br>
storage space space for criss-cross offsite backup across the fiber<br>
network.<br>
<br>
Alex talked about the home guinea pigs.  One of them has a deformed<br>
leg.  Sad.  Stephen talked about the joys of parenting a teenager.<br>
Aaron related a similar parenting issue with his 12 year old.  Somehow<br>
the story of the guinea pigs with the physical deformity sounds less<br>
sad now.<br>
<br>
Discussions are great because we also talked about electromigration<br>
issues of VLSI metal connect.  Back to back with frozen exterior water<br>
spigots!<br>
<br>
Discussion of tradeoffs of high core cpus and number of I/O channels.<br>
The joys of large ram machines with more than 2 TB of RAM.<br>
<br>
Pricing of Amazon AWS services.  Absolutely EVERYTHING costs a very<br>
small micro-charge and that is multipled by a godzillian operations.<br>
Trying to budget for this is very difficult.  What is the result of a<br>
very small number multiplied by a very large number?  Who knows!<br>
<br>
Apache problems on a small server.  Apache wasn't running.  MariaDB<br>
was not running.  They were killed.  Various things were killed.  And<br>
no one knew until it was noticed.  So that could use some monitoring.<br>
But the problem was the Linux OOM Killer.  Due to external "Internet<br>
background radiation" probes of the web server could cause Apache to<br>
fork so many processes that the system would run completely out of<br>
memory and then processes would get killed by the OOM.<br>
<br>
When running Apache on the Internet it is necessary to benchmark how<br>
much RAM it uses and to tune the limits to keep the max number of<br>
processes below the available memory limits.  One can benchmark web<br>
server using "ab" the apache-benchmark program.  This was fired up<br>
immediately and and we watched it crash the web server by having it<br>
spawn too many processes.  Definitely a problem.<br>
<br>
Logcheck.  It's good for monitoring.  But it starts out as a firehose<br>
of noise from things that you don't care about.  So *if* you want to<br>
use logcheck then you have to immediately and agressively add filter<br>
rules to allow system log entries that are not important.<br>
<br>
Tonight were more disorganized than even out typical level.  But a<br>
good time was had by all.<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div>Brian Sturgill</div><div>President and CTO</div><div>Ataman Software, Inc.</div><div><br></div></div>