Zrozumienie użycia pamięci wirtualnej> zamień + fizycznie w systemie Linux


9

Mam proces, który zgłasza „u góry”, że ma 6 GB pamięci rezydentnej i 70 GB przydzielonej pamięci wirtualnej. Dziwne jest to, że ten konkretny serwer ma tylko 8 GB pamięci fizycznej i 35 GB dostępnej przestrzeni wymiany.

Z „górnego” podręcznika:

   o: VIRT  --  Virtual Image (kb)
      The total amount of virtual memory used by the  task.   It  includes
      all  code,  data  and  shared  libraries  plus  pages that have been
      swapped out. (Note: you can define the STATSIZE=1 environment  vari-
      able  and  the VIRT will be calculated from the /proc/#/state VmSize
      field.)

      VIRT = SWAP + RES.

Biorąc pod uwagę to wyjaśnienie, spodziewałbym się, że alokacja pamięci virutal dla procesu będzie ograniczona do mojej swap + dostępnej pamięci fizycznej.

Według „pmap” sekcje kodu, biblioteki współużytkowanej i pamięci współużytkowanej tego procesu są minimalne - nie więcej niż 300 mln.

Oczywiście maszyna i proces nadal działają poprawnie (choć powoli), więc czego tu brakuje?

Odpowiedzi:


9

Może to wymagać pamięci zerowej, która nie znajduje się w fizycznym pamięci RAM lub w pliku stronicowania.

Niektóre zasoby, na które warto spojrzeć:

Czy twoja aplikacja tworzy dużo pustych stron pamięci? Jeśli tak, Twoja aplikacja może znacznie skorzystać z:

Pozwala kompresować i dekompresować strony pamięci w czasie rzeczywistym. Z kolei możesz trzymać wszystko w pamięci RAM, a nie zamieniać na dysk ( bardzo wolno ).


Tak, aplikacja wykonuje wiele korelacji w przestrzeni IPV4, więc potencjalnie może mieć wiele pustych stron w zależności od rozkładu ruchu. Będziemy musieli na to uważać. Dzięki!
Brzuch

Cieszę się, że mogę pomóc, mam nadzieję, że jakiś inny użytkownik mnie oznaczy. Wpadłem na mordercze odpowiedzi, ale mam ocenę 1,266 :-(. Nie sądzę, aby użytkownicy błędów serwera lubili mnie, hahhah
The Unix Janitor

1
Kilka powodów, dla których ludzie nie mogą na ciebie głosować: 1. Formatowanie odpowiedzi --- użyj znaczników. 2. Twoja nazwa użytkownika wydaje się ogólna. 3. Co najważniejsze: fakt, że uważasz, że jest wystarczająco ważny, aby wypowiedzieć się na ten temat. Pozostawia kwaśny smak w ustach ludzi.
Belmin Fernandez

@ user37899 Pozytywne opinie dzielą się na 3 kategorie: jak pouczająca jest odpowiedź, jak dobrze sformatowana i łatwa do odczytania oraz jak popularne jest pytanie. Pracowałbym nad twoim formatowaniem, ale musisz też mieć trochę zen i zdać sobie sprawę, że fantastyczne odpowiedzi siedzą na stronie z jednym pozytywnym głosowaniem - popularność pytania jest czynnikiem o największym skutku.
Jeff Ferland

1
Czy trochę formatowania. Mam nadzieję, że to pomaga heh.
Belmin Fernandez

2

Oto dyskusja pamięci virt vs. rezydent:

/programming/561245/virtual-memory-usage-from-java-under-linux-too-much-memory-used

Dyskusja dotyczy procesów Java, ale ma zastosowanie do wszystkiego, co działa pod Linuksem. Najważniejsze w odniesieniu do virt jest to, że całość zawiera całą masę rzeczy, których nigdy nie można użyć. Virt jest czymś, na co warto zwrócić uwagę w 32-bitowych systemach operacyjnych (ponieważ procesy przekroczą limit przestrzeni adresowalnej), ale w większości nie jest przydatny. Jak wspomniano, należy zwrócić uwagę na pamięć rezydentną, która będzie ograniczona do dostępnej fizycznej pamięci RAM i wymiany.


faktycznie zapytał, dlaczego przydzielona pamięć wirtualna jest większa niż jego pamięć fizyczna + przestrzeń wymiany ..
The Unix Janitor

Tak, a dyskusja w Stackoverflow mówi o tym, jak to możliwe.
cjc

1

Jest to prawdopodobne, ponieważ przestrzeń adresowa procesu ma rozmiar, jak podano, ale tak naprawdę nie jest przydzielana przez system operacyjny.

Od: http://lwn.net/Articles/428100/

Próbując osiągnąć cel, jakim jest „wystarczająco niski narzut i brak znaczących opóźnień”, programiści Go przyjęli pewne uproszczenia, z których jednym jest to, że pamięć zarządzana dla działającej aplikacji pochodzi z jednej, praktycznie ciągłej zakres adresów. Takie założenia mogą napotkać ten sam problem, z którym redaktor natrafił na vi - inny kod może alokować elementy w środku zakresu - więc programiści Go przyjęli to samo rozwiązanie: po prostu przydzielają całą pamięć, którą mogą potrzebować (pomyśleli, rozsądnie, że 16 GB powinno wystarczyć w systemie 64-bitowym) podczas uruchamiania.

Jest to więc nieelegancki sposób zarządzania pamięcią czasami - posiadanie ciągłej przestrzeni adresowej upraszcza uwalnianie nieużywanej pamięci.


0

Odpowiedź brzmi prawdopodobnie MMAP - dane znajdują się na dysku, ale są „poza” wymianą i nie można ich zobaczyć za pomocą polecenia „wolny” lub „górny”.

Jeśli proces Java nie jest zbyt skomplikowany, możesz spróbować zagrać w „lsof”, aby dowiedzieć się, gdzie jest plik MMAP. Jednak jeśli ten proces Java jest skomplikowany, będzie trudno go zobaczyć.


-1

Byłem również zaskoczony, że Linux pozwala ci przydzielić więcej pamięci wirtualnej niż jest pamięć fizyczna + przestrzeń wymiany, ale najwyraźniej poprawia wydajność w typowych sytuacjach.

Na szczęście istnieje parametr dostrajania jądra, za pomocą którego można przełączać tryb rozliczania pamięci. Ten parametr to vm.overcommit_memory i wskazuje, który algorytm jest używany do śledzenia dostępnej pamięci. Wartość domyślna (0) wykorzystuje metodę heurystyczną i zastępuje system pamięci wirtualnej. Jeśli chcesz, aby twoje programy otrzymywały odpowiednie błędy braku pamięci przy przydzielaniu zamiast poddawania procesów losowym zabójstwom, powinieneś ustawić ten parametr na 2.

http://www.linuxjournal.com/article/10678


To jest całkowicie zdezorientowane. Overcommit nie jest tym, co pozwala alokować więcej pamięci wirtualnej niż pamięć fizyczna plus przestrzeń wymiany. Możesz to zrobić nawet bez nadmiernego zaangażowania. (Na przykład na komputerze z 2 GB pamięci RAM, bez wymiany i bez nadmiernego zaangażowania, nadal można mapować pamięć pliku 4 GB tylko do odczytu, używając 4 GB pamięci wirtualnej.)
David Schwartz
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.