약 일주일 정도에 걸쳐 Ubuntu 16.04 서버의 스왑 공간이 가득 차고 비워지지 않아 서버에 다른 계단식 문제가 발생했습니다. 즉, Solr를 실행하는 Tomcat 인스턴스가 주기적으로 실패합니다.
서버는 16g
RAM과 16g
스왑을 갖춘 쿼드 코어 가상 머신입니다. 현재 swappiness
값은 입니다 60
.
우리는 이미지 처리 등을 위해 로컬 서버에 내부 HTTP 호출을 많이 하면서 서버를 매우 열심히 운영하고 있으며 대부분은 Apache를 통해 수행됩니다. 스왑 공간이 천천히 채워지고 비워지지 않는 문제가 있었기 때문에 눈에 띄는 효과 없이 다른 영역을 간소화했습니다. 다시 시작하면 정상으로 돌아올 때까지 문제가 해결될 수 있습니다.
스왑 드롭의 차트 번호를 첨부할 수 있지만 그것이 얼마나 도움이 될지는 잘 모르겠습니다(nmon을 사용하여 추적했습니다). 예를 들어, 어제 다시 시작한 후 free -m
출력은 다음과 같습니다.
total used free shared buff/cache available
Mem: 16047 4888 7621 32 3536 10729
Swap: 16380 0 16380
보시다시피 0
교환에 사용됩니다. 그러나 아직 확인되지 않은 이유로 시스템이 다운되면 실제로는 복구되지 않으며 다음과 같은 중단 현상이 발생합니다.
오후 1시 30분쯤 바닥이 닿을 때까지 며칠을 건너뛰세요.
어떤 제안이 있으십니까? 아니면 조사를 계속하는 방법에 대한 제안이 있으신가요?
질문 업데이트
댓글의 피드백을 바탕으로 질문을 약간 업데이트하세요.
Tomcat의 힙 크기는 아닌 것 같습니다. 현재 Tomcat에 대한 JVM 설정에서는 JAVA_OPTS=' -Xms4096m -Xmx4096m'
해당 크기를 크게 늘렸습니다(보통 2g 정도 실행). 톰 고양이가 catalina.out
우리에게 말해요Native memory allocation (mmap) failed to map 2863661056 bytes for committing reserved memory.
답변1
이는 아마도 solr에서 메모리 누수가 발생했거나 JVM 매개변수를 잘못 구성한 것 같습니다. 나는 이것이 가상 머신이기 때문에 solr만 실행한다고 생각합니다.
메모리 관련 JVM 매개변수를 확인하고 싶을 수도 있습니다.
-Xms
-Xmx
-Xmx
최대 힙 크기가 지정되어 있습니다 .
"-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/some/path/filename"
JVM 매개변수를 추가하여 OOME에서 힙 덤프를 생성하도록 JVM을 구성할 수도 있습니다 . 파일이 상당히 크기 때문에 최소 32GB의 디스크 공간이 필요할 수 있습니다!
이를 알고 나면 누출이 발생하는 위치를 확인할 수 있습니다.
업데이트: JVM이 아닌 것 같으므로 모든 프로세스를 살펴봐야 합니다.
이것을 실행하면 어떤 프로세스가 가장 많은 스왑 공간을 사용하고 있는지 알려줍니다.
for file in /proc/*/status ; do awk '/VmSwap|Name/{printf $2 " " $3}END{ print ""}' $file; done | sort -k 2 -n -r
에서 가져옴https://www.cyberciti.biz/faq/linux-which-process-is-using-swap/