Chrome żre dwa rdzenie bez powodu - jak znaleźć przyczynę?

0

Podobno obraz wyraża więcej niż 1000 słów. Oto obraz nędzy i rozpaczy:
screenshot-20201229214254.png

Jak wyczaić dlaczego Chrome zjada tyle procka? Czasami (nic nie robiąc) Chrome zjada 0% procka, czasami jeden rdzeń, czasami dwa. Różnie. Nie wiem od czego to zależy. Menedżer zadań Chrome'a jak widać nie pomaga, bo całe obciążenie zawsze jest podpięte pod główny proces, a tego przecież nie ubiję.

1

Zapnij się perfem/stracem i zobacz co on robi

0

Hmm, odpaliłem Chrome'a przez strace'a i dostaję w konsoli masę spamu tego typu (sorry, że zrzut ekranu, ale zbyt dużo tego spamu):
screenshot-20201229221446.png
Co by tu teraz z tym zrobić?

6

Najprostsze rozwiązanie:
Menu Start -> Ustawienia -> Aplikacje -> Chrome -> Odinstaluj.

A potem zacznij korzystać z Firefoxa. Można go pobrać stąd - https://www.mozilla.org/pl/firefox/download/thanks/

screenshot-20201229221724.png

0

RAMu mam pod dostatkiem. Chrome może nawet 10 GiB extra zjadać i nie będzie problemu. Problem jest z CPU, bo mi benchmarki w losowych momentach dają mocno nietypowe wyniki.

0

Jak rozumiem zapiąłeś się pod tego zachłannego na CPU pida, powyłączałeś jakieś procesy inne chrome (czyli inne karty)? I czy to jest moment, w którym strace pokazuje ciągle te same sekwencje syscalli czy "czeka" na jakimś?

Najpierw upewnij się, że nic innego od Chrome nie chodzi w tle i to jest jedyny proces, który "coś robi"

0

Kart nie wyłączyłem, ale teraz podłączyłem się pod PIDa pokazanego w menedżerze zadań Chrome'a i jest mniej więcej to samo. Żaden inny program oprócz Chroma nie chodzi.

Posprawdzałem dalej i te błędy dotyczą: /proc/23463/fd/131 -> 'socket:[1435995]'

Dobra. Pozamykałem inne karty, została tylko ta z tym tematem na 4p. Nadal Chrome wciąga CPU jak szalony.

Zacząłem się bawić wtyczkami. Po wyłączeniu Ghostery obciążenie CPU spadło. Zobaczę na strace jeszcze.

1

Czy sprawdziłeś, jak Chrome działa na ustawieniach domyślnych? (m.in. bez wtyczek, skórek, rozszerzeń itp.)


UPDATE: https://support.google.com/chrome/answer/3296214?hl=en

0

Sprawdziłem jak działa bez Ghostery. strace mocno się uspokaja, zużycie CPU spada do normalnego poziomu (pojedyncze procenty). Dziwne, że tego w menedżerze zadań Chroma nie widać.

0

Takich rzeczy we wbudowanych managerze zadań w Chrome bym nie szukał.

Możesz jeszcze użyć tcpdumpa/wiresharka, aby sprawdzić, czy jak włączysz Ghostery, to ono nie ma "ekstra" komunikacji sieciowej (i processing tej komunikacji może spowodować spike CPU). Jeśli Chrome coś "miele" na dysku lub na coś czeka z dysku (wtedy też o dziwo często CPU lubi wisieć obciążony) lub jakiegoś urządzenia z /dev to pomogą Ci komendy iotop lub iostat

Ponadto na linuksach używałbym chromium zamiast chrome - to w zasadzie chrome, ale bez telemetrii i "automatyzacji" od Google

0

Hmm, jednak wywalenie Ghostery nic nie dało. I tak mi losowo zaczyna obciążać CPU. Wbiłem na YouTube i mam 40% zużycia CPU (czyli prawie dwa rdzenie) i tak mi zostało nawet po zamknięciu YouTube'a.
:/

0

@Wibowit: A sprawdzałeś jakoś co stoi za deskryptorami 30 i 31? Druga rzecz: dodaj do parametrów wywołania strace "-tt" i wrzuć gdzieś log z tego strace'a.

0
vtx napisał(a):

@Wibowit: A sprawdzałeś jakoś co stoi za deskryptorami 30 i 31?

Sprawdziłem inne:

Wibowit napisał(a):

Posprawdzałem dalej i te błędy dotyczą: /proc/23463/fd/131 -> 'socket:[1435995]'

I chyba to był socket typu AF_UNIX ale nie pamiętam dokładnie.

vtx napisał(a):

Druga rzecz: dodaj do parametrów wywołania strace "-tt" i wrzuć gdzieś log z tego strace'a.

Na razie problem minął. Zrobiłem reset Chrome'a, zastąpiłem Ghostery inną wtyczką, pozmieniałem jakieś ustawienia i jest na razie OK (odpukać). Nadal nie wiem co konkretnie było przyczyną problemu.

1
Wibowit napisał(a):
vtx napisał(a):

@Wibowit: A sprawdzałeś jakoś co stoi za deskryptorami 30 i 31?

Sprawdziłem inne:

Wibowit napisał(a):

Posprawdzałem dalej i te błędy dotyczą: /proc/23463/fd/131 -> 'socket:[1435995]'

I chyba to był socket typu AF_UNIX ale nie pamiętam dokładnie.

vtx napisał(a):

Druga rzecz: dodaj do parametrów wywołania strace "-tt" i wrzuć gdzieś log z tego strace'a.

Na razie problem minął. Zrobiłem reset Chrome'a, zastąpiłem Ghostery inną wtyczką, pozmieniałem jakieś ustawienia i jest na razie OK (odpukać). Nadal nie wiem co konkretnie było przyczyną problemu.

W sumie trochę szkoda że problem zniknął. Możnaby podebugować :) Na przyszłość komenda: lsof -p <pid_chrome'a> - pokazuje co stoi za jakim deskryptorem. A opcja "-tt" do strace pokazuje timestamp czyli możnaby mniej więcej dowiedzieć się jak często następują wywołania syscall - tutaj akurat recvmsg().

0

U mnie (Opera) pomogło w takiej sytuacji usunięcie wszystkich cookies i zapisanych danych witryn, chociaż zastanawiam się, czy to może być to, skoro zamknąłeś wszystkie karty z wyjątkiem jednej.

3

Odpal chrome w dockerze przydzielając mu jakieś ograniczone zasoby :D

0

@Wibowit: próbowałeś oglądać z chromowego trejsera co to może być? W pasku adresu chrome://tracing/ i można spróbować zebrać materiał do przemyśleń.

Inna opcja, to zebranie stacków i dalsze przemyślenia co może być nie tak. Można zebrać i zrobić wizualizację: https://github.com/brendangregg/FlameGraph

1 użytkowników online, w tym zalogowanych: 0, gości: 1