Re: Killing only selected Chrome windows from the CLI ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



JD,


On 2018-03-28 10:27, JD wrote:
On 03/26/2018 07:53 PM, Philip Rhoades wrote:
Samuel,


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 . .

P.
Phil,
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 . .

Thanks,

Phil.
--
Philip Rhoades

PO Box 896
Cowra  NSW  2794
Australia
E-mail:  phil@xxxxxxxxxxxxx
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx



[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux