You are not logged in.

#1 2018-11-28 19:15:17

this.julian
Member
Registered: 2018-11-28
Posts: 2

Strange usage of CPU (100% one/two of cores) in Thinkpad P70

Hello,

few weeks ago after update something has fcked with my notebook.
When I open monitor, I see that one of the core uses 100%, and then it drops down and another uses 100%. And they are still swaping.
It's drilling my battery (2-3h less work time) and making me frustrated.

Kernel: 4.19.2-arch1-1-ARCH

Process which probably eats my CPU: tracker-store
( tried to turn off it following this advice - https://ask.fedoraproject.org/en/questi … -in-gnome/ )

Screenshot of CPU monitor diagram:

https://imgur.com/a/6dyY2bG

I love to work without cable, so I hope one of You guys will find excellent solution how to solve this issue. I believe in You guys. I will present all necessary info.

Last edited by this.julian (2018-11-28 22:54:46)

Offline

#2 2018-11-28 19:30:38

V1del
Forum Moderator
Registered: 2012-10-16
Posts: 5,716

Re: Strange usage of CPU (100% one/two of cores) in Thinkpad P70

The 4.19 kernel switched to multi-queue IO schedulers. Indexers like tracker or KDE's baloo set an IO-scheduler flag to notify schedulers that they shouldn't prioritize their processes. The current multiqueue default mq-deadline doesn't honor these flags afaik. You can try switching to the BFQ scheduler or disable the mq layer with

scsi_mod.use_blk_mq=0

on your kernel params to revert to the previous scheduler and behaviour, though that approach is considered obsolete and relevant code has been removed from modern kernels (4.20+), so might not be a sustainable solution

Also please edit your post and only post a link or thumbnail to an image https://wiki.archlinux.org/index.php/Co … s_and_code

Last edited by V1del (2018-11-28 19:32:09)

Offline

#3 2018-11-28 23:18:39

this.julian
Member
Registered: 2018-11-28
Posts: 2

Re: Strange usage of CPU (100% one/two of cores) in Thinkpad P70

I tried, but with no success.

Post edited as You wish.

Monitor cheats on usage of CPU probably...
Using "top" command, I got info about tracker-store process:

3595 j         20   0  391684  30852  13444 R  89,7   0,2   0:02.69 tracker-s+
where 89,7 is % usage of CPU.

But I found solution how to solve it:

Copy the autostart file and override it with a user-specific one:

$ cp /etc/xdg/autostart/tracker-store.desktop ~/.config/autostart/tracker-store.desktop

and append to it:

Hidden=true

(The same step also applies for tracker’s friends, such as tracker-miner-fs, etc.)
Mask (which is the strongest yet nondestructive way to “disable” a static systemd service completely [4]) all tracker-related

$ systemctl --user mask tracker-store

Source:
https://www.soimort.org/notes/171103/

Last edited by this.julian (2018-11-28 23:42:53)

Offline

#4 2018-11-29 08:35:01

V1del
Forum Moderator
Registered: 2012-10-16
Posts: 5,716

Re: Strange usage of CPU (100% one/two of cores) in Thinkpad P70

Well now you just disabled tracker, you can of course do that, but I don't consider that a solution as there can be valid reasons to want to have tracker running.

Offline

#5 2018-12-13 17:03:49

Amphitryon
Member
Registered: 2013-09-20
Posts: 19

Re: Strange usage of CPU (100% one/two of cores) in Thinkpad P70

V1del wrote:

Well now you just disabled tracker, you can of course do that, but I don't consider that a solution as there can be valid reasons to want to have tracker running.

I suppose the question is whether the improvement in search speed once the indexing is complete makes up for any degradation in performance doing other things while the indexing is taking place.

I have just found baloo_file_extractor using 85% CPU, 45% of memory and generating a lot of I/O and causing my desktop PC to be slow to respond, sometimes.  It has improved a bit after changing the I/O scheduler for my SSD from 'mq-deadline' to 'none'.  According to 'balooctl status' it has 'Indexed 1002720 / 1113120 files' and running this command twice, 100s apart gives a rate of 80 files per 100s, i.e. 0.8 file/sec.  At that rate it has 38h to go.

I am not sure faster searches in the future are worth that 38h of further sub-par performance so I will be turning it off.

Offline

Board footer

Powered by FluxBB