리소스 집약적인 작업에 가장 적합한 서버 결정

분산 작업/작업 스케줄러, 클러스터 관리 시스템 또는 클라우드 관리를 찾아야 합니다. 이들 중 다수는 이미 존재하며 Cas는 그의 의견에서 일부를 지적했으며 Google은 더 많은 것을 발견할 것입니다.

일단 배포하면 두 사람 모두 더 행복해질 것이며 더 이상 항상 서로의 발가락을 밟는 것에 대해 걱정할 필요가 없을 것이라고 확신합니다. 또한 오류로 인해 시스템이 손상되지 않고 작업이 실패하도록 서버를 수정해야 합니다.

자신만의 리소스를 구축해야 한다고 주장한다면(15년 전의 일이지만 이미 그렇게 했다고 인정합니다), 광범위하게 말하면 작업은 몇 가지 다른 유형의 리소스를 소비하므로 작업이 차지하는 리소스는 무엇인지 고려해 보는 것이 좋습니다.

• 메모리(RAM) [실행 속도가 매우 느리거나 충돌이 발생하는 것으로 보아 make작업에 큰 문제가 될 것 같습니다.]
• 디스크 I/O 대역폭
• 초당 디스크 I/O 작업(조회)
• 디스크 공간
• CPU 시간
• GPU 시간
• 네트워크 대역폭

을 통해 메모리 사용량을 확인하고 free, 를 통해 디스크 I/O를 확인하고 , 를 통해 공간을 확인하고, iostat(Linux에서)을 통해 freeCPU 사용량을 확인하는 등의 작업을 수행할 수 있습니다.cat /proc/loadavguptimetopps

그러나 물론 현재 수치를 확인하는 데에는 문제가 있습니다. make작업이 먼저 몇 가지 간단한 작업을 수행하는 데 몇 분이 걸리고 수십억 개의 RAM이 필요한 대규모 프로세스를 시작할 수도 있습니다. 이런 일이 발생할 수 있습니다:

1. Alice는 스크립트를 실행하여 "make" 작업을 시작합니다.
2. 스크립트는 serverA를 확인하고 여유 RAM이 많고 CPU 사용량이 낮다는 것을 확인한 후 serverA에서 작업을 시작합니다.
3. 얼마 지나지 않아 Bob은 스크립트를 실행하여 RAM을 많이 사용하는 다른 작업을 시작합니다.
4. 앨리스의 임무는 아직 자원 집약적인 단계에 진입하지 않았습니다. 따라서 스크립트가 serverA를 확인할 때 여전히 사용 가능한 RAM이 많이 있습니다. 또한 serverA에서 Bob의 작업을 시작합니다.
5. Bob의 작업은 serverA에서 사용 가능한 RAM의 대부분을 사용합니다.
6. Alice의 작업은 마침내 RAM 집약적인 부분에 진입했지만 이제 사용 가능한 RAM이 없습니다. 어 오! ServerA가 사망했습니다.

예, 위의 내용은 하나를 작성한 경험에서 나온 것입니다(비록 내 것을 사용하는 경우에는 CPU 시간이었습니다).