우리는 한동안 Linux 애플리케이션을 사용해 왔습니다(우리의 여정은 10년 전 RHEL 4로 시작되었습니다). 우리는 최근 RHEL 7.9에서 애플리케이션을 실행해 왔으며 현재 RHEL 8.4로 마이그레이션하고 있습니다.
우리는 여전히 사용 가능한 메모리가 많을 때(페이지 캐시의 GIG 페이지) 가능한 많은 스왑을 피하기 위해 항상 vm.swappiness를 1로 설정합니다. 예, 우리는 페이지 캐시를 먼저 먹는 것을 선호합니다 :-)
이는 RHEL 7.x에서 항상 잘 작동했습니다. 사용 가능한 메모리가 500MB 정도를 초과할 때 스와핑이 발생하는 것을 본 적이 없습니다. 우리 시스템에는 일반적으로 16~64GB의 RAM이 있습니다.
RHEL 8.4에서는 사용 가능한 메모리가 많을 때(여러 기가) 스왑이 발생하는 것을 확실히 목격했습니다. RHEL 7에서는 비슷한 상황이 발생하지 않았습니다.
따라서 저는 스왑 "공격성" 관점에서 RHEL 7과 RHEL 8 사이의 변경 사항을 이해하고 싶거나, 이 스왑 결정이 내려진 이유를 더 잘 설명/문제 해결/이해하기 시작해야 할 부분이 무엇인지 알고 싶습니다.
내가 이것을 달성할 수 있는 방법에 대한 아이디어나 제안이 있습니까?
미리 감사드립니다. ++키릴 문자
답변1
FWIW, 우리가 발견한 동작은 Red Hat에 의해 버그로 확인되었습니다(오류 gila1990580, 이는 공개되지 않습니다).
답변2
스왑, RHEL 및 MariaDB에서도 동일한 문제가 있습니다. 임시 해결책은 커널을 RHEL 8.0/8.1에서 이전 버전으로 다운그레이드하는 것입니다. 이 문제는 RHEL 8.2/8.3/8.4/8.5 커널에서만 발생합니다.
핵심아니요문제: 4.18.0-80.el8 - 4.18.0-147.8.1.el8_1
핵심그리고문제: 4.18.0-193.el8 - 4.18.0-348.12.2.el8_5(및 5.4.x 및 5.16.x와 같은 모든 새로운 커널)elrepo.org)
첨부된:시릴 몰트케Red Hat Bugzilla 문제에 대한 추가 정보(민감한 데이터 제외)를 공유할 수 있습니까?너의 답?
FWIW, 우리가 발견한 동작은 Red Hat에 의해 버그로 확인되었습니다(오류 gila1990580, 이는 공개되지 않습니다).
따라서 현재로서는 커널을 다운그레이드하는 것이 유일한 해결책인 것 같습니다. 어쩌면 이 정보가 나와 다른 사용자에게 도움이 될 수도 있습니다.
답변3
참고로, Bugzilla 티켓은 방금 kernel-4.18.0-361.el8에서 "확인됨"으로 표시되었습니다. 이 커널 수준은 (현재) 사용 가능한 최신 RHEL 8.6 베타에 포함되어 있습니다. ++Cyrille을 직접 확인할 수는 없습니다.
답변4
RH 8.7로 업그레이드하지 않으려면 여기에서 해결 방법을 찾을 수 있습니다.https://github.com/systemd/systemd/issues/9276#issuecomment-1256304197
다양한 RHEL 8(8.2~8.6)에서 테스트되었으며 작동합니다.