Linux procfs dla administratorów: przegląd najważniejszych plików

Das Linux procfs pokazuje aktualny stan jądra za pomocą plików wirtualnych w katalogu /proc. Z punktu widzenia administracji istotne są przede wszystkim obciążenie, pamięć, procesy, deskryptory plików i urządzenia blokowe. Kluczowe znaczenie ma właściwa interpretacja: niektóre wartości są chwilowymi odczytami, inne to liczniki od momentu uruchomienia systemu lub średnie kroczące. Dlatego nigdy nie należy opierać się wyłącznie na pojedynczej wartości, lecz należy ją porównać z odpowiednimi sygnałami oraz uwzględnić kontekst hosta, maszyny wirtualnej lub kontenera.

Zrozumieć procfs: wirtualny widok jądra zamiast pamięci danych

Das procfs jest wirtualnym systemem plików: wpisy w katalogu /proc odzwierciedlają struktury danych i stany uruchomionego jądra systemu Linux. Nie są one trwale zapisane na nośniku danych. Podczas odczytu jądro generuje odpowiedni widok na podstawie swojego aktualnego stanu; na przykład po ponownym uruchomieniu wiele liczników zaczyna od nowa. Dlatego /proc stanowi interfejs służący do monitorowania i częściowego sterowania, a nie miejsce na własne pliki lub trwałe konfiguracje.

W zakresie administracji należy rozróżnić trzy obszary. Globalne pliki stanu, takie jak /proc/meminfo, /proc/stat czy /proc/loadavg, dostarczają wskaźniki dotyczące całego jądra. Katalogi o nazwach numerycznych, na przykład /proc/1234, zawierają szczegółowe informacje na temat pojedynczego procesu. Natomiast w katalogu /proc/sys znajdują się parametry jądra, które w zależności od uprawnień i ustawień mogą być zarówno dostępne do odczytu, jak i do zapisu. Podobna nazwa pliku nie może przesłaniać faktu, że sprawdzenie stanu i zmiana konfiguracji mają zasadniczo różne konsekwencje.

Dostępne ścieżki i pola nie są identyczne w każdym systemie Linux. Na widoczne wpisy wpływają wersja i konfiguracja jądra, architektura, rozpoznany sprzęt oraz załadowane moduły. Również przestrzenie nazw zmieniają poszczególne widoki. W szczególności procfs powiązany z przestrzenią nazw PID ogranicza widok procesów i identyfikatorów PID; nie oznacza to jednak, że pliki globalne automatycznie zawierają wartości specyficzne dla kontenerów lub grup cgroup. Skrypty powinny sprawdzać pliki i pola przed analizą ich zawartości, zamiast zakładać istnienie pełnej, wszędzie identycznej struktury procfs.

Należy odróżnić od tego sysfs w katalogu /sys: przedstawia on przede wszystkim urządzenia, sterowniki i obiekty sprzętowe. W kontekście alokacji zasobów i ograniczeń grup istotny jest również cgroup2. procfs pozostaje jednak bezpośrednim źródłem wielu stanów jądra i procesów, które są niezbędne podczas wstępnej diagnostyki.

Właściwe interpretowanie wskaźników, danych punktowych i widoczności

W przypadku procfs sama wartość rzadko wyjaśnia problem. Najpierw należy wyjaśnić jej odniesienie czasowe: niektóre dane są liczniki skumulowane od uruchomienia systemu, inne opisują aktualny stan, a jeszcze inne przedstawiają ruchome przedziały czasowe. Wysoki stan licznika wskazuje początkowo jedynie, że od momentu uruchomienia systemu nastąpiło zsumowanie zdarzeń. Częstotliwość powstaje dopiero na podstawie dwóch punktów pomiarowych: różnicy wartości podzielonej przez przedział czasu między nimi. Dotyczy to na przykład wielu liczników procesora, przerwań i nośników danych.

Plik /proc/uptime zawiera informacje o dotychczasowym czasie pracy oraz zagregowanym czasie bezczynności. Pomaga on w ustaleniu kolejności liczników od momentu uruchomienia, ale nie zastępuje serii pomiarów. Jednorazowe zapytanie stanowi jedynie migawkę; aby uzyskać wiarygodne wnioski dotyczące trendów, szczytów lub powtarzających się obciążeń, konieczne są powtarzające się zapytania z sygnaturą czasową. Wartości mogą się zmieniać już podczas odczytu, ponieważ jądro nadal pracuje.

Również dane widoczne mają swoje ograniczenia. /proc/self zawsze odnosi się do procesu, który w danym momencie rozdziela ścieżkę. Dzięki temu jest to rozwiązanie praktyczne dla skryptów i interaktywnych sprawdzeń, bez konieczności przyjmowania identyfikatora PID. Dostęp do katalogów innych procesów może jednak być ograniczony przez uprawnienia do plików, możliwości systemu Linux oraz opcję montowania procfs hidepid może być ograniczony. Brak dostępu do niektórych informacji nie wynika w tym przypadku z usterki systemu procfs, lecz stanowi zabezpieczenie przed odczytem poufnych danych dotyczących procesów.

W kontenerach należy zachować szczególną ostrożność. System plików procfs powiązany z przestrzenią nazw PID wyświetla w przypadku ścieżek związanych z procesami wyłącznie procesy z tej perspektywy przestrzeni nazw. Z kolei globalne pliki jądra, takie jak /proc/meminfo, /proc/stat lub /proc/diskstats, mogą nadal odzwierciedlać wartości hosta i nie są automatycznie ograniczane do limitów kontenera. Przed każdą diagnostyką należy zatem wyjaśnić, czy dana kwestia dotyczy procesów, globalnych wartości jądra czy faktycznie przydzielonych zasobów; limity i wykorzystanie kontenera należy dodatkowo uwzględnić w analizie cgroup2.

Odczytywanie, konfigurowanie i zabezpieczanie w katalogu /proc/sys

Dział /proc/sys jest widokiem systemu plików interfejsu sysctl. Odczyt wartości służy do celów diagnostycznych. Natomiast dostęp do zapisu bezpośrednio zmienia zachowanie działającego jądra i może wpływać na usługi, zużycie zasobów lub funkcje bezpieczeństwa. Fakt, że zmiana obowiązuje bez konieczności ponownego uruchomienia systemu, nie oznacza, że jest ona pozbawiona ryzyka ani że automatycznie ma charakter trwały: trwałość zależy od wybranej konfiguracji systemu.

Struktura katalogów ułatwia wstępną orientację. W katalogu /proc/sys/fs znajdują się między innymi globalne parametry systemu plików oraz uchwyty plików. Katalog /proc/sys/vm zawiera ustawienia związane z zarządzaniem pamięcią, natomiast /proc/sys/net zawiera parametry sieciowe. To, jakie podkatalogi i klucze są dostępne, zależy z kolei od konfiguracji jądra i funkcji systemu. Istniejący parametr nie stanowi zatem uniwersalnej recepty na optymalizację; decydujące znaczenie mają jego dokumentacja oraz konkretne obciążenie systemowe.

Przykładem przeciwnym do pozornej optymalizacji jest drop_caches w katalogu /proc/sys/vm. Dokumentacja jądra przypisuje tę funkcję do celów debugowania i testów oraz odradza jej stosowanie poza tymi celami, ponieważ opróżnianie pamięci podręcznej, która może być ponownie wykorzystana, może negatywnie wpływać na wydajność. Niewielka ilość wolnej pamięci nie jest sama w sobie powodem do usuwania pamięci podręcznej: jądro celowo wykorzystuje pamięć RAM również jako pamięć podręczną plików.

Przed każdą zmianą powinna istnieć jasno określona przyczyna. Najpierw zapisz wartość początkową, udokumentuj cel i spodziewane skutki uboczne, wprowadź zmianę w sposób kontrolowany, a następnie obserwuj odpowiednie wartości pomiarowe oraz zachowanie usługi. Należy z wyprzedzeniem zaplanować powrót do stanu poprzedniego i wprowadzić wartość do stałej konfiguracji dopiero po fachowej weryfikacji. Bardziej szczegółowe informacje na temat parametrów i ich kontrolowanego zarządzania znajdują się w artykule Strojenie jądra w hostingu Linuksa: Parametry Sysctl w skrócie.

Najważniejsze pliki procfs w podziale na zadania administracyjne

Wybór pliku procfs powinien wynikać z potrzeb administracyjnych, a nie z dążenia do uzyskania jak najpełniejszej listy katalogów. Pliki globalne często zawierają wartości dotyczące całego jądra, ścieżki procesów opisują pojedynczy widoczny proces, a wpisy w katalogu /proc/sys/fs zawierają ustawienia konfiguracyjne i ograniczenia systemowe. Niektóre wartości odzwierciedlają aktualny stan, inne są licznikami skumulowanymi od momentu uruchomienia systemu lub średnimi ruchomymi. To rozróżnienie decyduje o tym, czy wystarczy pojedynczy odczyt, czy też konieczne są dwa punkty pomiarowe.

Tabela stanowi pomoc w rozpoczęciu pracy, a nie schemat diagnostyczny. Nietypowa wartość zawsze wymaga niezależnego potwierdzenia: obciążenie – danymi dotyczącymi procesora i operacji wejścia/wyjścia, wartości pamięci – informacjami o zablokowaniu pod ciśnieniem, a parametry procesu – zachowaniem usługi. Szczególnie /proc/diskstats i /proc/stat są liczniki skumulowane; ich różnica w znanym przedziale jest bardziej miarodajna dla wskaźników niż wartość bezwzględna. W przypadku kontenerów należy dodatkowo sprawdzić, czy dany plik zawiera globalne wartości jądra, czy też przedstawia widok dostępny dla poszczególnych grup cgroup. W poniższych sekcjach sygnały zostały zatem pogrupowane według obciążenia, pamięci, procesów i operacji wejścia/wyjścia.

Obciążenie, procesor i pamięć: łączna ocena sygnałów

W przypadku wolno działającej aplikacji /proc/loadavg stanowi dobry punkt wyjścia, ale nie pozwala na ostateczną ocenę obciążenia procesora. Trzy wartości odzwierciedlają średnie obciążenie z ostatnich 1, 5 i 15 minut. W obciążeniu uwzględniane są nie tylko jednostki gotowe do wykonania w stanie R, ale także zadania w stanie oczekiwania D, którego nie można przerwać, na przykład podczas operacji wejścia/wyjścia (I/O). Czwarte pole pokazuje liczbę jednostek planowania, które można obecnie wykonać, w porównaniu z liczbą wszystkich istniejących jednostek planowania. Wysokie Średnie obciążenie może zatem wskazywać na rywalizację o procesor, zablokowane operacje wejścia/wyjścia lub jedno i drugie.

cat /proc/loadavg
grep -E '^(cpu|intr|ctxt|processes)' /proc/stat
cat /proc/meminfo
cat /proc/pressure/memory

Wiersze dotyczące procesora w pliku /proc/stat zawierają udziały czasu od momentu uruchomienia systemu w jednostkach USER_HZ. Aby na tej podstawie określić udziały obciążenia, należy porównać dwa odczyty; pojedynczy odczyt pokazuje jedynie skumulowany czas. Wartość iowait nie jest przy tym bezpośrednią miarą opóźnienia dla pamięci masowej: jej obliczanie ma udokumentowane ograniczenia, a w pewnych okolicznościach może nawet ulec zmniejszeniu. W przypadku przyczyny związanej z operacjami wejścia/wyjścia (I/O) warto zatem dodatkowo uwzględnić wartości urządzeń oraz wskaźnik I/O-PSI.

Nawet niska wartość MemFree nie oznacza jeszcze braku pamięci RAM. System Linux celowo wykorzystuje nieużywaną pamięć roboczą jako pamięć podręczną. MemAvailable szacuje, ile pamięci mogą prawdopodobnie uzyskać nowe aplikacje bez konieczności stosowania wymiany danych, i zazwyczaj jest bardziej pomocny przy wstępnej ocenie sytuacji. Dopiero gdy wartość MemAvailable staje się niska, a jednocześnie pojawiają się zatory pamięciowe, nasilają się oznaki ciśnienie w zbiorniku. W kontenerze te globalne wartości pamięci mogą jednak pochodzić z hosta; w przypadku zasobów gwarantowanych lub ograniczonych decydujące znaczenie ma dodatkowo perspektywa cgroup2.

Pliki w katalogu /proc/pressure uzupełniają ten obraz. W przypadku pamięci (memory) i operacji wejścia/wyjścia (io) wartość „some” oznacza, że przynajmniej niektóre zadania utknęły w martwym punkcie przez część przedziału czasowego; wartość „full” oznacza stan, w którym wszystkie zadania niebędące w stanie bezczynności zostały jednocześnie zablokowane. Wartości „avg10”, „avg60” i „avg300” odnoszą się odpowiednio do 10, 60 i 300 sekund, natomiast „total” to skumulowany licznik zablokowań. W przypadku procesora (CPU) wartość „full” w skali całego systemu nie jest semantycznie zdefiniowana i od wersji Linuksa 5.13 jest wyświetlana jako zero ze względów kompatybilnościowych; nie należy jej zatem interpretować jako wartości diagnostycznej na poziomie systemu. Wskaźniki PSI dla procesora, pamięci i operacji wejścia/wyjścia odpowiadają na różne pytania i nie należy ich stosować zamiennie.

Jeśli usługa działa wolno przy niskim poziomie MemFree, najpierw sprawdź MemAvailable i /proc/pressure/memory. Jeśli obie wartości są w normie, nie wskazuje to na ostry niedobór pamięci w całym systemie. Następnie plik /proc//status może wykazać, czy dany proces charakteryzuje się np. wysoką wartością VmRSS, dużą liczbą wątków lub nietypowym stanem. Ta kombinacja pozwala odróżnić obciążenie pamięci spowodowane działaniem pamięci podręcznej, ale mieszczące się w normie, od problemu wymagającego dalszej analizy procesu.

Analiza procesów, deskryptorów plików i operacji wejścia/wyjścia na nośnikach danych

Aby zapewnić bezpieczne działanie z gwarantowaną dostępnością procesu, $$ oznacza identyfikator PID bieżącej powłoki. Plik status jest bardziej czytelny dla człowieka niż zorientowany na pola plik stat. Nazwa identyfikuje proces, stan określa jego aktualny stan, PPid wskazuje proces nadrzędny, a liczba wątków określa liczbę wątków. VmRSS stanowi szybkie przybliżenie pamięci rezydentnej, której księgowanie RSS odbywa się w sposób skalowalny i asynchroniczny, przez co może być niedokładne; natomiast VmSize opisuje wirtualną przestrzeń adresową. FDSize opisuje rozmiar tablicy deskryptorów, niekoniecznie liczbę aktualnie otwartych wpisów. Dobrowolne i przymusowe zmiany kontekstu mogą pomóc w klasyfikacji zachowań planowania, ale same w sobie nie stanowią dowodu na występowanie błędu.

cat /proc/$$/status
ls -l /proc/$$/fd

Katalog fd zawiera dowiązania symboliczne do otwartych plików, potoków, urządzeń lub gniazd. Pomaga to na przykład w znalezieniu procesu, który nadal utrzymuje otwarty usunięty plik dziennika. Duża liczba otwartych deskryptorów plików jest jednak całkowicie normalna w przypadku serwerów proxy, baz danych lub serwerów zorientowanych na zdarzenia. W przypadku widoków filtrowanych i mapowania między procesami należy Wykorzystanie lsof do analizy otwartych plików odpowiednie uzupełnienie. Wiersze poleceń z cmdline mogą ujawniać poufne argumenty; environ jest jeszcze bardziej wrażliwy ze względu na potencjalne dane dostępowe lub tokeny i nie należy go wywoływać rutynowo.

Polecenie `maps` wyświetla listę wirtualnych obszarów pamięci wraz z uprawnieniami, przesunięciem, urządzeniem, i-węzłem oraz, w razie potrzeby, ścieżką. Polecenie `smaps` uzupełnia dla każdego mapowania szczegółowe wartości pamięci i dostarcza dokładniejszy, choć bardziej rozbudowany obraz sytuacji w porównaniu z danymi RSS. Oba pliki są przeznaczone do pogłębionej analizy pamięci: ich wynik może być obszerny, a interpretacja poszczególnych mapowań wymaga kontekstu. Na pierwszy rzut oka polecenie `status` oraz pliki pamięci i PSI obejmujące cały system są zazwyczaj bardziej wydajne.

W przypadku dużego obciążenia i niskiego wykorzystania procesora katalog /proc/diskstats rozszerza diagnostykę o poziom urządzeń. Plik ten zawiera skumulowane statystyki operacji wejścia/wyjścia dla każdego urządzenia blokowego. Aby ocenić aktywność jako wskaźnik, należy porównać dwa momenty w czasie. Należy przy tym wyraźnie rozróżnić dyski fizyczne, partycje oraz urządzenia wirtualne lub urządzenia mapujące; nie wolno bezkrytycznie sumować liczników z różnych poziomów. Otwarty deskryptor pliku procesu nie może być przy tym bezpośrednio przypisany do licznika urządzenia diskstats: pomiędzy nimi znajdują się system plików, pamięć podręczna i warstwy mapowania. W połączeniu z /proc/pressure/io można jednak sprawdzić, czy obserwowane zatory we/wy i aktywność urządzeń pokrywają się czasowo.

procfs w działaniu: zapytania, monitorowanie i ochrona danych

Aby zapewnić powtarzalność diagnostyki działania, traktuj zapytania procfs jako punkty pomiarowe: zanotuj sygnaturę czasową, kontekst systemowy oraz konkretne zapytanie. Wiele wartości to liczniki skumulowane od momentu uruchomienia; dopiero różnica między dwiema wartościami podzielona przez przedział czasowy daje wartość częstotliwości. Dotyczy to na przykład liczników z /proc/diskstats. Pojedyncze zapytanie może zatem świadczyć o aktywności, ale nie pozwala wiarygodnie określić ani przepustowości, ani trwałego pogorszenia wydajności.

System monitorowania powinien w stałych odstępach czasu odczytywać między innymi wartości zapisane w pamięci z /proc/meminfo, wartości z urządzeń z /proc/diskstats, rejestrować stany procesów i systemu, a także – o ile jądro systemu to obsługuje – sygnały drukowania. Musi przeliczać wartości surowe na odpowiednie jednostki, obliczać różnice w przypadku liczników oraz zapisywać historię. W kontenerach nie wolno utożsamiać globalnych wartości procfs z limitami zasobów obciążenia: ścieżki procesów mogą być ograniczone do przestrzeni nazw PID, podczas gdy wartości pamięci lub urządzeń mogą częściowo odzwierciedlać host. Do określenia limitów i obciążenia grupy niezbędne są uzupełniające metryki cgroup2. Tylko trendy w czasie pozwalają na ustalenie wiarygodnych wartości progowych: wysoka wartość może być normalna, jeśli mieści się w oczekiwanym przedziale obciążenia; nagły wzrost w stosunku do własnej wartości bazowej jest często bardziej istotny. Dostępne wpisy procfs zależą od uruchomionego jądra i jego konfiguracji.

Pliki bezpośrednie i narzędzia wzajemnie się uzupełniają. ps, top lub htop nadają się do interaktywnego przeglądu procesu; free, vmstat, iostat, pidstat, ss oraz sar W zależności od konfiguracji przygotowują dane dotyczące konkretnych zagadnień. procfs nadal ma sens, jeśli chcesz bezpośrednio sprawdzić kod źródłowy jądra lub stworzyć mały, przejrzysty skrypt. W przypadku systemów ostrzegawczych i planowania wydajności dane szeregów czasowych są zazwyczaj bardziej odpowiednim poziomem analizy.

Ograniczenia widoczności obowiązują również w przypadku zapytań wyłącznie odczytowych. Uprawnienia dostępu, opcje montowania oraz przestrzenie nazw PID mogą ukrywać dane procesów lub ograniczać je do widoku kontenera. Z drugiej strony posiadanie własnego punktu montowania /proc nie oznacza, że każdy globalny plik jądra zawiera wyłącznie dane kontenera. Brak wpisu procesu lub nieoczekiwanie wysoka wartość globalna jest zatem w pierwszej kolejności wskazówką, aby sprawdzić środowisko wykonawcze, opcje montowania oraz kontekst cgroup.

Ścieżki diagnostyczne dotyczące powolnego działania usług i wąskich gardeł zasobów

Rozwiązywanie problemów zaczyna się od objawu, a nie od pojedynczej wartości, którą uznaje się za przyczynę. Następnie sprawdź co najmniej jeden niezależny sygnał i odnotuj, czy zaobserwowana sytuacja dotyczy hosta, maszyny wirtualnej czy kontenera. W ten sposób unikniesz na przykład pochopnego uznania wysokiego obciążenia za problem z procesorem lub dużej liczby otwartych deskryptorów za wyciek. Poniższe ścieżki stanowią wstępną diagnozę opartą na analizie danych i nie zastępują logów związanych z aplikacją.

W przypadku wysokiego wskaźnika średniego obciążenia (Load Average) należy najpierw sprawdzić, czy na tę wartość wpływają zadania wykonywane, czy też oczekujące. Wartości obciążenia przedstawiają średnie z okresu jednej, pięciu i 15 minut oraz uwzględniają zarówno stany R, jak i D. Dlatego też należy z zachowaniem ostrożności porównywać pola czasu procesora z obciążeniem wejścia/wyjścia i aktywnością urządzeń. W szczególności iowait nie należy interpretować tego wyłącznie jako opóźnienia pamięci.

W przypadku powolnego działania i małej wartości MemFree MemAvailable lepsza pierwsza wartość kontekstowa. Dodaj dane PSI dotyczące pamięci oraz stan danego procesu, np. jego wartość VmRSS, liczbę wątków i stan. W odniesieniu do pamięci i operacji wejścia/wyjścia PSI rozróżnia między some dla częściowo zablokowanych zadań oraz full w celu całkowitego zablokowania zadań innych niż zadania bezczynne. Brak plików PSI może wynikać z konfiguracji jądra lub środowiska; nie oznacza to jednak, że nie występuje wąskie gardło.

W przypadku diagnostyki plików i procesów uprawnienia oraz Przestrzenie nazw PID ograniczają miarodajność wyników. W środowisku kontenerowym katalog /proc często opisuje jedynie przypisane środowisko procesów. W przypadku odmowy dostępu lub niekompletnych katalogów należy zatem sprawdzić uprawnienia użytkownika, opcje montowania procfs oraz kontekst przestrzeni nazw, zanim wyciągnie się wnioski techniczne na podstawie braku danych.

Korygowanie typowych błędnych założeń i dobór odpowiednich narzędzi

Cztery typowe błędy w administrowaniu systemem Linux często prowadzą do podjęcia niewłaściwych działań. Niewiele MemFree nie oznacza automatycznie niedoboru pamięci RAM, ponieważ jądro wykorzystuje pamięć m.in. jako pamięć podręczną; w przypadku nowych aplikacji bardziej miarodajnym wskaźnikiem jest MemAvailable. Wysokie obciążenie nie świadczy o przeciążeniu procesora, ponieważ uwzględniane są również zadania oczekujące w trybie nieprzerwalnym. Wysoki udział iowait nie odzwierciedla bezpośredniego opóźnienia nośnika danych. Ponadto procfs nie jest wszędzie identyczny: wersja jądra, konfiguracja, sprzęt, moduły i przestrzenie nazw mają wpływ na pliki i pola.

Wybierz metodę w zależności od pytania. W przypadku punktowej analizy przyczyn przydatna jest procfs bezpośrednie dane surowe z bieżącego jądra. Aby uzyskać szybki, czytelny dla człowieka przegląd, zazwyczaj skuteczniejsze są specjalistyczne narzędzia wiersza poleceń. Jeśli liczą się trendy, alerty lub decyzje dotyczące wydajności, potrzebujesz systemu monitorowania, który porządkuje punkty pomiarowe w czasie, oblicza różnice w wartościach liczników i przechowuje historyczne wartości porównawcze. W przypadku ograniczeń zasobów poszczególnych usług lub kontenerów analiza na poziomie cgroup uzupełnia globalny widok hosta; przy odpowiedniej konfiguracji PSI może być również dostępne dla poszczególnych cgroup.

Szczególną ostrożność należy zachować w przypadku /proc/sys. Odczyt parametru ma charakter diagnostyczny, natomiast jego zapis zmienia bieżące zachowanie jądra. Należy zmieniać wartość tylko wtedy, gdy znana jest przyczyna, wartość początkowa została udokumentowana, skutki są widoczne i istnieje możliwość powrotu do stanu poprzedniego. Katalogi fs, vm oraz net klasyfikują parametry według tematów, ale nie podają uniwersalnych wytycznych dotyczących tuningu.

Przykład drop_caches pokazuje różnicę między ingerencją a optymalizacją: dokumentacja jądra opisuje ten interfejs jako nieinwazyjny, ostrzega jednak przed problemami z wydajnością i nie zaleca jego stosowania jako standardowego działania operacyjnego poza scenariuszami testowymi lub debugowania. Z tego powodu należy stosować ostrożne podejście: najpierw należy przeprowadzić pomiary, następnie wprowadzić uzasadnioną zmianę w ograniczonym zakresie, obserwować jej skutki i skutki uboczne oraz udokumentować podjętą decyzję.