Linux 서버의 응답 속도가 매우 느립니다. top과도한 CPU 사용량을 표시하지 않습니다. 약 5GB의 여유 메모리가 있음에도 불구하고 시스템은 남은 여유 스왑 없이 스왑을 모두 사용하고 있는 것으로 나타났습니다. 이것이 시스템이 느리게 실행되는 이유가 될 수 있습니까? 프로세스 수를 줄이는 것 외에 다른 해결책은 없나요?
둘째, 사용 가능한 여유 메모리가 있음에도 불구하고 Linux가 이미 스와핑되는 이유는 무엇입니까? 나는 실제 메모리가 남아 있지 않을 때만 스왑을 사용한다고 생각했습니다.
free -m
total used free shared buffers cached
Mem: 32045 26218 5826 0 127 123
-/+ buffers/cache: 25967 6077
Swap: 16387 16387 0
업데이트:
- 교환성은 기본 수준: 60입니다.
- 누마 시스템이 아닌가 싶습니다.
- 8GB 힙으로 실행되는 두 개의 Java 프로세스가 있습니다.
-Xms8000m -Xmx8000m
얼핏 보면 미친 것 같지만 누군가가 이렇게 한 이유가 있었을 수도 있습니다. 이것이 스왑의 대부분을 차지하는 것이라고 생각하지만 Java 힙이 Linux 스왑과 메모리/성능에 일반적으로 어떤 영향을 미치는지 더 자세히 조사해야 합니다. 위의 Java 힙 구성이 시스템 성능에 미치는 영향에 대한 조언은 정말 도움이 될 것입니다.
답변1
8GB 힙으로 초기화된 Java 프로세스는 몇 개입니까? 아마도 최대값을 8로 유지하고 초기 힙 크기를 낮출 수 있습니다. 디스크 공간이 있으면 스왑 크기도 늘려보세요.
답변2
마운트 가 있나요 tmpfs? 이는 스왑으로 백업되므로 사용 가능한 스왑 공간이 0이 되는 원인일 수 있습니다. 예상치 못한 일이 있거나 나타나 syslog나요 dmesg? 시스템이 지속적으로 교체되지 않는 것이 확실합니까? 열과 (KB/s 단위로 들어오고 나가는 페이지 교체)를 확인 vmstat -SK 1하고 확인하세요 . 어떤 프로세스가 교체되고 있는지 알고 싶다면 를 실행하세요 . Ubuntu를 실행하는 경우 전체 통계를 위해서는 커널 플래그가 필요합니다. 제가 보기에 귀하의 시스템은 이렇게 큰 시스템 메모리에 비해 매우 작은 캐시와 버퍼를 갖고 있는 것 같습니다.sisosudo iotop -od5delayacct
스왑은 전체 시스템 성능을 향상시키는 데 사용됩니다. 이에 대한 예는 디스크 캐시나 파일 버퍼에 더 많은 메모리를 사용할 수 있도록 현재 대기 중인 큰 프로그램의 일부를 교체하는 것입니다. 이 경우 스왑을 비활성화하면 시스템의 디스크 캐시와 파일 버퍼가 실제로 더 작아집니다. 스왑 공간이 꽉 찼기 때문에 동일한 문제가 발생할 수 있습니다.
메모리를 "누수"하는 프로그램이 있는 경우(즉, 프로그램이 실제로 사용되지 않는 메모리 블록을 획득하는 경우) 스왑 공간이 특히 중요합니다. 이러한 "누출"은 프로그램의 오류가 아닐 수 있으며, 메모리가 거의 사용되지 않아 누출된 것으로 처리하는 것이 더 나을 수 있기 때문에 발생할 수 있습니다. 스왑 공간이 없으면 이러한 누출된 메모리를 캐시나 버퍼로 사용할 수 없습니다.
가상 메모리가 있는 올바르게 실행되는 OS는 전체 작업 세트(액세스된 모든 파일, 애플리케이션에 예약된 모든 메모리 및 모든 쓰기 버퍼)가 시스템의 전체 런타임 동안 메모리에 완전히 맞지 않는 한 거의 항상 스왑을 사용합니다. 대부분의 경우 이는 시스템이 지속적으로 재부팅되거나 시스템이 전체 파일 시스템 크기에 비해 RAM 용량이 큰 경우에만 해당됩니다.