사용 가능한 메모리가 기가바이트이면 상단에 "swout"이라고 표시됩니다. 왜?

사용 가능한 메모리가 기가바이트인데 왜 atop20,000페이지(80MB 이상) 이상을 교환한다고 표시됩니까 ?

나는 이것에 대한 성능 문제를 발견하지 못했습니다. 저는 이 기회를 통해 지식을 늘리고 싶었습니다 :-).

atop10초마다 새로 고쳐집니다. 새로 고칠 때마다 마지막 새로 고침 이후의 활동이 표시됩니다.

MEM | tot     7.7G | free    3.7G | cache 608.3M | buff   19.1M | slab  264.6M |
SWP | tot     2.0G | free    1.4G |              | vmcom  13.4G | vmlim   5.8G |
PAG | scan  167264 | steal 109112 | stall      0 | swin       0 | swout  23834 |

                                "swout" is non-zero and coloured in red  ^

커널 메모리 정보:

$ head -n 5 /proc/meminfo
MemTotal:        8042664 kB
MemFree:         3563088 kB
MemAvailable:    3922092 kB
Buffers:           20484 kB
Cached:           775308 kB

커널 버전:

$ uname -r
5.0.16-200.fc29.x86_64

---

1. 이것이 영향을 받을지는 불분명합니다 vm.swappiness. 이 설정은 캐시 제거와 스와핑의 균형을 유지합니다. 그러나 많은무료기억, 그렇다면 애초에 기억을 되찾아야 하는 이유는 무엇입니까?

2. 보시다시피 이것은 작은 시스템입니다. NUMA를 사용하지 않습니다. 체크인한 결과 /proc/zoneinfo"Node 0" 노드가 하나만 있는 것으로 나타났습니다. 그래서 이것은 아니다NUMA로 인해 발생함.

3. 관련 질문과 답변에는 "기회적 스와핑", "시스템이 할 일이 없을 때", "나중에 메모리 부족이 발생하는 경우" 등과 같은 아이디어가 언급되어 있습니다. 나는 이러한 아이디어가 커널 문서와 모순되기 때문에 신뢰할 수 없다고 생각합니다. 바라보다 Linux는 "기회적 교환"을 수행합니까, 아니면 신화입니까?

4. 이 기능을 사용할 때 RAM 사용량에는 설정된 제한이 없습니다 systemd.resources. 즉 systemd, 모든 장치의 RAM 사용 제한이 "무제한"으로 설정되어 있는 것 같습니다 .

   $ systemctl show '*' | \
       grep -E '(Memory|Swap).*(Max|Limit|High)' | \
       grep -v infinity
   $
   

5. 편집: 나는 이것이 투명한 거대한 페이지와 관련이 있다고 생각합니다. 가상 머신은 게스트 메모리를 효율적으로 할당하기 위해 투명한 hugepage를 사용하는 것으로 나타났습니다. 거대한 페이지를 사용하는 유일한 사용자 프로그램입니다.내 시스템에서.

   비슷한 질문이 있습니다:사용 가능한 메모리가 Pages_high 워터마크보다 훨씬 높으면 kswapd를 활성화할 수 있습니까?모든 애플리케이션에 대해 대형 페이지를 지원하는 RHEL 6에 대해 묻고 있습니다.

이 결과를 재현하는 방법을 잘 모르겠습니다.

이는 가상 머신을 시작할 때 발생합니다. libvirt를 사용하여 가상 머신을 실행합니다. 기본적으로 VM 디스크 읽기는 호스트 페이지 캐시를 사용하여 캐시됩니다. (캐시 모드: "하이퍼바이저 기본값"은 "쓰기 저장"을 의미합니다).

가상 머신, FADVISE_DONTNEED이미지 파일을 중지하고 다시 시도했습니다. 그러나 같은 일은 일어나지 않았습니다.

그런 다음 다른 가상 머신으로 다시 시도했는데 이 문제가 잠시 동안 발생했습니다. 나는 그것을 잡았다 vmstat. 나는 "swout"이 다른, 더 높은 숫자를 나타내는 것이라고 생각했지만 atop그것을 잡지 못했습니다.

$ vmstat 10
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0 770168 5034300  28024 936256    0    2    21    86   60  101 22  9 68  1  0
 0  0 770168 5033852  28048 935904    0    0     0     8  372  633  1  1 97  0  0
 1  0 770168 4974048  28252 948152    3    0  1137   194 1859 2559 11  7 79  3  0
 0  1 770168 4557968  28308 1037512    0    0  8974    45 3595 6218 16  6 57 21  0
 6  3 770168 4317800  28324 1111408    0    0  7200   609 6820 6793 12  5 38 44  0
 0  4 770168 4125100  28348 1182624    0    0  6900   269 5054 3674 74  3  8 15  0
 0  5 770168 3898200  27840 1259768    2    0  9421   630 4694 5465 11  6 11 71  0
 1  3 770168 3760316  27672 1300540    0    0  9294   897 3308 4135  5  4 28 63  0
 0  1 770168 3531332  27032 1356236    0    0 10532   155 3140 4949  8  5 63 25  0
 0  0 783772 3381556  27032 1320296    0 1390  7320  4210 4450 5112 17  5 43 35  0
 0  0 783772 3446284  27056 1335116    0    0   239   441  995 1782  4  2 92  2  0
 0  0 783772 3459688  27076 1335372    0    0     3   410  728 1037  2  2 95  1  0

systemd또한 libvirt가 우회 하고 실수로 자체 스왑하는 경우를 대비하여 VM의 cgroup 메모리 제한도 확인했습니다 .

$ cd /sys/fs/cgroup/memory/machine.slice/machine-qemu\x2d5\x2ddebian9.scope
$ find -type d  # there were no sub-directories here
$ grep -H . *limit_in_bytes
memory.kmem.limit_in_bytes:9223372036854771712
memory.kmem.tcp.limit_in_bytes:9223372036854771712
memory.limit_in_bytes:9223372036854771712
memory.memsw.limit_in_bytes:9223372036854771712
memory.soft_limit_in_bytes:9223372036854771712
$ cd ../..
$ find -name "*limit_in_bytes" -exec grep -H -v 9223372036854771712 \{\} \;
$