[ale] System Load Summary Script?

[Jim Kinney]

Ha! Weblogic. Say no more!
On Thu, 2019-06-27 at 11:45 -0500, Todor Fassl via Ale wrote:
> Never the less:
> https://it.wisc.edu/security/bitcoin-malware-removed-uw-madison-servers-services-restored/
> 
> 
> 
> On 6/26/19 9:44 PM, Jeff Hubbs wrote:
> > Anyone who is mining Bitcoin on even the most powerful extant
> > x86_64 server in 2019 is accomplishing essentially nothing.
> > On 6/26/19 6:06 PM, Todor Fassl wrote:
> > > I would not recommend ignoring high loads on a server these days.
> > > That could be a sign someone is mining bitcoins on your server.
> > > 
> > > 
> > > On 6/26/19 2:29 PM, Jeff Hubbs via Ale wrote:
> > > > On 6/26/19 1:58 PM, Todor Fassl via Ale wrote:
> > > > > Right, but that is my point. If I run uptime and I see the
> > > > > load on a system is high, I still have to manually figure out
> > > > > if it is cpu bound, memory bound, or disk IO bound, or
> > > > > network IO bound. If you google for tutorials on diagnosing
> > > > > load problems, they all say something like "First run top and
> > > > > look at column 10. Then run iotop and look at column 23. Then
> > > > > run netstat and ..." I don't think I should have to do that
> > > > > in 2019.
> > > > 
> > > > Maybe just go to lunch?
> > > > I'm only half-joking. Well, not even half.
> > > > At A Previous Employer (tm) the network operations group forced
> > > > the issue of running Nagios to monitor everything. I complied
> > > > and put a Nagios client on the Gentoo Linux file server I'd
> > > > designed, built, and managed for the entire company's use.
> > > > Every night this machine made Nagios absolutely explode with
> > > > warnings. Of course it would, I told them, it's running
> > > > mksquashfs on all the Samba share volumes to make backups and
> > > > it lights up every core in the box in so doing because the
> > > > RAID1+0 is insanely fast in read and it's writing to a
> > > > completely different set of spindles on a completely different
> > > > controller. Moreover, it would do the same thing whenever
> > > > ClamAV ran because ClamAV was nicely multithreaded and would
> > > > read at over 200MiB/s. It was expected, normal, and intended.
> > > > The "problem," plainly speaking, was Nagios.
> > > > The point of this graybeard parable is that machines turning
> > > > into hairdryers is not a bad thing on its face. It's different
> > > > if e.g. a) it can't complete something in the amount of time it
> > > > has to do it per line-of-business requirements b) you're
> > > > limited on electrical or cooling plant power c) your computers
> > > > are doing something with no utility or value. Just let the
> > > > things glow red and go to lunch.
> > > > _______________________________________________Ale mailing 
> > > > listAle at ale.org
> > > > https://mail.ale.org/mailman/listinfo/ale
> > > > See JOBS, ANNOUNCE and SCHOOLS lists at
> > > > http://mail.ale.org/mailman/listinfo
> 
> 
-- 
James P. Kinney III

Every time you stop a school, you will have to build a jail. What you
gain at one end you lose at the other. It's like feeding a dog on his
own tail. It won't fatten the dog.
- Speech 11/23/1900 Mark Twain

http://heretothereideas.blogspot.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.ale.org/pipermail/ale/attachments/20190627/96afe707/attachment.html>