From T3_KR_KNU
(→MemoryUsage가 RequestMemory보다 많은 작업) |
(→내 작업들의 세부정보를 살펴보려면 어떻게 해야할까?) |
||
| (9 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
== 경북대 HTCondor Job Policy 안내 == | == 경북대 HTCondor Job Policy 안내 == | ||
| − | === MemoryUsage가 RequestMemory보다 많은 작업 === | + | |
| + | === Hold 상태인 작업 === | ||
| + | |||
| + | |||
| + | ==== MemoryUsage가 RequestMemory보다 많은 작업 ==== | ||
* MemoryUsage가 RequestMemory보다 많은 작업은 Hold 상태로 변경됩니다. | * MemoryUsage가 RequestMemory보다 많은 작업은 Hold 상태로 변경됩니다. | ||
| + | * 작업을 넣을때 request_memory를 설정하지 않았다면 기본 RequestMemory는 2GB입니다. | ||
| − | === MemoryUsage가 RequestMemory보다 많은 작업을 hold 시켜야하는 이유 === | + | ===== MemoryUsage가 RequestMemory보다 많은 작업을 hold 시켜야하는 이유 ===== |
* request_memory 옵선에 따라서 사용 가능한 메모리가 할당이 되는데 작업이 이이상으로 많은 메모리를 사용하게 되면 자신의 작업뿐만아니라 타사용자의 작업에도 메모리 부족으로 문제를 일으키게 됩니다. | * request_memory 옵선에 따라서 사용 가능한 메모리가 할당이 되는데 작업이 이이상으로 많은 메모리를 사용하게 되면 자신의 작업뿐만아니라 타사용자의 작업에도 메모리 부족으로 문제를 일으키게 됩니다. | ||
| − | === 그렇다면 request_memory를 무조건 크게 넣으면 좋을까? === | + | ===== 그렇다면 request_memory를 무조건 크게 넣으면 좋을까? ===== |
* request_memory를 많이 설정하면 메모리 부족 문제는 발생하지 않겠지만 메모리를 크게 설정하는 만큼 사용가능한 작업 슬롯수가 줄어듭니다. | * request_memory를 많이 설정하면 메모리 부족 문제는 발생하지 않겠지만 메모리를 크게 설정하는 만큼 사용가능한 작업 슬롯수가 줄어듭니다. | ||
* 가령 64GB에 32core를 가지고 있는 연산노드가 있다고 가정하면 작업당 메모리 2GB를 사용하는 작업은 32개의 작업슬롯을 8GB를 사용하는 작업은 8개의 작업슬롯을 사용할 수 있습니다. | * 가령 64GB에 32core를 가지고 있는 연산노드가 있다고 가정하면 작업당 메모리 2GB를 사용하는 작업은 32개의 작업슬롯을 8GB를 사용하는 작업은 8개의 작업슬롯을 사용할 수 있습니다. | ||
| + | * 따라서 빠른 결과를 위해서는 적절한 request_memory 값을 설정해야합니다. 위의 예시에서 2GB면 충분한데도 8GB를 사용했다면 작업의 전체 소요시간은 4배 증가합니다. | ||
| − | === | + | ===== 내 작업들의 세부정보를 살펴보려면 어떻게 해야할까? ===== |
| − | ==== hold 상태인 작업은 ? ==== | + | * 현재 실행중인 작업은 (''jobid''는 작업 아이디 번호입니다.) |
| + | $ condor_q -l ''jobid'' | ||
| + | |||
| + | * 종료된 작업은 | ||
| + | $ condor_history -l ''jobid'' | ||
| + | |||
| + | * 종료된 작업의 정보를 좀더 편리하게 보고 싶다면 다음 서비스를 이용하세요. | ||
| + | |||
| + | https://chep17.knu.ac.kr:3003 | ||
| + | |||
| + | [[File:htcondor_memory1.png|414px]] [[File:htcondor_memory2.png|400px]] | ||
| + | |||
| + | ==== hold 상태인 작업은 어떻게 되나요? ==== | ||
* hold 상태인 작업은 24시간 후에 자동으로 삭제됩니다. | * hold 상태인 작업은 24시간 후에 자동으로 삭제됩니다. | ||
==== 작업이 hold 된 원인을 파악하려면 ==== | ==== 작업이 hold 된 원인을 파악하려면 ==== | ||
| − | * | + | * ''jobid''는 작업아이디 번호입니다. |
| − | $ condor_q -l jobid | grep HoldReason | + | $ condor_q -l ''jobid'' | grep HoldReason |
HoldReason = "memory usage exceeded request_memory" | HoldReason = "memory usage exceeded request_memory" | ||
| Line 30: | Line 48: | ||
* 내가 넣은 전체 작업이 메모리가 부족하고 메모리를 request_memory를 4096MB로 늘리고자 한다면 | * 내가 넣은 전체 작업이 메모리가 부족하고 메모리를 request_memory를 4096MB로 늘리고자 한다면 | ||
| − | $ condor_qedit userid RequestMemory 4096 | + | $ condor_qedit ''userid'' RequestMemory ''4096'' |
| − | $ condor_release | + | $ condor_release ''userid'' |
* 특정 작업만 메모리가 부족하다면 | * 특정 작업만 메모리가 부족하다면 | ||
* jobid는 작업아이디 번호입니다. | * jobid는 작업아이디 번호입니다. | ||
| − | $ condor_qedit jobid RequestMemory 4096 | + | $ condor_qedit ''jobid'' RequestMemory ''4096'' |
| − | $ condor_release jobid | + | $ condor_release ''jobid'' |
| + | |||
| + | === Hold 없이 삭제되는 작업 === | ||
| + | |||
| + | * WallTime이 60시간 이상인 작업은 삭제됩니다. | ||
| + | * CpuTime이 60시간이 이상인 작업은 삭제됩니다. | ||
| + | * 작업의 최대 실행 시간은 변경될수 있습니다. | ||
| + | * 60시간 이상의 작업 실행이 필요한 사용자는 lcg_knu@knu.ac.kr로 문의주세요. | ||
Latest revision as of 08:03, 9 February 2022
경북대 HTCondor Job Policy 안내
Hold 상태인 작업
MemoryUsage가 RequestMemory보다 많은 작업
- MemoryUsage가 RequestMemory보다 많은 작업은 Hold 상태로 변경됩니다.
- 작업을 넣을때 request_memory를 설정하지 않았다면 기본 RequestMemory는 2GB입니다.
MemoryUsage가 RequestMemory보다 많은 작업을 hold 시켜야하는 이유
- request_memory 옵선에 따라서 사용 가능한 메모리가 할당이 되는데 작업이 이이상으로 많은 메모리를 사용하게 되면 자신의 작업뿐만아니라 타사용자의 작업에도 메모리 부족으로 문제를 일으키게 됩니다.
그렇다면 request_memory를 무조건 크게 넣으면 좋을까?
- request_memory를 많이 설정하면 메모리 부족 문제는 발생하지 않겠지만 메모리를 크게 설정하는 만큼 사용가능한 작업 슬롯수가 줄어듭니다.
- 가령 64GB에 32core를 가지고 있는 연산노드가 있다고 가정하면 작업당 메모리 2GB를 사용하는 작업은 32개의 작업슬롯을 8GB를 사용하는 작업은 8개의 작업슬롯을 사용할 수 있습니다.
- 따라서 빠른 결과를 위해서는 적절한 request_memory 값을 설정해야합니다. 위의 예시에서 2GB면 충분한데도 8GB를 사용했다면 작업의 전체 소요시간은 4배 증가합니다.
내 작업들의 세부정보를 살펴보려면 어떻게 해야할까?
- 현재 실행중인 작업은 (jobid는 작업 아이디 번호입니다.)
$ condor_q -l jobid
- 종료된 작업은
$ condor_history -l jobid
- 종료된 작업의 정보를 좀더 편리하게 보고 싶다면 다음 서비스를 이용하세요.
hold 상태인 작업은 어떻게 되나요?
- hold 상태인 작업은 24시간 후에 자동으로 삭제됩니다.
작업이 hold 된 원인을 파악하려면
- jobid는 작업아이디 번호입니다.
$ condor_q -l jobid | grep HoldReason HoldReason = "memory usage exceeded request_memory"
request_memory 부족으로 hold 된 작업은 어떻게 해결해야하나요?
- 내가 넣은 전체 작업이 메모리가 부족하고 메모리를 request_memory를 4096MB로 늘리고자 한다면
$ condor_qedit userid RequestMemory 4096 $ condor_release userid
- 특정 작업만 메모리가 부족하다면
- jobid는 작업아이디 번호입니다.
$ condor_qedit jobid RequestMemory 4096 $ condor_release jobid
Hold 없이 삭제되는 작업
- WallTime이 60시간 이상인 작업은 삭제됩니다.
- CpuTime이 60시간이 이상인 작업은 삭제됩니다.
- 작업의 최대 실행 시간은 변경될수 있습니다.
- 60시간 이상의 작업 실행이 필요한 사용자는 lcg_knu@knu.ac.kr로 문의주세요.