[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