[KVM] Host swap 부족에 따른 Guest 의 성능저하 현상으로 문의드립니다.

   조회 5361   추천 0    

안녕하세요.

CentOS7 KVM으로 구성된 Guest OS의 CPU 사용률 증가로 문의드립니다.

서버의 구성은 

Host : 128G Mem, 480G SSD * 2 (Raid 1), 480G SSD * 6 (Raid 5) 구성입니다.

Guest : Host의 딱 반씩 사용하고 있습니다.

OS 는 Raid1 에 설치, Raid5 에는 Data 영역으로 사용중입니다.

Swap 설정은 Host, Guest 각각 32G 입니다.

이때 Host의 Swap이 free 가 0 일 경우 Guest의 성능저하가 발생합니다. 이때 Host의 물리메모리는 여유가 있었고 swappiness=60 으로 설정되어 있습니다.

위와 같은 현상은 파악하여 Swap을 64G로 올려주니 동일 발생하지는 않았습니다. (물론 swappiness를 줄여주면 해결될지도 모르겠습니다)

그러나 왜 성능저하가 발생했는지를 모르겠습니다. 알고싶어요,.,.

혹시라도 이유를 알고 계신분이 계시면 도움 부탁드립니다.

감사합니다.

Dreaday 2022-03
점유 가능 메모리가 적을 시에는 자바의 경우 프로그램을 강제 종료시키고, 타 프로그램들의 경우 DISK를 대체하여 메모리를 끌어다 쓰기에 느려집니다 .

자세한 설명은 SWAP 메모리 검색하시면 많은자료들이 있으니 참고 하시면 될 것 같습니다.

https://mozi.tistory.com/424
     
사수지몽 2022-03
알려주신 포스트는 이미 본 문서인데요.
Guest의 swap과 메모리는 충분히 여유가 있는 상태인데도 불구하고
Guest가 Host swap의 영향을 받아서 궁금합니다.
          
구차니 2022-03
host 128G
guest 64G * 2vm 이라고 하면
host 에서 OS가 점유하고 파일 캐싱 등으로 인해서 실제 guest에 할당 가능한 메모리는 많아야 60G 정도 되지 않을까 생각됩니다.

아무튼 host 에서는 자기 자신이 써야 할 메모리 + guest 에서 예약할 메모리 하면
물리 메모리 보다 많은 메모리를 사용해야 하기 때문에 필연적으로 스왑이 발생하게 되고
그로 인해 성능 저하가 생길 것으로 생각됩니다.
꼬소 2023-02
오래전 글이지만 혹시나 도움 되는 분이 있을까 하여 글을 남깁니다.
swap으로 이동되는 메모리 영역은 Inactive(Anon)입니다. file system의 cache를 제외한 프로세스의 최근 참조되지 않은 메모리가 일반적으로 Inactive(Anon)이고, qemu 프로세스의 메모리 또한 이 대상이 될 수 있습니다.
사수지몽 님 말씀대로 swap free 용량이 0이 되면, kernel이 메모리 할당 요청을 받게 되면 메모리 할당 요청을 거부할 수 없기에 memory free, cache 또는 swap을 검색한 뒤 trade off를 거쳐 메모리를 할당하게 됩니다. OS의 대부분의 동작은 메모리 할당과 I/O 처리인데, I/O 처리에 시간이 많이 걸리므로 가급적 메모리에서 모든 것을 처리하려고 합니다. 시스템의 속도 또한 메모리 복사 속도가 대변한다고 할 수 있습니다. 그런데 swap free까지 모든 메모리를 다 사용하였다고 한다면, cache까지 소진하기 위해 flush를 시도할 것이고,  만약 flush할 cache까지 다 소진하였다면 file system은 disk의 read와 메모리 요청을, KVM과 기타 프로세스들은 메모리 할당 요청을 kernel로 하게 됩니다. I/O의 속도는 메모리보다 매우 느리며, I/O는 blocking을 할 확률이 높아지므로 만약 이런 상황이 되면 시스템의 처리 속도는 disk I/O 속도에 거의 미치게 됩니다. 이런 현상이 계속되면서 정말 할당할 메모리가 더 이상 존재하지 않을 경우 kernel은 시 OOM을 시도할 수도 있습니다. 하지만 사수지몽 님 시스템은 그 정도까지 간 것 같지는 않습니다. 아직 cache 메모리가 남아 있어서 그런 것일지도 모르겠습니다.
적어도 VM의 성능 저하를 막고 싶다면 VM을 위해 hugepage로 강제 할당하는 것을 추천합니다. VM 실행 시 메모리가 할당되는 것이 아니냐고 반문하실 수 있으나, 메모리가 할당되는 것은 가상 메모리이지 실제 물리 메모리가 아닙니다. mapping이 일어나지도 않았고, qemu 또한 프로세스이기 때문에 swap 대상이 될 수 있습니다. VM이 사용하는 메모리가 swap이 된다면 안 그래도 VM kernel에서 mapping을 처리하기 위해 다수의 step이 걸리는 것을 swap page-in으로 인해 I/O 속도만큼이나 기다려야 할 것입니다. VM이 사용하지 않은 메모리 공간이 아쉬울지 모르겠지만 적어도 VM은 별도의 공간에서 정상적으로 동작하기 위해서는 hugepage로 메모리 영역을 확보해 주시는 것이 좋습니다.
추가적으로 swap의 예방을 위해 min_free_kbytes 값을 늘려주시고, vfs_cache_pressure 값을 100 이상 늘려 cache의 flush를 좀 더 유도해 주시기  바랍니다.  시스템에서 swap 사용은 메모리 압박으로 밖에 볼 수 없습니다. swap 사용으로 성능 저하가 발생한다면 그 시스템은 지속적인 swap 사용에 영향받을 수밖에 없을 것입니다. 만약, 이렇게 조정 후에도 swap 사용이 있을 경우 메모리 확장을 권해드립니다.
     
늦게 발견했지만 정말 기술적인 분석이십니다.
이 글 보고 바로 hugepages 를 사용토록 변경했습니다.
페이지 사이즈는 2M가 좋을까요? 1G가 좋을까요?
일단 THP를 사용하고 있습니다. 2M 블럭으로...
AnonHugepages 가 증가하는거로 봐선 VM 할당시
잘 적용되는것으로 보입니다.
1G 블럭으로 사용하면 캐시 미스, 메모리 누수 등의
문제와 부적절한 상황에서 오버헤드가 증가할 수 있기에
일단은 이렇게 사용중입니다.
          
꼬소 2024-12
hugepage size는 원하시는 크기로 사용하시면 되겠습니다. 1 GiB와 2MiB의 차이는 없습니다.
VM에 보통 GiB 단위로 메모리를 할당하므로 1 GiB 단위 사용이 문제 될 것 같지는 않으나, 사용상 2 MiB 단위가 유용하시다면 어느 쪽을 사용하시든 관계는 없습니다.

kswapd 동작으로 인해 swap 사용이 늘어나고 있다면 메모리 압박으로 보시면 되겠습니다.
메모리 압박의 원인은 다양하나, free page list와 cache의 상관관계를 이해하고 계신다면 어느 부분에서 압박을 유발하고 있는지 파악하실 거라 생각합니다.
혹시 sys 사용률과 함께 ldavg 값이 상승한다면 cache flush를 위한 scan이 활발해 지는 것이니 free page 확보를 위한 min_free_kbytes 값이 적절한지 검토해 보시길 바랍니다.           

kernel 버전에 따라 swap 사용에 대한 관점이 달라지며, cgroup 사용 유무에 따라서도 swap 이슈 발생이 있을 수 있으니 가급적 최신 버전으로 업데이트하시고 changelog의
내용을 확인한 뒤 sysctl 항목을 설정하시기 바랍니다.
     
또한 특정 I/O (주로 디스크)에서 kswapd0 프로세스가
사용되는거로 봐선 스왑 영역이 사용중으로 보이는데
왜 그런지 기본적인 이해는 하고있지만 커널 설정에 비해
너무 과한 사용이 되는거로 보이기에 제가 놓치는 부분이
있는지 궁금합니다.
          
꼬소 02-05
접속이 뜸하여 늦게 답을 드리네요.
fault를 처리하고 있을 가능성이 큽니다. min_free_kbytes가 작아 지속적인 메모리 압박이 있다면 특정 order page 요청에 응대하기 위해 swap으로 이동되거나 이동된 swap을 다시 swap out 하면서 swapd가 동작하고 있을 가능성이 있습니다.
메모리 압박을 해소해야 하나 사용자의 사용이 원래 메모리를 과도하게 사용한다면 물리 메모리 부족이라 볼 수 있고, 물리 메모리 사용자의 사용에 충족하나 지속적인 메모리 압박이 있다면 min_free_kbytes가 작아 풍요속에 빈곤이 있을 수도 있습니다.
               
네 안그래도 찾아보니 해당 커널 설정을 수정 후 적용했더니 문제가 말끔하게 사라졌습니다. 풍요속에 빈곤이 정말 정확한 말씀이신거 같습니다.
                    
꼬소 03-24
잘 해결 되었다니 다행이네요.


제목Page 1/3
2024-08   6561   친절한김선임
2024-05   11529   Andrew
2023-10   11085   회상2
2023-03   22671   회상2
2022-03   5362   사수지몽
2021-11   4537   진화생물
2021-07   3752   INMD
2021-05   3535   꿀벌l최인혁
2020-09   5064   김세윤
2020-08   5014   유적발굴
2020-08   5623   유적발굴
2020-06   5280   응무소주
2020-02   4950   슬기로운생활
2020-02   5311   유적발굴
2019-12   11705   ZISQO
2019-08   12080   Andrew
2018-10   6175   IDC센터
2018-09   6088   NGC
2018-06   8877   아름드리소…
2017-12   7695   아슬레이