cgroups
są właściwym sposobem, aby to zrobić, jak wskazały inne odpowiedzi. Niestety nie ma idealnego rozwiązania tego problemu, ponieważ przejdziemy poniżej. Istnieje wiele różnych sposobów ustawiania limitów użycia pamięci grupy cgroup. To, jak ktoś robi, aby sesja logowania użytkownika była automatycznie częścią grupy, różni się w zależności od systemu. Red Hat ma pewne narzędzia, podobnie jak systemd .
memory.memsw.limit_in_bytes
i memory.limit_in_bytes
ustawić limity, w tym odpowiednio swap i bez. Minusem memory.limit_in_bytes
jest to, że zlicza pliki buforowane przez jądro w imieniu procesów w grupie w porównaniu z przydziałem grupy. Mniejsze buforowanie oznacza większy dostęp do dysku, więc potencjalnie tracisz trochę wydajności, jeśli system miałby dostępną pamięć.
Z drugiej strony memory.soft_limit_in_bytes
pozwala cgroup przekroczyć limit, ale jeśli wywoływany jest zabójca jądra OOM, logicznie zabijane są te grupy, które przekroczyły swoje limity. Wadą tego jest jednak to, że niektóre sytuacje wymagają natychmiastowej pamięci i zabójca OOM nie ma czasu rozejrzeć się za procesami do zabicia, w takim przypadku coś może się nie powieść, zanim procesy użytkownika z nadmierną kwotą zostaną zabity.
ulimit
jest jednak absolutnie niewłaściwym narzędziem do tego. ulimit ogranicza wykorzystanie pamięci wirtualnej, co prawie na pewno nie jest tym, czego chcesz. Wiele rzeczywistych aplikacji wykorzystuje znacznie więcej pamięci wirtualnej niż pamięci fizycznej. Większość środowisk uruchomieniowych zbieranych przez śmieci (Java, Go) działa w ten sposób, aby uniknąć fragmentacji. Trywialny program „witaj świecie” w C, jeśli skompilowany z dezynfekatorem adresu, może wykorzystywać 20 TB pamięci wirtualnej. Alokatory, na których nie można polegać sbrk
, takie jak jemalloc (który jest domyślnym alokatorem dla Rust) lub tcmalloc, wykorzystanie pamięci wirtualnej znacznie przewyższy zużycie fizyczne. W celu zwiększenia wydajności wiele narzędzi mapuje pliki, co zwiększa wykorzystanie wirtualne, ale niekoniecznie fizyczne. Wszystkie procesy Chrome używają 2 TB pamięci wirtualnej. Jestem na laptopie z 8 GB pamięci fizycznej. Jakikolwiek sposób, w jaki ktoś próbowałby tutaj ustawić przydziały pamięci wirtualnej, albo złamałby Chrome, zmusiłby Chrome do wyłączenia niektórych funkcji bezpieczeństwa, które polegają na przydzielaniu (ale nieużywaniu) dużej ilości pamięci wirtualnej, albo byłby całkowicie nieskuteczny w zapobieganiu nadużyciom systemu przez użytkownika .