파일 전송 시 디스크 I/O로 인해 발생하는 OOM Killer

3 min

language: ja bn de en es fr hi ko pt ru zh-cn zh-tw

안녕하세요, 무능입니다.
새집에 저렴하게 홈 서버를 구축한 지 며칠이 지났습니다. 전부터 신경 쓰였던 문제가 메모리가 충분함에도 불구하고 발생하고 말았습니다.

무슨 일이 일어났는가

제 현재 환경은 좀 특수합니다. 메모리 용량이 16GB + 8GB로 어중간한 느낌이지만, 남는 부품으로 만들었으니 양해 부탁드립니다.

RAM 자체는 24GB로 요즘은 당연할 수도 있지만, 개인적으로는 상당히 풍족한 상태라고 생각해서 OOM 같은 건 발생하지 않을 거라고 생각했는데, 리눅스 커널로부터 꾸지람 같은 OOM이 발생했습니다.

애플리케이션이라고 해봐야 Apache와 php-fpm, Redis 정도인데, 각각이 확보하는 메모리 양은 얼마 되지 않습니다만...

파일 전송에 골머리를 앓다

아직 본가에 있는 홈 서버에서 scp로 가져오려 하거나, 어느 정도 이미지를 저장하기 위해 aria2c로 2TB HDD에 일괄 저장 처리를 하다가 발생했습니다.
자, 여기서 왜 이 쓰기 처리만으로 OOM이 발생하는가? 라고 말씀드리자면, 파일이라는 것은 한 번 메모리에서 받아들인 후 기록 영역에 쓰기가 이루어지므로, 고속화를 위해서도 한 번 캐시로서 메모리 측에서 받아들일 필요가 있습니다.

대략 scp -r로 수백 GB 단위의 파일, 게다가 그 파일에 랜덤 I/O 처리가 들어가면 정말 리소스를 많이 잡아먹는 것 같습니다.
그리고 이것은 어디까지나 프로세스 단위의 메모리 사용에 해당하지 않으므로 top으로 확인해도 단일 프로세스에서는 확인할 수 없고, 어디까지나 리눅스 커널 측의 이야기이므로 특정하기가 상당히 어렵습니다.

간단히 말해 I/O 대기 때문에 일시적으로 메모리에 저장하는 양이 쓰기 속도를 따라잡지 못해 점차 고갈되는 상황이 되는 것 같습니다.

변경 가능한 커널 파라미터

커널 측에서 할 수 있는 것으로, 얼마나 캐시할지 등을 설정할 수 있는 것 같아서 조정해 보았지만, 별다른 효과를 느끼지 못했습니다.
2.2. VFS 튜닝 옵션: 연구 및 실험 Red Hat Product Documentation
Linux 페이지 캐시 설정을 변경하여 Write I/O를 튜닝한 메모- YOMON8.NET

현상적으로는 이 사람과 비슷합니다.
OOM Killer invoked due to slow disk I/O - #17 by Whis-key - troubleshooting - Storj Community Forum (official)
오랜만에 Storj라는 글자를 봤네요... 제 무료 할당량은 멋대로 삭제되었지만...

설마 HDD에 쓰기만으로 메모리 고갈에 골머리를 앓을 줄이야...
흔히 메모리 관련해서 "리눅스는 RAM에 낙관적, 윈도우는 비관적"이라고 하는 부분이기도 합니다. 다만 메모리를 최대한 활용하여 성능을 더욱 효율적으로 만들려는 의도는 이해할 수 있지만, 어떻게든 이 I/O 대기로 인해 발생하는 문제에 대처하고 싶네요.

Related Posts