[Egyelõre úgy néz ki, hogy SOLVED] Debian Jessie magas CPU-terhelés tétlen állapotban

Debian GNU/Linux

Sziasztok!

Nemrég frissítettem az általános PC-nk Debian Wheezy (7) rendszerét Jessie-re (8). A saját másodlagos gépemen állandó "testing" verzió fut, így a Jessie "viselt dolgaival" többé-kevésbé tisztában voltam (legalábbis azt hittem).

Az átállás következményeként a gépen folyamatosan 90-100% közötti CPU használatot tapasztaltunk, ami nem javult az "idő múlásával" (bootolás után x órával) sem. Rákerestem angol nyelven a problémára, első körben azt találtam az egyik fórumon, hogy ezt okozhatja, ha a /dev/kmsg nem valós eszköz, hanem linkként mutat a /dev/console - de nálam ez rendben volt.

Másik helyen mondták, hogy pl. CUPS vagy a clamav frissítő daemon is okozhatja ezt Jessie-n.
Ezek után - mivel a géphez nem kapcsolódik nyomtató - lelőttem a CPUS-ot, valamint az Apache servert (és még pár nem igazán használt service-t), de ez sem adott megoldást.

Tovább keresgéltem a hibát; az egyik fórumon találtam egy infot, hogy a journactl paranccsal nézzem a rendszerüzeneteket, és keressem benne a clamavval kapcsolatos hibákat. Ilyet nem találtam, viszont találtam gnome-session és systemd hibákat, miszerint a /run/user/1000/dconf/user nem írható. Rákerestem a hibaüzenetre, elég szép "irodalmat" találam hozzá: a lényeg az, hogy az ownernek (user és group egyaránt) 1000-nél a 1000-es uid-ű usernek kell lennie, nálam a root volt. Jogosultság beállítás után leesett a CPU használat közel 0-ra tétlen állapotba (nagy volt az öröm).

Amiért most mégis írok: sajnos az öröm nem tartott sokáig; valamiért a rendszer úgy megy, hogy bootolás után kb. fél óráig minden rendben van, utána viszont egyik pillanatról a másikra felmegy a CPU használat ismét 100% közelébe.

Keresgéltem tovább, de kb. elakadtam: mindenhol apache szerver bugra, mono-s scriptekre, stb. találok válaszokat, de ilyenek nálam nincsenek.

Merre tudnék innen továbbmenni? Konkrét hibaüzenetem nincs (nem találok), általános kulcsszóval (magas CPU használat) pedig túlnyomórészt irreleváns keresési találatot kapok, amelyek között alig tudok olyat találni, aminek bármi köze lehetne az én rendszeremnél tapasztaltakhoz.

Ugyanilyen hibát egyáltalán nem láttam a Jessie fejlesztési folyamata alatt a másik (folyamatosan frissített) Debian testing-es gépnél, így onnan sem tudok semmilyen információt szerezni... ráadásul azon a gépen 64 bites Debian fut...

Bármilyen segítséget megköszönnék, amin elindulhatok.

HW:
- AMD Sempron 2600 egymagos CPU
- VIA K8 alaplap
- 2 GB RAM
- Nvidia Geforce 7800 GS
- parallel ATA HDD

SW:
- Debian 8 - 32 bites
- Gnome/Mate környezet (felhasználónként változó)
- Proprietary NVIDIA driver csomagból

Ha még valami érdekes lehet, akkor megírom.

Köszi

borosspet

  • 3342 megtekintés

( blackluck v | 2015. 06. 07., v – 22:02 )

top -ban mi latszik azon felul, hogy cpu 100%, milyen cpu hasznalat, sys, user, io wait stb. (gondolom az nem latszik melyik process viszi a terhelest), nem fogy el esetleg memoria es swap-elni kezd erosen?

"valamiért a rendszer úgy megy, hogy bootolás után kb. fél óráig minden rendben van, utána viszont egyik pillanatról a másikra felmegy a CPU használat ismét 100% közelébe"
Ezt be tudod hatarolni konkretabban, pl ujrainditashoz kepest x ido elteres vagy esetleg mindig egesz orakor, netan valamit csinalsz es azutan, ha nem grafikus feluleten lepsz be, csak siman console-on akkor is felmegy fel ora utan a terheles?

sudo journalctl -f nem mond esetleg valamit olyankor, hogy mi dolgozik?

Probaltad egyessevel kiloni a processeket, megvonni tole a netet stb. hogy jobban behatarolhato legyen mi emeli meg cpu hasznalatot?

Szia!

Köszi a tippeket; a jelenlegi válaszaim a kérdéseidre:

- Top-ot nem használtam még idáig; a rendszerfigyelő szerint a /run/user/1000/dconf/user hiba javításáig a systemd használta a legtöbb CPU időt, azóta a xorg-ot látom...

- Az az igazság, hogy arra nem volt sosem idő, hogy üresen menjen a gép; mindig végeztünk vele valamit (pl. telepítettem, konfiguráltam vagy a gyerekek játszottak rajta). Konzolban hogyan tudom ellenőrizni a CPU pillanatnyi terhelését?
(Vélhetően amiatt, hogy a dconf hiba után a xorg-ot láttam sok CPU-t foglalni, a jelenség konzolban nem jelentkezne.)

- a sima journalctf parancshoz képest miben ad más kimenetet a -f kapcsolós változat?

- Igazából idáig csak a működést nem zavaró service-ket állítgattam le; processz kilövéssel óvatos lennék, mert egy systemd kilövésének szerintem mélyreható következményei lehetnek - és sok olyan processz van, amiről nem tudom, mit csinál pontosan...

Mindenesetre még egyszer köszönöm a tippeket, javaslatokat; ezen már el tudok indulni és utána jelentkezem.

Nagyon jók voltak a tippek.

Egyrészt: egy kiváltó okot már találtam: firefox elindítása és leállítása (de nem csak ez okozza, mert biztosan emlékszem arra, hogy korábban olyankor is előjött a probléma, amikor nem indítottam el a rókát).

A firefox leállításkori hibaüzeneteket kimásoltam a journalctl-bõl:


jún 07 22:48:49 localhost /etc/gdm3/Xsession[1584]: *************************
jún 07 22:48:49 localhost /etc/gdm3/Xsession[1584]: A coding exception was thrown and uncaught in a Task.
jún 07 22:48:49 localhost /etc/gdm3/Xsession[1584]: Full message: TypeError: Filter is null
jún 07 22:48:49 localhost /etc/gdm3/Xsession[1584]: Full stack: INIParser.prototype.process@resource://gre/modules/addons/XPIProvider.jsm -> file:///usr/share/mozilla/extensions/%7Bec8030f7-c20a-464f-9b0e-13a3a9e97384%7D/%7Bd10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d%7D/bootstrap.js -> file:///usr/share/mozilla/extensions/%7Bec8030f7-c20a-464f-9b0e-13a3a9e97384%7D/%7Bd10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d%7D/lib/filterStorage.js:789:9
jún 07 22:48:49 localhost /etc/gdm3/Xsession[1584]: exports.IO.readFromFile/onProgress@resource://gre/modules/addons/XPIProvider.jsm -> file:///usr/share/mozilla/extensions/%7Bec8030f7-c20a-464f-9b0e-13a3a9e97384%7D/%7Bd10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d%7D/bootstrap.js -> file:///usr/share/mozilla/extensions/%7Bec8030f7-c20a-464f-9b0e-13a3a9e97384%7D/%7Bd10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d%7D/lib/io.js:97:15
jún 07 22:48:49 localhost /etc/gdm3/Xsession[1584]: exports.IO.readFromFile/<@resource://gre/modules/addons/XPIProvider.jsm -> file:///usr/share/mozilla/extensions/%7Bec8030f7-c20a-464f-9b0e-13a3a9e97384%7D/%7Bd10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d%7D/bootstrap.js -> file:///usr/share/mozilla/extensions/%7Bec8030f7-c20a-464f-9b0e-13a3a9e97384%7D/%7Bd10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d%7D/lib/io.js:182:11
jún 07 22:48:49 localhost /etc/gdm3/Xsession[1584]: TaskImpl_run@resource://gre/modules/Task.jsm:330:41
jún 07 22:48:49 localhost /etc/gdm3/Xsession[1584]: Handler.prototype.process@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:867:23
jún 07 22:48:49 localhost /etc/gdm3/Xsession[1584]: this.PromiseWalker.walkerLoop@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:746:7
jún 07 22:48:49 localhost /etc/gdm3/Xsession[1584]: this.PromiseWalker.scheduleWalkerLoop/<@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:688:37
jún 07 22:48:49 localhost /etc/gdm3/Xsession[1584]: *************************
jún 07 22:48:49 localhost /etc/gdm3/Xsession[1584]: *************************
jún 07 22:48:49 localhost /etc/gdm3/Xsession[1584]: A coding exception was thrown in a Promise rejection callback.
jún 07 22:48:49 localhost /etc/gdm3/Xsession[1584]: See https://developer.mozilla.org/Mozilla/JavaScript_code_modules/Promise.jsm/Promise
jún 07 22:48:49 localhost /etc/gdm3/Xsession[1584]: Full message: TypeError: Cu is null
jún 07 22:48:49 localhost /etc/gdm3/Xsession[1584]: Full stack: exports.FilterStorage.loadFromDisk/readFile file:///usr/share/mozilla/extensions/%7Bec8030f7-c20a-464f-9b0e-13a3a9e97384%7D/%7Bd10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d%7D/bootstrap.js -> file:///usr/share/mozilla/extensions/%7Bec8030f7-c20a-464f-9b0e-13a3a9e97384%7D/%7Bd10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d%7D/lib/filterStorage.js:385:11
jún 07 22:48:49 localhost /etc/gdm3/Xsession[1584]: exports.IO.readFromFile/onError@resource://gre/modules/addons/XPIProvider.jsm -> file:///usr/share/mozilla/extensions/%7Bec8030f7-c20a-464f-9b0e-13a3a9e97384%7D/%7Bd10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d%7D/bootstrap.js -> file:///usr/share/mozilla/extensions/%7Bec8030f7-c20a-464f-9b0e-13a3a9e97384%7D/%7Bd10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d%7D/lib/io.js:149:9
jún 07 22:48:49 localhost /etc/gdm3/Xsession[1584]: Handler.prototype.process@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:870:21
jún 07 22:48:49 localhost /etc/gdm3/Xsession[1584]: this.PromiseWalker.walkerLoop@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:746:7
jún 07 22:48:49 localhost /etc/gdm3/Xsession[1584]: this.PromiseWalker.scheduleWalkerLoop/<@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:688:37
jún 07 22:48:49 localhost /etc/gdm3/Xsession[1584]: *************************
jún 07 22:49:27 localhost /etc/gdm3/Xsession[1584]: Figyelmeztetés az ablakkezelőtől: Log level 8: Source ID 863 was not found when attempting to remove it

Ezenkívül készítettem egy top snapshotot is: 


top - 22:53:59 up 12 min,  5 users,  load average: 2,41, 2,10, 1,24
Tasks: 161 total,   5 running, 156 sleeping,   0 stopped,   0 zombie
%Cpu(s): 80,9 us, 18,5 sy,  0,0 ni,  0,0 id,  0,0 wa,  0,0 hi,  0,7 si,  0,0 st
KiB Mem:   2072228 total,   898648 used,  1173580 free,    73808 buffers
KiB Swap:  1062908 total,        0 used,  1062908 free.   472064 cached Mem

  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND     
    1 root      20   0   23628   4516   2940 R 41,4  0,2   2:28.12 systemd     
  763 message+  20   0    6004   3936   2912 R 41,1  0,2   2:27.32 dbus-daemon 
  717 root      20   0    3820   2776   2492 S  9,6  0,1   0:34.66 systemd-log+
 1252 root      20   0  141744  68808  23740 S  3,0  3,3   0:23.81 Xorg        
 1990 root      20   0   71024  28232  22092 S  1,3  1,4   0:05.05 gnome-termi+
 2290 pet       20   0   84208  32592  26648 S  1,3  1,6   0:01.02 gedit       
 1639 pet       20   0   51008  22264  19936 S  0,7  1,1   0:01.78 marco       
 1808 pet       20   0   56696  19704  17448 S  0,7  1,0   0:04.21 multiload-a+
    7 root      20   0       0      0      0 R  0,3  0,0   0:02.77 rcu_sched   
   22 root      20   0       0      0      0 S  0,3  0,0   0:00.23 kworker/0:1 
 1735 pet       20   0   18232   4720   4340 S  0,3  0,2   0:00.14 at-spi2-reg+
 1806 pet       20   0   58472  20996  18312 S  0,3  1,0   0:01.70 wnck-applet 
    2 root      20   0       0      0      0 S  0,0  0,0   0:00.00 kthreadd    
    3 root      20   0       0      0      0 R  0,0  0,0   0:00.39 ksoftirqd/0 
    5 root       0 -20       0      0      0 S  0,0  0,0   0:00.00 kworker/0:0H
    8 root      20   0       0      0      0 S  0,0  0,0   0:00.00 rcu_bh      
    9 root      rt   0       0      0      0 S  0,0  0,0   0:00.00 migration/0

Ki tudsz ezekből (főleg a hibaüzenetből) valamit olvasni?

Köszi

borosspet

Szamomra ennyibol nem jon le konkretabban mi a gond csak hogy dbus terheli a gepet, amiket erdemes lehetne megprobalni:
- kezzel inditani firefox-ot konzolbol, talan van valami debug/verbose opcioja amivel hatha tobbet latsz
- journalctl -f -el (-f csak annyi hogy folyamatosan irja, mintha tail -f /var/log/syslog -ot probalnad) nezni amikor inditod firefox-ot, illetve mikor terheles van, hatha teleszorja valamivel a logot es arra jobban ra tudsz guglizni
- uj default profillal inditva megnezni firefox indulast is jelentkezik-e a gond, amiben nincsenek benne modositott beallitasok es extension betoltesek, hatha azokban van valami

about:config
devtools*.enabled - kikapcsolható ha csak böngésztek
privacy.trackingprotection.enabled megfontolandó - pár font stb nem lesz használatban, de jelentős oldalletöltés gyorsulás tapasztalható (valamit valamiért..)
stbstb..

---
Referrall https://goo.gl/7S2vlp (koding) | https://goo.gl/muWzKz (digitalocean)

Sikerült kapnom egy 100%-ot csomagtelepítés és eltávolítás közepén (ugyanúgy dbus); viszont az égvilágon semmit nem írt a journalctl -f kimenetre... egyre kevésbé értem az egész jelenséget... :-(

Ui: próba-cseresznye alapon csináltam egy service dbus restart-ot... :-) a hatás frenetikus volt; szerencsére ctrl+alt+del még működött utána, legalább tudtam egy unmountolás szempontjából szabályos újraindítást csinálni (nem kellett hidegreset)

Lehet, hogy megvan a tettes. Semmit nem csinált a gép (direkt üresben hagytam menni), egyszer csak a CPU felugrott 100%-ra (dbus megint), és a következő üzenetsor jelent meg a journalctl -f kimeneten: 


jún 08 21:53:52 localhost freshclam[717]: Received signal: wake up
jún 08 21:53:52 localhost freshclam[717]: ClamAV update process started at Mon Jun  8 21:53:52 2015
jún 08 21:53:52 localhost freshclam[717]: nonblock_connect: connect(): fd=4 errno=22: Invalid argument
jún 08 21:53:52 localhost freshclam[717]: Can't connect to port 80 of host 10 (IP: 0.0.0.10)
jún 08 21:53:52 localhost freshclam[717]: WARNING: Can't download main.cvd from 10
jún 08 21:53:52 localhost freshclam[717]: Trying again in 5 secs...
jún 08 21:53:57 localhost freshclam[717]: ClamAV update process started at Mon Jun  8 21:53:57 2015
jún 08 21:53:57 localhost freshclam[717]: nonblock_connect: connect(): fd=4 errno=22: Invalid argument
jún 08 21:53:57 localhost freshclam[717]: Can't connect to port 80 of host 10 (IP: 0.0.0.10)
jún 08 21:53:57 localhost freshclam[717]: WARNING: Can't download main.cvd from 10
jún 08 21:53:57 localhost freshclam[717]: Trying again in 5 secs...
jún 08 21:54:02 localhost freshclam[717]: ClamAV update process started at Mon Jun  8 21:54:02 2015
jún 08 21:54:02 localhost freshclam[717]: nonblock_connect: connect(): fd=4 errno=22: Invalid argument
jún 08 21:54:02 localhost freshclam[717]: Can't connect to port 80 of host 10 (IP: 0.0.0.10)
jún 08 21:54:02 localhost freshclam[717]: WARNING: Can't download main.cvd from 10
jún 08 21:54:02 localhost freshclam[717]: Trying again in 5 secs...
jún 08 21:54:07 localhost freshclam[717]: ClamAV update process started at Mon Jun  8 21:54:07 2015
jún 08 21:54:07 localhost freshclam[717]: nonblock_connect: connect(): fd=4 errno=22: Invalid argument
jún 08 21:54:07 localhost freshclam[717]: Can't connect to port 80 of host 10 (IP: 0.0.0.10)
jún 08 21:54:07 localhost freshclam[717]: WARNING: Can't download main.cvd from 10
jún 08 21:54:07 localhost freshclam[717]: Trying again in 5 secs...
jún 08 21:54:12 localhost freshclam[717]: ClamAV update process started at Mon Jun  8 21:54:12 2015
jún 08 21:54:12 localhost freshclam[717]: nonblock_connect: connect(): fd=4 errno=22: Invalid argument
jún 08 21:54:12 localhost freshclam[717]: Can't connect to port 80 of host 10 (IP: 0.0.0.10)
jún 08 21:54:12 localhost freshclam[717]: ERROR: Can't download main.cvd from 10
jún 08 21:54:12 localhost freshclam[717]: Giving up on 10...
jún 08 21:54:12 localhost freshclam[717]: Update failed. Your network may be down or none of the mirrors listed in /etc/clamav/freshclam.conf is working. Check http://www.clamav.net/doc/mirrors-faq.html for possible reasons.

Azt látom, hogy a freshclam hasal el, azt is, hogy valami teljesen blőd IP címről próbálja letölteni a frissítést, de két dolgot nem egészen értek:
- ha ez nem megy neki, és feladja (Giving up), akkor miért akad ki mégis a rendszer?
- ha a boot-up managerben kivettem az aktivációt a clamav-freshclam elől, akkor miért fut mégis?

Köszi

borosspet

Úgy néz ki, hogy sikerült...

Találtam egy infot arra, hogy újra kell konfigurálni a freshclam-ot (dpkg-reconfigure clamav-freshclam), és nem kell kérni a "Private mirror for freshclam" opciót. Ezután kézzel lefuttattam a freshclamot, ami rögtön működött, és ráadásul ki is rántotta a rendszert a 100%-os cpu használatból...

Köszönöm a segítségeket, azok alapján tudtam elindulni valamerre, ami eredményes lett.

borosspet