SLES 시스템 업그레이드 중 발생하는 "메모리를 할당할 수 없습니다" 오류 해결 방법

SLES 업그레이드가 순조롭게 진행되는 듯하다가 터미널, 설치 프로그램 또는 마이그레이션 로그에 "메모리를 할당할 수 없습니다."라는 메시지가 나타납니다. 이 메시지만으로는 서버에 물리적 RAM이 더 필요하다는 것을 알 수 없습니다. 오류는 메모리 부족, 가상 머신 또는 서비스 제한, 스왑 공간 부족 또는 사용 불가, 혹은 업그레이드 환경 자체의 문제로 인해 발생할 수 있습니다. 먼저 어떤 프로세스와 업그레이드 단계에서 이 메시지가 발생했는지 확인해야 합니다. 안전한 해결 방법은 이 정보에 따라 달라집니다.

버전이 중요합니다. 2026년 10월 현재, SUSE의 SLES 16.0 주요 버전 업그레이드 가이드에서는 전용 라이브 업그레이드 이미지를 부팅하는 배포판 마이그레이션 시스템을 설명하고 있으며, SLES 15 서비스 팩 마이그레이션은 기존의 YaST 또는 Zypper 마이그레이션 워크플로를 사용합니다. 온라인 서비스 팩 마이그레이션용으로 작성된 수정 사항을 주요 버전 업그레이드에 적용하기 전에 해당 릴리스의 절차를 확인하십시오. SUSE는 SLES 16 업그레이드 가이드 에서 현재 SLES 16 경로를 설명하고 있습니다 .

1. 변경하기 전에 먼저 문제가 발생하는 단계를 파악하십시오.

전체 오류 메시지, 타임스탬프, 오류가 발생한 명령 또는 화면, 그리고 시스템이 설치 프로그램 또는 마이그레이션 이미지로 재부팅되었는지 여부를 기록하십시오. "메모리를 할당할 수 없습니다"는 광범위한 운영 체제 오류이므로 메시지 자체보다는 주변 줄을 함께 기록하는 것이 더 유용할 수 있습니다.

• 패키지 트랜잭션이 시작되기 전에 등록, 저장소, 마이그레이션 준비 또는 설치 프로그램 프로세스에 오류가 발생했을 수 있습니다. 시스템 및 프로세스 메모리를 확인한 다음 관련 서비스 또는 마이그레이션 로그를 검토하십시오.
• 패키지를 설치하거나 제거하는 동안 Zypper와 RPM이 이미 시스템을 변경했을 수 있습니다. 진행 속도가 느리다고 해서 프로세스를 종료하거나, 재부팅하거나, 다른 패키지 관리자를 실행하지 마십시오. 콘솔과 로그를 확인하고, 지원되는 마이그레이션 프로세스가 완료되거나 명확한 오류 상태에 도달할 때까지 기다리십시오.
• 업그레이드 이미지로 재부팅한 후: 프로세스가 원래 운영 체제와 다른 리소스 환경에서 실행될 수 있습니다. 재부팅 전에 스왑 영역이 보인다고 해서 업그레이드 이미지가 해당 영역을 사용할 수 있다는 것을 의미하지는 않습니다.

SUSE의 SLES 16 마이그레이션 시퀀스는 마이그레이션 환경 준비, 파일 시스템 마운트, 네트워킹 구성, Zypper 준비, 패키지 업그레이드, 부트 로더 업데이트 및 재부팅을 포함합니다. 가이드에 따르면 업그레이드 시작 전에 오류가 발생하면 시스템이 원래 상태로 되돌아갑니다. 하지만 패키지 교체 중 발생하는 모든 오류가 무해한 것은 아닙니다. 어떤 단계에서 오류가 발생했는지 알 때까지 로그를 보존하고 수동 복구 작업을 피하십시오.

2. RAM, 스왑 공간 및 최근 커널 메시지를 확인하십시오.

원래 SLES 시스템이 여전히 실행 중이거나 복구 셸에 도달한 경우 읽기 전용 검사부터 시작하십시오.

free -h
swapon --show
vmstat 1 5
ps -eo pid,comm,rss,%mem --sort=-rss | head -n 15

free -h메모리와 스왑 사용량을 요약해서 보여줍니다. "여유" 열뿐만 아니라 사용 가능한 메모리와 사용된 스왑 공간을 중점적으로 살펴보세요. Linux는 유휴 상태인 RAM을 캐시로 활용하기도 합니다. 이 기능은 vmstat시스템이 지속적으로 페이징을 수행하는지 여부를 파악하는 데 도움이 됩니다. 프로세스 목록을 통해 업그레이드 중에 메모리를 소모하는 데이터베이스, Java 서비스, 백업 또는 기타 워크로드를 확인할 수 있습니다.

오류 발생 시점 주변의 커널 OOM 기록을 찾아보세요.

sudo journalctl -k --since "30 minutes ago" |
  grep -i -E 'out of memory|oom|killed process'

오류가 더 일찍 발생했다면 시간 범위를 변경하십시오. 종료된 프로세스의 이름을 언급하는 커널 메시지는 메모리 부족 이벤트의 증거입니다. 일치하는 줄이 없다고 해서 모든 할당 실패를 배제할 수는 없습니다. 업그레이드가 별도의 운영 환경에서 진행되는 경우, 이전 시스템의 저널에만 의존하지 말고 해당 환경의 로그를 가능한 한 검사하십시오.

가상 머신, 컨테이너 또는 systemd 유닛에 메모리 제한이 있는지 확인하십시오. 게스트 운영 체제는 호스트에서 사용 가능한 메모리가 있더라도 자체적으로 설정한 제한에 도달할 수 있습니다. SUSE는 SLES 16에서 cgroups v2를 기본 리소스 제어 계층 구조로 설명하고 systemd가 리소스 제한을 적용할 수 있다고 명시하고 있습니다. 임의로 MemoryMax전역 커널 제한을 높이는 대신 관련 VM 구성 또는 서비스 설정을 검토하십시오. SUSE의 SLES 16 커널 제어 그룹 가이드를 참조하십시오 .

3. 메모리 사용량 경쟁을 줄이고 안전한 시점에만 재시도하십시오.

측정 결과 워크로드가 사용 가능한 메모리의 대부분을 사용하고 있는 것으로 나타나면 유지 관리 기간을 예약하고 필수적이지 않은 서비스를 안전하게 종료한 후 다시 시도하십시오. 예를 들어 메모리 사용량이 많은 애플리케이션 워커, 분석 작업, 테스트 데이터베이스 및 백업 프로세스 등이 있습니다. 운영 환경에서 스토리지, 클러스터 또는 애플리케이션 서비스를 임의로 종료하지 마십시오. 애플리케이션의 공식 종료 절차를 따르고 종료로 인해 사용자 또는 복구 작업이 중단되지 않는지 확인하십시오.

가상 머신의 경우 게스트에 구성된 RAM을 호스트 용량 및 다른 게스트의 현재 요구량과 비교하십시오. 게스트에 할당된 메모리가 부족한 경우 하이퍼바이저에서 지원하는 방법을 사용하여 할당된 메모리를 늘리십시오. 메모리 핫 추가 가능 여부는 하이퍼바이저, 게스트 구성 및 워크로드에 따라 다르므로 필요한 경우 재부팅을 계획하십시오. 퍼블릭 클라우드에서는 인스턴스 크기와 공급자별 메모리 제한을 확인하십시오.

시스템에 사용 가능한 RAM이 충분하고 OOM(메모리 부족) 기록이 없는데도 메시지가 계속 표시되면 프로세스 제한을 조사하십시오. 실행 중인 프로세스의 경우 /proc/PID/limits실제 프로세스 ID를 사용하여 확인하십시오. systemd로 관리되는 업그레이드 도우미의 경우 해당 장치의 리소스 설정을 확인하십시오. 호스트에 사용 가능한 메모리가 있더라도 제한으로 인해 특정 프로세스가 제한될 수 있습니다. 해당 설정을 식별하고 그 영향을 이해할 수 있는 경우에만 제한을 변경하십시오.

확인된 제약 조건을 해결한 후에는 사용 중인 SLES 릴리스 및 업그레이드 경로에 맞는 업그레이드 방법을 통해서만 업그레이드를 재개하거나 다시 시도하십시오. SLES 15 서비스 팩 마이그레이션의 경우, 문서화된 YaST 또는 Zypper 마이그레이션 워크플로를 사용하십시오. SLES 16 주요 버전 마이그레이션의 경우, SLES 16 배포판 마이그레이션 절차를 따르십시오. SUSE의 SLES 15 SP7 가이드에서는 온라인 업그레이드 문서 에서 서비스 팩 워크플로 및 지원되는 롤백 필수 조건을 설명합니다 .

4. 교체를 신중하게 고려하십시오. 맹목적으로 해결책으로 사용하지 마십시오.

추가 스왑 공간은 워크로드가 메모리를 페이징할 수 있을 때 시스템에 더 많은 가상 메모리 여유 공간을 제공할 수 있지만 RAM보다 훨씬 느립니다. 시스템에서 이미 스왑 사용량이 많은 경우 스왑 공간을 추가하면 VM 크기 부족이나 특정 프로세스의 제한 문제를 해결하지 못하고 업그레이드 속도가 매우 느려질 수 있습니다. 먼저 스왑 공간이 있는지, 그리고 와 함께 사용되고 있는지 확인 swapon --show하십시오 free -h.

스왑을 추가해야 하는 경우 사용 중인 SLES 버전 및 파일 시스템에 맞는 SUSE의 절차를 따르십시오. 특히 Btrfs 파일 시스템의 경우 주의해야 합니다. SUSE는 Btrfs 파일 시스템의 스왑 파일 사용에 대한 제한 사항을 문서화하고 있으며, 소스 서브볼륨의 스왑 파일이 활성화된 동안에는 스냅샷을 생성할 수 없다고 명시하고 있습니다. SLES는 시스템 복구를 위해 Snapper 스냅샷을 주로 사용하므로, 업그레이드 기간 동안 스냅샷이 생성된 루트 서브볼륨에 일반 스왑 파일을 생성하고 활성화하지 마십시오. 스토리지 레이아웃 및 복구 계획을 확인한 후 RAM을 추가하거나 올바르게 구성된 스왑 파티션 또는 지원되는 위치를 사용하는 것이 좋습니다. 파일 시스템별 자세한 내용은 SUSE의 SLES 15 SP7 스토리지 가이드를 참조하십시오 .

초기 대응책으로 메모리 설정을 변경하거나, OOM 킬러를 비활성화하거나, 임의의 정리 명령을 실행하지 마십시오 vm.overcommit_memory. 이러한 변경은 증상을 숨기거나, 워크로드를 불안정하게 만들거나, 복구를 더 어렵게 만들 수 있습니다. 먼저 증거를 수집하고, 로그에서 특정 메모리 구성이 지적되는 경우 SUSE 또는 애플리케이션 공급업체의 설정별 지침을 따르십시오.

5. 패키지 변경이 시작된 후 업그레이드가 중단된 경우 복구

업그레이드를 다시 실행하기 전에 패키지 관리자가 여전히 활성화되어 있는지, 마이그레이션 도구가 최종 실패를 보고했는지 확인하십시오. 패키지 변경이 시작된 후 업그레이드가 중단된 경우 전체 로그 출력을 저장하고 릴리스별 복구 문서를 참조하십시오. zypper dup, zypper migration, YaST 마이그레이션 및 RPM 명령을 동시에 실행하지 마십시오.

SLES 15 SP7에서 SUSE는 루트 파일 시스템이 Btrfs이고 Snapper 스냅샷이 활성화된 경우 서비스 팩 롤백 절차를 문서화합니다. 롤백 절차는 마이그레이션 전 스냅샷을 식별하고 테스트한 다음 롤백을 영구적으로 적용하는 과정을 포함하며, 모든 업그레이드 오류에 대한 만능 해결책은 아닙니다. SLES 16의 주요 버전 마이그레이션은 다른 워크플로를 따르므로 SLES 15 절차를 적용하는 대신 SLES 16의 최신 업그레이드 및 복구 지침을 따르십시오. 시스템이 비즈니스에 중요한 경우, 테스트된 백업이 없는 경우, 또는 패키지 교체 중에 마이그레이션이 실패하는 경우 수동 패키지 복구를 시도하기 전에 SUSE 지원 사례를 개설하십시오.

6. 정상 서비스를 재개하기 전에 시스템을 검증하십시오.

업그레이드가 완료되고 서버가 정상적으로 부팅되면 운영 체제 릴리스 및 등록을 확인한 다음 패키지 일관성과 원래 문제를 발생시킨 워크로드를 확인하십시오.

cat /etc/os-release
sudo SUSEConnect --status
sudo zypper verify
free -h
swapon --show

SLES 버전에서 지원하는 패키지 검증 명령을 사용하십시오. zypper verify해당 명령을 사용할 수 없거나 릴리스 버전에 따라 동작이 다른 경우, zypper help해당 릴리스의 관리 가이드를 참조하십시오. 애플리케이션 및 커널 로그에서 새로운 오류를 확인하고, 의도한 서비스가 정상적으로 작동하는지 확인하고, 부하가 다시 걸리는 동안 메모리와 스왑 사용량을 모니터링하십시오. 유지 관리 창을 닫기 전에 지원되는 업그레이드 대상이 설치되었는지, 그리고 서버의 등록 및 저장소가 예상 상태인지 확인하십시오.

문제 해결이 성공적이라는 것은 단순히 오류 메시지가 사라지는 것 이상의 의미를 갖습니다. 지원되는 경로를 사용하여 SLES 마이그레이션이 완료되고, 시스템이 예상되는 릴리스로 부팅되며, 패키지 및 레지스트리 체크아웃이 정상적으로 완료되고, 정상적인 워크로드가 반복적인 OOM(메모리 부족) 이벤트 없이 실행되는 것을 의미합니다. 메모리 사용량이 적고, 스왑 공간이 충분하며, 리소스 제한이 없음에도 불구하고 "메모리를 할당할 수 없습니다"라는 오류가 발생하는 경우, 정확한 로그와 프로세스 세부 정보를 보관하십시오. 이러한 단서는 업그레이드 결함과 용량 문제를 구분하는 데 도움이 됩니다.