DokuWiki

User Tools

Site Tools

Trace:
cluster:103

Warning: Undefined array key -1 in /usr/share/dokuwiki/inc/html.php on line 1458

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision 		Previous revision
cluster:103 [2011/12/21 14:01]
hmeij [Submit] 		cluster:103 [2011/12/22 14:34] (current)
hmeij [Submit 2]
Line 128: Line 128:
 And so the job was dispatched to host ''n10'' for execution.  Results are posted in my home directory, in fact the entire job ran in my home directory while on the remote compute node.  I may not want to do that if I process or generate a lot of data. So we're going to add some statements to the script next. Also, I may want to reserve some memory so the scheduler does not submit the job to hosts that have insufficient memory available or some other job is dispatched later that causes memory conflicts with my job. And so the job was dispatched to host ''n10'' for execution.  Results are posted in my home directory, in fact the entire job ran in my home directory while on the remote compute node.  I may not want to do that if I process or generate a lot of data. So we're going to add some statements to the script next. Also, I may want to reserve some memory so the scheduler does not submit the job to hosts that have insufficient memory available or some other job is dispatched later that causes memory conflicts with my job.
  
-The ''hp12'' queue is the cluster greentail default queue where each compute node has a 12 GB memory footprint.  Memory footprints for the other queues differ, please consult this link (there is some old data...) [[http://petaltail.wesleyan.edu/cgi-bin/bqueues_web.cgi|http://petaltail.wesleyan.edu/cgi-bin/bqueues_web.cgi]] for information about other queues.+The ''hp12'' queue is the cluster greentail's default queue where each compute node has a 12 GB memory footprint.  Memory footprints of hosts for the other queues differ, please consult this link (there is some old data...) [[http://petaltail.wesleyan.edu/cgi-bin/bqueues_web.cgi|http://petaltail.wesleyan.edu/cgi-bin/bqueues_web.cgi]] for information about other queues. 
 + 
 +==== Submit 2 ==== 
 + 
 +On the back end compute nodes, unless specified, the job runs inside your home directory.  That job competes with other activities inside /home.  Compute nodes have two other areas where the jobs could be submitted: /localscratch and /sanscratch.  The former is a local filesystem for each node and should be used if file locking is essential. The later is a filesystem from greentails diskarray (5 TB) served vi IPoIB (that is NFS traffic over fast interconnects switches, the performance should be much better than gigabit ethernet switches).  It is comprised of disks and spindles that are not impacted by what happens on /home.  So we're going to use that. 
 + 
 +In the SAS program we add the following lines 
 + 
 +<code> 
 +%let jobpid = %sysget(LSB_JOBID); 
 +libname here "/sanscratch/&jobpid"; 
 +</code> 
 + 
 +And change this line to use local disks for storage 
 + 
 +<code> 
 +data here.one; 
 +</code> 
 + 
 +In the submission script we change the following 
 + 
 +  * new submission file with edits 
 +  * -n implies reserve job slots (cpu cores) for job (not necesssary, SAS jobs will always use only one) 
 +  * -R reserves memory, for example, reserve 200 MB of memory on target compute node 
 +  * scheduler creates unique dirs in scratch by JOBPID for you, so we'll stage the job there 
 +  * but now we must copy relevant files //to// scratch dir and results back //to// home dir 
 + 
 + 
 +<code> 
 + 
 +#!/bin/bash 
 +# submit via 'bsub < run' 
 + 
 +#BSUB -q hp12 
 +#BSUB -J test 
 +#BSUB -o stdout 
 +#BSUB -e stderr 
 +#BSUB -n 1 
 +#BSUB -R "rusage[mem=200]" 
 + 
 +# unique job dir in scratch  
 +export MYSANSCRATCH=/sanscratch/$LSB_JOBID 
 +cd $MYSANSCRATCH 
 + 
 +cp ~/sas/test.dat ~/sas/test.sas . 
 +time sas test 
 +cp test.log test.lst ~/sas 
 + 
 +</code> 
 + 
 + 
 +  * you can monitor the progress of your jobs from greentail while it runs 
 + 
 +<code> 
 +[hmeij@greentail sas]$ ll /sanscratch/492667/ 
 +total 16 
 +-rw-r--r-- 1 hmeij its   33 Dec 21 14:31 test.dat 
 +-rw-r--r-- 1 hmeij its 2568 Dec 21 14:31 test.log 
 +-rw-r--r-- 1 hmeij its  258 Dec 21 14:31 test.lst 
 +-rw-r--r-- 1 hmeij its  140 Dec 21 14:31 test.sas 
 +</code> 
 + 
 +==== Best Practices ==== 
 + 
 +  * You may submit as many SAS jobs as you like, just leave enough resources available for others to also get work done 
 +  * Because SAS submission are serial, non-parallel jobs your -n flag is always 1 
 +  * Reserve resources if you know what you need, especially memory 
 +  * Use /sanscratch for large data jobs with heavy read/write operations 
 +  * Queue ehwfd is preferentially for Gaussian users and stay off the stata and matlab queues please 
 +  * Write smart SAS code, for example, use data set indexes and PROC SQL (this can be your best friend) 
 +  * ... suggestions will be added to this page
  
 \\ \\
 **[[cluster:0|Back]]** **[[cluster:0|Back]]**
cluster/103.1324494086.txt.gz · Last modified: 2011/12/21 14:01 by hmeij

Page Tools

Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
CC Attribution-Share Alike 4.0 International Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki