[ale] System Load Summary Script?
Todor Fassl
fassl.tod at gmail.com
Thu Jun 27 12:45:48 EDT 2019
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 list
>>> Ale at ale.org
>>> https://mail.ale.org/mailman/listinfo/ale
>>> See JOBS, ANNOUNCE and SCHOOLS lists at
>>> http://mail.ale.org/mailman/listinfo
>>
>
--
Todd
More information about the Ale
mailing list