머신 : Dell r815, CentOS 5.4, 256GB RAM, 4 x 12 코어.
275GB 파일이있는 응용 프로그램이 있습니다. 한 번에 20GB의 데이터에 대해 적절한 정렬을 수행합니다. 즉, 비트를 교환하고 동일한 파일에서 대체합니다. 이 모든 것이 잘 작동합니다.
그런 다음 전체 파일을 읽고 다른 20GB 청크에서 병합 정렬을 수행하여 완전히 새로운 파일로 출력하는 마지막 패스가 있습니다.
이 프로세스는 잠시 동안 정상적으로 실행되고 디스크로 약 50GB 플러시됩니다. 그 후 언젠가는 WHOLE 머신이 놀라기 시작합니다.
ps -ef
, 와 같은 간단한 명령 ls -al
은 오랫동안 중단되어 100 % CPU (하나의 핵심)를 차지하는 것으로 나타납니다.
의 메모리 통계를 살펴보면 top
약 120GB의 RAM (128GB의 여유 공간)을 사용하고 “캐시 된”섹션 아래에 120GB가 있음을 알 수 있습니다.
전에 이런 종류의 행동을 본 사람이 있습니까? 동일한 프로세스가 64GB의 메모리가있는 컴퓨터에서 제대로 실행되므로 어떻게 든 그것이 컴퓨터에있는 RAM 마운트와 관련이 있다고 생각합니다.
(우리가 말했듯이 하드웨어 문제를 배제하기 위해 64GB를 제외한 모든 컴퓨터에서 테스트를 실행하고 있습니다).
아마도 일부 VM 매개 변수가 누락 /etc/sysctrl.conf
되었습니까?
감사!
답변
귀하의 질문에 내가 최근에 읽은 내용을 상기시켜주었습니다.
http://jcole.us/blog/archives/2010/09/28/mysql-swap-insanity-and-the-numa-architecture/
이는 48 코어 AMD 시스템에서 볼 수있는 NUMA 아키텍처가 메모리 할당 및 스와핑에 미치는 영향을 설명합니다. 이것이 당신이 겪고있는 것인지 모르겠지만 충분히 읽을만한 가치가 있습니다.
그것이 대답이 아니더라도 매혹적인 독서를합니다.
답변
따라서 이것은 64 비트 Centos 5.4 및 64 비트 Fedora 14에서 커널 버그 인 것처럼 보였습니다. Centos 5.5를 설치 한 후 문제가 사라졌습니다.
죄송합니다. 모두에게 더 나은 답변이 없습니다 …
답변
/etc/sysctl.conf에 행을 추가하여 스왑이 반드시 필요한 경우에만 사용되도록 지정할 수 있습니다.
swappiness = 0
이 파일이 전역 설정을 정의한다는 것을 이미 알고있을 것이므로이 변경이 환경에서 실행중인 나머지 응용 프로그램에 미치는 영향을 고려해야합니다.
답변
당신의 임시 공간은 어디에 있습니까? 종종 tempfs에 있습니다. Tempfs는 스왑 공간으로 백업 된 메모리에서 공간을 확보하므로 tempfs에 너무 많은 항목이 있으면 스왑 I / O가 트리거됩니다.
병합하는 데이터의 크기를 고려할 때 최종 병합에 도달하면 스왑이 예상됩니다.
스왑 저장소를 여러 디스크에 분산 시키면 도움이 될 수 있습니다.
답변
스왑을 사용하지 않는 동안에도 여전히 I / O 바인딩 상태 일 수 있습니다. ls 정보는 이것을 제안합니다.
dstat -df
디스크 통계를 표시하기 위해 출력을 보거나 dstat -af
(예, 너비 열이 넓을 것입니다. 이것은 48 코어가 있고 모든 CPU 사용량을 표시 할 때 발생합니다) 모든 것을보고 싶다면.
모든 CPU가 사용 중이면 (병렬 정렬은 CPU를 많이 사용하는 작업이 아님) 놀랍지 만 I / O 시스템에 대해서는 아무 말도하지 않습니다. 디스크가 적고 파일이 많은 경우 병합 정렬을 유지하기 위해 각 파일을 검색하는 디스크를 스 래싱 할 수 있습니다.