Hodor and Bran - Job Scheduling and PBS Scripts

Transcription

1 Hodor and Bran - Job Scheduling and PBS Scripts UND Computational Research Center Now that you have your program compiled and your input file ready for processing, it s time to run your job on the cluster. However, running a parallel program on the cluster isn t as simple as running a serial program. Novice users sometime have the misconception that the cluster is a single large computer. That is not the case. The cluster is a cluster of multiple computers (aka nodes), where there is a head node and multiple compute nodes. Job Scheduler When a user first logs into Hodor using the SSH process described in the Hodor and Bran - Cluster Account Basics tutorial, the user is actually logging into the cluster head node. The head node is where you write and compile your programs. It is also the node that schedules computation runs (aka jobs ) on the compute nodes. The software that manages the schedule of the programs to run is known as a Job Scheduler. Why is a job scheduler necessary? Without a job scheduler, users would randomly assign their programs to run on compute nodes. This type of behavior leads to crashed programs and slow runtimes, as one user s program would compete for compute node RAM and processor time of a compute node with another user s program. For instance, maybe your program needs 64GB of RAM, and another user s program also needs to use 64GB of RAM. Without a job scheduler, your program and the other user s program might end up running on the same compute node that only has 64GB of RAM available for use. If both programs try to use all the RAM, something is going to fail: either your program, his/her program, or the node itself. As such, when running your research code on the cluster it is always important that you use the job scheduler to run your job. Also, you should never run your research code directly from the command line on the head node. Therefore we have a few basic rules that we require users follow, which are listed below. Should a user violate these rules, the CRC reserves the right to ban the user from using cluster resources in cases of repeated or severe rules violations: Cluster Rules: 1. Do not run your research computational program on the head node. The head node is for writing code, editing/transferring files, and compiling programs. 2. Use the job scheduler to run your program on the compute nodes. 3. Do not use programs that you don t have a license to use. 4. Do not flood the cluster with jobs without first notifying the CRC. If you need to submit 1000 s of jobs at a time, please notify the CRC before submitting that many jobs. 5. Follow directions given by the CRC. 6. Be courteous to other users. The cluster a shared resource. Job may need to wait in the queue. 7. Don t give access to your account login/password to others rd party accounts must be approved by the CRC. (aka other universities, private organizations) 1

2 QSUB and PBS Scripts The job scheduler uses the qsub command and PBS scripts to launch a job. A user would type something similar to the following on the command line to submit a job where example.pbs is a PBS script written by the user: qsub example.pbs A PBS script, is simply a text file. Edit it with your text editor of choice and upload it to the cluster, or use VI/VIM to edit it after logging into the head node. Directions on how to use VIM can be found here: OpenMP Programs: Below are the contents of our example.pbs file. It assumes that you are attempting to run an OpenMP program called nbody.x. The line numbers are not part of the file, and have been added for purposes of discussion. 1 #PBS -S /bin/bash 2 #PBS -l nodes=1:ppn=8,walltime=10:00:00,naccesspolicy=singlejob 3 #PBS N mynbody 4 #PBS M john.doe@my.und.edu 5 #PBS m bea 6 #PBS o /${PBS_O_WORKDIR}/out_${PBS_JOBNAME}.txt 7 #PBS e /${PBS_O_WORKDIR}/err_${PBS_JOBNAME}.txt 8 #PBS V 9 10 #Set the environment variable that tells your openmp program 11 #how many threads to use. 12 export OMP_NUM_THREADS=`wc l < ${PBS_NODESFILE}` #Change directory to the current working directory 15 cd ${PBS_O_WORKDIR} /nbody.x inp inputfile.inp Essentially, the PBS script is a shell script, however its file permissions need only be read/write, and it does not need to be executable. For users who are familiar with shell scripts, you might think lines that begin with #PBS are code comments, but this is incorrect. Any line that begins with #PBS, that line is PBS instruction for qsub. A complete list of #PBS can be found here: Let s discuss example.pbs line by line. LINE 1: #PBS S /bin/bash PBS command that sets non-pbs commands to be interpreted as BASH shell commands. Bash and CSH are available on the cluster. 2

3 LINE 2: #PBS l nodes=1:ppn=8,walltime=10:00:00,naccesspolicy=singlejob The pbs command -l that sets the resource request. In other words, it tells the scheduler that it wants: One node (nodes=1) Eight processes per node (:ppn=8) Use of the requested resources for 10 hours (,walltime=10:00:00) where walltime=hh:mm:ss Exclusive use of this node (,naccesspolicy=singlejob). This means that only a single job will have access to this node while this job is running. Each compute node in the cluster has two 3.3GHz quad-core processors. As such, the maximum number that ppn= can be set to is 2x4 in other words, a value of 8. Notice that each variable on line 2 is separated by a comma and no spaces. These aren t the only variables that can be set by the #PBS l command, but most users will only need to the above variables. For a list of more #PBS l variables, see the following web page: LINE 3: #PBS N mynbody The pbs command that sets the name of the job to mynbody. This flag is not required. If not included, the job scheduler will make the job name the same as the job ID number. However, if you want to control the job s name, you should set it yourself. In some cases, it may be more convenient to the user to leave this command out of the PBS script, and instead, set the job name in the following manner: qsub N mynbody example.pbs LINE 4: #PBS M jane.doe@my.und.edu The pbs command that sets the list of addresses that should be sent a message once a mail_option has been triggered. To add more addresses, separate each address by a comma and no spaces. LINE 5: #PBS m bea The pbs command that sets the list of mail_options for this job. Options are: b when the job begins, e when the job ends, a when the job aborts. LINES 6 & 7: #PBS o /${PBS_O_WORKDIR}/out_${PBS_JOBNAME}.txt #PBS e /${PBS_O_WORKDIR}/err_${PBS_JOBNAME}.txt The pbs commands that set the files two which the program s standard out (#PBS o) and standard error (#PBS e) are dumped. The environment variable PBS_O_WORKDIR, is directory path for the current directory when qsub is executed by the user. So if my current directory is: /home/john.doe and my job name is mynbody, then standard out and standard error will be dumped to the following files: 3

4 /home/john.doe/out_mynbody.txt /home/john.doe/err_mynbody.txt Notice in lines 6 & 7 that ${PBS_O_WORKDIR} is proceeded by a forward slash /, but in the BASH shell commands of PBS script it is not. When setting o or e it the forward slash is required due to a bug in the scheduling sosftware. An alternative means of setting the stdout and stderr files is to have them dumped to a single file. This is done using the following PBS commands: #PBS j oe #PBS o /${PBS_O_WORKDIR}/out_${PBS_JOBNAME}.txt LINE 8: #PBS V The pbs command that has all the user s environment variables sent to all the nodes. May or may not be necessary. Ultimately, it s up to the user to determine whether or not this is necessary. ==================== At this point, the rest of the commands in the PBS script are Bash shell commands and a call to run your program. The PBS_NODESFILE environment variable holds the full path to a temporary file that contains a list of the hostnames for every node that your job will use. Since ppn=8, each node s hostname will be listed 8 times, each time on its own line. The BASH commands and your executable will only be executed once on the first node listed in the PBS_NODESFILE temporary file. ==================== LINES 9: blank LINES 10-11: code comments LINE 12 export OMP_NUM_THREADS=`wc l < ${PBS_NODESFILE}` ThIs BASH shell command sets the user s OMP_NUM_THREADS environment variable on the compute node(s) requested by the job with the number of threads required by the user s openmp program. A bit more of an explanation is required to understand what this line is doing. The BASH shell command `wc l < ${PBS_NODESFILE)` simply dumps the list of hostnames to the wc BASH program, which in turn counts the number of lines in that file, and then that count value is stored in OMP_NUM_THREADS. 4

5 LINES 13: blank LINES 14: code comment LINE 15 cd ${PBS_O_WORKDIR} This BASH shell command changes the current directory on the compute node to the path designated by PBS_O_WORKDIR. Notice a forward slash is not needed here. LINES 16: blank LINE 17./nbody.x inp inputfile.inp Here the user is simply executing his program. It assumes that the nbody.x executable is in the directory pointed to by PBS_O_WORKDIR. This ficational program takes two arguments, a flag inp (defined by the fictional program code) and inputfile.inp, which is the filename that this fictional program expects to follow the inp flag. These program arguments are specific to this fictional program. Your program will take completely different arguments as defined by your program MPI Programs: Below are the contents an alternative example.pbs file. It assumes that you are attempting to run an MVAPICH2-x MPI program called mpi_nbody.x. The line numbers are not part of the file, and have been added for purposes of discussion. 1 #PBS -S /bin/bash 2 #PBS -l nodes=2:ppn=8,walltime=10:00:00,naccesspolicy=singlejob 3 #PBS N mynbody 4 #PBS M john.doe@my.und.edu 5 #PBS m bea 6 #PBS o /${PBS_O_WORKDIR}/out_${PBS_JOBNAME}.txt 7 #PBS e /${PBS_O_WORKDIR}/err_${PBS_JOBNAME}.txt 8 #PBS V 9 10 #Set the environment variable that tells your openmp program 11 #how many threads to use. 12 NP=`wc l < ${PBS_NODESFILE}` module load mvapich2-x-runtime #Change directory to the current working directory 17 cd ${PBS_O_WORKDIR} mpirun machinefile ${PBS_NODESFILE} np ${NP}./mpi_nbody.x inp inputfile.inp module unload mvapich2-x-runtime 5

6 Essentially, the PBS script is a shell script, however its file permissions need only be read/write, and it does not need to be executable. For users who are familiar with shell scripts, you might think lines that begin with #PBS are code comments, but this is incorrect. Any line that begins with #PBS, that line is PBS instruction for qsub. A complete list of #PBS can be found here: Let s discuss example.pbs line by line. LINE 1: #PBS S /bin/bash PBS command that sets non-pbs commands to be interpreted as BASH shell commands. Bash and CSH are available on the cluster. LINE 2: #PBS l nodes=2:ppn=8,walltime=10:00:00,naccesspolicy=singlejob The pbs command -l that sets the resource request. In other words, it tells the scheduler that it wants: Two nodes (nodes=2) Eight processes per node (:ppn=8) Use of the requested resources for 10 hours (,walltime=10:00:00) where walltime=hh:mm:ss Exclusive use of this node (,naccesspolicy=singlejob). This means that only a single job will have access to this node while this job is running. Each compute node in the cluster has two 3.3GHz quad-core processors. As such, the maximum number that ppn= can be set to is 2x4 in other words, a value of 8. Notice that each variable on line 2 is separated by a comma and no spaces. These aren t the only variables that can be set by the #PBS l command, but most users will only need to the above variables. For a list of more #PBS l variables, see the following web page: LINE 3: #PBS N mynbody The pbs command that sets the name of the job to mynbody. This flag is not required. If not included, the job scheduler will make the job name the same as the job ID number. However, if you want to control the job s name, you should set it yourself. In some cases, it may be more convenient to the user to leave this command out of the PBS script, and instead, set the job name in the following manner: qsub N mynbody example.pbs LINE 4: #PBS M jane.doe@my.und.edu The pbs command that sets the list of addresses that should be sent a message once a mail_option has been triggered. To add more addresses, separate each address by a comma and no spaces. 6

7 LINE 5: #PBS m bea The pbs command that sets the list of mail_options for this job. Options are: b when the job begins, e when the job ends, a when the job aborts. LINES 6 & 7: #PBS o /${PBS_O_WORKDIR}/out_${PBS_JOBNAME}.txt #PBS e /${PBS_O_WORKDIR}/err_${PBS_JOBNAME}.txt The pbs commands that set the files two which the program s standard out (#PBS o) and standard error (#PBS e) are dumped. The environment variable PBS_O_WORKDIR, is directory path for the current directory when qsub is executed by the user. So if my current directory is: /home/john.doe and my job name is mynbody, then standard out and standard error will be dumped to the following files: /home/john.doe/out_mynbody.txt /home/john.doe/err_mynbody.txt Notice in lines 6 & 7 that ${PBS_O_WORKDIR} is proceeded by a forward slash /, but in the BASH shell commands of PBS script it is not. When setting o or e it the forward slash is required due to a bug in the scheduling sosftware. An alternative means of setting the stdout and stderr files is to have them dumped to a single file. This is done using the following PBS commands: #PBS j oe #PBS o /${PBS_O_WORKDIR}/out_${PBS_JOBNAME}.txt LINE 8: #PBS V The pbs command that has all the user s environment variables sent to all the nodes. May or may not be necessary. Ultimately, it s up to the user to determine whether or not this is necessary. ==================== At this point, the rest of the commands in the PBS script are Bash shell commands and a call to run your program. The PBS_NODESFILE environment variable holds the full path to a temporary file that contains a list of the hostnames for every node that your job will use. Since ppn=8, each node s hostname will be listed 8 times, each time on its own line. The BASH commands and your executable will only be executed once on the first node listed in the PBS_NODESFILE temporary file. ==================== 7

8 LINES 9: blank LINES 10-11: code comments LINE 12 NP=`wc l < ${PBS_NODESFILE}` ThIs BASH shell command sets at temporary environment variable for the user called NP on the first compute node listed in the PBS_NODESFILE temporary file. Unlike the OpenMP version of this PBS script, the NP environment variable is not exported. A bit more of an explanation is required to understand what this line is doing. The BASH shell command `wc l < ${PBS_NODESFILE)` simply dumps the list of hostnames to the wc BASH program, which in turn counts the number of lines in that file, and then that count value is stored in NP. LINES 13: blank LINE 14 module load mvapich2-x-runtime Loads the modulefile mvapich2-x-runtime that sets up the environment variables necessary for running an MPI program compiled using the MVAPICH2-X API. LINES 15: blank LINES 16: code comment LINE 17 cd ${PBS_O_WORKDIR} This BASH shell command changes the current directory on the compute node to the path designated by PBS_O_WORKDIR. Notice a forward slash is not needed here. LINES 18: blank LINE 19 mpirun machinefile ${PBS_NODESFILE} np ${NP}./mpi_nbody.x inp inputfile.inp Here the user is simply executing his program. It assumes that the mpi_nbody.x executable is in the directory pointed to by PBS_O_WORKDIR. There are a few things going on here. 1. It should be noted, that the PBS is actually is executing mpirun not the user s executable. 2. Also mpirun needs to know: a. which compute nodes will are used by this job. i. As such, the PBS_NODESFILE variable is passed to mpirun using the machinefile flag. ii. DO NOT use a custom machinefile here. This will seriously screw up your job run, and most probably other user s as well. iii. ALWAYS use ${PBS_NODESFILE} variable here! b. How many total MPI processes there are in this job i. this is why we pass the value of ${NP} to mpirun using the np flag. 8

9 ii. NP should equal the number of nodes times the number of ppn iii. You could replace np ${NP} with np 16 in this case, just be sure the number is correct. 3. You could also use mpiexec instead of mpirun 4. This ficational program takes two arguments: a. a flag inp (defined by the fictional program code) b. and inputfile.inp, which is the filename that this program expects to follow the flag. c. These program arguments are specific to this fictional program. Your program will take completely different arguments as defined within your code. LINES 20: blank LINE 21 module unload mvapich2-x-runtime Unloads the modulefile mvapich2-x-runtime and removes environment variables that had been previously setup by the load. Not really necessary, because the job is over at this point. It s included in this example to show that it can be done within the PBS script Embarrassingly Parallel Programs: Below are the contents of our example.pbs file. It assumes that you are attempting to run a non-communicating Embarrassingly Parallel program called renderer.x. In other words, you want to run multiple copies of a serial program that don t communicate with each other. The line numbers are not part of the file, and have been added for purposes of discussion. 1 #PBS -S /bin/bash 2 #PBS -l nodes=4:ppn=8,walltime=10:00:00,naccesspolicy=singlejob 3 #PBS N renderjob 4 #PBS M john.doe@my.und.edu 5 #PBS m bea 6 #PBS o /${PBS_O_WORKDIR}/out_${PBS_JOBNAME}.txt 7 #PBS e /${PBS_O_WORKDIR}/err_${PBS_JOBNAME}.txt 8 #PBS V 9 10 #Change directory to the current working directory 11 cd ${PBS_O_WORKDIR} pbsdsh./renderer.x inp inputfile.inp Like the other two PBS script examples, the PBS script shown immediately above is essentially a shell script. Since this script is very much like the OpenMP version, we can skip a discussion of most of this file, down to line 13. LINE 13 pbsdsh./renderer.x inp inputfile.inp 9

10 Here the user is simply wants to execute his/her serial program on all requested processes. It assumes that the renderer.x program is a serial program and is located in the directory pointed to by PBS_O_WORKDIR. In this case, the PBS script is actually executing the pbsdsh program. This PBS script requests the use of four nodes, and eight processes per node, for a total of 32 processes. As such, pbsdsh will execute the renderer.x program on all 32 processes. If the -u flag was added to this line, as so: pbsdsh u./renderer.x inp inputfile.inp then renderer.x would run only one processes per node, for a total of four processes. For more information on the use of pbsdsh see the following web page: PBS_NODENUM and PBS_TASKNUM can be used in combination with the pbsdsh program. For more information see: WARNING - If you wish to use pbsdsh be careful that your program s arguments/flags are different from flags used by pbsdsh. If they are the same, pbsdsh will assume that the flags are meant for pbsdsh, and will not pass them along to your program Other Information qstat and qdel: In addition to the command to submit jobs, you should know the commands to see which jobs are in the job queue, and how to delete a job. To see which jobs are in the queue use the qstat command. Will display all jobs queued Q and running - R qstat a Will display all jobs, plus the nodes on which they are running qstat n Will display all jobs, plus all job information for each job (a lot of information) qstat f If there are a large number of jobs in the queue, you may wish to use grep in addition to qstat such as: qstat a grep jane.doe The figure on the next page demonstrates the output generated from using qstat a 10

11 Notice the Job ID column in the figure above. Use the number in the Job ID column to cancel a running or queued job like demonstrated below: qdel Typing the above text on the command line and pressing return/enter will kill the job with Job ID Users can only kill their own jobs. WALLTIME: When invoking the #PBS l command, be sure to set your walltime variable to a value high enough to ensure your job completes its run before the walltime runs out. In other words, if you feel that your program will take 3 days to run, make sure you set your walltime to at least: 72:00:00. It would probably be wise to set the hours value a bit higher than 72 hours. Estimate too low, and your time may run out before your program completes. Estimate too high, and other jobs with a shorter walltime may jump ahead of your job in the scheduler queue. Be a courteous user and estimate appropriately. NODES: There maybe cases in which a user may wish to select specific compute nodes. Hodor Compute Nodes: node001 thru node032 Bran Compute Nodes: node001-test thru node004-test If you wish to request specific nodes, you can do so by using the following PBS commands Instead of using this: #PBS l nodes=4:ppn=8,wallti. Use this: #PBS l nodes=node002:ppn=8+node003:ppn=8+node004:ppn=8+node004:ppn=8,wallti 11

12 Of course, if you request specific nodes, your job will wait to run until every one of the nodes that you request becomes available. You might wait awhile. Final Thoughts This tutorial only scratches the surfaces of using the Hodor and Bran job scheduler. We haven t covered many things for example: GPU programs, MIC programs, combination MPI/OpenMP just to name a few. If you have any questions at all, please contact the CRC. Aaron Bergstrom HPC Specialist aaron.bergstrom@ .und.edu