 안녕Ȣ16;세요
아래 서버가 현1116; 메모리가 ǥ12;1313;한 상태1064;,172; 맞나요?
맞다면 buff/cache 에 할NJ17;.108; 녀석들1012; 비워1480;야할텐데 buff/cache에 할NJ17;.108; 애들1008; 디스크랑 아1649; sync가 안.104;lj16; 애들 아닌가요?
Ǻ12;떤식1004;/196; ǥ16;석Ȣ16;고 1312;치해야 Ȣ16;lj16;1648; 1312;Ǻ16;ǥ12;ᓠ1;드립니다.
so
스왑을 비활성화 할 수도 있지만, 일부 애플리케이션은 스왑이 필수적으로 필요한 경우도 있기 때문에 권장되는 사항은 아닙니다.
DB 서버의 경우 캐시를 어그레시브하게 할당하고, 그에 따라 메모리 프레셔가 증가, 스왑을 할당하는 경우가 생길 수 있습니다.
MariaDB의 경우 스왑을 최대한 막기 위해 vm.swapiness를 1로 설정할 것을 권고하고 있습니다. 서버에서 동작 중인 애플리케이션의 권고사항에 따르십시오.
메모리를 점유하고 있는 프로세스는 그 메모리를 사용할 수 있지만, 다른 프로세스는 그 메모리에 접근하지 못하니,, 메모리를 정리 해 줘야 합니다.
윈도우에서는 RAMMAP라는 프로그램으로 Stanby 메모리를 Free로 풀어줄 수 있는데, 리눅스에서는 어떻게 해야하는지는 모르겠네요.
실제는 96G가 되겠죠
실제 프로그램이 메모리를 쓰면 버퍼 캐시 부분이 줄어듭니다.
커널이 알아서 해줍니다.
그냥 응용프로그램용 메모리 잔량은 available로 보시면 될 듯 합니다.
쉽게 표현하면, swapping i/o를 줄이려는 설계로 인하여...
확보만 해놓고 일부만 썼거나, 아직 안쓴 메모리임다.
https://wiki.kldp.org/Translations/html/The_Linux_Kernel-KLDP/tlk3.html
위에서 요구페이징을 보시면 되는데요,
보시다보면 virtual address, physical address 가 뇌를 괴롭힙니다 흑흑
일반적으로 사용자가 보는 주소는 대부분 가상 주소 번지임다.
물리적 메모리의 주소를 찾을라면 CR3 레지스터의 주소를 구해서... 뭐, 이렇습니다^^
걍 요구페이징이고 서버는 이상없다... 라고 넘어가시죠 ㅠㅠ
갑자기 고수이신 엠브리오님이 생각납니다 ㅠ
swap을 많이 사용하여 서버가 느려서 그렇습니다
현재 메모리가 부족한 상태인게 맞습니다.
저런 상황은 자주 겪는 일입니다.
free -h 로 리턴되어서 나오는 메시지 의미는 ...
서버 물리적 메모리 용량은 94GB 이고
스왑은 29GB 로 설정한 상황에서
메모리는 12GB를 사용 하고 있고 캐쉬로 80GB 를 사용중이고 1.8GB가 남아 있는 것 입니다.
12 + 80 + 1.8 = 93.8 ~= 94GB ( 물리적 메모리 용량 )
그런데 가용메모리 78GB 라고 표시되고 있는데 프로세스가 실행중 사용하고 있지 않지만 점유를 하고 있는 상태입니다.
보통의 경우 .. 메모리 부족 상태가 아니면 스왑까지 할당하지 않지만 29GB 중에서 12GB를 할당 하고 있습니다.
스왑까지 할당이 발생했다면 메모리가 부족하기 때문 이라는 것 입니다.
Available 78GB 은 루트 권한으로 아래 몀령으로 drop_caches를 실행 하면 free memory로 돌려 주기는 합니다.
% sync; sync; sync; echo 3 > /proc/sys/vm/drop_caches
위 명령을 실행하면 free memory 가 증가 하긴 하지만 메모리 점유가 많은 프로세스가 실행중이면 다시 캐시/버퍼 영역이 커지게 됩니다.
스왑이 할당될 만큼이므로 위 명령으로도 free memory가 커지지 않을 수도 있습니다.
하지만 메모리 점유가 많은 프로세스가 이미 완료된 상태라면 위 명령어가 유효할 수는 있지만 스왑이 12GB 이나 점유 하고 있다는 것은 메모리를 점유하는 프로세스 들이 모두 완료되지 않은 상태라고 생각 됩니다.
Free 메모리가 거의 없고 스왑이 할당된 상태이면 ....
1KB ASCII Text file을 editor 로 열어도 편집가능 까지는 한참 걸릴겁니다.
메모리가 없으니까요....
실행중인 프로세스도 더 많은 메모리가 필요하지만 할당하지 못하기때문에 ,... 매우 느리게 진행됩니다.
실행중 프로세스들의 메모리 점유량을 확인하세요.
% top
을 하면 가장 헤비하게 실행되는 프로세스의 메모리 점유량을 표시해 줍니다.
이들중 우선 순위가 낮은 것을 kill해서 종료하고 ... 나중에 다시 실행 하는 것이 저 상태로 진행할때보다 빠르게 완료할 수 가 있습니다.
하지만 하나의 프로세스가 모든 점유된 메모리를 사용한다면 ...
완료때까지 기다리거나 .... 메모리를 늘려야만 합니다.
메모리가 더 큰 시스템으로 작업을 다시 할당하는 것도 방법 입니다.
시스템 리소스 관리되는그리드 컴프팅 으로 구성된 상태에서 bsub 된 것이면 저 상태의 시스템에는 Job Que를 넣지 않습니다.
그리드 구성이 아닌 개별머신이면 .. 위에 말씀드린데로 .. 다른 시스템으로 Job을 옮기거나 덜 급한 프로세스를 Kill 하거나 ... 메모리를 늘리거나 ...
아니면 ... 걍 기다리는 겁니다, 조그만 파일 편집도 어려운 상태로 프로세스가 완료될때 까지 ..
구글링하거나 대부분의 사람들이 메모리 문제없다고 하는데 메모리가 문제가 없다면 swap을 사용하는부분이 납득이 안가네요
또한 buffer나cache부분을 명령어를 통해 비워주는것도 실행중인 프로세스에 전혀 상관이 없는건가 싶기도 합니다.
또한 사실상 top에서는 mem 점유율이 거의 없는것으로 나옵니다..
-->
top 화면을 잘못 읽고 있는거예요.
위 상태에서 % top 의 결과는 동일하게 나옵니다.
프로세스별로 메모리 사용량이 나옵니다.
대부분 swap 할당으로 거의 진행되지 않는데요...
그 이유는 최근의 빌드된 어프리케이션들은 실행 진행중 malloc 리턴 값이 충분하지 않으면 프로세스를 스스로 kill 해 버립니다.
swap 할당이 발생하는 상태는 잘못되거나 OS 나 HW 문제가 있는 것은 아니지만
원할한 운용에 좋지 않은 상태 임을 나타냅니다.
램을 소진해서 ... 프로세스간 컨텍스트 발생시 메인 메모리를 디스크에 만들어둔 가상 메모리로 잠시 대피한 것이기 때문에
메모리가 부족한 상태 이구요.
이런 상태로 계속 작업하면 .... 회사에선 일정 지연 사유로 인정 하지 않을 겁니다.
잘게 나누어서 시리얼로 진행하면 2-3일 소요 작업이 동시에 모두 Que 해서 시스템 리소스 부족에 허덕이면
시간이 2-3배로 더 걸리거나 작업 결과를 리뷰 할 수 없을 정도로 시스템이 느려지기 때문이죠.
그래서 2-3일 걸릴일을 일주일 이상 걸리게 되고 ... 그러면 팀 회이에서 일을 잘 못하거나 .. 태스크 분할 할줄 모르는 바보로 취급 하게 되거나 하죠.
내 팀원중 이런게 일 하면 과제 팀에서 아웃 시킵니다.
회사에 시스템 그리드 구성을 요청하세요.
그리면 리소스 분배를 software로 관리 해주므로 이런 귀찮은 .. 일종의 컴퓨터 노예 작업으로 부터 해방 됩니다.