Linux 캐시/스왑 비율을 미세 조정하는 방법은 무엇입니까?

내 컴퓨터에는 GUI가 죽을 때까지 거의 사용할 수 없게 만들고 매우 엉성하게 만드는 문제가 있었습니다.

나는 분석 결과 이것이 캐시/버퍼로 인해 너무 많은 스왑이 발생했기 때문에 발생했다고 결론지었습니다. 이러한 설정을 세부적으로 조정할 수 있는 방법이 있나요?

사용 사례: SSD가 아닌 하드 드라이브에서 대량의 데이터를 읽거나 쓰기만 하면 됩니다. dd또는 f3read/ 를 사용한다고 가정합니다 f3write. 약 1분 후에 캐시나 버퍼가 너무 커지면 Linux는 대량 교체를 시작합니다.

이 atop코드 조각에서는 PAG 줄에서 이를 볼 수 있습니다.

MEM |  tot    15.5G |  free    3.5G  | cache   7.8G  |  buff   96.1M |  slab  394.5M |  vmbal   0.0M  | hptot   0.0M  |
SWP |  tot     1.0G |  free  634.7M  |               |               |               |  vmcom   8.5G  | vmlim   8.8G  |
PAG |  scan  156637 |  steal 156616  | stall      0  |               |               |  swin       0  | swout  11814  |
PSI |  cs     0/0/2 |  ms     5/2/2  | mf     5/2/1  |  is  50/24/15 |  if  50/24/15 |                |               |
DSK |           sdb |  busy     56%  | read      61  |  write   1312 |  MBr/s    0.0 |  MBw/s  147.8  | avio 3.95 ms  |
DSK |           sda |  busy     24%  | read     100  |  write  11803 |  MBr/s    0.2 |  MBw/s    4.6  | avio 0.20 ms  |

이 필드의 의미를 완전히 이해하지 못합니다. 하지만 노트북에서도 똑같이 시도했습니다. SWOUT통계가 훨씬 낮고 시스템이 영향을 받지 않는다는 점을 제외하면 모든 것이 유사합니다 .

두 시스템 모두에 Ubuntu 19.10 커널 5.3.0-19-generic이 있습니다. 스왑은 SSD에 있습니다. SSD 데이터 에 따르면 atop사용량은 20%~50%이며 주로 스와핑으로 인해 발생합니다.

60에서 10으로 설정하려고 시도했지만 /proc/sys/vm/swappiness도움이 되지 않았습니다. 100에서 50으로 설정 했지만 vfs_cache_pressure그것도 도움이 되지 않았습니다.

그 이유가 다른 곳에 있을 수 있을까요? SATA 문제가 있었는데 지금쯤 해결되어야 합니다. 한 번(인텔에서) 이런 일이 발생했는데 GPU HANG교체 문제로 인해 발생한 것 같습니다...

이 문제를 보기 시작했을 때(철저하게 분석하기 전에) 항상 문제가 발생했기 때문에 스왑(이전에는 없었던)을 추가했습니다 kswapd. 스왑을 추가하면 최소한 kswapd가 CPU의 100%를 차지하는 것을 방지할 수 있습니다.

어떤 아이디어가 있나요?