Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.



05.09.2022

Łatwiejsza migracja do chmur

Commvault i Oracle rozszerzyły partnerską współpracę i wspólnie oferują rozwiązanie...
01.09.2022

Badanie sieci

QNAP ogłosił wprowadzenie oprogramowania ADRA Network Detection and Response (NDR) dla...
01.09.2022

5G w Polsce

Z badania Kearney 5G Readiness Index 2022 wynika, że Polska jest jednym z najgorzej...
01.09.2022

Zarządzanie działaniami

Fortinet zaprezentował chmurową usługę, która koreluje informacje dotyczące...
01.09.2022

Selektywna rejestracja

Naukowcy z UCLA przedstawili projekt inteligentnej kamery, która pozwala wybrać, jaki...
01.09.2022

Więcej mocy, komputer...

Profesjonalny komputer Dell Precision 7865 Tower z AMD Ryzen Threadripper PRO 5000...
01.09.2022

Rekord prędkości

Firma Aorus zapowiada superszybki dysk, następcę modelu Gen4 7000s SSD, który ma oferować...
01.09.2022

Beprzewodowe drukowanie

Firma Brother wprowadziła do swojego portfolio nowe urządzenie wielofunkcyjne z systemem...
01.09.2022

Obraz dobrze zaprogramowany

Monitor interaktywny Lyra to połączenie Androida 11, szyby antybakteryjnej, wbudowanego...

Linux – pamięć rezydentna i HugePages

Data publikacji: 01-09-2022 Autor: Kamil Stawiarski

Linux jest tak rewelacyjny w zarządzaniu pamięcią, że zazwyczaj wybaczamy mu potknięcia w raportowaniu. Bo kogo – wyjąwszy urzędników – obchodzą formalności, jeśli robota jest dobrze wykonana? Niestety zdarzają się sytuacje, w których problemy z raportowaniem mogą wpłynąć na błędnie przeprowadzoną analizę sytuacji, a wręcz stworzenie problemu, tam gdzie go nie ma.

 

Omawiana historia ma swój początek w systemach monitorujących klienta, które zaczęły raportować niepokojące dane. Najwyraźniej po migracji do bazy danych Oracle 19.15 procesy DBWR zaczęły konsumować imponujące ilości pamięci – po 17 GB każdy! Nieprawidłowości na tym się nie skończyły, ponieważ każdy z procesów serwera zaczął iść w ich ślady, raportując zużycie, którego nie dało się w żaden sposób wyjaśnić. Na dowód zaistniałej sytuacji, klient załączył zrzut ekranu (%%rys. 1%%).
Sytuacja faktycznie przedstawiała się kuriozalnie, jeśli wziąć pod uwagę najbardziej interesujący nas zwykle wskaźnik – RES (RSS). Interesujące jest również to, że przed migracją do wersji 19.15 taka sytuacja nie miała miejsca – zacząłem więc analizę ciekawego przypadku wycieku pamięci w Oracle 19c.

> Alokacja pamięci operacyjnej

Rewelacyjne wyjaśnienie alokacji i budowy pamięci w najważniejszym obecnie systemie operacyjnym na rynku serwerowym (dostępne pod adresem ===bit.ly/3QjAnrI===) przedstawił holenderski ekspert od niskopoziomowych analiz – Frits Hoogland. Jego pracę można streścić na nasze potrzeby następująco. System operacyjny Linux posługuje się pojęciem pamięci wirtualnej – oznacza to, że każdy proces, który zaalokował sobie jakiś stos pamięci, ma swój unikalny zakres adresów (przestrzeń adresową), a translacja z adresu wirtualnego do fizycznego odbywa się za pomocą specjalnej fizycznej jednostki procesora, zwanej MMU (ang. memory management unit). Każdy proces posiada możliwość zablokowania 16 eksabajtów (2^64 bajtów) pamięci wirtualnej. Jednak fizyczna pamięć przypisana do serwera ma swoje sprzętowe ograniczenia. Jeśli spojrzymy na wynikowe dane dotyczące procesora maszyny przedstawione na %%listingu 1%% możemy zobaczyć, że nasz serwer posiada jeden socket o możliwości adresacji 2^46 pamięci RAM, czyli 64 terabajtów. Przyjrzyjmy się raportowaniu Linuksa na temat zużytej pamięci wirtualnej przez prosty proces:

[root@kordelas ~]# ps -o vsz -C less
   VSZ
  7168

VSZ jest podane w KB, widzimy więc ponad 7 MB zablokowanej pamięci na binarkę, która sama w sobie ma zaledwie 188 KB:

[root@kordelas ~]# du -sk /usr/bin/less
188     /usr/bin/less

Listing 2 przedstawia wszystkie obszary pamięci zablokowane na potrzeby wykonania prostego polecenia <<less>>. W przedstawionym w niej listingu zwracają uwagę biblioteki użyte do uruchomienia tego polecenia:

 

 

  • /usr/lib64/libc-2.28.so;
  • /usr/lib64/libtinfo.so.6.1;
  • /usr/lib64/ld-2.28.so;


[root@kordelas ~]# du -sk /usr/lib64/libc-2.28.so
3096    /usr/lib64/libc-2.28.so
[root@kordelas ~]# du -sk /usr/lib64/ld-2.28.so
276     /usr/lib64/ld-2.28.so
[root@kordelas ~]# du -sk /usr/lib64/libtinfo.so.6.1
184     /usr/lib64/libtinfo.so.6.1

Sumaryczny rozmiar powyższych elementów wynosi już ponad 3 MB. Jeśli dorzucimy do tego obszary stosu, wykonania i zmiennych, otrzymamy naszą raportowaną pamięć wirtualną o wielkości 7 MB.

Nie oznacza to jednak, że nasz proces tyle właśnie pamięci operacyjnej zużył, a jedynie, że potencjalnie mógłby to zrobić, gdyby wszystkie podlinkowane biblioteki zostały użyte w całości i odczytane. Konkluzja zatem jest taka, że rozmiar wirtualnej pamięci dla danego procesu nie mówi nam absolutnie nic. Kierując się tą wiedzą, spokojnie ignorujemy kolumnę VIRT ze zrzutu ekranu dostarczonego przez klienta, gdzie każdy proces zajmuje ponad 34 GB, ponieważ możemy uznać, że jest to suma wielkości wszystkich potencjalnych bibliotek środowiska bazodanowego Oracle, które mogłyby zostać odczytane, jak również potencjalnie zmapowane obszary pamięci współdzielonej.

 

Zdecydowanie bardziej interesującą nas statystyką jest zwykle pamięć RSS, która zgodnie z definicją pokazuje pamięć faktycznie użytą przez badany proces:

rss         RSS       resident set size, the non-swapped physical memory that a task has used (in kiloBytes).  (alias rssize, rsz)

Dla takiego polecenia <<less>> kolumna RSS pokazuje znacznie bardziej wiarygodną wielkość:

[root@kordelas ~]# ps -o rss -C less
  RSS
 2128

W załączonym zrzucie ekranu ta wielkość zawarta jest w kolumnie RES i to właśnie ona zaniepokoiła administratorów klienta. W momencie wystąpienia problemu RSS wynosiło ponad 17 GB, podczas gdy przed migracją, ta wielkość nie wzrastała powyżej 200 MB. Słusznie można podejrzewać, że wskazane liczby nie oddają rzeczywistego stanu, ponieważ ilość fizycznego RAM-u w serwerze nie wystarczyłaby na takie pokrycie zapotrzebowania procesów bazy danych Oracle. Jednak w przypadku rozpatrywania tak złożonych systemów jak Oracle RDBMS nie można pominąć wpływu na raportowanie zużycia pamięci, segmentów współdzielonych.

 

[...]

 

Autor jest laureatem Oracle ACE Director i członkiem stowarzyszenia Oracle OakTable zrzeszającego ok. 100 najlepszych specjalistów na świecie.

Pełna treść artykułu jest dostępna w papierowym wydaniu pisma.

prenumerata Numer niedostępny Spis treści

.

Transmisje online zapewnia: StreamOnline

All rights reserved © 2019 Presscom / Miesięcznik \"IT Professional\"