고급 리눅스 메모리 관리: 완벽하고 실용적인 가이드

인포매텍 디지털 » Recursos » 고급 리눅스 메모리 관리: 완벽하고 실용적인 가이드

시스템을 관리하거나, 컨테이너를 다루거나, 프로덕션 서버를 유지 관리하는 경우, Linux의 메모리 관리에 대한 철저한 이해는 더 이상 선택 사항이 아닙니다. 이는 서버가 부하 급증에도 흔들림 없이 대처할 수 있는지, 아니면 버벅거리거나, 과부하 상태에 빠지거나, 최악의 순간에 OOM killer를 호출하게 되는지 여부를 결정짓는 중요한 요소입니다.

리눅스는 RAM을 최대한 효율적으로 사용하도록 설계되었습니다. 파일을 캐싱하고, 페이지를 압축하고, 데이터를 스왑 영역으로 이동시키고, 매우 정밀한 정책에 따라 프로세스의 우선순위를 지정합니다. 겉으로 보기에는 "메모리를 많이 사용하는 것처럼" 또는 "사용 가능한 RAM이 항상 부족한 것처럼" 보일 수 있지만, 실제로는 최고의 성능과 안정성을 제공하기 위한 것입니다 . 이제 단계별로, 그리고 다소 쉬운 설명과 함께 이러한 모든 작동 방식과 고급 설정 방법을 살펴보겠습니다.

리눅스에서 메모리에 대한 기본 개념과 오해

커널 매개변수를 함부로 변경하거나 zram을 마구 마운트하기 전에 메모리 유형, 아키텍처 및 시스템이 RAM을 인식하는 방식 에 대한 몇 가지 명확한 개념을 갖는 것이 좋습니다.

컴퓨터가 처리할 수 있는 최대 물리적 메모리 용량은 운영 체제와 프로세서 아키텍처에 따라 결정됩니다. 32비트 시스템은 일반적으로 4GB의 RAM으로 제한되는 반면, 64비트 시스템은 수십 또는 수백 기가바이트(이론적으로는 훨씬 더 많지만 실제 한계는 하드웨어에 의해 결정됨)를 쉽게 처리할 수 있습니다.

리눅스에서는 모든 메모리가 가상 메모리 로 관리됩니다 . 여기에는 물리적 RAM과 스왑 공간이 모두 포함됩니다. RAM은 물리적 모듈을 추가하는 것 외에는 확장할 수 없지만, 가상 메모리는 디스크(파티션 또는 스왑 파일)와 zram 또는 zswap과 같은 고급 메커니즘을 사용하여 확장할 수 있습니다.

La 물리적 메모리(RAM) RAM은 빠르고 비용이 많이 드는 자원입니다. 프로세스, 라이브러리, 파일 캐시, I/O 버퍼, 공유 메모리 등이 이곳에 로드됩니다. Linux는 명확한 철학을 가지고 있습니다. 사용 가능한 RAM이 있다면 비워두는 것보다 캐시로 활용하여 접근 속도를 높이는 것이 더 낫습니다. 따라서 도구에서 "사용 가능한" 메모리가 거의 보이지 않는 것입니다. free 그렇다고 해서 당신에게 문제가 있다는 뜻은 아닙니다.

디스크 메모리 ( 영구 저장소)는 훨씬 느립니다. RAM은 나노초 단위로 응답하는 반면, SSD조차도 마이크로초 또는 밀리초 단위로 응답합니다. 따라서 시스템은 자주 사용하는 데이터를 RAM에 유지하고 실행 파일 로딩, 자주 사용하지 않는 데이터 읽기, 페이지 스왑과 같이 절대적으로 필요한 경우에만 디스크에 접근합니다.

가상 메모리, 페이지 및 내부 커널 구조

가상 메모리는 리눅스가 각 프로세스에 자체적으로 격리되고 보호된 주소 공간을 제공하는 메커니즘입니다 . 하드웨어와 커널은 페이지 테이블이라는 구조를 통해 가상 주소를 물리적 주소로 변환합니다.

메모리 관리에 사용되는 가장 작은 단위는 페이지 이며 , 일반적으로 4KB입니다. 전체 가상 메모리 시스템은 페이지를 중심으로 작동합니다. 페이지는 할당, 해제, 스왑, 캐싱되고, 읽기 전용, 실행 등 다양한 권한으로 표시됩니다.

페이지 테이블 은 커널에서 관리하는 계층적 구조입니다. 각 프로세스의 가상 페이지에 대해 실제 물리적 페이지의 위치(존재하는 경우), 권한 및 현재 상태를 저장합니다. 이러한 변환을 통해 프로세스를 격리하고, 프로세스를 통해 페이지를 공유하며, 파일을 메모리에 직접 매핑할 수 있습니다.

프로세스가 유효한 주소에 접근했지만 페이지가 접근 준비가 되지 않은 경우 페이지 폴트가 발생합니다 . 이는 가벼운 오류일 수도 있고(페이지가 RAM에 있지만 업데이트가 필요한 상태인 경우), 비용이 많이 드는 오류일 수도 있습니다(페이지가 디스크, 스왑 영역 또는 파일에 있고 RAM으로 가져와야 하는 경우). 페이지 폴트가 빈번하게 발생하면 시스템이 디스크에서 읽는 데 너무 많은 시간을 소비하게 되어 속도가 느려집니다.

페이지 캐시 는 커널이 관리하는 파일 페이지 캐시입니다. 파일과 디렉터리의 데이터 및 메타데이터를 저장하여 디스크 접근 횟수를 줄여줍니다. 리눅스가 마치 모든 RAM을 사용하는 것처럼 보이는 이유 중 하나는 바로 이 페이지 캐시 때문입니다. 실제로는 애플리케이션이 활발하게 사용하지 않는 메모리를 활용하여 디스크 접근 속도를 높이는 것입니다.

메모리 유형: 파일 기반 메모리, 익명 메모리, 그리고 스왑과의 관계

리눅스에서는 일반적으로 파일 메모리와 익명 메모리를 구분합니다 . 둘 다 RAM에 상주하지만, 생성 경로와 디스크 백업 방식이 다릅니다.

전화 파일 메모리 이는 시스템 파일, 즉 실행 파일, 공유 라이브러리, 매핑된 데이터에 의해 뒷받침되는 것입니다. mmap 파일 등에서 데이터를 읽어올 수 있습니다. 공간이 필요한 경우 해당 메모리를 버리고 원본 파일에서 다시 불러올 수 있습니다.

La 익명의 기억 이는 프로세스가 파일에 연결되지 않고 예약하는 모든 것을 의미합니다. 즉, 동적 힙, 스택, 개인 영역 등이 포함됩니다. MAP_ANONYMOUS그리고 복사 시 쓰기 기능을 사용하여 복사되는 영역은 다음과 같습니다. fork()이 메모리는 RAM(또는 이동된 경우 스왑 공간)에만 존재하며, 유일한 백업 방법은 바로 그 스왑 공간입니다.

커널이 RAM을 확보해야 할 때, 먼저 재조립 가능한 페이지들을 해제하려고 시도합니다. 일반적으로 페이지 캐시나 파일 기반 영역의 페이지들이 이에 해당합니다. 더 이상 공간이 없거나 메모리 부족 현상이 심각할 때만 익명 메모리를 스왑 영역으로 이동시키기 시작하는데 , 이는 비용이 훨씬 많이 들지만 시스템에 휴식을 제공합니다.

메모리 압박, 과부하 및 OOM 킬러

메모리 부족 현상은 사용 가능한 페이지 수가 특정 내부 임계값 아래로 떨어질 때 발생합니다 . 이때 커널은 캐시를 비우고, 변경된 페이지를 디스크에 기록하고, 사용 빈도가 낮은 페이지를 제거하는 등 메모리를 확보하기 위해 지속적으로 작업해야 합니다.

메모리 부족 현상이 심해지면 웹 서비스 지연 , 느린 그래픽 인터페이스, 원격 세션(SSH, VNC, RDP) 응답 지연, 마우스 끊김, 창 반응 속도 저하 등과 같은 명확한 증상이 나타날 수 있습니다. 이러한 상황에서는 시스템이 유용한 작업을 수행하기보다는 생존에 더 집중하게 됩니다.

RAM 용량이 프로세스가 지속적으로 사용하는 페이지를 저장하기에 부족할 때 스래싱(Thrashing) 현상이 발생합니다 . 커널은 페이지를 끊임없이 스왑하는데, 하나의 페이지를 제거하고 다른 페이지를 삽입하지만, 곧바로 방금 제거한 페이지를 필요로 하게 됩니다. 이러한 과정은 페이지 폴트와 디스크 접근의 악순환으로 이어져 성능을 저하시킵니다.

스왑이 활성화된 경우, 익명 페이지가 RAM과 스왑 공간 사이를 끊임없이 오가면서 디스크 용량을 포화시키는 스래싱 현상이 발생합니다. 스왑이 비활성화된 경우, 문제는 파일 페이지로 옮겨가는데, 파일 시스템에서 파일 페이지가 반복적으로 버려지고 다시 로드되면서 시스템이 사실상 사용 불가능해질 수 있습니다.

커널이 여전히 사용 가능한 메모리를 확보하지 못하면 다음 단계가 진행됩니다. 메모리 부족(OOM) 메커니즘삭제, 압축 또는 교환할 수 있는 모든 것이 소진되면 커널은 각 프로세스에 대한 점수를 계산합니다.oom_score그리고 누구를 희생시킬지 결정합니다. 그 과정은 다음과 같이 완료됩니다. OOM 킬러 상당한 양의 RAM을 확보하고 시스템 전체가 다운되는 것을 방지하기 위해서입니다.

스왑: 스왑이란 무엇이며, 얼마나 투자해야 하고, 왜 "악마"가 아닌지 알아봅시다.

스왑 메모리는 "RAM이 많으면 스왑이 필요 없다"와 같은 시대착오적인 조언과 지나친 단순화 때문에 좋지 않은 평판을 얻고 있습니다. 하지만 실제로는 스왑 공간은 RAM이 충분한 시스템에서도 리눅스 메모리 설계의 핵심 요소입니다.

스왑은 커널이 비활성 메모리 페이지를 저장하는 데 사용하는 디스크 영역(파티션 또는 파일)입니다 . 이를 통해 커널은 실제로 RAM이 필요한 프로세스를 위해 RAM을 확보할 수 있습니다. 스왑 자체는 가상 메모리가 아니지만, 가상 메모리를 가능하게 하는 메커니즘 중 하나입니다.

스왑이 없으면 메모리 부족 현상이 심해질 때 익명 페이지가 저장할 곳이 없어집니다. 커널은 여전히 ​​캐시와 파일 기반 페이지를 사용할 수 있지만, 익명 메모리 사용량이 임계점에 도달하면 사실상 OOM 킬러를 훨씬 더 빨리 실행해야 합니다. 기술적으로는 리눅스가 스왑 없이도 작동할 수 있지만, 실제 대부분의 상황에서 이는 불필요한 위험입니다.

스왑 공간 크기를 정하는 데에는 정해진 공식은 없지만, 컴퓨터의 역할에 따라 몇 가지 합리적인 최신 기준이 있습니다.

• 최대 절전 모드가 없는 서버일반적으로 RAM 용량이 충분하더라도 4~8GB의 스왑 공간은 버퍼로 충분합니다. 메모리 사용량이 많은 서비스(데이터베이스, 가상화)의 경우 RAM 용량의 1,5배까지 늘릴 수 있지만, 물리적 RAM 용량을 늘리는 데 우선순위를 두어야 합니다.
• 최대 절전 모드가 없는 데스크톱16GB 이상의 RAM을 사용하는 경우, 2~4GB의 스왑 공간은 안전망으로 충분합니다.
• 절전 모드 지원 기기시스템이 최대 절전 모드로 전환될 때 메모리의 모든 내용을 스왑 공간으로 옮기기 때문에 스왑 공간은 RAM 용량과 같거나 약간 더 커야 합니다.

스왑 공간 생성은 매우 유연합니다. 전용 파티션을 사용 하거나 스왑 파일을 사용할 수 있습니다 . 스왑 파일은 디스크가 이미 파티션되어 있거나 전체 시스템을 재구성하지 않고 크기를 조정하려는 경우에 적합합니다.

메모리 메트릭: free, vmstat, ps, RSS, PSS 등

기존 리눅스 메모리 관리 도구는 각 열의 의미를 모르면 오해를 불러일으킬 수 있습니다. 명령어는 다음과 같습니다. free -h 이는 전체 메모리, 사용 중인 메모리, 여유 메모리, 캐시 및 스왑 영역을 한눈에 확인할 수 있는 가장 간단한 방법입니다.

출구에서 free 버퍼와 캐시를 차감하는 줄을 살펴보는 것이 중요합니다. 왜냐하면 해당 열이 다음을 나타내기 때문입니다. 실제로 프로세스가 점유하고 있는 메모리커널이 캐시로 사용하고 필요할 경우 빠르게 해제할 수 있는 부분은 제외합니다.

와 vmstat -s -S M 더 자세한 요약 정보를 확인할 수 있습니다. 총 메모리, 사용 메모리, 여유 메모리, 활성 메모리, 유휴 메모리, 스왑 캐시 등을 볼 수 있습니다. 또한 다음 항목을 참조할 수도 있습니다. /proc/meminfo 각 지표를 자세히 볼 수 있지만, 출력 결과는 다소 딱딱하고 사용자 친화적이지 않습니다.

RAM에 가장 큰 영향을 미치는 프로세스를 알아보려면, ps aux 다음과 같은 열을 표시합니다. VSZ (프로세스가 모든 것을 로드했을 경우 사용할 수 있는 총 가상 메모리) RSS (상주 메모리 크기, 현재 RAM에 있는 실제 메모리 용량). 참고: 상주 메모리 크기(RSS)에는 공유 라이브러리 메모리도 포함되며, 여러 프로세스에서 사용하는 경우 여러 번 계산됩니다.

여기에 등장합니다 PSS(비례 집합 크기)이는 공유 라이브러리의 비용을 해당 라이브러리를 사용하는 프로세스 간에 분산합니다. PSS를 쉽게 얻으려면 다음과 같은 도구를 사용할 수 있습니다. smem공유 라이브러리로 인해 데이터가 왜곡되지 않고 어떤 애플리케이션이 실제로 "데이터를 많이 사용하는지" 확인하는 데 매우 유용합니다.

메모리 단편화, 스택, 힙 및 ulimit

메모리 관리에서 잘 드러나지 않는 또 다른 측면은 단편화 입니다 . 내부 단편화(4바이트, 8바이트 또는 16바이트의 배수로 반올림된 블록이 할당되어 쓸모없는 부분이 남는 경우)와 외부 단편화(사용 가능한 메모리가 있지만 작은 조각으로 나뉘어 있어 하나의 큰 연속된 할당을 사용할 수 없는 경우)에 대해 이야기할 수 있습니다.

Redis와 같은 애플리케이션에서는 시스템에서 보고하는 메모리(RSS)와 애플리케이션 자체에서 유용하다고 판단하는 메모리 사이에 차이가 발생하는 경우가 있습니다.used_memory이러한 차이는 대개 다음과 같은 이유로 발생합니다. 외부 파편화시스템에서 점유된 것으로 간주하지만 실제 프로세스에서는 사용하지 않는 공백입니다.

프로세스에 대한 기억은 개념적으로 다음과 같이 나뉩니다. 스택과 힙스택은 지역 변수와 함수 호출에 사용되고, 힙은 동적 할당에 사용됩니다. malloc() 이와 유사하게, 데이터 구조가 스택이 저장할 수 있는 용량을 초과하면 힙에서 데이터를 가져와 포인터를 사용하여 처리합니다.

프로세스당 최대 스택 크기는 다음을 통해 조정할 수 있습니다. ulimit -a 시스템 구성에 따라 달라집니다. 이 값을 줄이면 큰 지역 변수의 수를 제한할 수 있고, 늘리면 더 많은 변수를 사용하거나 깊은 재귀 호출을 허용할 수 있습니다. 이 매개변수를 조정하면 메모리 사용량을 더 잘 제어하고 특정 유형의 단편화를 줄이는 데 도움이 될 수 있지만, 만능 해결책은 아닙니다.

고급 모니터링 및 진단 도구: top, htop, vmstat, sar 등

RAM을 많이 사용하는 프로세스를 찾으려면 다음부터 시작할 수 있습니다. top 좀 더 사용하기 쉬운 것을 원하신다면, htop후자는 CPU, 메모리 및 스왑 사용량 막대를 표시하고 프로세스를 대화형으로 정렬하고 필터링할 수 있도록 합니다.

데비안 및 파생 배포판에서, htop을 설치하세요 와 sudo apt install htopAlmaLinux 및 기타 Red Hat 계열 시스템에서는 sudo dnf install htop일단 접속하면 메모리 사용량별로 정렬하고, 특정 프로세스를 검색하고, 문제가 있는 작업을 인터페이스에서 직접 종료할 수 있습니다.

보다 심층적인 분석 및 일괄 처리 모드를 위해, vmstat 5 이 도구는 프로세스, 메모리, 페이징, 블록 I/O, 인터럽트 및 CPU 스케줄링에 대한 정보를 정기적으로 제공합니다. 메모리 사용량이 시간에 따라 어떻게 변화하는지 확인하는 데 이상적입니다.

계속 sysstat 여기에는 다음과 같은 도구들이 포함됩니다. sar이를 통해 메모리 및 기타 자원의 사용을 기록하고 분석할 수 있습니다. 예를 들어, sar -r 1 5 이 프로그램은 메모리 및 스왑 사용량을 1초마다 5회 표시합니다. 데비안에서는 다음 명령어로 설치됩니다. sudo apt install sysstat그리고 AlmaLinux에서는 다음과 같습니다. sudo dnf install sysstat.

커널 수준의 심층 디버깅이 필요한 경우, bpftrace eBPF 기반의 강력한 도구입니다. 시스템 호출을 계측하고, 메모리 접근을 관찰하고, 재컴파일이나 재시작 없이 병목 현상을 감지할 수 있습니다. 일반적으로 설치 시 함께 제공됩니다. sudo apt install bpftrace 데비안 계열 시스템에서.

실용적인 메모리 관리: 스왑, 스왑 현상 및 캐시 정리

많은 서버에서 기본적인 작업 중 하나는 다음을 확인하는 것입니다. 스왑의 현재 상태. 과 swapon --show 활성화된 스왑 장치 및 파일 목록과 해당 크기, 유형 및 우선순위가 표시됩니다. 필요에 따라 스왑 공간을 즉시 추가하려면 다음 명령을 사용하여 파일을 생성할 수 있습니다. fallocate허가를 확보하세요 chmod 600다음과 같이 포맷하세요 mkswap 그리고 그것을 활성화하세요 swapon설정을 영구적으로 유지하려면 해당 항목을 추가하기만 하면 됩니다. /etc/fstab.

매개 변수 vm.swappiness 이 값은 커널이 RAM을 계속 채우는 것보다 스왑을 우선시하는 정도를 제어합니다. 값은 0에서 100까지입니다. 낮은 값(10~20)은 시스템이 절대적으로 필요할 때까지 스왑을 사용하지 않도록 하고, 높은 값(60 이상)은 시스템이 여유 RAM을 유지하기 위해 페이지를 스왑으로 더 쉽게 이동하도록 합니다.

디스크 속도가 느리거나 데이터베이스 규모가 큰 서버에서는 이러한 기능이 종종 유용합니다. 교환성을 낮추다예를 들어 10이나 20으로, sudo sysctl vm.swappiness=10빠른 zRAM이나 SSD가 장착된 데스크톱의 경우 30~60과 같은 중간값이 지연 시간과 메모리 사용률 사이에서 좋은 균형을 제공할 수 있습니다.

기억이 정확한 상황에서는 때때로 강제로라도 기억을 되살려야 할 필요가 있습니다. 캐시 해제 와 sudo sync && sudo sysctl -w vm.drop_caches=3이렇게 하면 페이지 캐시와 dentry의 상당 부분이 비워집니다. 매우 제한적인 시스템에서 테스트하거나 메모리를 확보하기 위해 가끔 사용할 수 있지만, 캐싱이 제공하는 성능 향상 효과를 잃게 되므로 일상적으로 사용해서는 안 됩니다.

고급 제어 도구: 사용자 공간에서의 cgroup v2, memory.pressure 및 OOM

systemd와 cgroup v2를 사용하는 최신 시스템에서는 프로세스 그룹별로 메모리 관리를 세밀하게 조정할 수 있습니다. cgroup v2는 작업을 계층 구조로 구성하고 개별 프로세스 수준이 아닌 그룹 수준에서 리소스 제한 및 우선순위(CPU, 메모리, I/O)를 적용합니다.

메모리 계층 구조 내에서 다음과 같은 매개변수 memory.low 이 기능을 사용하면 특정 cgroup의 메모리가 전역적인 압력으로부터 더 잘 보호되어야 하는 반면, RAM 확보가 필요한 경우 다른 cgroup은 더 쉽게 처분할 수 있도록 지정할 수 있습니다.

파일 memory.pressure 이는 매우 유용한 지표를 보여줍니다. 해당 cgroup 내의 작업이 메모리 부족으로 인해 차단된 시간을 10초, 60초, 300초 간격으로 확인할 수 있습니다. 일부 이는 적어도 하나의 작업이 지연되었는지 여부를 나타냅니다. 가득 찬 이는 그룹의 모든 과제가 동시에 영향을 받았던 순간들을 반영합니다.

커널의 OOM 킬러 외에도 다음과 같은 사용자 공간 솔루션이 등장했습니다. Earlyoom, 노항 o systemd-oomdEarlyOOM은 RAM과 스왑 공간을 모니터링하고, 특정 임계값 이하로 떨어지면 프로세스를 선제적으로 종료합니다. oom_score 더 높은 수준으로 설정하면 기기가 멈추기 전에 사용성을 복원할 수 있습니다.

NoHang은 한 단계 더 나아가 더 많은 선택 기준을 지원하고 , 메모리 부족 상황을 고려할 수 있으며, 고급 설정과도 잘 통합됩니다. 다만 개발 과정에서 부침을 겪기도 했습니다. 한편, systemd-oomd 는 systemd 및 cgroup v2와 직접 통합되며, 현재 많은 배포판에서 메모리 부족 상황을 보다 지능적이고 세밀하게 관리하는 데 선호되는 옵션입니다.

최신 스왑: zram, zswap 및 장치 우선순위

리눅스는 "고전적인" 디스크 스와핑 외에도 RAM 압축과 선택적 디스크 사용을 결합하여 성능을 크게 향상시키는 최신 메커니즘을 제공합니다.

zram 은 커널 모듈로, RAM 자체에 블록 장치를 생성하여 페이지를 압축된 상태로 저장합니다. 이러한 블록 장치는 일반적으로 초고속 스왑 장치로 사용됩니다. 압축 및 압축 해제 과정에서 CPU 자원이 일부 소모되지만, 논리적 메모리 용량을 확보하고 디스크 사용량을 대폭 줄일 수 있습니다.

많은 배포판에서는 설치하는 것만으로도 충분합니다. zram-tools o zram-generator 그리고 해당 서비스를 활성화하십시오. 예를 들어, 데비안에서는 다음과 같이 사용할 수 있습니다. sudo apt install zram-tools 활성화 zramswap systemd를 사용하면 AlmaLinux에서 다음과 같이 할 수 있습니다. sudo dnf install zram-generator 그리고 그에 상응하는 서비스.

반면 zswap은 디스크 스왑 앞에 압축 캐시 역할을 합니다 . 먼저 스왑될 페이지를 압축된 RAM에 저장하려고 시도하고, 이 캐시가 가득 차거나 페이지가 비활성화된 경우에만 실제 스왑 영역에 기록합니다. 이는 디스크 I/O를 줄이고 SSD의 수명을 연장하는 효과가 있지만, CPU 사용량은 다소 증가할 수 있습니다.

여러 개의 스왑 장치(예: zram과 디스크 파일)를 결합할 때는 설정을 조정하는 것이 매우 중요합니다. 우선 순위. 과 swapon -p 또는 옵션 pri= en /etc/fstab 어떤 장치를 먼저 사용할지 지정합니다. 일반적인 관행은 zram에 높은 우선순위(예: 100)를 부여하고 디스크 스왑에 낮은 우선순위(10)를 부여하여 커널이 디스크에 액세스하기 전에 RAM의 압축된 스왑 공간을 최대한 활용하도록 하는 것입니다.

서버에 적용되는 메모리 관리: 스왑, 서비스 및 보안

웹 서버(Apache, Nginx), 데이터베이스(MySQL, MariaDB, MongoDB) 또는 리소스 집약적인 애플리케이션에서 메모리는 매우 중요한 리소스입니다. RAM 및 스왑 구성은 시스템 성능 저하가 시작되기 전에 처리할 수 있는 동시 요청 수를 직접적으로 결정합니다.

MongoDB와 같은 데이터베이스 엔진의 경우, 물리적 RAM 용량이 데이터베이스 요구량을 초과하는 것이 매우 중요합니다 . 그렇지 않으면 스왑 공간을 사용하게 되고, RAM 접근과 디스크 접근 간의 큰 차이로 인해 성능이 급격히 저하됩니다. MySQL/MariaDB도 마찬가지이며, MySQLTuner와 같은 도구는 사용 가능한 RAM 용량을 기반으로 메모리 매개변수를 권장합니다.

메모리 낭비를 방지하려면 사용하지 않는 서비스를 중지하고 더 이상 필요하지 않은 컨테이너, 이미지 및 Docker 볼륨을 정리하는 것이 좋습니다 . 개발 및 QA 환경에서는 아무도 알아채지 못하는 사이에 수 기가바이트의 RAM과 디스크 공간을 차지하는 리소스가 쌓이기 쉽습니다.

보안 또한 중요한 역할을 합니다. 불필요한 포트가 열려 있습니다. 이는 공격 표면을 증가시킵니다. 시스템에 침투하는 데 성공한 악성 소프트웨어는 예를 들어 CPU와 메모리를 소모하는 마이닝 프로세스를 실행하거나 작업을 예약할 수 있습니다. crontab 그리고 시스템을 다운시킬 수도 있습니다. 수신 및 발신 포트를 확인하고, 필수적이지 않은 모든 것을 닫고, 의심스러운 cron 작업을 정리하는 것은 메모리 리소스를 보호하는 기본적인 시스템 관리 활동입니다.

메모리 및 파일 시스템: ext4, XFS, Btrfs 및 저널링

별개의 문제처럼 보일 수 있지만, 파일 시스템 선택 및 구성은 메모리 동작과 I/O 부하에도 영향을 미칩니다. 예를 들어, Ext4는 저널링을 사용하는데, 이는 부하에 따라 디스크에 추가적인 부담을 주고 결과적으로 캐시 관리에도 영향을 미칠 수 있습니다.

고성능 서버 환경에서 많은 관리자들이 XFS 또는 Btrfs 파일 시스템 을 선택합니다 . XFS는 일반적으로 대용량 파일과 고성능 시스템에서 뛰어난 성능을 보여줍니다. Btrfs는 스냅샷, 투명 압축, 서브볼륨과 같은 고급 기능을 제공하지만, 사용법이 다소 복잡하고 버전 및 배포판에 따라 모든 워크로드에 적합한지 여부에 대한 논쟁이 여전히 존재합니다.

커널은 파일 시스템의 특성에 맞춰 캐싱 및 쓰기 정책을 조정하므로 ext4에서 XFS 또는 Btrfs로 전환하면 순수 I/O뿐만 아니라 읽기 및 쓰기 작업을 버퍼링하는 데 사용되는 RAM 및 페이지 캐시의 사용 방식에도 영향을 미칩니다.

관리자를 위한 필수 그래픽 도구 및 유틸리티

터미널은 여전히 ​​관리자에게 만능 도구와 같지만, 메모리와 리소스 관리를 훨씬 쉽게 해주는 도구들이 있습니다 . 그중 하나가 Glances입니다 . Glances 는 CPU, 메모리, 디스크, 네트워크 및 프로세스를 한 화면에 실시간으로 표시하는 모니터링 도구이며, 웹 인터페이스를 통해 브라우저에서 여러 서버를 모니터링할 수도 있습니다.

데비안에 빠르게 설치하려면 다음 단계를 따르세요... sudo apt install glances흘끗 보는 것은 ~와 아주 잘 어울립니다. htop, vmstat y sar이를 통해 시스템이 부하 상태에서 어떻게 작동하는지 시각적으로 더 자세히 파악할 수 있습니다.

그래픽 서버 관리 영역에서 Cockpit은 메모리, 프로세스 및 서비스를 모니터링할 수 있는 사용자 친화적인 웹 인터페이스를 제공합니다 . 이를 통해 단일 콘솔에서 여러 서버를 관리하고, systemd 유닛을 시작 및 중지하고, 스왑 및 zram 사용량을 모니터링하고, 브라우저를 벗어나지 않고 로그를 검토할 수 있습니다.

데스크톱 시스템에서는 많은 배포판에 자체 리소스 모니터가 통합되어 있지만, GUI가 없거나 가벼운 솔루션을 원하는 환경에서는 이러한 콘솔 도구를 사용자 지정 스크립트와 결합하면 특정 시점의 메모리 상태를 탁월하게 파악할 수 있습니다.

리눅스에서 적절한 메모리 관리를 위해서는 커널이 RAM을 사용하는 방식, 스왑, zram, zswap의 역할, cgroup v2 및 다양한 OOM(메모리 부족 오류)이 부하에 어떻게 대응하는지, 그리고 시스템을 모니터링하고 최적화하는 데 사용할 수 있는 도구들을 이해해야 합니다. free, vmstat, PSS, memory.pressure부터 zram, swappiness, systemd-oomd에 이르기까지 이러한 모든 요소들을 종합적으로 고려하면 "리눅스가 RAM을 너무 많이 소비한다"는 문제에 더 이상 시달리지 않고, 서버, 데스크톱, 고부하 환경 등 어떤 역할에서도 하드웨어 성능을 극대화할 수 있는 안정적이고 최적화된 시스템을 구축할 수 있습니다.