리눅스 메모리 관리: 완벽 가이드 및 최적화

인포매텍 디지털 » Recursos » 리눅스 메모리 관리: 완벽 가이드 및 최적화

리눅스 기반 서버나 데스크톱을 사용할 때, 메모리 관리는 시스템의 속도를 결정짓는 핵심 요소 중 하나입니다 . 데비안, 우분투, 알마리눅스, 센토OS 등 어떤 배포판을 사용하든, 리눅스가 RAM, 스왑, 그리고 기타 내부 메커니즘을 어떻게 처리하는지 이해하는 것은 시스템 충돌, 성능 저하, 안정성 문제를 예방하는 데 매우 중요합니다.

더 나아가, 고성능 데이터베이스, 컨테이너, 데스크톱 환경, 그리고 무거운 애플리케이션을 실행하는 현대 환경에서는 단순히 "RAM이 많다"는 것만으로는 충분하지 않습니다. RAM 용량을 제대로 파악하는 것이 필수적입니다. 리눅스가 메모리를 사용하는 방식, 지표의 실제 의미는 무엇일까요? 우리는 무엇에서 볼 수 있습니까? 같은 도구 top, htop, free o vmstat그렇다면 커널, 스왑, cgroups 또는 zram, zswap, EarlyOOM, systemd-oomd와 같은 메커니즘의 동작을 세밀하게 조정할 수 있는 옵션은 무엇일까요?

리눅스에서의 메모리 기초

리눅스는 사용 가능한 메모리를 최대한 활용하도록 설계되었기 때문에, 커널이 RAM을 디스크 캐시, 버퍼, 임시 저장소 로 사용하여 데이터와 애플리케이션 접근 속도를 높이기 때문에 RAM이 거의 "비어있는" 것처럼 보이지 않습니다. 이로 인해 많은 오해가 생기는데, "사용 가능한" 메모리가 적다고 해서 문제가 있는 것이 아니라 시스템이 효율적으로 작동하고 있다는 뜻입니다.

컴퓨터가 관리할 수 있는 총 메모리 용량은 운영 체제 아키텍처 에 따라 다릅니다 . 32비트 시스템은 일반적으로 약 4GB의 주소 지정 가능한 메모리로 제한되는 반면, 64비트 시스템은 수십 또는 수백 기가바이트를 쉽게 처리할 수 있습니다. 이론적으로 64비트 아키텍처는 엄청난 양(엑사바이트 단위)을 지원하지만, 실제 한계는 사용되는 하드웨어와 커널에 의해 결정됩니다.

리눅스는 다음과 같은 것을 결합합니다. 분할 및 페이지네이션 메모리를 구성하기 위해 메모리는 고정 크기 페이지(일반적으로 4KiB)로 나뉘며, 이 페이지는 다음과 같은 방식으로 쿼리할 수 있습니다. getconf PAGESIZE커널은 가상 주소를 물리적 주소로 변환하고, 권한을 적용하고, 각 페이지의 상태를 제어하기 위해 페이지 테이블이라는 내부 구조를 관리합니다.

컴퓨터에 설치된 물리적 메모리, 즉 RAM 은 비싸지만 매우 빠른 자원입니다. 리눅스는 이를 프로세스 실행, 데이터 캐시, 공유 메모리, I/O 버퍼 및 내부 커널 구조에 사용합니다. 프로세스가 RAM을 모두 사용하지 못할 경우, 시스템은 디스크 캐싱을 통해 부족한 부분을 채워 속도가 느린 파일과 저장 장치에 대한 접근 속도를 높입니다.

리눅스는 RAM 용량이 제한적이기 때문에 가상 메모리와 스왑 메커니즘을 사용하여 사용 가능한 공간을 논리적으로 확장합니다 . 이를 통해 프로세스는 페이지가 RAM과 하위 보조 저장 장치 사이에서 재사용되고 이동되더라도 크고 연속적인 주소 공간을 볼 수 있습니다.

가상 메모리, 물리 메모리, 스왑 및 디스크

리눅스에서 "가상 메모리"라는 용어는 각 프로세스가 접근할 수 있는 메모리 공간을 가리키는 데 자주 사용됩니다. 각 프로그램은 프로세서의 MMU와 커널의 페이지 테이블 덕분에 격리되고 보호된 자체 주소 공간을 사용할 수 있습니다 . 이 공간은 사용 가능한 RAM보다 훨씬 크며 물리적 메모리, 스왑 영역 및 매핑된 파일을 모두 활용합니다.

물리적 메모리(RAM)는 실제로 사용 중인 페이지가 저장되는 공간입니다. 일반적인 작업 부하에 충분한 RAM을 확보하는 것이 매우 중요합니다 . 예를 들어, MongoDB와 같은 데이터베이스를 사용하는 서버는 데이터베이스 엔진 및 기타 서비스에 필요한 것보다 더 많은 물리적 메모리가 필요합니다. MongoDB가 스왑을 과도하게 사용하게 되면 성능이 급격히 저하되기 때문입니다. RAM 접근 속도는 나노초 단위인 반면, 디스크 스왑은 밀리초 단위로 작동합니다.

스왑 메모리는 RAM의 속도를 늦춘 확장 기능 입니다 . 물리적 메모리가 가득 차면 Linux는 사용 빈도가 낮은 페이지를 스왑 공간으로 이동할 수 있습니다. 스왑 공간은 전용 파티션이거나 파일 시스템 내의 파일일 수 있습니다. 두 가지 방식 모두 유효하며, 선택은 관리 정책, 관리 용이성 및 최대 절전 모드 요구 사항에 따라 달라집니다.

스왑 공간에 대한 오해를 바로잡는 것이 중요합니다. 스왑 공간 자체가 시스템 속도 저하의 주범은 아닙니다. 스왑 공간 그 자체만으로는 시스템 속도 저하의 원인이 아니며, 모든 시스템이 다운될 때만 사용해야 하는 리소스도 아닙니다. 제대로 구성된 스왑 공간은 오랫동안 사용되지 않은 익명 페이지(예: 프로세스 메모리의 일부)와 같은 비활성 페이지를 제거하여 RAM을 확보하고 , 속도가 필요한 새로운 작업에 필요한 공간을 만들어 줍니다.

RAM과 스왑 영역 외에도 저장 장치가 중요한 역할을 합니다. 디스크 메모리는 재부팅이나 정전 후에도 유지되는 영구 데이터를 저장합니다 . 컴퓨터 전원이 켜져 있는 동안 이러한 데이터의 대부분은 RAM(페이지 캐시)에 저장되며, 커널은 최근 사용량 데이터를 기반으로 어떤 페이지를 유지하고 어떤 페이지를 제거할지 결정하여 비용이 많이 드는 디스크 접근을 최소화합니다.

리눅스에서 메모리 사용량이 어떻게 흐르는지

리눅스 시스템에서 일반적인 데이터 흐름은 여러 구성 요소로 이루어져 있습니다. 사용자 또는 애플리케이션이 요청을 생성하면 시스템은 이를 메모리 및 디스크 접근 으로 변환합니다 . 저장소에서 읽은 데이터는 먼저 RAM에 로드되어 페이지 캐시에 저장됩니다. 다시 요청이 있을 때 커널은 해당 데이터가 이미 캐시되어 있는지 확인하여 새로운 디스크 접근을 방지합니다.

CPU와 MMU 또한 이 과정에 관여합니다. CPU는 가상 주소를 기반으로 작동하며, 페이지 테이블을 사용하여 하드웨어는 각 접근을 RAM의 물리적 주소로 변환하거나, 주소가 로드되지 않은 경우 페이지 폴트 메커니즘을 사용하여 해결합니다. 데이터를 영구 저장해야 하는 경우 디스크에 기록되지만, 데이터를 처리하는 동안에는 성능 향상을 위해 빠른 메모리 에 유지하는 것이 우선시됩니다.

RAM 용량이 부족해지기 시작하면 커널은 메모리 회수 알고리즘을 작동시킵니다. 사용 빈도가 낮은 페이지 캐시를 해제하고, 메모리 영역을 압축하며, 우선순위가 낮은 페이지에 대해서는 스왑을 사용하고, 상황이 심각해지면 OOM-killer를 활성화하는 것과 같은 더욱 강력한 조치를 취할 수 있습니다.

리눅스에서 프로세스의 메모리 맵

리눅스에서 실행되는 모든 프로세스는 주소 공간이 어떻게 구성되는지를 정의하는 메모리 맵 또는 메모리 레이아웃을 가지고 있습니다 . 즉, 실행 코드, 전역 변수, 힙, 스택, 명령줄 인수, 환경 변수, 공유 파일 또는 라이브러리 매핑이 어디에 위치하는지를 나타냅니다.

이 주소 공간은 일반적으로 여러 개의 뚜렷한 부분으로 나뉩니다. 가상 공간의 맨 아래에는 텍스트 영역 (프로그램의 이진 코드)이 있고, 그 아래에는 초기화된 데이터 영역과 초기화되지 않은 데이터 영역(BSS), 동적 할당이 저장되는 힙, 그리고 맨 위에는 프로세스 스택이 있습니다. 인자와 환경 변수 또한 주소 공간의 상단에 위치합니다.

텍스트 영역에는 프로그램의 실행 명령어와 공유 라이브러리의 명령어가 포함되어 있습니다 . 이 영역은 일반적으로 읽기 전용이며, 동일한 바이너리를 실행하는 여러 프로세스에서 공유될 수 있으므로 물리적 메모리를 절약할 수 있습니다. 이 영역에 쓰기를 시도하면 세그멘테이션 오류가 발생합니다.

초기화된 데이터 세그먼트는 초기값이 0이 아닌 전역 변수와 정적 변수를 저장합니다. 이 세그먼트는 데이터 유형에 따라 읽기 전용 부분과 읽기/쓰기 부분으로 개념적으로 나눌 수 있습니다. 반면, BSS 세그먼트는 코드에서 명시적인 값이 없거나 0으로 초기화된 전역 변수 또는 정적 변수를 그룹화합니다.

힙은 malloc, calloc, realloc과 같은 명령어를 통해 관리되는 동적 메모리 영역입니다 . 프로그램이 메모리를 요청하면 사용자 메모리 관리자가 힙에서 메모리를 할당받고, free 명령어로 메모리를 해제하면 해당 메모리는 힙으로 반환되지만 운영 체제에는 반환되지 않을 수 있어 내부적인 메모리 조각화가 발생할 수 있습니다. 스택은 함수 내 변수, 반환 주소, 매개변수 등을 저장하는 데 사용되며, 함수 호출 및 반환 시마다 크기가 커지거나 작아집니다.

실행 중인 프로세스의 메모리 맵을 검사하려면 다음과 같은 도구를 사용할 수 있습니다. pmap 그것들은 매우 유용합니다. pmap <PID> 매핑된 다양한 영역, 크기, 권한, 익명 영역인지 파일과 연결된 영역인지 여부, RAM 상주 크기(RSS) 및 애플리케이션의 실제 메모리 사용량을 파악하는 데 도움이 되는 기타 지표를 확인할 수 있습니다.

핵심 개념: 페이지, 페이지 폴트, 캐시

리눅스에서 메모리 관리의 최소 단위는 메모리 페이지 이며 , 일반적으로 4KiB 크기이지만 특정 작업 부하에 따라 더 큰 페이지(대용량 페이지)도 사용할 수 있습니다. 이동, 해제 또는 캐시에 대한 모든 커널 결정은 개별 바이트 수준이 아닌 페이지 수준에서 이루어집니다.

페이지 테이블은 커널이 관리하는 계층 구조로, 가상 주소가 물리적 주소로 변환되는 방식을 나타냅니다. 각 항목에는 읽기, 쓰기 및 실행 권한 , 페이지 상태(메모리, 스왑, 변경됨, 공유됨 등) 및 MMU가 변환 과정에서 사용하는 기타 메타데이터에 대한 정보가 포함될 수 있습니다.

페이지 폴트는 프로세스가 유효한 가상 주소에 접근했지만 해당 페이지가 사용 준비가 되지 않았을 때 발생합니다. 페이지가 아직 할당되지 않았거나, 디스크에 있거나, 초기 매핑이 필요한 경우 등이 이에 해당합니다. 커널은 해당 페이지를 찾거나 생성하기 위해 개입합니다 . 페이지가 RAM에 있지만 제대로 표시되지 않은 경우, 폴트 비용은 낮습니다. 하지만 디스크(스왑 영역 또는 파일)에서 페이지를 가져와야 하는 경우에는 비용이 훨씬 높아집니다.

페이지 캐시는 리눅스의 뛰어난 성능을 뒷받침하는 중요한 요소 중 하나입니다. 커널은 파일 데이터와 메타데이터를 RAM에 저장 하여 읽기 및 쓰기 속도를 높이고 디스크 접근 횟수를 획기적으로 줄입니다. 따라서 사용 가능한 메모리가 부족해 보일지라도 실제로는 많은 양의 RAM을 사용할 수 있습니다. 커널은 애플리케이션이 더 많은 메모리를 필요로 할 경우 캐시 공간을 신속하게 해제할 수 있기 때문입니다.

가상 공간 내에서는 파일 메모리와 매핑된 파일(예: 바이너리 및 라이브러리 코드 또는 명시적으로 매핑된 파일)을 구분합니다. mmap), 그리고 파일 백업이 없는 힙, 스택 및 기타 매핑에 해당하는 익명 메모리가 있습니다. 후자는 필요한 경우에만 스왑 아웃될 수 있습니다. 해당 파일을 복원할 수 있는 소스가 없습니다..

메모리 압박, 과부하 및 메모리 부족(OOM)

사용 가능한 페이지 수가 특정 임계값 아래로 떨어지면 시스템이 메모리 압박 상태에 빠진다고 합니다 . 이 경우 커널은 해제, 압축 또는 스왑 영역으로 이동할 수 있는 페이지를 찾는 데 더 많은 시간을 소비해야 하므로 전반적인 성능에 영향을 미칩니다.

웹 서버에서 메모리 사용량이 많아지면 지연 시간이 증가 할 수 있습니다 . 작업자는 요청 처리를 계속하기 전에 페이지가 해제될 때까지 기다려야 하며, CPU는 페이로드를 처리하는 대신 메모리 관리 작업에 시간을 소모하게 됩니다. 데스크톱 환경에서는 이러한 현상이 화면 끊김, 마우스 반응 속도 저하, 창 응답 없음, 심지어는 순간적인 멈춤 현상으로 나타납니다.

SSH, RDP 또는 VNC를 통한 원격 접속 시, 이러한 상황은 명령 실행 시 "멈춤" 현상, 타이핑 지연, 그리고 전반적으로 느린 반응 속도로 나타납니다. 스왑 메모리가 과도하게 사용될 경우, 시스템이 유용한 코드 실행보다 RAM과 스토리지 간의 페이지 이동에 더 많은 시간을 소모하는 스래싱(thrashing) 상태가 발생할 수 있습니다.

RAM 용량이 활성 프로세스 집합을 유지하기에 부족할 때 스래싱 현상이 발생합니다. 스왑이 활성화된 경우 익명 페이지가 RAM과 스왑 공간 사이를 끊임없이 이동하면서 디스크 I/O를 유발합니다. 스왑이 비활성화된 경우 커널은 이러한 익명 페이지를 저장할 공간이 없으므로 OOM-killer를 사용하여 프로세스를 종료하는 것 외에는 해결책이 없습니다.

스왑이 없더라도 파일 메모리 스래싱이 발생할 수 있습니다. 파일 캐시에 속한 페이지가 애플리케이션이 필요로 하는 속도에 맞춰 디스크에서 지속적으로 배출되고 다시 로드되면서 I/O 활동의 루프가 발생하고 극심한 속도 저하가 초래됩니다.

커널이 캐시 해제, 스왑 영역으로 페이지 이동, 압축, cgroups 정책 적용 등 메모리 확보를 위한 모든 방법을 다 사용했을 때 메모리 부족(OOM) 상태가 됩니다 . 이때 OOM 킬러는 메모리를 회수하고 시스템의 나머지 부분을 보호하기 위해 하나 이상의 프로세스를 종료해야 합니다.

어떤 프로세스를 종료할지 선택하기 위해 커널은 다음을 계산합니다. oom_score 각 PID에 대해 메모리 사용량, 프로세스 중요도 및 기타 내부 매개변수와 같은 요소를 기반으로 동작이 결정됩니다. 이 동작은 다음을 통해 수정할 수 있습니다. oom_score_adj특정 프로세스의 가중치를 조정하는 도구입니다. 예를 들어 다음과 같은 도구들이 있습니다. choom 이 기능을 사용하면 이러한 값을 쉽게 확인하고 변경할 수 있습니다.

물물교환: 잘못된 상식, 모범 사례 및 현대적 변형

스왑은 다소 부당하게 나쁜 평판을 얻고 있습니다. 많은 사용자는 스왑을 무슨 수를 써서라도 피해야 하거나, RAM 용량이 매우 제한적일 때만 의미가 있다고 생각합니다. 하지만 리눅스에서 스왑은 전체적인 가상 메모리 전략 의 일부입니다 . 커널이 스왑을 통해 비활성 익명 페이지를 RAM에서 제거하여 활성 데이터와 페이지 캐시의 우선순위를 높일 수 있습니다.

스왑을 모든 방법이 실패했을 때만 사용하는 "최후의 수단"으로 생각하는 것은 잘못된 생각입니다. 실제로 RAM이 충분한 시스템에서도 스왑은 커널에 여유 공간을 제공하여 메인 워킹 세트를 더욱 민첩하게 유지하고 물리적 메모리를 효율적으로 활용할 수 있도록 해줍니다. 하지만 스왑 사용량이 매우 높고 지속적으로 높을 경우 성능 저하가 눈에 띄게 나타나는 것은 사실입니다.

실질적으로, 스왑 영역은 RAM 용량의 1~2배여야 한다는 기존 규칙은 더 이상 불변의 법칙이 아닙니다. 대용량 메모리를 탑재한 서버에서는 훨씬 작은 스왑 영역을 비례적으로 할당하거나, zram이나 zswap과 같은 기술을 사용하여 스왑 영역을 RAM에 압축함으로써 성능을 향상시키고 디스크 쓰기 횟수를 줄이는 것이 일반적입니다.

스왑 공간의 또 다른 활용 사례는 최대 절전 모드입니다. 시스템은 RAM의 내용을 스왑 공간으로 옮기고 완전히 종료한 다음, 시작 시 원래 상태로 복원할 수 있습니다. 이를 위해서는 사용 가능한 스왑 공간이 절약할 메모리 용량 이상이어야 하며, 이는 최대 절전 모드를 지원하지 않는 zram과 기존 디스크 스왑 방식 중 어떤 것을 선택할지에 영향을 미치는 요소입니다.

최근 몇 년 동안 일부 커널에서 OOM-killer의 오작동 사례가 보고되고 있는데, OOM-killer가 작동하기 전에 시스템이 충돌하는 현상입니다. 특정 경우에는 다음과 같은 단축 기능을 활성화하면 이러한 문제를 해결할 수 있습니다. Alt+SysRq+F (매개변수를 활성화한 후) /proc/sys/kernel/sysrq이를 통해 OOM-killer가 시스템이 멈춘 것처럼 보일 때 시스템을 복구하도록 강제할 수 있습니다. 또한 EarlyOOM, nohang, systemd-oomd와 같은 데몬은 커널이 극단적인 상황에 도달하기 전에 대응하기 위해 등장했습니다.

메모리 모니터링 및 관리 도구

메모리 문제를 방지하려면 올바른 도구를 사용하는 것이 필수적입니다. 다음과 같은 명령어를 사용하세요. free, top, htop, vmstat, ps o sar 제안하다 시스템 상태를 매우 상세하게 보여주는 X선 사진실시간으로도, 시간에 따라서도 마찬가지입니다.

명령 free 이 기능은 총 메모리 용량, 사용 중인 메모리, 여유 메모리, 캐시 메모리, 버퍼는 물론 스왑 정보까지 빠르게 표시합니다. 물리적 메모리가 실제로 부족한지, 아니면 대부분의 메모리가 캐시되어 문제없이 재사용될 수 있는지 확인하는 데 매우 유용합니다.

클래식 top 그리고 그 개선된 버전 htop 이 도구들을 사용하면 프로세스별 CPU 및 메모리 사용량은 물론 시스템 부하, 가동 시간, 스왑 사용량 및 기타 지표를 실시간으로 확인할 수 있습니다. htop은 더욱 사용자 친화적인 인터페이스를 제공합니다.색상 막대와 키보드 단축키를 사용하여 프로세스를 빠르게 정렬, 필터링 또는 종료할 수 있습니다.

명령 vmstat 이 도구는 메모리 통계, 프로세스, 페이징, 인터럽트 및 CPU 스케줄링과 같은 보다 기술적인 관점을 제공합니다. 과도한 페이지 폴트, 높은 스왑 활동 또는 스래싱 패턴을 감지하는 데 이상적입니다. 한편, ps 이 기능을 사용하면 상주 메모리(RSS), 가상 메모리(VSZ) 및 "실행된" 애플리케이션을 찾는 데 도움이 되는 기타 매개변수 열을 포함하여 프로세스를 매우 자세하게 나열할 수 있습니다.

Debian 또는 AlmaLinux 환경에서는 다음과 같은 패키지가 있습니다. sysstat 그들은 다음과 같은 추가 명령을 제공합니다. sar, 할 수있는 시간에 따른 메모리 사용량 기록이를 통해 소비량 급증을 예정된 작업, 배포 또는 특정 이벤트와 연관시켜 시스템 구성을 그에 맞게 조정할 수 있습니다.

특정 프로세스의 메모리 맵을 검사하려면, 추가적으로 다음을 수행할 수 있습니다. pmap가상 파일 시스템을 살펴보는 것은 언제나 좋은 생각입니다. /proc각 프로세스는 메모리 맵을 포함한 자세한 정보가 담긴 자체 디렉터리를 가지고 있습니다. /proc/<PID>/maps 그리고 통계 /proc/<PID>/smaps.

기본 최적화: 스왑, 캐시 및 스왑 기능

이론을 넘어, 실천하기 쉬운 몇 가지 간단한 방법들이 있습니다. 리눅스에서 메모리 관리 미세 조정하기 미치지 않고. 가장 먼저 해야 할 일 중 하나는 스왑 상태를 확인하는 것입니다. swapon --show 또한, 필요한 경우 파티션에만 의존하는 대신 스왑 파일을 생성할 수 있습니다. 이렇게 하면 디스크를 다시 파티션하지 않고도 크기를 유연하게 조정할 수 있습니다.

매개 변수 vm.swappiness 이 설정은 커널이 스왑을 얼마나 적극적으로 사용할지, 캐시를 얼마나 자주 해제할지를 제어합니다. 값이 높을수록 스왑이 더 자주 사용되고, 값이 낮을수록 극단적인 경우에만 스왑을 사용하며 데이터를 RAM에 유지하는 것을 우선시합니다. 설정에는 다음과 같은 내용이 포함됩니다. 교환성=10 이러한 플러그인은 대부분의 데스크톱 및 경량 서버 환경에서 잘 작동하며, 일시적으로 적용할 수 있습니다. sysctl을 사용한 커널 최적화 또는 지속적으로 /etc/sysctl.conf.

특정 상황, 예를 들어 집중적인 읽기 작업이 완료된 후와 같이 캐시를 수동으로 지워야 하는 경우에는 해당 설정을 사용할 수 있습니다. vm.drop_caches. 결합 sync 그리고 해당 매개변수에 적절한 값(1, 2 또는 3)을 쓰면 커널이 특정 캐시를 버립니다. 하지만 이 기능은 신중하게 사용하는 것이 좋습니다. 왜냐하면 캐시는 "낭비되는 메모리"가 아닙니다.하지만 상당한 최적화입니다.

Debian이나 AlmaLinux 같은 배포판에서는 이러한 설정에 더해 리소스를 많이 사용하는 프로세스를 효과적으로 모니터링하는 것이 일반적입니다. htop o ps메모리를 과도하게 사용하는 서비스 또는 애플리케이션을 식별하고, 필요한 경우 재구성하거나 메모리 사용량을 제한합니다.

스왑 영역을 생성하고 조정하는 것은 비교적 간단한 작업입니다. 단순히 파일을 예약하기만 하면 됩니다. fallocate올바른 권한을 부여하고 스왑 파일로 초기화합니다. mkswap 그리고 그것을 활성화하세요 swapon변경 사항을 영구적으로 적용하려면 적절한 항목을 추가합니다. /etc/fstab 이 파일이 부팅할 때마다 스왑 파일로 사용될 것임을 나타냅니다.

고급 기술: 사용자 공간에서의 zram, zswap, cgroupv2 및 OOM

최적화를 한 단계 더 발전시키고자 할 때, 메모리를 최대한 활용하고 시스템 부하 시 응답성을 향상시키도록 설계된 EarlyOOM, nohang, systemd-oomd와 같은 데몬 외에도 zram, zswap, 네임스페이스, cgroups 와 같은 고급 메커니즘이 사용됩니다.

zram은 커널 모듈을 사용하여 RAM 자체에 압축 블록 장치를 생성합니다. 이러한 장치에 스왑 공간을 마운트할 수 있으므로 페이지는 저장되기 전에 압축됩니다. 실제로 이는 압축에 약간의 CPU 시간이 소요되지만 사용 가능한 메모리를 더 효율적으로 활용할 수 있게 해주고 디스크에 쓸 필요가 없어집니다. 다만, 최대 절전 모드 기능은 사용할 수 없게 됩니다.

zswap은 디스크의 실제 스왑 공간에 대해 압축된 캐시 역할을 합니다. 스왑될 페이지는 처음에 RAM에 압축된 상태로 저장되고, 해당 캐시가 가득 차거나 페이지가 제거될 때만 기존 스왑 공간에 기록됩니다. 이는 디스크 I/O를 줄이고 SSD의 수명을 연장하며, 스왑 사용량이 적당한 상황에서 성능을 향상시킵니다.

리소스 제어 영역에서 cgroupv2는 프로세스를 계층 구조로 구성하고 메모리, CPU 및 기타 리소스를 할당하는 강력한 메커니즘을 제공합니다. 이는 다음과 같은 매개변수를 통해 구현됩니다. memory.low 또는 다음과 같은 파일 memory.pressure커널에 어떤 그룹이 우선순위를 갖는지 알려주고 메모리 부족으로 인해 작업이 차단되는 시간을 모니터링하여 문제가 일부 작업에만 영향을 미치는지 아니면 전체 그룹에 영향을 미치는지 구분할 수 있습니다.

시스템 멈춤 현상을 어떤 경우에도 피해야 하는 상황에서는 OOM(메모리 부족) 상황을 보다 선제적으로 관리하기 위해 여러 사용자 공간 데몬이 등장했습니다. EarlyOOM은 주기적으로 RAM과 스왑 공간을 모니터링하고, 두 공간 모두 특정 임계값 이하로 떨어지면 (기본적으로 10% 미만 무료 (작용을 시작하기 위해) 더 큰 프로세스에 신호를 보냅니다. oom_score 커널 패닉이 발생하기 전에 메모리를 확보하기 위해서입니다.

nohang은 zram을 지원하고 메모리 사용량을 분석하며 충돌 위험이 감지될 때 사용자가 사용자 지정 작업을 정의할 수 있도록 하는 등 유사하지만 더 구성 가능한 접근 방식을 제공합니다. 다른 프로젝트에 비해 활동이 다소 줄어들긴 했지만, 어떤 프로세스를 언제 희생할지 세밀하게 제어 하려는 고급 사용자에게는 여전히 매력적인 옵션입니다.

마지막으로, 페이스북에서 개발되어 최신 systemd를 사용하는 많은 배포판에 통합된 systemd-oomd는 대규모 배포 환경과 데스크톱 환경 모두에 적합한 솔루션을 제공합니다. cgroup 제한, 메모리 사용량 및 기타 지표를 모니터링하고 시스템 사용성을 복원하기 위해 어떤 유닛이나 서비스를 중지할지 결정하여, 기존 커널 OOM-killer보다 더욱 정교한 보완 기능을 제공합니다.

기억력 문제를 예방하기 위한 좋은 습관

일상적인 사용 환경에서 특정 매개변수를 조정하는 것 외에도, Linux에서 메모리 관련 문제를 최소화하기 위해 몇 가지 모범 사례를 따르는 것이 좋습니다 . 첫 번째는 실제 작업 부하에 따라 RAM과 스왑 영역을 적절하게 할당하는 것입니다. 데이터베이스, 애플리케이션 서버, 부하가 큰 데스크톱 환경 또는 여러 컨테이너를 사용하는 환경은 단순한 서비스보다 더 많은 메모리를 필요로 합니다.

서버에서는 실행 중인 서비스를 정기적으로 검토하고 사용하지 않는 서비스는 비활성화하거나 중지하는 것이 좋습니다 . Docker 또는 기타 컨테이너 환경에서는 테스트 또는 임시 배포를 완료한 후 더 이상 필요하지 않은 컨테이너, 이미지 및 볼륨을 정리하여 잔여 프로세스가 메모리를 조용히 소모하는 것을 방지하는 것이 좋습니다.

RAM 디스크는 특정 유형의 임시 작업을 가속화하는 데 유용한 도구입니다. 파일 시스템이 RAM에 정의되어 애플리케이션 데이터나 자주 변경되는 작업 영역을 캐싱하는 데 사용됩니다. 휘발성 디스크이므로 컴퓨터 전원을 끄거나 재시작하면 내용이 모두 손실된다는 점을 이해해야 합니다. 하지만 그 대신 SSD보다 수십 배 빠른 속도를 제공하여 집중적인 임시 읽기/쓰기 작업에 매우 유리합니다.

보안 관점에서 볼 때, 열린 포트를 모니터링하고 반드시 필요한 포트만 노출하는 것이 중요합니다. 암호화폐 채굴 프로그램과 같은 악성코드 공격은 종종 엄청난 양의 CPU와 메모리를 소모하는 프로세스 형태로 흔적을 남기고, 시스템에 작업을 설치할 수도 있습니다. crontab 지속성을 유지하려면 의심스러운 cron 작업을 검토하고 정리하고, 필수적이지 않은 포트를 닫으면 원치 않는 프로세스가 메모리를 소비하는 것을 방지할 수 있습니다.

마지막으로 파일 시스템이 전반적인 성능에 미치는 영향도 간과해서는 안 됩니다. XFS나 Btrfs 와 같은 최신 파일 시스템은 특정 시나리오, 특히 과부하 상태이거나 고급 기능을 활용할 때 ext4보다 유리할 수 있습니다. 각 사례별로 테스트가 필요하지만, 파일 시스템 선택은 메타데이터 및 디스크 접근 처리 방식에도 영향을 미쳐 시스템의 체감되는 부드러움에 간접적으로 영향을 미칩니다.

리눅스에서 메모리 관리를 마스터하려면 RAM, 스왑, 스토리지 할당 방식, 페이지, 페이지 캐시, 메모리 압력, OOM(메모리 부족)과 같은 개념의 역할, 그리고 zram, zswap, cgroupv2, systemd-oomd와 같은 고급 도구 및 메커니즘 사용법을 이해해야 합니다. 이러한 지식을 갖추면 일반 노트북부터 수많은 서비스가 탑재된 운영 서버에 이르기까지 모든 시스템을 훨씬 쉽게 최적화할 수 있으며, 메모리가 더 이상 문제의 원인이 아니라 민첩하고 안정적인 시스템을 구축하고 최대 부하를 문제없이 처리할 수 있도록 지원하는 아군이 될 수 있습니다.