대규모 클러스터에서 캐시 삭제 속도가 극도로 느려지는 원인은 무엇입니까?

대규모 클러스터에서 캐시 삭제 속도가 극도로 느려지는 원인은 무엇입니까?

디스크에서 파일 I/O 시간을 측정하려고 합니다. 모든 I/O가 RAM이 아닌 하드 드라이브에서 발생하는지 확인하기 위해 읽기 시간을 정하기 전에 캐시 삭제 명령을 실행했습니다. 특히 fprintfC 프로그램을 호출하여 3을 작성합니다. /proc/sys/vm/drop_caches소스는 다음과 같습니다.

FILE *f = fopen("/proc/sys/vm/drop_caches", "w");

  if (!f)
  {
    perror("Opening of /proc/sys/vm/drop_caches failed");
    return 1;
  }

fprintf(f, "3");

fclose(f);

코드는 실제로 대규모 클러스터의 많은 시스템에서 실행되고 있으며 대부분 이상한 문제가 발생합니다. 위 코드를 실행하는 데는 몇 시간이 걸리는 경우가 있습니다. 여기서의 작업 흐름은 읽기 → 캐시 삭제 → 반복입니다. 읽는 데는 약 5분밖에 걸리지 않으므로 그 짧은 시간 동안 캐시된 내용이 많지 않아야 합니다.

두 컴퓨터는 거의 동일한 소프트웨어와 하드웨어를 갖추고 있지만 약 20개 중 1개만이 캐시를 삭제하는 데 문제가 없는 것 같습니다.

그렇게 오래 걸리는 이유가 있나요? 어떤 경우에는 프로그램이 완전히 정지되는 것 같습니다. 이 문제를 해결하는 방법에 대한 팁이 있습니까?

편집자: =============================================== == =========

저는 이에 대한 몇 가지 문제 해결을 수행했으며 나중에 다른 사람이 이 문제에 직면할 경우를 대비하여 제가 찾을 수 있는 내용을 분류하고 싶었습니다. 전체적으로 우리는 이것이 Hadoop 및 HDFS와 관련이 있다고 생각합니다.

1) 명령의 다른 인스턴스가 중단된 동안 컴퓨터에서 C 프로그램을 수동으로 실행할 수 있으며 어떤 경우에는 중단된 프로그램보다 먼저 반환됩니다. 즉, 프로그램의 다른 인스턴스가 캐시를 삭제하고 반환할 수 있으므로 실제 캐시 삭제에는 그리 오래 걸리지 않을 수 있습니다.

2) 머신 중 하나에 문제가 없는 이유는 hadoop이나 다른 프로그램이 해당 노드에서 충돌하여 hadoop에서 사용할 수 없게 되었기 때문입니다. 이것이 우리가 HDFS와 관련이 있다고 생각하는 이유입니다.

관련 정보