스왑 공간은 디스크의 영역으로, 파티션, 파일 또는 이들의 조합일 수 있습니다.
간단히 말하면, 시스템의 물리적 메모리가 부족할 때 Linux는 자주 액세스하지 않는 데이터를 메모리에 저장하여 교체함으로써 시스템이 각 프로세스를 처리할 더 많은 물리적 메모리를 확보하고 시스템이 스토리지에 액세스해야 할 때 콘텐츠를 교환한 다음 스왑의 데이터를 메모리에 로드하는 것을 흔히 스왑 아웃(swap out) 및 스왑 인(swap in)이라고 합니다.
이 질문에 대답하려면 스왑이 우리에게 어떤 이점을 가져다 주는지 답해야 합니다.
일부 대형 애플리케이션(예: LibreOffice, 비디오 편집기 등)의 경우 시작 프로세스 중에 많은 양의 메모리가 사용되지만 이 메모리는 시작 중에만 사용되는 경우가 많으며 후속 작업에서는 거의 사용되지 않습니다. 이 추억들. 스왑을 사용하면 시스템은 이러한 방식으로 사용되지 않는 메모리 데이터 부분을 스왑에 저장할 수 있으므로 시스템에서 사용할 수 있는 물리적 메모리를 더 확보할 수 있습니다.
우분투와 같은 많은 배포판의 최대 절전 모드 기능은 스왑 파티션에 의존합니다. 시스템이 최대 절전 모드로 전환되면 메모리의 데이터는 다음에 시스템이 시작될 때 스왑 파티션에 저장됩니다. 시스템 시작 속도를 높일 수 있으므로 최대 절전 모드 기능을 사용하려면 스왑 파티션을 구성해야 하며 크기는 실제 메모리보다 크거나 같아야 합니다.
물리적 메모리가 제한되어 있는 경우도 있는데, 메모리를 많이 소모하는 프로그램을 실행하고 싶다면 어떻게 해야 하나요? 이때, 스왑 공간을 충분히 구성하면 목표를 달성할 수 있습니다. 조금 느리긴 하지만 최소한 실행은 가능합니다.
대부분의 경우 물리적 메모리는 충분하지만 프로세스에 예상보다 많은 메모리가 필요하거나 프로세스에 메모리 누수가 발생하는 등 예상치 못한 상황이 항상 발생합니다. 메모리가 충분하지 않으면 커널의 OOM 킬러가 OOM 킬러의 구성에 따라 일부 프로세스가 종료되거나 시스템이 직접 다시 시작됩니다(기본값은 가장 많은 메모리를 소비하는 프로세스를 먼저 종료하는 것입니다). 그러나 스왑을 사용하면 스왑을 다음과 같이 사용할 수 있습니다. 메모리 약간 느리기는 하지만 적어도 디버깅하거나 프로세스를 종료하거나 현재 작업 진행 상황을 저장할 수 있는 기회를 제공합니다.
Linux 메모리 관리를 보신 분이라면 시스템이 시스템의 I/O 속도를 높이기 위해 캐시에 여유 메모리를 최대한 많이 사용한다는 것을 아실 것입니다. 따라서 자주 사용하지 않는 메모리 데이터를 스왑으로 옮길 수 있다면 , 캐시에 더 많은 실제 메모리가 사용되어 전체 시스템 성능이 향상됩니다.
위에서 스왑의 장점을 소개했는데, 스왑의 단점은 어떨까요? 스왑은 디스크에 저장됩니다. 디스크의 속도는 메모리의 속도보다 몇 배나 느립니다. 스왑을 계속해서 읽고 쓴다면, 특히 시스템의 성능에 영향을 미칠 것입니다. 메모리가 매우 부족합니다. 스왑 공간의 빈도가 매우 높기 때문에 시스템이 죽은 것처럼 매우 느리게 실행됩니다. 이때 물리적 메모리를 추가하는 것이 유일한 해결책입니다.
시스템은 자주 사용하지 않는 메모리 데이터를 자동으로 스왑으로 이동시키기 때문에 데스크톱 프로그램의 경우 프로그램을 최소화했다가 다시 열 때 스왑에 있는 데이터를 메모리에 다시 로드해야 하기 때문에 약간의 일시 중지가 발생할 수 있습니다. .
위에서는 스왑이 무엇인지, 장점과 단점을 소개했는데, 스왑을 구성해야 할까요? 대답은 다음과 같습니다. 상황에 따라 다릅니다.
다음은 메모리 부족, 메모리 부족, 메모리 넉넉 등 세 가지 상황에서 서버 및 데스크톱 환경에서 스왑을 선택하는 방법에 대해 설명합니다.
데스크톱이든 서버이든 물리적 메모리가 충분하지 않아 프로그램을 실행하려는 경우 스왑을 추가하는 것이 전혀 작동하지 않는 것보다 느린 것이 낫습니다.
스왑을 구성하는 것이 좋습니다. 그러면 커널이 자주 사용되지 않는 데이터를 메모리에서 스왑으로 이동하여 시스템 호출을 위한 물리적 메모리를 더 많이 확보하고 시스템 성능을 향상하며 가끔 물리적인 오류를 방지할 수 있습니다. 메모리 장애로 인해 프로세스가 비정상적으로 종료되어 시스템 안정성이 향상되는 것은 아닙니다. 그러나 서버의 경우 스왑 공간이 예상보다 많이 사용되거나 스왑 인되는 경우에는 이를 제한하거나 모니터링해야 합니다. /out이 자주 발생하므로 적절한 조치를 취해야 합니다. 그렇지 않으면 시스템에 심각한 손상을 초래할 수 있습니다.
이론적으로 물리적 메모리가 충분하고 최대 절전 모드 기능이 필요하지 않은 경우 그러면 스왑은 쓸모가 없지만 핵심 문제는 어떤 상황에서도 물리적 메모리가 충분한지 확인하기 어렵다는 것입니다. 특정 프로세스가 예상보다 많은 메모리를 소비하거나 예상을 초과하는 서버 압력과 같은 예상치 못한 상황이 항상 있기 때문입니다. , 메모리 누수 등
현재 메모리 부족 현상이 발생하는 이유는 무엇입니까? mysql이 서버의 메모리 부족을 직접적으로 발생시키는 이유는 무엇입니까? 그러면 mysql 서버에서 스왑이 발생하는 이유는 무엇입니까?
직접 말하면, 시스템은 mysql이 차지하는 공간이 너무 커서 특별한 작업을 수행할 수 없다고 생각합니다. 메모리를 사용하려면 다른 필요한 프로세스 영역을 위한 공간을 만들어야 합니다. 재생 속도가 느려집니다!
mysql에서 가장 큰 메모리 점유자는 innodb_buffer_pool_size인데 처음에 이 값이 무리하게 설정되어 있지는 않은지 고려해야겠죠?
MySQL의 메모리 소비는 다음과 같이 나뉩니다.
1. 세션 수준 메모리 소비: sort_buffer_size 등. 각 세션은 정렬 작업을 위해 sort_buffer_size를 엽니다.
2. 전역 메모리 소비: : innodb_buffer_pool_size 등 글로벌 공유 메모리 세그먼트
여기서 우리 DBA는 전문가가 아닌 것 같습니다. 세션 레벨에서 메모리 사용량을 확인하는 첫 번째 상황을 고려하지 않고 직접 조정하라고 했습니다. innodb_buffer_pool_size
테이블 데이터와 인덱스 데이터를 캐시하고, 디스크의 데이터를 버퍼 풀에 로드하고, 액세스할 때마다 디스크 IO를 방지하고, 액세스 속도를 높입니다.
MySQL의 동시성 성능은 버퍼 풀에서 할당한 메모리 크기에 정비례합니다. 할당된 메모리가 클수록 동시성 성능이 향상됩니다. 머신 메모리의 99%를 모두 버퍼 풀에 할당해야 합니까?
물론 아니죠! 운영 체제 커널에도 몇 기가바이트의 메모리가 필요하다는 점은 말할 것도 없습니다. MySQL에는 다른 메모리 데이터 구조도 많이 있으므로 위의 아이디어는 확실히 실현 가능하지 않습니다.
버퍼 풀의 메모리 크기가 머신 전체 메모리의 50%~60%를 차지하는 것이 보다 합리적인 비율이어야 합니다.
Show Engine innodb statusG;를 통해 적중 상태를 확인할 수 있습니다. 적중률이 97%를 넘지 않으면 메모리 추가를 고려할 수 있습니다. 물론 이는 비즈니스와도 관련이 있습니다. 쓰기량이 많고 읽기량이 적은 경우는 특별한 경우입니다.
다른 경우에는 97% 이상에 도달하지 못하고, 읽기량이 많은 경우에는 98% 이상에 도달하지 못하는 경우, 이는 버퍼가 충분하지 않다는 것을 의미하며, 반면에 메모리 적중률이 20%이면 버퍼에 도달할 수 있으므로 사용 가능한 페이지가 많습니다. 이는 충분하다는 것을 의미합니다. 사용 가능한 페이지에 따라 계산하여 일부 메모리를 줄일 수도 있습니다.
위 내용은 Linux 스왑 공간 활용도가 높은 문제를 해결하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
