From T3_KR_KNU
Jump to: navigation, search
(HTCondor의 빠른 시작을 위한 추천 참고 자료)
(Apptainer(Singularity)를 이용하여 코드 실행)
 
(75 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
== HTCondor Batch System 사용법 ==
 
== HTCondor Batch System 사용법 ==
  
HTCondor Batch System 사용법이 작성 중 입니다.
 
  
 
=== Tier-3 HTCondor/CentOS7 UI 접속하기 ===
 
=== Tier-3 HTCondor/CentOS7 UI 접속하기 ===
다음과 같이 터미널을 열어서 원격로그인(SSH)으로 접속합니다. 현재는 cms02 한대 서버만 지원합니다.
+
다음과 같이 터미널을 열어서 원격로그인(SSH)으로 접속합니다.  
   ssh -X username@cms02.knu.ac.kr
+
   ssh -X username@cms.knu.ac.kr
  
 +
=== Job submit ===
 +
Job submit을 위해서는 다음과 같이 "condor_submit" 명령어를 사용합니다.
  
=== HTCondor의 빠른 시작을 위한 추천 참고 자료  ===
+
* sleep.sh - 테스트 코드
* [https://research.cs.wisc.edu/htcondor/manual/quickstart.html HTCondor Quick Start Guide] : 기본적인 사용법을 익히기에 좋은 자료입니다.
+
  
=== 전체 작업 현황 살펴보기 ===
+
#!/bin/bash
 +
 +
TIMETOWAIT="10"
 +
echo "sleeping for $TIMETOWAIT seconds"
 +
/bin/sleep $TIMETOWAIT
  
$ condor_status -schedd
+
* sleep.sub - 작업 명세 파일
Name            Machine        RunningJobs  IdleJobs  HeldJobs
+
 
   
 
   
  ce01.knu.ac.kr ce01.knu.ac.kr            2          0          0
+
  executable              = sleep.sh
  cms02.knu.ac.kr cms02.knu.ac.kr        211      1134          0
+
log                    = sleep.log
   
+
  output                  = outfile.txt
                TotalRunningJobs      TotalIdleJobs      TotalHeldJobs
+
  error                  = errors.txt
   
+
  should_transfer_files  = Yes
   
+
  when_to_transfer_output = ON_EXIT
          Total              213              1134                  0
+
  queue
  
=== Job submit ===
+
* job submit
Job submit을 위해서는 다음과 같이 "condor_submit" 명령어를 사용합니다.
+
  
  condor_submit test.jdl
+
  condor_submit sleep.sub
  
 
=== Job 상태 확인 ===  
 
=== Job 상태 확인 ===  
 +
 +
====condor_q ====
 
작업의 상태 확인을 위해서는 "condor_q"명령을 사용합니다.<br>
 
작업의 상태 확인을 위해서는 "condor_q"명령을 사용합니다.<br>
 
전체 작업현황을 확인하려면 다음과 같이 실행하면 됩니다.
 
전체 작업현황을 확인하려면 다음과 같이 실행하면 됩니다.
Line 41: Line 45:
 
  Total for hanbi: 100 jobs; 0 completed, 0 removed, 0 idle, 100 running, 0 held, 0 suspended
 
  Total for hanbi: 100 jobs; 0 completed, 0 removed, 0 idle, 100 running, 0 held, 0 suspended
 
  Total for all users: 100 jobs; 0 completed, 0 removed, 0 idle, 100 running, 0 held, 0 suspended
 
  Total for all users: 100 jobs; 0 completed, 0 removed, 0 idle, 100 running, 0 held, 0 suspended
 +
 +
작업이 실행되지 않는다면 다음 명령으로 원인을 확인할 수 있습니다.
 +
$ condor_q -analyze 51.0
 +
 +
$ condor_q -better-analyze 51.0
 +
 +
==== condor_wait ====
 +
condor_wait 는 사용자의 로그 파일을 모니터링하고, 작업의 진행 상태에 대한 정보를 추출합니다. 이 명령어는 특히 작업이 완료될 때까지 대기하며, 로그 파일을 통해 작업의 상태 변경을 추적할 수 있습니다.
 +
$ condor_wait -status job_121945.log
 +
121945.0.0 submitted
 +
...
 +
121945.1.0 executing on host <155.230.21.74:9618?addrs=155.230.21.74-9618+[2407-c000-c024-0-e2cb-4eff-fe53ced7]-9618&alias=cluster27
 +
4.knu.ac.kr&noUDP&sock=startd_2946_4a18>
 +
...
 +
121945.1.0 completed
 +
...
 +
 +
====condor_tail ====
 +
condor_tail은 HTCondor 시스템에서 실행 중인 작업의 표준 출력(standard output)과 표준 오류(standard error)를 실시간으로 확인할 수 있습니다. <br>
 +
-f 옵션은 tail -f 와 동일한 기능을 제공합니다.
 +
-stderr 옵션은 작업의 표준 오류 출력을 보여줍니다.
 +
$ condor_tail -f 121946.0
 +
Thinking really hard for 180 seconds...
 +
We calculated: 200
 +
 +
====condor_ssh_to_job ====
 +
condor_ssh_to_job을 사용하면 사용자가 실행 중인 작업의 노드로 SSH(보안 셸) 접속을 할 수 있으며, 작업 디렉토리에 직접 접근하여 현재 작업이 어떻게 진행되고 있는지 확인할 수 있습니다.
 +
$ condor_ssh_to_job 121946.0
 +
Welcome to slot1_1@cluster242.knu.ac.kr!
 +
Your condor job is running with pid(s) 21165.
 +
$ ls -al
 +
total 44
 +
drwx------  5 user001  cms    187 Mar 11 14:31 .
 +
drwxr-xr-x. 10 condor root    141 Mar 11 14:02 ..
 +
-rwx------  1 user001  cms      48 Mar 11 14:02 .chirp.config
 +
drwxr-xr-x  2 user001  cms    128 Mar 11 14:03 .condor_ssh_to_job_1
 +
-rw-r--r--  1 user001  cms      0 Mar 11 14:02 _condor_stderr
 +
-rw-r--r--  1 user001  cms      59 Mar 11 14:05 _condor_stdout
 +
-rw-r--r--  1 condor condor 4165 Mar 11 14:02 .job.ad
 +
-rw-r--r--  1 condor condor 6111 Mar 11 14:02 .machine.ad
 +
-rwxr-xr-x  1 user001  cms    8512 Mar 11 14:02 test
 +
drwx------  2 user001  cms      6 Mar 11 14:02 tmp
 +
-rw-r--r--  1 user001  cms    6157 Mar 11 14:31 .update.ad
 +
drwx------  3 user001  cms      17 Mar 11 14:02 var
 +
 +
====condor_history ====
 +
종료된 작업을 조회하려면 condor_history 명령을 사용합니다.
 +
$ condor_history -const 'Owner == "user001" && JobStatus ==4' -limit 5
 +
  ID    OWNER          SUBMITTED  RUN_TIME    ST COMPLETED  CMD
 +
121946.9 user001          3/11 14:02  0+00:03:01 C  3/11 14:06 /u/user/user001/condor/test 180 100
 +
121946.8 user001          3/11 14:02  0+00:03:01 C  3/11 14:05 /u/user/user001/condor/test 180 100
 +
121946.6 user001          3/11 14:02  0+00:03:01 C  3/11 14:05 /u/user/user001/condor/test 180 100
 +
121946.7 user001          3/11 14:02  0+00:03:01 C  3/11 14:05 /u/user/user001/condor/test 180 100
 +
121946.5 user001          3/11 14:02  0+00:03:01 C  3/11 14:05 /u/user/user001/condor/test 180 100
 +
 +
특정 작업을 조회하려면 -l 옵션을 사용합니다.
 +
$ condor_history -l  121946.9
  
 
=== Job 삭제 ===
 
=== Job 삭제 ===
Line 50: Line 111:
 
  condor_rm <UserID>
 
  condor_rm <UserID>
  
 +
=== 작업 명세 파일 예제 ===
  
=== Singularity를 이용하여 Scientific Linux 6 코드 실행  ===
+
* 단독 실행
 +
 
 +
$ science.exe infile-A.txt infile-B.txt outfile.txt
 +
 
 +
* science1.sub - 1개 작업 실행
 +
 
 +
# science1.sub -- run one instance of science.exe
 +
executable              = science.exe
 +
arguments              = "infile-A.txt infile-B.txt outfile.txt"
 +
transfer_input_files    = infile-A.txt,infile-B.txt
 +
should_transfer_files  = IF_NEEDED
 +
when_to_transfer_output = ON_EXIT
 +
log                    = science1.log
 +
queue
 +
 
 +
* science2.sub - 40개 작업 실행, Process 번호로 input, output 파일 구분
 +
 
 +
# science2.sub -- run 40 instances of science.exe
 +
executable              = science.exe
 +
arguments              = "infile-$(Process)A.txt infile-$(Process)B.txt outfile$(Process).txt"
 +
transfer_input_files    = infile-$(Process)A.txt,infile-$(Process)B.txt
 +
should_transfer_files  = IF_NEEDED
 +
when_to_transfer_output = ON_EXIT
 +
log                    = science2.log
 +
queue 40
 +
 
 +
* science3.sub  - 100개 실행 예제. Process 번호로 작업 디렉토리 구분
 +
 
 +
# science3.sub -- run 100 instances of science.exe, with
 +
#  unique directories named by the $(Process) macro
 +
executable              = science.exe
 +
arguments              = "infile-A.txt infile-B.txt outfile.txt"
 +
should_transfer_files  = IF_NEEDED
 +
when_to_transfer_output = ON_EXIT
 +
initialdir              = run$(Process)
 +
transfer_input_files    = infile-A.txt,infile-B.txt
 +
log                    = science3.log
 +
queue 100
 +
 
 +
* geant4 실행 예제
 +
 
 +
$ cat run_geant4.sh
 +
#!/bin/bash
 +
 +
source /cvmfs/sft.cern.ch/lcg/contrib/gcc/8.3.0/x86_64-centos7/setup.sh
 +
source /cvmfs/geant4.cern.ch/geant4/10.6/x86_64-centos7-gcc8-optdeb/CMake-setup.sh
 +
./$*
 +
 
 +
$ cat geant4.sub
 +
Universe = vanilla
 +
Log        = geant4_$(ClusterId).log
 +
Output    = geant4_$(ClusterId)_$(ProcId).out
 +
Error      = geant4_$(ClusterId)_$(ProcId).err
 +
Should_Transfer_Files = Yes
 +
When_To_Transfer_Output = ON_EXIT
 +
 +
#Executable = <wrapper_script>.sh
 +
Executable = run_geant4.sh
 +
Transfer_Executable = True
 +
#Arguments = <Geant4 executable> <input file(s)>
 +
Arguments = exampleB1 exampleB1.in
 +
#Transfer_Input_Files = <Geant4 executable>,<input file(s)>
 +
Transfer_Input_Files = exampleB1, exampleB1.in
 +
 +
Queue
 +
 
 +
[[SFT#Geant4_10.6_.26_gcc83_.26_centos7| 위의 예제를 위한 geant4 설치 및 테스트는 여기를 클릭하세요.]]
 +
 
 +
=== Submitting Multiple Jobs with HTCondor ===
 +
 
 +
복수의 input 파일을 이용하여 동시에 다수의 작업을 처리하고 싶다면
 +
[https://indico.cern.ch/event/611296/contributions/2604376/attachments/1471164/2276521/TannenbaumT_UserTutorial.pdf AN INTRODUCTION TO USING HTCONDOR(Todd Tannenbaum)] 에서 52p에서부터 72p의 내용을 참고하시기 바랍니다
 +
 
 +
=== <u>Apptainer(Singularity)를 이용하여 코드 실행</u>  ===
 +
 
 +
==== el6(Scientific Linux 6) 코드 실행  ====
 
submit description file에 아래 내용을 추가합니다.
 
submit description file에 아래 내용을 추가합니다.
 
   
 
   
Line 58: Line 195:
 
혹은 선호하는 이미지가 있다면 아래와 같이 기입합니다.
 
혹은 선호하는 이미지가 있다면 아래와 같이 기입합니다.
  
  +SingularityImage = "/cvmfs/singularity.opensciencegrid.org/cmssw/cms:rhel6-m202001
+
  +SingularityImage = "/cvmfs/singularity.opensciencegrid.org/cmssw/cms:rhel6-m202001"
 +
 
 +
==== <u>el7(CentOS Linux 7) 코드 실행</u>  ====
 +
submit description file에 아래 내용을 추가합니다.
 +
 +
Universe  = vanilla
 +
...
 +
+SingularityImage = "/cvmfs/singularity.opensciencegrid.org/opensciencegrid/osgvo-el7:latest"
 +
...
 +
 
 +
====  <u>el8(Rocky Linux 8) 코드 실행</u>  ====
 +
submit description file에 아래 내용을 추가합니다.
 +
 +
Universe  = vanilla
 +
...
 +
+SingularityImage = "/cvmfs/singularity.opensciencegrid.org/opensciencegrid/osgvo-el8:latest"
 +
...
 +
 
 +
==== <u>el9(Rocky Linux 9) 코드 실행</u>  ====
 +
submit description file에 아래 내용을 추가합니다.
 +
 +
Universe  = vanilla
 +
...
 +
+SingularityImage = "/cvmfs/singularity.opensciencegrid.org/opensciencegrid/osgvo-el9:latest"
 +
...
  
 
=== create-batch 사용 ===
 
=== create-batch 사용 ===
Line 66: Line 227:
  
 
* [[Create-batch|create-batch 사용법으로 가기]]
 
* [[Create-batch|create-batch 사용법으로 가기]]
 +
 +
=== 전체 작업 현황 살펴보기 ===
 +
 +
$ condor_status -schedd
 +
Name            Machine        RunningJobs  IdleJobs  HeldJobs
 +
 +
ce01.knu.ac.kr  ce01.knu.ac.kr            2          0          0
 +
cms02.knu.ac.kr cms02.knu.ac.kr        211      1134          0
 +
 +
                TotalRunningJobs      TotalIdleJobs      TotalHeldJobs
 +
 +
 +
          Total              213              1134                  0
 +
 +
=== HTCondor에서 GPU 사용 ===
 +
 +
* [[HTCondor에서_GPU_사용하기]]
 +
 +
=== request_memory 관련 ===
 +
 +
* dynamic slot에서는 request_memory 메모리를 어떻게 지정하냐에 따라서 연산노드에서 들어갈 수 있는 작업의 수가 변화합니다.
 +
* 가령 CPU 8core, 메모리 16GB를 가지고 있는 연산노드가 있다고 가정했을 때 request_memory 가 2GB일때는 8개가 8GB일때는 2개의 작업이 할당됩니다.
 +
* 따라서 적절한 request_memory를 설정해야 작업 slot의 낭비를 줄이고 자신과 타인의 작업이 빠르게 실행됩니다. 위의 예의 경우 4배의 차이가 나게 됩니다.
 +
* htcondor에서 request_memory의 자동 수정
 +
** 작업 실행후 1시간 뒤를 기준으로 request_memory 가 작업의 실사용메모리보다 2GB이상 많이 설정되어 있는 경우 자동으로 해당 작업은 hold 되고 request_memory가 수정후 재실행됩니다.
 +
** request_memory 보다 실사용하는 메모리가 많아 hold 된 작업은 htcondor가 request_memory를 자동으로 증가시킨 후 재실행됩니다.
 +
 +
=== x509 proxy 사용 ===
 +
 +
htcondor 에서 그리드 인증이 필요한 경우
 +
 +
* X509_USER_PROXY를 설정하여 proxy 파일의 위치를 다음과 같이 연산노드에서 접근 가능한 위치로 변경해야합니다.
 +
export X509_USER_PROXY=/u/user/(userid)/proxy.cert
 +
 +
* voms-proxy-info 명령을 이용해서 proxy가 올바른 위치에 생성되었는지 반드시 확인하세요.
 +
 +
* 자세한 내용은 다음 링크를 참고하시기 바랍니다.
 +
https://batchdocs.web.cern.ch/tutorial/exercise2e_proxy.html
 +
 +
=== 최대 작업시간 ===
 +
 +
{| style="background:#cccc99;color:#black;white:80%;" border="1" cellpadding="5" cellspacing="0"
 +
!  작업 구분  !! 최대 작업시간
 +
|- style="background:white; color:black"
 +
! CPU 작업
 +
| 80 시간
 +
|- style="background:white; color:black"
 +
! GPU 작업
 +
| 14일
 +
|}
 +
 +
* 최대 작업시간은 연산노드에서 작업이 실행되는 최대 시간입니다. 최대 작업시간을 초과하면 작업이 강제로 중지됩니다.
 +
* 자원의 효율적 사용을 위해서 가급적 작업을 나누어 제출하는 것을 권장합니다.
 +
* 최대 작업시간과 관련하여 문의사항이 있으면 관리자에게 메일주시기 바랍니다.
  
 
=== 주의사항 ===
 
=== 주의사항 ===
  
* 메모리 부족으로 인해서 작업이 kill 되는 경우
+
* 작업이 실행 중에 죽는 경우
 +
 
 +
작업 제출시 명시한 메모리보다 작업이 더 많은 메모리를 사용할 경우 메모리 부족으로 작업이 죽는 경우가 발생할 수 있습니다. <br>
 +
다음과 같이 requset_memory 옵션으로 요구 메모리를 지정해주시기 바랍니다. 특히 많은 메모리를 사용하는 작업이라면 반드시 지정해 주어야합니다.
 +
request_memory = 4 GB
 +
 
 +
* submit 한 작업도 속성을 다음과 같이 변경할 수 있습니다.
 +
 
 +
$ condor_hold {job_id}
 +
$ condor_qedit {job_id} RequestMemory 4096
 +
$ condor_release {job_id}
  
Dynamic slot으로 인해서 기본 설정에서는 메모리 부족으로 작업이 죽는 경우가 발생할 수 있습니다. 다음과 같이 requset_memory 옵션으로 요구 메모리를 지정해주시기 바랍니다.
+
* 최근에는 작업의 메모리 사용량은 자동으로 관리되고 있습니다. 메모리 초과 사용 혹은 과다 사용시 시스템에서 중지 후 다시 제출됩니다.
requset_memory = 2 GB
+
  
 
=== 참고 자료  ===
 
=== 참고 자료  ===
  
* [https://research.cs.wisc.edu/htcondor/manual/quickstart.html HTCondor Quick Start Guide]
+
* [https://research.cs.wisc.edu/htcondor/manual/quickstart.html HTCondor Quick Start Guide] 위의 예제를 작성할때 참고한 자료로 처음에 시작하는 사용자가 참고하기 좋습니다.
* [https://indico.cern.ch/event/611296/contributions/2604376/attachments/1471164/2276521/TannenbaumT_UserTutorial.pdf AN INTRODUCTION TO USING HTCONDOR(Todd Tannenbaum)]
+
* [https://indico.cern.ch/event/611296/contributions/2604376/attachments/1471164/2276521/TannenbaumT_UserTutorial.pdf AN INTRODUCTION TO USING HTCONDOR(Todd Tannenbaum)] HTCondor의 동작에 대한 기본적인 이해와 다양한 기능들을 살펴보기 좋은 자료입니다.
 +
* [https://indico.cern.ch/event/733513/contributions/3118598/attachments/1711374/2759120/EUCW18-DAGMan.pdf AN INTRODUCTION TO WORKFLOWS WITH DAGMAN] DAGMAN 사용방법을 학습하기 좋은 자료입니다.

Latest revision as of 06:35, 8 July 2024

HTCondor Batch System 사용법

Tier-3 HTCondor/CentOS7 UI 접속하기

다음과 같이 터미널을 열어서 원격로그인(SSH)으로 접속합니다.

 ssh -X username@cms.knu.ac.kr

Job submit

Job submit을 위해서는 다음과 같이 "condor_submit" 명령어를 사용합니다.

  • sleep.sh - 테스트 코드
#!/bin/bash

TIMETOWAIT="10"
echo "sleeping for $TIMETOWAIT seconds"
/bin/sleep $TIMETOWAIT
  • sleep.sub - 작업 명세 파일
executable              = sleep.sh
log                     = sleep.log
output                  = outfile.txt
error                   = errors.txt
should_transfer_files   = Yes
when_to_transfer_output = ON_EXIT
queue
  • job submit
condor_submit sleep.sub

Job 상태 확인

condor_q

작업의 상태 확인을 위해서는 "condor_q"명령을 사용합니다.
전체 작업현황을 확인하려면 다음과 같이 실행하면 됩니다.

$ condor_q
-- Schedd: cms02.knu.ac.kr : <155.230.23.72:9618?... @ 07/30/20 16:49:47
OWNER BATCH_NAME    SUBMITTED   DONE   RUN    IDLE  TOTAL JOB_IDS
user001 ID: 51       7/30 16:47      _    100      _    100 51.0-99

Total for query: 100 jobs; 0 completed, 0 removed, 0 idle, 100 running, 0 held, 0 suspended
Total for hanbi: 100 jobs; 0 completed, 0 removed, 0 idle, 100 running, 0 held, 0 suspended
Total for all users: 100 jobs; 0 completed, 0 removed, 0 idle, 100 running, 0 held, 0 suspended

작업이 실행되지 않는다면 다음 명령으로 원인을 확인할 수 있습니다.

$ condor_q -analyze 51.0
$ condor_q -better-analyze 51.0

condor_wait

condor_wait 는 사용자의 로그 파일을 모니터링하고, 작업의 진행 상태에 대한 정보를 추출합니다. 이 명령어는 특히 작업이 완료될 때까지 대기하며, 로그 파일을 통해 작업의 상태 변경을 추적할 수 있습니다.

$ condor_wait -status job_121945.log
121945.0.0 submitted
...
121945.1.0 executing on host <155.230.21.74:9618?addrs=155.230.21.74-9618+[2407-c000-c024-0-e2cb-4eff-fe53ced7]-9618&alias=cluster27
4.knu.ac.kr&noUDP&sock=startd_2946_4a18>
...
121945.1.0 completed
...

condor_tail

condor_tail은 HTCondor 시스템에서 실행 중인 작업의 표준 출력(standard output)과 표준 오류(standard error)를 실시간으로 확인할 수 있습니다.
-f 옵션은 tail -f 와 동일한 기능을 제공합니다. -stderr 옵션은 작업의 표준 오류 출력을 보여줍니다.

$ condor_tail -f 121946.0
Thinking really hard for 180 seconds...
We calculated: 200

condor_ssh_to_job

condor_ssh_to_job을 사용하면 사용자가 실행 중인 작업의 노드로 SSH(보안 셸) 접속을 할 수 있으며, 작업 디렉토리에 직접 접근하여 현재 작업이 어떻게 진행되고 있는지 확인할 수 있습니다.

$ condor_ssh_to_job 121946.0
Welcome to slot1_1@cluster242.knu.ac.kr!
Your condor job is running with pid(s) 21165.
$ ls -al
total 44
drwx------   5 user001  cms     187 Mar 11 14:31 .
drwxr-xr-x. 10 condor root    141 Mar 11 14:02 ..
-rwx------   1 user001  cms      48 Mar 11 14:02 .chirp.config
drwxr-xr-x   2 user001  cms     128 Mar 11 14:03 .condor_ssh_to_job_1
-rw-r--r--   1 user001  cms       0 Mar 11 14:02 _condor_stderr
-rw-r--r--   1 user001  cms      59 Mar 11 14:05 _condor_stdout
-rw-r--r--   1 condor condor 4165 Mar 11 14:02 .job.ad
-rw-r--r--   1 condor condor 6111 Mar 11 14:02 .machine.ad
-rwxr-xr-x   1 user001  cms    8512 Mar 11 14:02 test
drwx------   2 user001  cms       6 Mar 11 14:02 tmp
-rw-r--r--   1 user001  cms    6157 Mar 11 14:31 .update.ad
drwx------   3 user001  cms      17 Mar 11 14:02 var

condor_history

종료된 작업을 조회하려면 condor_history 명령을 사용합니다.

$ condor_history -const 'Owner == "user001" && JobStatus ==4' -limit 5
 ID     OWNER          SUBMITTED   RUN_TIME     ST COMPLETED   CMD
121946.9 user001           3/11 14:02   0+00:03:01 C   3/11 14:06 /u/user/user001/condor/test 180 100
121946.8 user001           3/11 14:02   0+00:03:01 C   3/11 14:05 /u/user/user001/condor/test 180 100
121946.6 user001           3/11 14:02   0+00:03:01 C   3/11 14:05 /u/user/user001/condor/test 180 100
121946.7 user001           3/11 14:02   0+00:03:01 C   3/11 14:05 /u/user/user001/condor/test 180 100
121946.5 user001           3/11 14:02   0+00:03:01 C   3/11 14:05 /u/user/user001/condor/test 180 100

특정 작업을 조회하려면 -l 옵션을 사용합니다.

$ condor_history -l  121946.9

Job 삭제

submit 한 작업을 중간에 취소하기 위해서는 "condor_rm" 명령을 사용합니다.

condor_rm <JOBID>

모든 내 작업을 삭제하려면 다음 명령을 사용합니다.

condor_rm <UserID>

작업 명세 파일 예제

  • 단독 실행
$ science.exe infile-A.txt infile-B.txt outfile.txt
  • science1.sub - 1개 작업 실행
# science1.sub -- run one instance of science.exe
executable              = science.exe
arguments               = "infile-A.txt infile-B.txt outfile.txt"
transfer_input_files    = infile-A.txt,infile-B.txt
should_transfer_files   = IF_NEEDED
when_to_transfer_output = ON_EXIT
log                     = science1.log
queue
  • science2.sub - 40개 작업 실행, Process 번호로 input, output 파일 구분
# science2.sub -- run 40 instances of science.exe
executable              = science.exe
arguments               = "infile-$(Process)A.txt infile-$(Process)B.txt outfile$(Process).txt"
transfer_input_files    = infile-$(Process)A.txt,infile-$(Process)B.txt
should_transfer_files   = IF_NEEDED
when_to_transfer_output = ON_EXIT
log                     = science2.log
queue 40
  • science3.sub - 100개 실행 예제. Process 번호로 작업 디렉토리 구분
# science3.sub -- run 100 instances of science.exe, with
#  unique directories named by the $(Process) macro
executable              = science.exe
arguments               = "infile-A.txt infile-B.txt outfile.txt"
should_transfer_files   = IF_NEEDED
when_to_transfer_output = ON_EXIT
initialdir              = run$(Process)
transfer_input_files    = infile-A.txt,infile-B.txt
log                     = science3.log
queue 100
  • geant4 실행 예제
$ cat run_geant4.sh
#!/bin/bash

source /cvmfs/sft.cern.ch/lcg/contrib/gcc/8.3.0/x86_64-centos7/setup.sh
source /cvmfs/geant4.cern.ch/geant4/10.6/x86_64-centos7-gcc8-optdeb/CMake-setup.sh
./$*
$ cat geant4.sub
Universe = vanilla
Log        = geant4_$(ClusterId).log
Output     = geant4_$(ClusterId)_$(ProcId).out
Error      = geant4_$(ClusterId)_$(ProcId).err
Should_Transfer_Files = Yes
When_To_Transfer_Output = ON_EXIT

#Executable = <wrapper_script>.sh
Executable = run_geant4.sh
Transfer_Executable = True
#Arguments = <Geant4 executable> <input file(s)>
Arguments = exampleB1 exampleB1.in
#Transfer_Input_Files = <Geant4 executable>,<input file(s)>
Transfer_Input_Files = exampleB1, exampleB1.in

Queue

위의 예제를 위한 geant4 설치 및 테스트는 여기를 클릭하세요.

Submitting Multiple Jobs with HTCondor

복수의 input 파일을 이용하여 동시에 다수의 작업을 처리하고 싶다면 AN INTRODUCTION TO USING HTCONDOR(Todd Tannenbaum) 에서 52p에서부터 72p의 내용을 참고하시기 바랍니다

Apptainer(Singularity)를 이용하여 코드 실행

el6(Scientific Linux 6) 코드 실행

submit description file에 아래 내용을 추가합니다.

+ContainerOS = "SL6"

혹은 선호하는 이미지가 있다면 아래와 같이 기입합니다.

+SingularityImage = "/cvmfs/singularity.opensciencegrid.org/cmssw/cms:rhel6-m202001"

el7(CentOS Linux 7) 코드 실행

submit description file에 아래 내용을 추가합니다.

Universe   = vanilla
...
+SingularityImage = "/cvmfs/singularity.opensciencegrid.org/opensciencegrid/osgvo-el7:latest"
...

el8(Rocky Linux 8) 코드 실행

submit description file에 아래 내용을 추가합니다.

Universe   = vanilla
...
+SingularityImage = "/cvmfs/singularity.opensciencegrid.org/opensciencegrid/osgvo-el8:latest"
...

el9(Rocky Linux 9) 코드 실행

submit description file에 아래 내용을 추가합니다.

Universe   = vanilla
...
+SingularityImage = "/cvmfs/singularity.opensciencegrid.org/opensciencegrid/osgvo-el9:latest"
...

create-batch 사용

create-batch를 경북대 부분을 condor로 변경하여 create-batch2라는 이름으로 저장해두었습니다. condor에서는 --queue cms 옵션은 필요하지 않습니다.
torque system을 당분간 운영하는 기간동안 임시로 이렇게 사용하고 condor로 완전히 전환이 되면 create-batch에 수정사항을 반영요청하겠습니다.

전체 작업 현황 살펴보기

$ condor_status -schedd
Name            Machine         RunningJobs   IdleJobs   HeldJobs

ce01.knu.ac.kr  ce01.knu.ac.kr            2          0          0
cms02.knu.ac.kr cms02.knu.ac.kr         211       1134          0

                TotalRunningJobs      TotalIdleJobs      TotalHeldJobs


         Total               213               1134                  0

HTCondor에서 GPU 사용

request_memory 관련

  • dynamic slot에서는 request_memory 메모리를 어떻게 지정하냐에 따라서 연산노드에서 들어갈 수 있는 작업의 수가 변화합니다.
  • 가령 CPU 8core, 메모리 16GB를 가지고 있는 연산노드가 있다고 가정했을 때 request_memory 가 2GB일때는 8개가 8GB일때는 2개의 작업이 할당됩니다.
  • 따라서 적절한 request_memory를 설정해야 작업 slot의 낭비를 줄이고 자신과 타인의 작업이 빠르게 실행됩니다. 위의 예의 경우 4배의 차이가 나게 됩니다.
  • htcondor에서 request_memory의 자동 수정
    • 작업 실행후 1시간 뒤를 기준으로 request_memory 가 작업의 실사용메모리보다 2GB이상 많이 설정되어 있는 경우 자동으로 해당 작업은 hold 되고 request_memory가 수정후 재실행됩니다.
    • request_memory 보다 실사용하는 메모리가 많아 hold 된 작업은 htcondor가 request_memory를 자동으로 증가시킨 후 재실행됩니다.

x509 proxy 사용

htcondor 에서 그리드 인증이 필요한 경우

  • X509_USER_PROXY를 설정하여 proxy 파일의 위치를 다음과 같이 연산노드에서 접근 가능한 위치로 변경해야합니다.
export X509_USER_PROXY=/u/user/(userid)/proxy.cert
  • voms-proxy-info 명령을 이용해서 proxy가 올바른 위치에 생성되었는지 반드시 확인하세요.
  • 자세한 내용은 다음 링크를 참고하시기 바랍니다.

https://batchdocs.web.cern.ch/tutorial/exercise2e_proxy.html

최대 작업시간

작업 구분 최대 작업시간
CPU 작업 80 시간
GPU 작업 14일
  • 최대 작업시간은 연산노드에서 작업이 실행되는 최대 시간입니다. 최대 작업시간을 초과하면 작업이 강제로 중지됩니다.
  • 자원의 효율적 사용을 위해서 가급적 작업을 나누어 제출하는 것을 권장합니다.
  • 최대 작업시간과 관련하여 문의사항이 있으면 관리자에게 메일주시기 바랍니다.

주의사항

  • 작업이 실행 중에 죽는 경우

작업 제출시 명시한 메모리보다 작업이 더 많은 메모리를 사용할 경우 메모리 부족으로 작업이 죽는 경우가 발생할 수 있습니다.
다음과 같이 requset_memory 옵션으로 요구 메모리를 지정해주시기 바랍니다. 특히 많은 메모리를 사용하는 작업이라면 반드시 지정해 주어야합니다.

request_memory = 4 GB
  • submit 한 작업도 속성을 다음과 같이 변경할 수 있습니다.
$ condor_hold {job_id}
$ condor_qedit {job_id} RequestMemory 4096
$ condor_release {job_id}
  • 최근에는 작업의 메모리 사용량은 자동으로 관리되고 있습니다. 메모리 초과 사용 혹은 과다 사용시 시스템에서 중지 후 다시 제출됩니다.

참고 자료