Przejdź do głównej zawartości

Opowieść o tym jak baloo zżera zasoby komputera

Wraz z akonadi, to część KDE, który podawany jest zwykle jako argument na bezsensowność tego środowiska, jego przerośnięcie i ogromny apetyt na zasoby. Już nie tylko RAM, ale i CPU, którego potrafi zagospodarować np. cały jeden rdzeń. Komputer zwalnia, źle pracuje. Wszystkiemu oczywiście winne baloo. Czyżby? Nie na darmo mówi się, że największy błąd oprogramowania siedzi przed komputerem i z niego "korzysta". Ów element zwany użyszkodnikiem może jednak pomóc baloo. Kiedyś już pisałem o tym, jak można ustawić ten komponent. Także wyłączyć. Załóżmy jednak, że chcemy z niego korzystać i jednocześnie nie chcemy, by zużywał 100% rdzenia CPU, czy np. 1 (i więcej) GB RAM. Czy to możliwe? Oczywiście. U mnie np. baloo zużywa ok. 2MB RAM i zasadniczo pomijalny ma apetyt na CPU. Zwykle zużycie wynosi poniżej 1%, a najczęściej sobie śpi. Otóż częstą przyczyną nadmiernego zużywania zasobów przez baloo jest nakazanie mu indeksowania nieistniejących katalogów. W wielu dystrybucjach baloo jest domyślnie włączane. Jego pierwotnym ustawieniem jest indeksowanie katalogu domowego użytkownika wraz z wszystkimi podkatalogami. Jednocześnie nie indeksuje plików ukrytych, oraz niektórych typów plików. Indeksuje również nie tylko nazwy, ale i zawartość plików. W niektórych dystrybucjach, instalator zakładając konto użytkownika, jednocześnie stworzy w nim domyślne katalogi, które przyjmą angielskie nazwy. Wystarczy by użytkownik dokonał w jakikolwiek sposób (czy to programowo, czy też ręcznie) ich zmian np. na polskie odpowiedniki oraz jednocześnie wykasował zbędne już katalogi i wówczas baloo zaczyna mieć apetyt na olbrzymie ilości zasobów. Niestety baloo nie wie, że jakiś katalog został usunięty i próbuje go zindeksować. Podobnie będzie się działo również, gdy jakieś katalogi wykluczyliśmy z indeskowania, a następnie katalog ten został skasowany. Prosty trick polega na tym, by pamiętać o bardzo podstawowych zasadach: Kiedy zmieniamy nazwy, bądź kasujemy jakieś katalogi, które podlegają indeksowaniu, bądź też zostały przez nas z indeksowania wyłączone, to - wstrzymajmy albo nawet lepiej wyłączmy baloo, - po dokonaniu zmian w strukturze katalogów zmieńmy odpowiednio ustawienia w baloo, a w szczególności usuńmy zbędne, bo nieistniejące katalogi, które znajdują się w jego ustawieniach, - włączmy od nowa baloo i pozwólmy mu chwilę w spokoju ponownie zindeksować bazę. W ten sposób, po chwili, gdy dokona pierwszego (czyli nowego) indeksowania, gdzie w istocie zapotrzebowanie na zasoby może być widoczne (ale bez przesady, to w porywach 3 do 5% CPU mojego niezbyt wypasionego APU i nieco większe od wskazanego wyżej zapotrzebowanie na RAM), baloo stanie się praktycznie niewidoczny dla systemu. Pamiętajmy jednak o wykluczeniu z indeksowania zbędnych plików (czyli zbędnych katalogów bądź zbędnych typów).

Komentarze

Popularne posty z tego bloga

Na prostej drodze do wysypania Manjaro

Do napisania dzisiejszego wpisu zainspirował mnie jeden z wątków na forum manjaro.pl. Otóż jeden z użytkowników Manjaro chciał zainstalować spotify, którego PKGBUILD dostępny jest w AUR. Akurat ta paczka powstaje przez przebudowanie udostępnianej przez Spotify paczki deb na paczkę Archa. Niestety od pewnego czasu spotify z udostępnionego PKGBUILDu gdyż wersja to 1.0.92.x, która nie jest już dłużej udostępniana przez Spotify. Obecnie udostępniane są 3 paczki, przy czym dla wspieranej architektury w Archu to wyłącznie 1.0.80.x oraz najnowsza 1.0.94.x. Instalacja zatem z takiego PKGBUILDu nie ma najmniejszych szans powodzenia.
Autor wątku chce zaktualizować paczkę, stąd też domniemuję, że jakąś wersję spotify ma.
Inny forumowicz poleca zatem... dodanie repozytorium nexus do systemu (uwaga - poleca dodanie repozytorium budowanego dla Archa do Manjaro!!!), albowiem w tym repozytorium jest najnowsza wersja spotify.
Autor zastanawia się jednak, czy jest to bezpieczne i dochodzi do wniosku, ż…

Plasma i Strażnik Krypt

W czasach, gdy nasza prywatność jest wystawiana na ciężką próbę, jeden z deweloperów KDE postanowił dodać do Plasmy możliwość dość łatwej obsługi szyfrowanych, wirtualnych "katalogów" - krypt, jak je nazywa. Sam projekt nazywa się plasma-vault i po około 3 miesiącach rozwijania pojawiła się w repozytorium unstable KDE najpierw jego wersja 5.9.95, a obecnie 5.9.96. Jak wskazuje numer wersji (choć ten został nadany nie przez opiekuna, ale przez wszędobylskiego Jonathana Riddella), aplikacja była planowana jako część Plasma 5.10. Tak się jednak z jakichś przyczyn nie stało. Obecnie jest ona planowana, jako część nadchodzącego wydania 5.11. Sam program w Archu dostępny jest w AUR. Buduje się całkiem żwawo i działa na tyle, by można zaryzykować jeśli nie używanie, to przynajmniej sprawdzenie działania i zgłoszenie ewentualnych błędów deweloperom. Pamiętajcie by czytać to co po pacman pisze przy instalacji. Program do prawidłowej funkcjonalności potrzebuje bądź encfs bądź cryfs. …

MEGA a sprawa Arch Linux

Mniejsza o to, czy MEGA to popularny, czy godny zaufania itd. itp. dostarczyciel przestrzeni w chmurze. Fakt, że po moich doświadczeniach z dropboksem nie chcę mieć więcej z nim nic wspólnego. Może zatem MEGA, do którego mam dostęp niemal od samego początku? Miłym dodatkiem do MEGA może okazać się uruchomione repozytorium oferujące sam program synchronizujący (megasync) oraz dodatki dla trzech, chyba najpopularniejszych, menedżerów plików: Dolphin, Nautilus i Thunar, umożliwiające synchronizację z plików z ich poziomu. Jest to o tyle miłe, że do tej pory musieliśmy kompilować te programy z AUR, a nadto w przypadku megasync wersja oferowana w repozytorium jest nowsza, zaś dolphin-megasync obecnie w ogóle się nie kompiluje. Chcąc dodać repozytorium MEGA do pacmana, edytujemy plik /etc/pacman.conf i gdzieś na końcu listy dodajemy: [DEB_Arch_Extra]SigLevel = Optional TrustAllServer = https://mega.nz/linux/MEGAsync/Arch_Extra/x86_64/ Nadto musimy jeszcze dodać klucz: gpg --receive-keys BF…