우리 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마운트 가 있나요 ? 이는 스왑으로 백업되며 사용 가능한 스왑 공간이 없는 이유일 수 있습니다. 예기치 않게 행동 하거나 행동 syslog합니까 dmesg? 시스템이 자주 교체되지 않는 것이 확실합니까? vmstat -SK 1열 합계를 확인 하고 확인합니다 si( soKB/s 단위로 페이지 들어오고 나가기). 어떤 프로세스가 교체되고 있는지 알고 싶다면 를 실행하세요 sudo iotop -od5. Ubuntu를 실행 중인 경우 delayacct전체 통계를 얻으려면 커널 플래그가 필요합니다. 제가 보기에는 귀하의 시스템에는 이렇게 많은 양의 시스템 메모리에 비해 매우 작은 캐시와 버퍼가 있는 것 같습니다.
스와핑은 전체 시스템 성능을 향상시키는 데 사용됩니다. 예를 들어, 디스크 캐시나 파일 버퍼에 더 많은 메모리를 사용할 수 있도록 현재 대기 중인 대규모 프로그램의 일부를 교체합니다. 이 상황에서 스왑이 비활성화되면 시스템은 실제로 더 작은 디스크 캐시와 파일 버퍼를 갖게 됩니다. 스왑 공간이 가득 차서 동일한 문제가 발생할 수 있습니다.
메모리를 "누수"하는 프로그램이 있는 경우(즉, 프로그램이 실제로 사용되지 않는 메모리 블록을 획득하는 경우) 스왑 공간이 특히 중요합니다. 이 "누수"는 프로그램의 버그가 아닐 수도 있고, 메모리가 거의 사용되지 않아서 발생할 수도 있으므로 이를 누출로 처리하는 것이 좋습니다. 스왑 공간이 없으면 이러한 누출된 메모리를 캐시나 버퍼로 사용할 수 없습니다.
가상 메모리를 사용하여 올바르게 실행되는 운영 체제는 전체 작업 세트(액세스된 모든 파일, 애플리케이션이 예약한 모든 메모리 및 모든 쓰기 버퍼)가 시스템의 전체 런타임 동안 메모리에 완전히 들어맞지 않는 한 거의 항상 스왑을 사용합니다. 대부분의 경우 이는 시스템이 지속적으로 재부팅되거나 시스템에 전체 파일 시스템 크기에 비해 RAM 용량이 큰 경우에만 발생합니다.