On 2018-03-28 10:27, JD wrote:
On 03/26/2018 07:53 PM, Philip Rhoades wrote:
> On 2018-03-27 12:18, Samuel Sieb wrote:
>> On 03/26/2018 05:59 PM, Philip Rhoades wrote:
>>> but it is not what I want to do - when Chrome goes mad and the whole
>>> system starts grinding to a halt (I know from experience it is
>>> Chrome) I want to try and work out what specific Chrome tab or
>>> window is the problem. Chrome has its own task manager:
>> If you run top, which process is using the CPU? Just kill that one,
>> then go through your chrome tabs and find out which tab has the sad
>> face on it.
> That usually doesn't work from my recollection, no individual tab
> seems to be a problem - it is either Chrome as a whole or a whole
> window I think . . obviously shutting down all of Chrome fixes the
> problem . . but it is a pain to gradually re-open all the windows I
> previously had open again . .
How about using the trial and error method.
Kill one window (press the X on the right hand upper corner :) )
and then check the cpu load in a full screen cli window.
if the load is still high, at least u will have eliminated that window.
so try this with each window and check the cpu load.
The one that brings the load down (after killing it :) )
is the culprit.
The problem is that the GUI becomes VERY unresponsive so that is why I
preferred a CLI method - because terms seemed relatively unaffected and
I don't have to use mouse clicks - but also because it would be nice to
just iterate through a list killing IDs of something and immediately
know what was happening - it still might require killing every single
Chrome process of course . .
It is also odd that the graphical CPU and disk activity indicators do
not show much happening but that might be because of the afore-mentioned
GUI unresponsiveness - I can definitely HEAR more disk activity and top
SEEMS to show more CPU activity of Chrome processes. The problem seems
to go rapidly exponential from minor interactive delays to the GUI being
almost unusable with longer and longer waits between the mouse being
responsive - so I don't have a convenient before and after problem view
of what was happening with top. I might see if I can log the top output
to disk and find a method of reliably recreating the problem . .
While u r at it, also check the mem usage of chrome. High mem usage
can cause a lot of paging and even swapping if u r a small ram. But
if you have plethora of RAM, then u need not worry about it. U should
have at least 2 X RAM as SWAP space. Since I run a lot of apps, I have
4X RAM as SWAP on HD.
32GB RAM and 32GB of SWAP which doesn't get used. I will keep working
on it but at the moment, it looks like ALL Chrome processes start using
more RAM and cause more disk activity . .
PO Box 896
Cowra NSW 2794