techstaff:slurm
Differences
This shows you the differences between two versions of the page.
Next revision | Previous revisionNext revisionBoth sides next revision | ||
techstaff:slurm [2015/12/04 13:24] – created kauffman | techstaff:slurm [2016/01/04 16:49] – [Storage] kauffman | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== DRAFT | Peanut Job Submission Cluster | + | ====== DRAFT | Peanut Job Submission Cluster ====== |
We are currently **alpha** testing and gauging user interest in a cluster of machines that allows for the submission of long running compute jobs. Think of these machines as a dumping ground for discrete computing tasks that might have been rude or disruptive to execute on the main (shared) shell servers (i.e., linux1, linux2, linux3). | We are currently **alpha** testing and gauging user interest in a cluster of machines that allows for the submission of long running compute jobs. Think of these machines as a dumping ground for discrete computing tasks that might have been rude or disruptive to execute on the main (shared) shell servers (i.e., linux1, linux2, linux3). | ||
Line 8: | Line 8: | ||
SLURM is similar to most other queue systems in that you write a batch script, then submit it to the queue manager. The queue manager schedules your job to run on the queue (or partition in SLURM parlance) that you designate. Below is an outline of how to submit jobs to SLURM, how SLURM decides when to schedule your job, and how to monitor progress. | SLURM is similar to most other queue systems in that you write a batch script, then submit it to the queue manager. The queue manager schedules your job to run on the queue (or partition in SLURM parlance) that you designate. Below is an outline of how to submit jobs to SLURM, how SLURM decides when to schedule your job, and how to monitor progress. | ||
+ | |||
+ | ===== Where to begin ===== | ||
+ | SLURM is a set of command line utilities that can be accessed via the command line from **most** any computer science system you can login to. Using our main shell servers (linux.cs.uchicago.edu) is expected to be our most common use case, so you should start there. | ||
+ | |||
+ | ssh user@linux.cs.uchicago.edu | ||
+ | |||
===== Documentation ===== | ===== Documentation ===== | ||
Line 37: | Line 43: | ||
==== Storage ==== | ==== Storage ==== | ||
- | Available network storage info. | + | There is slow scratch space mounted to '' |
- | Mounted on / | + | * Files older than 90 days will be deleted automatically. |
+ | * Scratch space is shared by all users. | ||
+ | === Access === | ||
+ | Scratch space is only mounted on nodes associated with the cluster. If you want to be able to transfer files to the scratch space you will want to run an [[techstaff: | ||
+ | |||
+ | - You should only do a file transfer via the debug partition: '' | ||
+ | - Now you can create a directory of your own: '' | ||
+ | |||
+ | == Example == | ||
+ | |||
+ | Request interactive shell | ||
+ | < | ||
+ | |||
+ | Change into my scratch directory: | ||
+ | < | ||
+ | |||
+ | Get the files I need: | ||
+ | < | ||
+ | user@research2:/ | ||
+ | foo | ||
+ | </ | ||
+ | Check that the file now exists: | ||
+ | < | ||
+ | user@research2:/ | ||
+ | -rw------- 1 user user 105121 Dec 29 2015 foo | ||
+ | </ | ||
+ | |||
+ | I can now exit my interactive shell. | ||
+ | |||
+ | == Performance is slow == | ||
+ | This is expected. The maximum speed this server will ever be able to achieve is 1Gb/s because of its single 1G ethernet uplink. If this cluster gains in popularity we plan on upgrading the network and storage server. | ||
==== Utilization Dashboard ==== | ==== Utilization Dashboard ==== | ||
Sometimes it is useful to see how much of the cluster is utilized. You can do that via the following URL: http:// | Sometimes it is useful to see how much of the cluster is utilized. You can do that via the following URL: http:// | ||
==== Partitions / Queues ==== | ==== Partitions / Queues ==== | ||
- | As of December, 2015 we have 3 partitions in our cluster. | + | To find out what partitions we offer, checkout the [[techstaff: |
+ | |||
+ | As of December, 2015 we have will have at least 2 partitions in our cluster; ' | ||
^ Partition Name ^ Description ^ | ^ Partition Name ^ Description ^ | ||
| **debug** | The partition your job will be submitted to if none is specified. The purpose of this partition is to make sure your code is running as it should before submitting a long running job to the general queue. | | | **debug** | The partition your job will be submitted to if none is specified. The purpose of this partition is to make sure your code is running as it should before submitting a long running job to the general queue. | | ||
| **general** | All jobs that have been thoroughly tested can be submitted here. This partition will have access to more nodes and will process most of the jobs. If you need to use the '' | | **general** | All jobs that have been thoroughly tested can be submitted here. This partition will have access to more nodes and will process most of the jobs. If you need to use the '' | ||
- | | **hardware** | The purpose of this partition is to set aside nodes that do not use the virtualization layer. This is important if you need true hardware access. | | ||
Line 142: | Line 179: | ||
PARTITION AVAIL TIMELIMIT | PARTITION AVAIL TIMELIMIT | ||
debug* | debug* | ||
- | general | + | general |
- | hardware | + | |
</ | </ | ||
- | ===== Monitoring Jobs ===== | + | ====== Monitoring Jobs ====== |
'' | '' | ||
Line 158: | Line 194: | ||
- | ===== Interactive Jobs ===== | + | ====== Interactive Jobs ====== |
Though batch submission is the best way to take full advantage of the compute power in the job submission cluster, foreground, interactive jobs can also be run. | Though batch submission is the best way to take full advantage of the compute power in the job submission cluster, foreground, interactive jobs can also be run. | ||
Line 170: | Line 206: | ||
will start a command line shell ('' | will start a command line shell ('' | ||
- | ===== Job Scheduling ===== | + | ====== Job Scheduling |
We use a [[http:// | We use a [[http:// | ||
Line 177: | Line 213: | ||
- | ===== Common Issues ===== | + | ====== Common Issues |
^Error ^What does it mean? ^ | ^Error ^What does it mean? ^ | ||
Line 184: | Line 220: | ||
| JOB < | | JOB < | ||
| error: Unable to allocate resources: More processors requested than permitted | It usually has **nothing** to do with priviledges you may or may not have. Rather, it usually means that you have allocated more processors than one compute node actually has. | | | error: Unable to allocate resources: More processors requested than permitted | It usually has **nothing** to do with priviledges you may or may not have. Rather, it usually means that you have allocated more processors than one compute node actually has. | | ||
+ | |||
+ | ====== More ====== | ||
+ | If you feel this documentation is lacking in some way please let techstaff know. Email(techstaff@cs.uchicago.edu), |
/var/lib/dokuwiki/data/pages/techstaff/slurm.txt · Last modified: 2021/01/06 16:13 by kauffman