Tracker-miner-fs-3 High Cpu

[Hebe Zuelke]

andeither kill 9 the PID, or killall .

OTOH, I would check more about this, with htop, or other process manager, to see what it is doing.

Actually, using htop, you can also do the above (find and kill)

I experienced the same issue the last couple of days. I am using gnome since a long time now. But this problem with CPU load for tracker-miner-fs-3 just started some days ago. Must have something to do with a recent update.

In the meantime I have reverted the changes I mentioned earlier. I removed *.AVI from the file exclusion list (in fact I am using default exclusions again) and I renamed the folder with the AVI files back to its original name. I rebooted and everything is normal. No CPU load.

I was facing tracker processes spiking with a high CPU usage followed exits with failure exit code, especially tracker-miner-fs-3. I followed this suggestion from @evert and removed tracker cache. That was enough for my case.

Here is what happens: I start typing some search term, search hangs (no results are shown) and in System Monitor I can see tracker-miner-fs-3 running. The process runs for several minutes (no less than 10, with relatively high CPU usage), then it finally stops and the search results are shown. But the next time I try to search something else in Nautilus, no matter how little time may have passed, the same will happen again and again.

It seems quite obvious to me.

Tracker miner got the file name early on, then before it got to that file the file was removed so it was looping and trying to get data about a file that no longer existed.

Not a common occurrance, but in a dynamic file system it does happen.

Thanks for reporting the issue and creating a bug report. My Fedora 40 SilverBlue system was hanging 6 times in past weeks and the issue is due to tracker-miner that triggered oom-killer to kill Firefox, Nautilus and VLC.

In addition it filled logs with messages related to files downloaded with yt-dlp.

I hope the bug will be solved soon.

Hi, since you also used yt-dlp to download the file, could you add your logs to the gnome gitlab thread? I think it they could be helpful to figure out what the issue is: Constant high CPU usage (#340) Issues GNOME / tracker-miners GitLab

To tell Tracker Miner FS to ignore a directory and all its contents, you can create an empty file named .nomedia inside the directory. This trick also works on Android devices. Files named .trackerignore, .git and .hg have the same effect. You can configure this behaviour with the org.freedesktop.Tracker.Miner.Files ignored-directories-with-content GSettings key.

When you add or edit files, Tracker Miner FS will update its index. This should be very quick, but if a huge number of files are added then it may cause noticably high CPU and IO usage until the new files have been indexed. This is normal.

Tracker is not designed to index directories of source code or video game data. If content like this appears in the locations it is configured to index then you might see unwanted high resource usage.

If you see high resource usage from Tracker Miner FS even when no files have changed on disk, this probably indicates a bug in Tracker or one of its dependencies. See How can I help debug problems with Tracker services?

In case of a bug you may need to temporarily stop Tracker Miner FS indexing. The simplest way is to edit the configuration so that no directories are indexed. This should bring resource usage to zero.

Tracker developers advise all users and distributors to use the latest stable release of Tracker. The behavior of older stable releases staying correct and stable can not be guaranteed, thus they become unsupported.

The seccomp jail set up in tracker-extract-3 will catch non-observed syscalls and make the process quit. However updates in any of the dependencies used for metadata extraction (or any of their subdependencies) may introduce the usage of different syscalls that might not be observed by the seccomp jail.

SQLite has a history of API/ABI breaks and other regressions. This may sound anecdotal and unlikely, but Tracker uses SQLite API and logic much more extensively than most other users, there is a close to 100% chance that these will affect Tracker in some way. This most often happens between major releases, but distributors also do have a history to push these major version updates to stable/LTS distributions.

The implications of both is the same, handling those situations do not just require incessant updates, but also require active attention. Tracker maintainers backport these fixes on a best effort basis, but do not have the bandwidth to test all combinations induced by different distributions/versions across multiple Tracker branches.

Tracker uses an index system and this is what allows it to be so instantaneous. It will read its index and search in the metadata and content for matches with your search. This index is updated automatically and in real time as soon as a file is added or modified in an indexed location. The search is therefore always accurate and up to date.

Warning, Tracker is not designed to index millions of small files like those in a large source code. It remains a tool made for a desktop environment and the files related to it.Here is an excerpt from the documentation about it 1 :

When you add or edit files, Tracker Miner FS will update its index. This should be very quick, but if a huge number of files are added then it may cause noticably high CPU and IO usage until the new files have been indexed. This is normal. Tracker is not designed to index directories of source code or video game data. If content like this appears in the locations it is configured to index then you might see unwanted high resource usage.

Tracker supports tags, but Nautilus developers have decided (since v3.26) not to support them as before and to use a unique tag: favorites . It is therefore through the Tracker tag system that you can bookmark files and folders in Nautilus.If you want to use custom tags, you will have to turn to another file manager or Nautilus hacks.

Through the GUI you will only have access to one setting (the most important one), that of the directories to be included in the Tracker index.To do this, go to the GNOME settings, into the Search category and then at the top you will find Search Location.

It is always possible to remove tracker3, but this is strongly discouraged by the GNOME documentation because tracker3 is a central dependency in GNOME so you will certainly have side effects.

In the System Monitor, three are given priority 'Very High' (see screenshot) while 100% of the rest work fine with 'Normal' on my laptop. Does anyone know of a script (?) to add (and where?) to do this?

MichaelFinko If it's not causing any issue then why even bother to change it? Audio processes having higher priority is beneficial to you if your system is under CPU load (prevents audio skipping and other artifacts from the sound servers not being able to keep up under load) and has no negative if your system is not under load.

If you truly want to do this despite the fact that there is literally no benefit to it then you can run sudo systemctl mask rtkit-daemon which will prevent rtkit from starting on boot. rtkit is what automatically upgrades various audio threads to higher priority and disabling it will prevent that from happening.

Gnome Tracker (in our system 22.04 tracker3) is the full text indexing and search service of gnome. Depending on the size on type of your file this may introduce a significant load on the file servers and the client. Sometimes the tracker database gets corrupted. The reason for this is currently not clear. This article should give some hints to control and fix the behavior of this service.

Tracker uses several helper programs to get the required data from your files. This is 'tracker-miner-fs-3' and 'tracker-extract-3'. You can use top or any other load monitor to check the processes. If they are on the top of the most active processes and you see a high system load. With an Idle desktop the load should be lower then 1.0:

Yup, those settings allow */? tokens, as per GPatternSpec. Although you probably want ignored-directories, ignored-directories-with-content will ignore the parent directory of the matching file altogether. I assume you just want to skip *_files, not e.g. the downloads directory .

Tracker 3 is more conservative about indexing text/plain files because this reduces the risk of indexing huge sets of log files, data files, source code etc. and the corresponding high resource consumption that can cause.

There's a huge list of things to change to improve Linux Audio performance over stock distros.

Here are some issues I have encountered with Ubuntu 22.04 Jammy or Mint 21.1 Vera, what else can you think of?

Some kind of PREEMPT or "lowlatency" kernel work much better and you'll get less xruns at lower latencies with them. I avoid RT kernels because I need my laptop for general purpose use and they can cause issues when running VMs and I don't feel like rebooting into different setups.

10) Something which can really mess with your head are power scheduling processes. nvidia-powerd service will override whatever CPU governor & speeds you are trying to manually set using cpu tools. Stop and disable this in systemctl in case it messes with your system.

Note that "powersave" or "ondemand" CPU frequency schedulers can cause xruns which is why people often set this to "performance" but sometimes "performance" ramps up the CPU speeds too high and the system fans become problematic.

One can manually set the CPU frequency with the CPU governor and fix it at an appropriate value, but tools to accomplish this don't always work as hoped due to kernel changes, or systemctl daemons interfering (see the notes above).

3a8082e126