User Guide

From FarmShare

(Difference between revisions)
Jump to: navigation, search
Line 33: Line 33:
= Directory paths  =
= Directory paths  =
-
Your [[AFS]] home directory is something like '/afs/ir/users/c/h/chekh/'. You'll need an [[AFS]] token to access this directory.
+
Your [[AFS]] home directory is something like '/afs/ir/users/c/h/chekh/'. You'll need an [[AFS]] token to access this directory.  
-
A shared directory is /mnt/glusterfs, and you can get a /mnt/glusterfs/username directory there, currently by logging in to machine 'senpai1' or machine 'corn-image-new' and waiting 5mins (a script will run and notice your login and create the directory).  
+
A shared directory is /mnt/glusterfs, and you can get a /mnt/glusterfs/username directory there, currently by logging in to machine 'senpai1' and waiting 5mins (a script will run and notice your login and create the directory).  
There is also local scratch storage available on the compute nodes. The amount varies from ~70GB to ~500GB, depending on the node hardware. SGE will set the env vars $TMPDIR and $TMP to point to a directory like /tmp/$JOBID. Depending on your workload, it may be a good idea to copy input or reference data to the local scratch space on the node, and then copy the results back to your homedir.  
There is also local scratch storage available on the compute nodes. The amount varies from ~70GB to ~500GB, depending on the node hardware. SGE will set the env vars $TMPDIR and $TMP to point to a directory like /tmp/$JOBID. Depending on your workload, it may be a good idea to copy input or reference data to the local scratch space on the node, and then copy the results back to your homedir.  
Line 65: Line 65:
= Running jobs on the cluster  =
= Running jobs on the cluster  =
-
We use Open Grid Engine. There are three types of jobs: interactive, batch and parallel. You can start by reading the man page for 'sge_intro'. Then the man page for 'qsub'. We currently have a limit of 3000 jobs (running and/or queued) per user. We don't currently allow interactive jobs on the barleys because you can run interactive tasks on the corns. Job scheduling is pretty much FIFO (modified by resource requirements).
+
We use Open Grid Engine. There are three types of jobs: interactive, batch and parallel. You can start by reading the man page for 'sge_intro'. Then the man page for 'qsub'. We currently have a limit of 3000 jobs (running and/or queued) per user. We don't currently allow interactive jobs on the barleys because you can run interactive tasks on the corns. Job scheduling is pretty much FIFO (modified by resource requirements).  
== Running batch jobs  ==
== Running batch jobs  ==
Line 71: Line 71:
Use 'qsub'. This will allocate one slot on the cluster. See the bottom of the qsub man page for an example. Google 'SGE qsub' for more help.  
Use 'qsub'. This will allocate one slot on the cluster. See the bottom of the qsub man page for an example. Google 'SGE qsub' for more help.  
-
Check how much memory your job uses. You can run just one job and see its peak memory usage after it's done. The standard barley node is 24 cores and 96GB RAM, so you shouldn't use more than 4GB/core. Make sure your submitted job doesn't use too much memory or it can crash the node.
+
Check how much memory your job uses. You can run just one job and see its peak memory usage after it's done. The standard barley node is 24 cores and 96GB RAM, so you shouldn't use more than 4GB/core. Make sure your submitted job doesn't use too much memory or it can crash the node.  
-
== Running array jobs ==
+
== Running array jobs ==
-
For jobs that vary only by one parameter, it is easier to submit an "array" job to reduce the amount of output in qstat. If you want to be a good citizen and you're submitting an array job with thousands of tasks, you may want to limit how many tasks you run simultaneously, using the -tc parameter to qsub.
+
For jobs that vary only by one parameter, it is easier to submit an "array" job to reduce the amount of output in qstat. If you want to be a good citizen and you're submitting an array job with thousands of tasks, you may want to limit how many tasks you run simultaneously, using the -tc parameter to qsub.  
== Running parallel jobs  ==
== Running parallel jobs  ==
-
Use 'qsub' with the '-pe' parameter. Using the '-pe' parameter allows you to request more than one slot per job. We have several different "parallel environments" defined, they differ in how the slots are allocated. If you want your slots on the same node, use '-pe fah'. If you want your slots spread across nodes, use '-pe orte'. Use 'qconf -sp orte' to see the settings, and 'man sge_pe' for more info.
+
Use 'qsub' with the '-pe' parameter. Using the '-pe' parameter allows you to request more than one slot per job. We have several different "parallel environments" defined, they differ in how the slots are allocated. If you want your slots on the same node, use '-pe fah'. If you want your slots spread across nodes, use '-pe orte'. Use 'qconf -sp orte' to see the settings, and 'man sge_pe' for more info.  
== Running OpenMPI jobs  ==
== Running OpenMPI jobs  ==
Line 89: Line 89:
There's a 48hr limit on jobs in the regular queue and 7days in long.q. You can use '-l h_rt=xx:xx:xx' to tell the scheduler how long your job will run.  
There's a 48hr limit on jobs in the regular queue and 7days in long.q. You can use '-l h_rt=xx:xx:xx' to tell the scheduler how long your job will run.  
-
When jobs fail, you typically have to re-run them. So try to split them into many small chunks (but not too many).
+
When jobs fail, you typically have to re-run them. So try to split them into many small chunks (but not too many).  
-
== checking on your jobs ==
+
== checking on your jobs ==
-
Use the 'qstat' command to check on your currently pending/running jobs. Use the '-M' flag to qsub to have the system e-mail you about your job if you want. Look through your output files for output of the job stdout and stderr streams. Use the 'qacct' command to see some information about jobs that already finished, e.g. 'qacct -j JOBID'. If there is no record of the job in qacct, that means it didn't get written to the accounting file, which means it failed somehow. Look at your output files to see what the error was.
+
Use the 'qstat' command to check on your currently pending/running jobs. Use the '-M' flag to qsub to have the system e-mail you about your job if you want. Look through your output files for output of the job stdout and stderr streams. Use the 'qacct' command to see some information about jobs that already finished, e.g. 'qacct -j JOBID'. If there is no record of the job in qacct, that means it didn't get written to the accounting file, which means it failed somehow. Look at your output files to see what the error was.

Revision as of 11:18, 8 March 2012

If you have any questions, file HelpSU or ask on farmshare-discuss@lists.stanford.edu The modification date of this page is in the footer below.

Contents

Connecting

  • The public-facing hostname is corn.stanford.edu
  • Only SSH connections are allowed. This also includes SFTP.
    • Only SSH protocol v2 is supported.
    • SSH fingerprint for corn is
 0b:e7:b4:95:03:c1:1e:07:df:04:ca:a2:3d:8e:e3:37
  • If you're behind a firewall, you may want to add "ServerKeepAliveInterval 60" or "ServerAliveInterval 60" to your SSH client's configuration.

Connecting from Windows

You will want to use an SSH client like one of these:

Connecting from OS X / Linux / other OS

You should probably just use the included SSH client. Stanford does provide an SSH GUI for OS X to help you track connection settings: http://itservices.stanford.edu/service/ess/mac/lelandssh

Logging In

You can log in via SSH using your SUNet ID credentials.

Moving files to/from the cluster

Since you can connect via SSH, you can use the sftp or scp commands to upload/download files to farmshare. On Windows, you can use software like FileZilla or WinSCP. On OS X users can use Cyberduck or similar. Linux and other unix like OS just use the included sftp or scp commands.

Directory paths

Your AFS home directory is something like '/afs/ir/users/c/h/chekh/'. You'll need an AFS token to access this directory.

A shared directory is /mnt/glusterfs, and you can get a /mnt/glusterfs/username directory there, currently by logging in to machine 'senpai1' and waiting 5mins (a script will run and notice your login and create the directory).

There is also local scratch storage available on the compute nodes. The amount varies from ~70GB to ~500GB, depending on the node hardware. SGE will set the env vars $TMPDIR and $TMP to point to a directory like /tmp/$JOBID. Depending on your workload, it may be a good idea to copy input or reference data to the local scratch space on the node, and then copy the results back to your homedir.

Data Limits

Your AFS homedir is limited to 2GB of quota. You can request more space here: https://itservices.stanford.edu/service/storage/getmore

Use 'fs quota' to see your utilization. You may want to do something like the following command, which will generate a timestamped file in your homedir with the sizes of your directories. This command may take a while to run, as it will stat every single file in your homedir.

 du --exclude .backup -sh * | sort -h | tee ~/`pwd | tr '/' '_'`.du.`date +%Y-%m-%d`

Mounting your files elsewhere

Your AFS files can be accessed globally (literally), you just need the OpenAFS software installed. More info here: https://itservices.stanford.edu/service/afs/intro/mounting

You can make your /mnt/glusterfs/ directory accessible directly from your workstation. Again, access is only allowed over SSH, so you can use something like SSHFS (via FUSE). One caveat is that SSHFS doesn't work with concurrent/parallel access, so this solution is only appropriate if you're not accessing files from several places at once. E.g. don't have cluster jobs write some files while you access the same files via SSHFS.

Windows: you can try ExpanDrive (used to be SFTPDrive), $39, or WebDrive, $60, or Docan (Free Software).

OS X: try OSXFUSE, or ExpanDrive (above)

Linux: you can use sshfs, e.g. on Debian (and derivatives):

  • Install: apt-get install sshfs
  • Mount: sshfs host:/mount/point /mount/point
  • Unmount: fusermount -u /mount/point

Running jobs on the cluster

We use Open Grid Engine. There are three types of jobs: interactive, batch and parallel. You can start by reading the man page for 'sge_intro'. Then the man page for 'qsub'. We currently have a limit of 3000 jobs (running and/or queued) per user. We don't currently allow interactive jobs on the barleys because you can run interactive tasks on the corns. Job scheduling is pretty much FIFO (modified by resource requirements).

Running batch jobs

Use 'qsub'. This will allocate one slot on the cluster. See the bottom of the qsub man page for an example. Google 'SGE qsub' for more help.

Check how much memory your job uses. You can run just one job and see its peak memory usage after it's done. The standard barley node is 24 cores and 96GB RAM, so you shouldn't use more than 4GB/core. Make sure your submitted job doesn't use too much memory or it can crash the node.

Running array jobs

For jobs that vary only by one parameter, it is easier to submit an "array" job to reduce the amount of output in qstat. If you want to be a good citizen and you're submitting an array job with thousands of tasks, you may want to limit how many tasks you run simultaneously, using the -tc parameter to qsub.

Running parallel jobs

Use 'qsub' with the '-pe' parameter. Using the '-pe' parameter allows you to request more than one slot per job. We have several different "parallel environments" defined, they differ in how the slots are allocated. If you want your slots on the same node, use '-pe fah'. If you want your slots spread across nodes, use '-pe orte'. Use 'qconf -sp orte' to see the settings, and 'man sge_pe' for more info.

Running OpenMPI jobs

See OpenMPI, contact farmshare-discuss with any questions.

job duration

There's a 48hr limit on jobs in the regular queue and 7days in long.q. You can use '-l h_rt=xx:xx:xx' to tell the scheduler how long your job will run.

When jobs fail, you typically have to re-run them. So try to split them into many small chunks (but not too many).

checking on your jobs

Use the 'qstat' command to check on your currently pending/running jobs. Use the '-M' flag to qsub to have the system e-mail you about your job if you want. Look through your output files for output of the job stdout and stderr streams. Use the 'qacct' command to see some information about jobs that already finished, e.g. 'qacct -j JOBID'. If there is no record of the job in qacct, that means it didn't get written to the accounting file, which means it failed somehow. Look at your output files to see what the error was.

Toolbox
LANGUAGES