Changeset 44 for trunk/oarutils/oar-parexec

Timestamp:

Dec 5, 2011, 10:58:16 PM (13 years ago)

Author:

g7moreau

Message:

• doc doc and doc!

File:

• trunk/oarutils/oar-parexec (modified) (7 diffs)

trunk/oarutils/oar-parexec

@@ -233 +233 @@
 =head1 NAME
 
-oar-parexec - parallel execute lot of small job
+oar-parexec - parallel execution of many small job
 
 =head1 SYNOPSIS
 
- oar-parexec --filecmd filecommand [--logtrace tracefile] [--verbose] [--jobnp integer] [--nodefile filenode] [--masterio basefileio] [--switchio] [--oarsh sssh]
+ oar-parexec --filecmd filecommand [--logtrace tracefile] [--verbose] [--jobnp integer] \
+            [--nodefile filenode] [--masterio basefileio] [--switchio] [--oarsh sssh]
  oar-parexec --help
 
 =head1 DESCRIPTION
 
-C<oar-parexec> execute lot of small job.in parallel inside a cluster.
-Number of parallel job at one time cannot excede core number in the node file.
+C<oar-parexec> can execute lot of small job in parallel inside a cluster.
+Number of parallel job at one time cannot exceed the number of core define in the node file
 C<oar-parexec> is easier to use inside an OAR job environment
-which define automatically theses strategics parameters...
+which define automatically these strategics parameters...
+However, it can be used outside OAR.
 
 Option C<--filecmd> is the only mandatory one.
 
 Small job will be launch in the same folder as the master job.
-Two environment variable are define for each small job
+Two environment variable are defined for each small job
 and only in case of parallel small job (option C<--jobnp> > 1).
 
@@ -256 +258 @@
  OAR_NP        - number of processor affected
 
-The file define by OAR_NODE_FILE is created on the node before launching
-the small job in /tmp and will be delete after...
+The file define by OAR_NODE_FILE is created  in /tmp
+on the node before launching the small job
+and this file will be delete after job complete.
 C<oar-parexec> is a simple script,
 OAR_NODE_FILE will not be deleted in case of crash of the master job.
@@ -278 +281 @@
 
 File which log and trace running job.
-In case of running the same command (after crash for example),
-only job that ar not mark as done will be run again.
-Be carefful, job mark as running (start but for finish) will be run again.
+In case of running the same master command (after crash for example),
+only job that are not mark as done will be run again.
+Be careful, job mark as running (start but not finish) will be run again.
 
 This option is very usefull in case of crash
@@ -294 +297 @@
 =item B<-n|--nodefile filenode>
 
-File name that list all the node to launch job.
+File name that list all the node where job could be launch.
 By defaut, it's define automatically by OAR via
 environment variable C<OAR_NODE_FILE>.
@@ -326 +329 @@
 By default
 
-        oarsh -q -T
+ oarsh -q -T
+
+Change it to C<ssh> if you are not using an OAR cluster...
 
 =item B<-h|--help>
@@ -334 +339 @@
 
 =head1 EXAMPLE
+
+=head2 Simple list of sequential job
 
 Content for the job file command (option C<--filecmd>) could have:
@@ -352 +359 @@
  $HOME/test/subjob40.sh
 
-These jobs could be launch by
-
- oarsub -n test -l /core=6,walltime=00:35:00 "oar-parexec -f ./subjob.list.txt"
+These jobs could be launch by:
+
+ oarsub -n test -l /core=6,walltime=04:00:00 "oar-parexec -f ./subjob.list.txt"
+
+=head2 Parallel job
+
+You need to put the number of core each small job need with option C<--jobnp>.
+If your job is build on OpenMP or MPI,
+you can use OAR_NP and OAR_NODE_FILE variables to configure them.
+On OAR cluster, you need to use C<oarsh> or a wrapper like C<oar-envsh>
+for connexion between node instead of C<ssh>.
+
+Example with parallel small job on 2 core:
+
+ oarsub -n test -l /core=6,walltime=04:00:00 "oar-parexec -j 2 -f ./subjob.list.txt"
+
+=head2 Tracing and master crash
+
+If the master node crash after hours of calculus, everything is lost ?
+No, with option C<--logtrace>,
+it's possible to remember older result
+and not re-run these job the second and next time.
+
+ oarsub -n test -l /core=6,walltime=04:00:00 "oar-parexec -f ./subjob.list.txt -l ./subjob.list.log"
+
+After a crash or an C<oardel> command,
+you can then re-run the same command that will end to execute the jobs in the list
+
+ oarsub -n test -l /core=6,walltime=04:00:00 "oar-parexec -f ./subjob.list.txt -l ./subjob.list.log"
+
+C<logtrace> file are just plain file.
+We use the extension '.log' because these files are automatically
+eliminate from our backup system!
+
+=head2 Checkpointing and Idempotent
+
+C<oar-parexec> is compatible with the OAR checkpointing.
+Il you have 2000 small jobs that need 55h to be done on 6 cores,
+you can cut this in small parts.
+
+For this example, we suppose that each small job need about 10min...
+So, we send a checkpoint 12min before the end of the process
+to let C<oar-parexec> finish the jobs started.
+After being checkpointed, C<oar-parexec> do not start any new small job.
+
+ oarsub -t idempotent -n test -l /core=6,walltime=04:00:00 --checkpoint 720 \
+   "oar-parexec -f ./subjob.list.txt -l ./subjob.list.log"
+
+After 3h48min, the OAR job will begin to stop launching new small job.
+When all running small job are finished, it's exit.
+But as the OAR job is type C<idempotent>,
+OAR will re-submit it as long as all small job are not executed...
+
+This way, we let other users a chance to use the cluster!
+
+In this last exemple, we use moldable OAR job with idempotent
+to reserve many core for a small time or a few cores for a long time:
+
+ oarsub -t idempotent -n test \
+   -l /core=50,walltime=01:05:00 \
+   -l /core=6,walltime=04:00:00 \
+   --checkpoint 720 \
+   "oar-parexec -f ./subjob.list.txt -l ./subjob.list.log"
 
 
 =head1 SEE ALSO
 
-oar-dispatch, mpilauncher
+oar-dispatch, mpilauncher,
+orsh, oar-envsh, ssh