https://bugs.kde.org/show_bug.cgi?id=500665
--- Comment #48 from postix <pos...@posteo.eu> --- (In reply to tagwerk19 from comment #46) > That's a lot of information to sort through... > That's a lot of information to sort through... Unfortunately posting larger sequential updates on Bugzilla makes the whole issue not very clear, I wish I had structured my postings differently. Anyway, a short summary of my findings: * NTFS-3G and NTFS3 drivers role is not clear year. While with NTFS-3G the system responsiveness was often very bad, it seemed that with NTFS3 this was not the case. However this could have been a pure coincidence when testing, as with the NTFS-3G driver the system runs fine in the moment during indexing. * CPU usage is around 100% for both drivers currently. The point above and CPU usage could be rather affected by what is currently indexed. * RAM usage grows for both drivers over time. It seemed RES ram consumption grows faster in the case of NTFS3, but this needs to be re-checked again. * Somehow MemoryHigh [1] seems to not be in effect, despite being defined in the systemd service file. This can be seen as the RAM usage grows above 512 MB and there's no memory line in systemctl --user status kde-baloo.service, while the service is active (running). This needs to be investigated. * A recent heaptrack showed only a marginal memory leak of 45 MB in mdb_page_malloc, which could also be a false positive. Peak heap memory consumption was 230 MB and peak RSS 2.2 GB. This time kde-baloo.serice was gracefully stopped before detaching heaptrack: systemctl --user start kde-baloo.service heaptrack -p (pidof baloo_file_extractor) # wait 8 Minutes systemctl --user stop kde-baloo.service [1] https://www.freedesktop.org/software/systemd/man/latest/systemd.resource-control.html#MemoryHigh=bytes -- You are receiving this mail because: You are watching all bug changes.
