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