☰

시스템 RAM이 부족하면 IO 속도가 높아집니다.

tag-icon • tag-icon memory swap io
시스템 RAM이 부족하면 IO 속도가 높아집니다.

시스템의 메모리가 부족하면 디스크 IO 사용량이 매우 높을 수 있다는 것을 발견했습니다.

프로세스가 많은 것 같습니다.읽다하드 드라이브에 문제가 있습니다( htop아래 출력 확인). 너무 많은 메모리를 사용하는 프로세스를 종료하면 시스템에 일부 메모리를 확보하십시오. IO 사용량이 정상 상태로 떨어집니다.

시스템에 메모리가 충분하지 않을 때까지 많은 양의 메모리를 소비하는 프로그램을 작성하면 문제가 재현될 수 있습니다. 실행 중인 프로그램을 종료하면 모든 것이 정상으로 돌아갑니다.

나는 운영 체제의 스와핑 메커니즘을 알고 있습니다. 하지만 프로세스 전반에 걸쳐 스왑이 사용되지 않는 것 같습니다.(아래에서 확인 free하고 vmstat출력하세요)

❯ free -h
              total        used        free      shared  buff/cache   available
Mem:          859Mi       692Mi        60Mi        25Mi       106Mi        36Mi
Swap:            0B          0B          0B

❯ htop
PID   RES   SHR CPU% MEM%   TIME+    DISK READ  DISK WRITE    DISK R/W Command
 6386 37316  5380  0.7  4.2 10:40.07   14.96 M/s    0.00 B/s   14.96 M/s ahdbserver-1.3.2-SNAPSH
23252 17880 15748  0.0  2.0  0:01.24    7.91 M/s    0.00 B/s    7.91 M/s postgres -D /var/lib/po
29428   400     0  0.0  0.0  0:02.63    3.36 M/s    2.63 K/s    3.36 M/s sgagent -d
 2369  197M     0  0.0 23.0  0:01.00    1.86 M/s    0.00 B/s    1.86 M/s java -jar memtest-1.0-S
24596 10820     0  0.0  1.2  0:59.53  694.74 K/s    0.00 B/s  694.74 K/s frps -c frps.ini
22901  122M     0  2.0 14.2  1:15.23  644.74 K/s    0.00 B/s  644.74 K/s srcds_linux -game dod -
 8735  2016    52  0.7  0.2  1:46.21  344.74 K/s    0.00 B/s  344.74 K/s htop
 2959  4664   176  0.0  0.5 15:35.06  318.42 K/s    0.00 B/s  318.42 K/s tmux
23265 18160 14344  0.0  2.1  0:01.30  286.84 K/s    0.00 B/s  286.84 K/s postgres: 11/main: post
23264  7036  3992  0.0  0.8  0:00.03   78.95 K/s    0.00 B/s   78.95 K/s postgres: 11/main: Time
23262  7160  4116  0.0  0.8  0:00.04   71.05 K/s    0.00 B/s   71.05 K/

❯ vmstat 2
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0      0  68588   2096 103156    0    0 28436     0 1787 4288  2  8 79 12  0
 0  1      0  57564    920 115364    0    0 24604    86 1676 3811  2  4 81 14  0
 0  0      0  70252   1156 102360    0    0 31750     0 1794 4337  3  8 75 15  0
 1  0      0  68632   2776 101380    0    0 38570    16 2139 4879  2 11 67 19  0
 0  0      0  67656    892 104940    0    0 29356    14 1706 3936  3  5 77 15  0
 0  0      0  68596    372 103368    0    0 50684     0 2324 5078  3 11 70 16  0
 0  0      0  69596    268 102512    0    0 35688    38 1890 4282  2  8 76 15  0
 0  1      0  69368    172 102540    0    0 35726    54 1877 4458  2  9 71 19  0
 0  1      0  69684   1912 100916    0    0 28724     0 1759 4235  3  7 74 16  0
 0  0      0  74380    768  97076    0    0 21198     0 1484 3762  2  5 80 13  0


❯ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 10 (buster)
Release:    10
Codename:   buster

이유는 무엇입니까?

답변1

iotop어떤 프로세스가 읽고 있는지 알려줄 것입니다.

일반적으로 문제는 캐시 부족으로 인해 발생합니다.

프로세스가 동일한 파일을 계속해서 순차적으로 읽는다고 가정하고 이것이 여유 메모리에 적합합니다. 그러면 I/O가 발생하지 않습니다. 모든 I/O 요청은 디스크 캐시에 의해 충족됩니다.

그러나 파일의 90%만 여유 메모리에 맞는 경우(예: 여유 메모리가 너무 작기 때문에) 갑자기전혀이는 캐싱 알고리즘이 최근에 가장 적게 사용된 것을 사용하기 때문입니다. 처음 90%는 메모리에 맞지만 마지막 10%를 읽을 때 처음 10%는 최근에 가장 적게 사용되었으므로 플러시됩니다. 마지막 10% 공간.

처음 10%를 다시 읽으면 다음 10%는 최근에 가장 적게 사용된 것이므로 플러시됩니다. 등.

정확한 상황이 아닐 수도 있지만 프로세스가 다른 파일의 다른 부분을 계속해서 읽어 유사한 결과를 제공할 수도 있습니다.

답변2

디스크 캐시만 메모리에서 지울 수 있는 것은 아닙니다.

커널은 실행 중인 애플리케이션의 페이지를 제거하고 현재 실행 중인 애플리케이션만 남길 수 있습니다. 이는 많은 코드를 실행해야 하는 "두꺼운" 애플리케이션에 대해 많은 IO를 생성할 수 있습니다.

관련 정보