I/O 작업 중에 많은 메모리를 소비하는 프로그램이 있는데, 이는 I/O 작업을 수행하는 데 따른 부작용입니다. direct_io를 사용하여 프로그램을 실행하면 메모리 문제가 사라졌지만 프로그램이 작업을 완료하는 데 걸리는 시간은 4배 더 길어졌습니다.
버퍼 캐시(I/O 작업 중에 사용되는 커널 버퍼) 최대 크기를 줄이는 방법이 있습니까? 커널 소스를 변경하지 않는 것이 좋습니다.
dirty_bytes 등을 줄이려고 노력했지만 /proc/sys/vm/눈에 띄는 차이는 없는 것 같습니다.
업데이트: echo 1 > /proc/sys/vm/drop_caches echo 2 > /proc/sys/vm/drop_caches echo 3 > /proc/sys/vm/drop_caches
프로그램 런타임 중에 사용하면 사용되는 메모리 양이 일시적으로 줄어듭니다.
페이지 캐시, 덴트리 및 아이노드를 지속적으로 해제하는 대신 어떻게든 제한할 수 있나요? 그러면 아마도 내 문제가 해결될 것입니다.
이전에는 이를 눈치채지 못했지만 파티셔닝뿐만 아니라 모든 I/O 작업에서 문제가 발생합니다. Linux는 사용 가능한 거의 최대 메모리에 도달하여 4MB의 여유 메모리를 남겨둔 특정 지점까지 I/O를 통과하는 모든 것을 캐싱하는 것처럼 보입니다. 따라서 I/O를 위해 캐시할 수 있는 메모리 양에는 일종의 상한이 있습니다. 그러나 그것이 어디에 있는지 찾을 수 없습니다. 필사적으로 친절해지기. 커널 소스 어딘가에서 2로 나눌 수 없다면 기꺼이 그렇게 하겠습니다.
2016년 12월 12일 업데이트: 나는 그 문제를 고치는 것을 포기했지만 뭔가가 내 관심을 끌었고 이 문제를 생각나게 했습니다. 집에 오래된 HDD가 있는데 그걸로 뭔가를 하려고 하면 자원이 미친 듯이 낭비됩니다.
HDD 고장으로 인한 경우일 수도 있나요? 문제의 HDD는 문제가 발생한 지 한 달 이내에 사망했습니다. 그렇다면 나는 답을 얻었습니다.
답변1
당신이 묻는대로프로그램, 당신은 사용할 수 있습니다cgroup:
메모리 제한(예를 들어 50GB, CPU와 같은 다른 제한도 지원됨, 예를 들어 CPU도 언급됨)이 있는 group1과 같은 이름의 cgroup을 생성합니다.
cgcreate -g memory,cpu:group1
cgset -r memory.limit_in_bytes=$((50*1024*1024*1024)) group1
그런 다음 앱이 이미 실행 중이면 앱을 이 cgroup으로 가져옵니다.
cgclassify -g memory,cpu:group1 $(pidof your_app_name)
또는 이 cgroup 내에서 앱을 실행하세요.
cgexec -g memory,cpu:group1 your_app_name