Po co upuszczać pamięci podręczne w systemie Linux?


84

Na naszych serwerach mamy zwyczaj upuszczania skrytek o północy.

sync; echo 3 > /proc/sys/vm/drop_caches

Kiedy uruchamiam kod, wydaje się, że zwalnia dużo pamięci RAM, ale czy naprawdę muszę to zrobić. Czy wolna pamięć RAM nie jest marnotrawstwem?


62
Znajdź osobę, która to włożyła i zapytaj go, dlaczego to zrobił. Jak słusznie zgadłeś, nie ma wyraźnego uzasadnionego powodu.
Michael Hampton

10
Debugowanie jądra. O to chodzi. To tak naprawdę nie zwalnia żadnej pamięci RAM; porzuca pamięć podręczną, jak sama nazwa wskazuje, a tym samym zmniejsza wydajność.
Michael Hampton

28
@ivcode Następnie należy znaleźć i naprawić problem z tym serwerem, zamiast starać się unikać warunków, które go powodują. Jeśli mój samochód utknął za każdym razem, gdy ostro skręciłem w prawo, unikanie ostrych skrętów w prawo jest kiepskim rozwiązaniem.
David Schwartz

7
Powiązane thedailywtf.com/Articles/Modern-Memory-Management.aspx Mocno argumentując, że to zły pomysł.
Drunix

7
Powiązany i przydatny opis „problemu”: linuxatemyram.com
Bill Weiss

Odpowiedzi:


86

Masz 100% racji. To nie to dobra praktyka, aby zwolnić pamięć RAM. Jest to prawdopodobnie przykład administracji systemem kultu.


9
+1 za wzmiankę o administracji systemu kultowego ładunku. Każdy administrator systemu, który nie zna tego terminu i jego znaczenia, powinien zostać zwolniony.
Tonny

8
@Tonny: Zostalibyśmy wtedy bez działu administracyjnego :(
PlasmaHH

2
Podobnie jak większość ludzkości, uwielbiam zwięzłe zuchwałe twierdzenia z dużą aprobatą, ale cytowanie lub rozumowanie zarobiłoby +1 dla mojego superego.
Aaron Hall

2
Wyjaśnij administrację kultu ładunków, a także powyższe, jeśli nie masz nic przeciwko. Może w dalszej edycji? Nadal wstrzymuję moje +1 ...: P
Aaron Hall

2
„możliwe, że chociaż twoja aplikacja może nie używać tych pamięci RAM, ale Linux agresywnie buforuje się w jej pamięci i chociaż aplikacja potrzebuje pamięci, nie zwolni części pamięci podręcznej, ale wolałaby zacząć zamianę”. Niezbyt konkretny. W praktyce zarządzanie pamięcią nie jest idealne, a posiadanie pokrętła do obracania się, gdy pojawia się ta niedoskonałość, jest dobrą rzeczą.
Dan Pritts,

62

Tak, wyczyszczenie pamięci podręcznej zwolni pamięć RAM, ale powoduje, że jądro szuka plików na dysku zamiast w pamięci podręcznej, co może powodować problemy z wydajnością.

Zwykle jądro wyczyści pamięć podręczną, gdy dostępna pamięć RAM zostanie wyczerpana. Często zapisuje zabrudzoną zawartość na dysku przy pomocy pdflush.


20
+1 za wyjaśnienie, dlaczego to zły pomysł.
Ogre Psalm 33

35

Powodem upuszczenia takich pamięci podręcznych jest testowanie wydajności dysku i jest to jedyny powód, dla którego istnieje.

Podczas przeprowadzania testu porównawczego intensywnego we / wy chcesz mieć pewność, że różne ustawienia, które próbujesz, faktycznie wykonują operacje we / wy na dysku, więc Linux pozwala na upuszczenie pamięci podręcznej zamiast pełnego restartu.

Cytat z dokumentacji :

Ten plik nie jest środkiem do kontrolowania wzrostu różnych pamięci podręcznych jądra (i-węzły, dentries, pagecache itp.). Obiekty te są automatycznie odzyskiwane przez jądro, gdy pamięć jest potrzebna gdzie indziej w systemie.

Korzystanie z tego pliku może powodować problemy z wydajnością. Ponieważ odrzuca obiekty w pamięci podręcznej, odtworzenie upuszczonych obiektów może kosztować znaczną ilość operacji we / wy i procesora, zwłaszcza jeśli były one intensywnie używane. Z tego powodu użycie poza środowiskiem testowym lub debugującym nie jest zalecane.


Oczywiście, w zależności od tego, co próbujesz zrobić, nawet pełne ponowne uruchomienie może niewystarczająco wyczyścić pamięć podręczną dysku.
CVn

1
„te obiekty są automatycznie odzyskiwane przez jądro, gdy pamięć jest potrzebna” jest celem projektu, ale nie zawsze może to być rzeczywiste zachowanie.
Dan Pritts,

@DanPritts Co dokładnie sprawia, że ​​myślisz, że tak nie jest?
Joe

2
Oczywistym przypadkiem jest to, że chcesz wyczyścić pamięć RAM, aby umożliwić przydzielenie większej liczby (nieprzejrzystych) stronicowania; innym przypadkiem jest przezroczyste usuwanie śmieci na dużej stronie wstrzymywanie błędów (patrz moja odpowiedź / komentarze w innym miejscu na to pytanie). Ale mój komentarz był przeznaczony do ogólnej sprawy. Czasami ludzie obsługujący system wiedzą lepiej niż ludzie, którzy go zaprojektowali / wdrożyli. Często nie - przed tym ich komentarz stara się chronić. Cieszę się, że
Dan Pritts

26

Podstawowa idea tutaj prawdopodobnie nie jest taka zła (po prostu bardzo naiwna i wprowadzająca w błąd): mogą być buforowane pliki, do których uzyskanie dostępu w najbliższej przyszłości jest mało prawdopodobne, na przykład pliki logów. Te „zjadają” barana, które później będą musiały zostać uwolnione w razie potrzeby przez system operacyjny w taki czy inny sposób.

W zależności od ustawień swapiness, schematu dostępu do pliku, schematu alokacji pamięci i wielu innych nieprzewidywalnych rzeczy, może się zdarzyć, że gdy nie zwolnisz tych buforów, będą one później zmuszone do ponownego użycia, co zajmuje trochę więcej czasu niż przydzielanie pamięci z puli nieużywanej pamięci. W najgorszym przypadku ustawienia zamiany linuksa spowodują zamianę pamięci programu, ponieważ Linux uważa, że ​​pliki te mogą być używane w najbliższej przyszłości niż pamięć programu.

W moim środowisku Linux często zgaduje, a na początku większości giełd w Europie (około 0900 czasu lokalnego) serwery zaczną robić to, co robią tylko raz dziennie, potrzebując wymiany pamięci, która wcześniej została zamieniona, ponieważ pisanie logi, kompresowanie ich, kopiowanie itp. zapełniało pamięć podręczną do tego stopnia, że ​​trzeba było wymieniać rzeczy.

Ale czy upuszczenie pamięci podręcznej rozwiązuje ten problem? zdecydowanie nie. Rozwiązaniem byłoby powiedzenie linuxowi tego, czego nie wie: że te pliki prawdopodobnie nie będą już używane. Można to zrobić za pomocą aplikacji do pisania, używając rzeczy takich jak posix_fadvise()lub używając narzędzia linii cmd, takiego jak vmtouch(które może być również używane do przeglądania rzeczy, a także plików pamięci podręcznej).

W ten sposób możesz usunąć niepotrzebne dane z pamięci podręcznych i zachować rzeczy, które powinny być buforowane, ponieważ po upuszczeniu wszystkich pamięci podręcznych wiele rzeczy musi zostać ponownie odczytanych z dysku. I to w najgorszym możliwym momencie: kiedy jest potrzebny; powodując zauważalne i często niedopuszczalne opóźnienia w aplikacji.

To, co powinieneś mieć na miejscu, to system, który monitoruje wzorce wykorzystania pamięci (np. Jeśli coś się zmienia), a następnie odpowiednio analizuje i odpowiednio działa. Rozwiązaniem może być eksmisja niektórych dużych plików na koniec dnia za pomocą vtouch; może być również dodawanie większej ilości pamięci RAM, ponieważ dzienne szczytowe użycie serwera jest właśnie takie.


Wszystkie aplikacje na moim serwerze działają w trybie nohup. Może nohup.out jest buforowany i pochłania pamięć?
ivcode

@ivcode: Może to być powód, sprawdź, jak duży jest nohup.out. Może użyj vmtouch, aby dowiedzieć się, ile z tego jest buforowane.
PlasmaHH

Mam zadanie crona cat /dev/null > path/nohup.outco 15 minut, ponieważ nohup.out szybko rośnie. Może linux
buforuje

5
@ivcode Jeśli nie potrzebujesz danych wyjściowych nohup, przekieruj je na adres /dev/null. Wygląda na to, że w twoim systemie pracowali kiedyś niedoświadczeni administratorzy. Zobacz stackoverflow.com/questions/10408816/ ... jak przekierować nohupwyjście do/dev/null
David Wilkins

chociaż nohup.out jest usuwany w 15-minutowych odstępach, jeśli proces aplikacji zostanie z jakiegoś powodu zabity, nohup.out zostanie automatycznie skopiowany z innego skryptu. próbowałem vmtouch. to naprawdę bardzo dobre narzędzie
ivcode

16

Widziałem zrzuty pamięci, które są przydatne podczas uruchamiania kilku maszyn wirtualnych. Lub cokolwiek innego, co korzysta z dużych stron, takich jak niektóre serwery baz danych.

Duże strony w systemie Linux często muszą defragmentować pamięć RAM, aby znaleźć 2 MB ciągłej fizycznej pamięci RAM do umieszczenia na stronie. Uwolnienie całej pamięci podręcznej plików czyni ten proces bardzo łatwym.

Ale zgadzam się z większością innych odpowiedzi, ponieważ nie ma generalnie dobrego powodu, aby co wieczór upuszczać pamięć podręczną plików.


1
Poparłem za wskazanie, że uprzedzeniami drugiego rzędu są odpowiedzi na zrzuty pamięci podręcznej.
Noah Spurrier

1
Ponadto w aplikacjach HPC na węzłach o wysokiej pamięci (1 TB) odczyt kilku dużych plików powoduje buforowanie dużej ilości pamięci. Ponieważ wiele aplikacji HPC wykonuje malloc setki GB, system może utknąć na wiele godzin, ponieważ procesy migracji bezskutecznie przenoszą małe fragmenty pofragmentowanej pamięci w węzłach NUMA, gdy system osiągnie „granicę” pamięci podręcznej. Co gorsza, nic nie możesz zrobić w przestrzeni użytkownika, aby zwolnić pamięć podręczną, z wyjątkiem nakłonienia systemu do przydzielenia wszystkich małych bloków o wielkości 2 MB, które może od razu zwolnić, umożliwiając defragmentowaną defragmentację i aplikacje działające normalnie.
user1649948,

+1 Polecenie tworzenia dużych stron ( sysctl -w vm.nr_hugepages=...) odmawia nawet pracy, chyba że najpierw upuszczę pamięć podręczną (Arch Linux).
Aleksandr Dubinsky

8

Możliwe, że wprowadzono to jako sposób na ustabilizowanie systemu, gdy nie było nikogo z umiejętnościami lub doświadczeniem, aby faktycznie znaleźć problem.

Uwalnianie zasobów

Porzucenie pamięci podręcznej zasadniczo zwolni niektóre zasoby, ale ma to efekt uboczny, ponieważ system faktycznie ciężej pracuje, aby wykonać to, co próbuje. Jeśli system zamienia (próbuje czytać i zapisywać z partycji wymiany dysku szybciej, niż jest w rzeczywistości zdolny), to okresowe upuszczanie pamięci podręcznych może złagodzić symptomy , ale nic nie leczy przyczyny .

Co pochłania pamięć?

Powinieneś ustalić, co powoduje duże zużycie pamięci, które sprawia, że ​​upuszczanie pamięci podręcznej wydaje się działać. Może to być spowodowane dowolną liczbą źle skonfigurowanych lub po prostu źle wykorzystanych procesów serwera. Na przykład na jednym serwerze byłem świadkiem maksymalnego wykorzystania pamięci, gdy witryna Magento osiągnęła określoną liczbę odwiedzających w ciągu 15 minut. Skończyło się to na tym, że Apache został skonfigurowany tak, aby umożliwić jednoczesne uruchamianie zbyt wielu procesów. Zbyt wiele procesów, użycie dużej ilości pamięci (Magento jest czasem bestią) = zamiana.

Dolna linia

Nie zakładaj tylko, że jest to konieczne. Bądź proaktywny, aby dowiedzieć się, dlaczego on jest, miej odwagę, aby go wyłączyć, jeśli inni sugerują, że jest źle, i obserwuj system - dowiedz się, jaki jest prawdziwy problem i napraw go.


4

Linux / m68k faktycznie ma błąd jądra, który powoduje, że kswapd zwariował i zjadł 100% procesora (50%, jeśli jest jakieś inne zadanie związane z procesorem, takie jak autobuilder pakietu binarnego Debiana - vulgo buildd - już działa), co może (większość czasu; nie zawsze) można złagodzić, uruchamiając to polecenie co kilka godzin.

To powiedziawszy… Twój serwer najprawdopodobniej nie jest systemem m68k (Atari, Amiga, Classic Macintosh, VME, Q40 / Q60, Sun3) ;-)

W tym przypadku osoba, która wstawiła się w wiersze, albo zastosowała się do niektórych wątpliwych lub w najlepszym razie przestarzałych rad, albo wpadła na pomysł, w jaki sposób pamięć RAM powinna być używana nieprawidłowo (współczesne myślenie rzeczywiście mówi „wolna pamięć RAM jest marnowana” i sugeruje buforowanie) lub „odkrył”, że to „naprawia” [sic!] inny problem w innym miejscu (i był zbyt leniwy, aby szukać właściwej poprawki).


„błąd jądra, który powoduje, że kswapd wariuje” - Jaki to błąd?
Ben

@Ben zobacz ten wątek (ta wiadomość i kilka następnych, z których jedna zawiera przypuszczenie, skąd może pochodzić)
mirabilos

1
Mam podobny problem (chociaż jest to x86_64) i jedynym rozwiązaniem jest w tej chwili upuszczenie pamięci podręcznej serverfault.com/questions/740790/…
Fernando

2
@Fernando Mam również cronjob „drop cache” na pudełku m68k ☹
mirabilos

3

Jednym z powodów może być to, że witryna prowadzi pewien rodzaj monitorowania, który sprawdza ilość wolnego ram i wysyła ostrzeżenie do administratorów, gdy wolny ram spadnie poniżej określonego procentu. Jeśli to narzędzie do monitorowania jest wystarczająco głupie, aby nie uwzględniać pamięci podręcznej w obliczeniach wolnej pamięci RAM, może wysyłać fałszywe ostrzeżenia; regularne opróżnianie pamięci podręcznej może pomijać te ostrzeżenia, jednocześnie pozwalając narzędziu na wykrycie, kiedy „prawdziwy” RAM obniży się.

Oczywiście w takiej sytuacji prawdziwym rozwiązaniem jest zmodyfikowanie narzędzia do monitorowania w celu uwzględnienia pamięci podręcznej w obliczeniach wolnej pamięci RAM; czyszczenie pamięci podręcznej to tylko obejście, a także złe, ponieważ pamięć podręczna szybko się zapełni, gdy procesy będą miały dostęp do dysku.

Więc nawet jeśli moje założenie jest prawdziwe, czyszczenie pamięci podręcznej nie ma sensu, jest raczej obejściem przez kogoś, kto nie jest wystarczająco kompetentny, aby naprawić główny problem.


3

Mogę wymyślić jeden prawdopodobny powód, aby to zrobić podczas nocnej pracy crona.

W dużym systemie przydatne może być okresowe upuszczanie pamięci podręcznej, aby można było usunąć fragmentację pamięci.

Obsługa przezroczystej strony hukowej jądra dokonuje okresowego przeszukiwania pamięci w celu scalenia małych stron w strony hug. W zdegenerowanych warunkach może to spowodować pauzę systemową trwającą minutę lub dwie (moje doświadczenie z tym było w RHEL6; mam nadzieję, że zostało poprawione). Upuszczenie pamięci podręcznej może pozwolić zamiataczowi stron internetowych na trochę miejsca do pracy.

Możesz argumentować, że jest to dobry powód do wyłączenia przezroczystych stronicowania; OTOH, możesz uważać, że ogólna poprawa wydajności dzięki przezroczystym stronom jest warta i warta zapłaty za utratę pamięci podręcznej raz dziennie.


Zastanawiałem się nad innym powodem, dla którego chciałbyś to zrobić, chociaż nie w pracy z cronem. Byłby to bardzo dobry moment, zanim system wirtualizacji przeprowadzi migrację maszyny wirtualnej na nowy sprzęt. Mniej zawartości pamięci do skopiowania na nowy host. Oczywiście w końcu będziesz musiał czytać z magazynu, ale prawdopodobnie skorzystam z tego kompromisu.

Nie wiem, czy którekolwiek oprogramowanie virt to robi.


1
Czy masz na to jakieś źródło? To brzmi jak coś, co powinno zostać naprawione w jądrze, jeśli jest to taki problem.
gparent

3
Mam osobiste doświadczenia z przerwami z przezroczystymi stronami. RHEL6, Dell R810, 4CPU, 64 GB pamięci RAM. Wyłączenie przezroczystych stronicowania (jest to plik / proc) natychmiast naprawiło przerwy. Nie próbowałem wtedy techniki zrzutu pamięci podręcznej; zamiast tego zmieniłem konfigurację naszych aplikacji Java, aby używały nieprzezroczystych stron próbnych, i pozostawiłem wyłączone strony próbne przezroczyste. IIRC, przyjrzeliśmy się sytuacji na tyle, aby uświadomić sobie, że nie byliśmy jedynymi ludźmi, których to dotyczy, i że Red Hat wiedział o tym problemie.
Dan Pritts,

Witaj Dan, mam takie samo zachowanie na moim serwerze. Pracuję z ogromną ilością danych, a po ponad 10 obliczeniach tego samego programu python (x2-3 czasu pierwszego obliczenia) następuje drastyczny spadek wydajności. Jeśli spojrzę, rozmiar pamięci podręcznej jest ogromny, 100 + GB. A jeśli opróżnię pamięć podręczną i ponownie uruchomię program, odzyskuję początkowy czas obliczeń. Czy masz jakiś dokument lub informacje, aby podzielić się tym zjawiskiem? Dziękuję Ci.
Axel Borja

1
access.redhat.com/solutions/46111 opisuje to. Możesz wyłączyć przezroczyste strony testowe, aby sprawdzić, czy taki jest problem w twoim przypadku.
Dan Pritts,

2

Wystarczy dodać dwa centy: system bardzo dobrze wie, że te strony pamięci są buforami i spadną tyle, ile będzie potrzebne, gdy aplikacja poprosi o pamięć.

Odpowiednim ustawieniem jest to /proc/sys/vm/swappiness, które informuje jądro podczas nowego przydzielania pamięci, aby wolała upuszczać pamięć podręczną lub zamieniać „bezczynne” strony przydzielonej pamięci.


1

Pytanie pochodzi z 2014 roku, ale ponieważ problem istnieje do dziś w niektórych ukrytych backendach centos 6.8, może być nadal przydatny dla kogoś.

https://github.com/zfsonlinux/zfs/issues/1548 opisuje problem z ZFS. Tam miejsce na dysku nie jest zwalniane dla usuniętych plików, ponieważ jeśli nfs jest używany na szczycie zfs, i-węzły pliku nie są usuwane z pamięci podręcznej i-węzłów jądra.

Aby cytować z wątku błędu, behlendorf, 6 stycznia 2015 napisał:

Obecnie spekuluje się, że z jakiegoś powodu serwer NFS przechowuje buforowaną wersję uchwytu pliku. Dopóki serwer NFS nie upuści tego pliku, ZFS nie może odłączyć tego pliku. Niektóre lekkie testy wykazały, że upuszczenie pamięci podręcznej na serwerze spowoduje usunięcie tego odwołania (podobnie jak uchwyt pliku NFS), w którym to miejscu miejsce zostanie poprawnie zwolnione. Ciśnienie pamięci może również spowodować jego spadek.

tzn. nocne echo 3> / proc / sys / vm / drop_caches jest najłatwiejszym rozwiązaniem tego błędu, jeśli nie chcesz mieć przestoju na restrukturyzację ZFS.

Może więc nie administrowanie kultowym ładunkiem, ale powodem było całkiem dobre debugowanie.


0

Może to mieć sens w systemach NUMA (nierównomierny dostęp do pamięci), w których zazwyczaj każdy procesor (gniazdo) może uzyskać dostęp do całej pamięci w sposób transparentny, ale dostęp do własnej pamięci jest szybszy niż w przypadku pamięci innego gniazda, w połączeniu z równoległymi aplikacjami HPC.

Wiele prostych aplikacji równoległych wykonuje operacje we / wy pliku z jednego procesu, pozostawiając przy wyjściu dużą część pamięci w jednym węźle NUMA przydzielonym do pamięci podręcznej dysku, podczas gdy w drugim węźle NUMA pamięć może być w większości wolna. W takich sytuacjach, ponieważ proces odzyskiwania pamięci podręcznej w jądrze Linuksa, o ile wiem, nadal nie obsługuje NUMA, procesy działające w węźle NUMA, który ma pamięć przydzieloną do pamięci podręcznej, są zmuszone do przydzielenia pamięci w innym węźle NUMA, pod warunkiem, że w drugim węźle jest wolna pamięć RAM, co zabija występy.

Jednak w systemie HPC rozsądniej byłoby wyczyścić pamięć podręczną przed rozpoczęciem nowego zadania użytkownika, a nie w określonym czasie z cronem.

W przypadku aplikacji nierównoległych problem ten prawdopodobnie nie wystąpi.


0

Kiedy pamięć podręczna strony jest dość duża (dużo większa niż obecne użycie wymiany), a zamiana i zamiana odbywa się na zmianę, wtedy musisz upuścić pamięć podręczną. Widziałem przypadki, w których zużycie pamięci wzrasta na jednym z moich serwerów bazy danych MariaDB z systemem Ubuntu 16.04LTS, a Linux po prostu postanowił zwiększyć użycie wymiany zamiast usuwać nieużywane pamięci podręczne stron. Przezroczyste strony próbne są już wyłączone w moim systemie, ponieważ TokuDB wymagało wyłączenia. W każdym razie może nie jest to błąd, ale linux nadal zachowując się tak, jest dla mnie dość zagadkowy. Różne źródła podają, że Linux usunie pamięć podręczną strony, gdy aplikacja zażąda:

Ale rzeczywistość nie jest taka prosta. Obejściem jest albo:

  1. Okresowo wykonuj zrzut pamięci podręcznej
  2. W razie potrzeby uruchom pamięć podręczną (monitoruj za pomocą vmstat 1 w celu zamiany działań)
  3. Poradzić linuxowi, aby usunął niektóre pliki z pamięci podręcznej (np. Pliki dziennika apache) za pomocą narzędzia takiego jak dd lub python-fadvise. Zobacz https://unix.stackexchange.com/questions/36907/drop-a-specific-file-from-the-linux-filesystem-cache

Przykład uruchomienia dd:

dd if=/var/log/apache2/access_log.1 iflag=nocache count=0

Przykładowy python-fadvise:

pyadvise -d /var/log/apache2/access_log.1


-5

Mam komputer stacjonarny z 16 GB pamięci RAM działający na jądrze PAE. Po godzinie lub dwóch wydajność dysku dramatycznie spada, dopóki nie upuszczę pamięci podręcznej, więc po prostu wrzucę ją do crona. Nie wiem, czy jest to problem z jądrem PAE, czy też, że implementacja pamięci podręcznej działa tak wolno, jeśli jest dużo pamięci.


9
Jest to doskonały przykład administracji systemu „kultu ładunku”: zamiast lokalizować i rozwiązywać problem, po prostu go maskujesz.
Michael Hampton

2
Czasami celowe rozwiązanie jest właściwe. Może to po prostu odłożyć na bok rozwiązanie prawdziwego problemu lub może być tak dużo rozwiązania, jak jest to wymagane w danych okolicznościach. Nawet jeśli jest to zła praktyka, nadal nie jest to „kult ładunku”. Wykazano przyczynę i skutek: pamięć podręczna zrzutu i wydajność dysku poprawiają się.
Dan Pritts

1
Częścią oryginalnej definicji CCSA była tendencja do mylenia korelacji z przyczynowością, i oto my. Maskowanie problemu przez zajęcie się skorelowanym, ale nie przyczynowym bytem, ​​jest nieoptymalnym rozwiązaniem problemu, przed którym stara się ostrzegać koncepcja CCSA.
underscore_d
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.