☰

스왑이 왜 그렇게 느린가요? [복사]

tag-icon • tag-icon linux swap
스왑이 왜 그렇게 느린가요? [복사]

내 스왑/하드웨어/드라이버에 뭔가 이상한 일이 벌어지고 있는 것 같아요.

swapoff스왑 크기를 늘리고 lvresize다시 늘리려고 합니다 swapon.

이 작업을 수행했을 때 swapoff /dev/swapdev명령이 약 3.5GB의 스왑 페이지를 메모리로 이동하는 데 8분 19초가 걸렸습니다.

실행하기 전에 사용 가능한 RAM이 스왑 사용량보다 큰지 확인했고 swapoff실행하는 동안 동일하게 유지되었습니다.

SSD HDD가 장착된 Intel Core i5 노트북이 있습니다. 이전에는 프로세서 사용률이 10% 미만이었는데 swapoff, 체크인해보니 swapoffCPU 사용률이 70%를 넘었습니다.

일기에는 흥미로운 내용이 전혀 없었습니다.

디스크에서 메모리로 3.5G를 오프로드하는 데 대략 예상되는 시간은 다음과 같습니다.

$ time dd if=/dev/urandom of=/tmp/del bs=1M count=3500
3500+0 records in
3500+0 records out
3670016000 bytes (3.7 GB, 3.4 GiB) copied, 23.7288 s, 155 MB/s

real    0m24.789s
user    0m0.000s
sys     0m22.743s

나는 뛰고있어Linux svelte 4.9.53-1-MANJARO #1 SMP PREEMPT Thu Oct 5 15:11:15 UTC 2017 x86_64 GNU/Linux

이 주문은 왜 이렇게 오래 걸리나요? 이것은 더 큰 문제의 일부일 수 있지만 이상해 보이는 것이 가장 먼저 지적할 수 있는 것입니다.

답변1

당신은 스왑오프가 실제로 무엇을 하는지 이해하지 못합니다.

실행 중인 머신에서 스왑되고 있는 스왑 공간을 종료하는 것은 매우 복잡합니다. 3.5G는 아마도 8분 정도로 매우 빠르며 예상대로 작동하고 있습니다.

swapoff를 실행하면 단순히 코드를 디스크에서 메모리로 이동하는 것 이상의 작업이 수행됩니다.

일단 스왑을 하고 있다면...글쎄...스왑을 하고 있다는 것은 OS에 메모리가 부족하다는 뜻입니다. + 스왑 장치에 대한 디스크 I/O가 있고, 디스크 I/O가 있다는 뜻입니다. 다른 파일 시스템의 경우 + 아마도 워치독이나 systemd 자동 재시작이 포함되면 OOM(Out of Memory Killer)이 실행되기 시작한 다음 OOM 프로세스가 다시 시작됩니다.

시스템이 스와핑 중인 경우 이는 스와핑이 시스템을 활성 상태로 유지하는 유일한 방법임을 의미합니다.

스왑 공간을 죽이면 시스템은 더 이상 스왑 공간을 사용할 수 없으므로 이제 OS는 빠른 스왑에서 최적화된 원시 디스크를 거치는 대신 일반 파일 시스템의 코드를 로드하고 메모리가 고갈되면 코드를 제거해야 합니다. 코드를 읽으려면 모든 코드가 일반 파일 시스템에서 나와야 하며 디렉터리 탐색을 수행해야 합니다. 이는 스왑 공간에서 리소스를 가져오는 것보다 훨씬 더 집약적입니다.

교체 중인 시스템에서 교체를 수행할 때... 일반적으로 프로세스에 몇 시간이 걸리고 때로는 시스템이 충돌하는 상황이 발생합니다.

어떤 이유로 스왑 장치를 폐기해야 하는 경우 먼저 보조 파일 시스템 기반 스왑 공간을 만들고 이 새 스왑 공간에 대해 스왑을 수행한 다음 이전 스왑 장치에서 스왑 오프를 수행하는 것이 가장 좋습니다.

이 접근 방식을 취하면 시스템은 영원히 살아남을 것입니다.

관련 정보