NOTE: Do not use the -i (import) option. Use the cd command inside your script to cd to the desired directory instead. Some users work with extremely large files, this command would require that the machine have enough space to have two copies of each file in each working job's directory. The machine does not have that much disk space.
The cpu-power of the machine isn't infinite. Running jobs in NQS limits the number of jobs running at any one time to something the machine can handle. Computers handle multiple jobs by swapping them in and out of the cpu; run enough jobs and the silce of time the cpu can devote to a given job gets close to the time taken simply to load it - the condition is called thrashing. Effectively, the computer spends all it's time changing jobs without acutally working on any job.
At the moment, there is only one queue on ccstat.uky.edu: long.
On ccstat.uky.edu use the qsub command. You can get more information by logging on to ccstat.uky.edu and issuing man qsub.
qsub -q queuename scriptname where
queuename is the name of the queue your job is submitted to scriptname is the name of the shell script that executes your program.
The following is a sample shell script:
---------Cut Here------------------------------------------------------ #!/bin/sh cd $HOME/my_project.dir # # Do not run any part of your shell script in the background in batch - # it won't run. # This script assumes that you do your work in the /scratch filespace # because you don't want to use up your disk quota with working files # You can cut out this section if you aren't worried about exceeding your # quota. mytmpdir="/scratch/`whoami`" cp myprogram.std_in $mytmpdir cp -pr myprogram $mytmpdir cd $mytmpdir #end of section that can be cut out my_program > my_program.std_out < myprogram.std_in # If you ran the program in scratch space, you may want to copy the # output back to your home directory (or a sub-directory of your Home # directory) - if so, include this section. cp my_program.std_out $HOME/my_project.dir # end of section ---------Cut Here------------------------------------------------------
Use the qstat command. For the simplest form, type qstat. For more options, log on to ccstat.uky.edu and issue man qstat
There are as many jobs running at the moment as NQS will allow. Your job will run when one of the jobs currently running under NQS finishes.
Use the qdel job# command. job# is the number NQS uses to identify your job; use the qstat command to get it. For a full list of options, log on to ccstat.uky.edu and issue man qdel. Generally, the one you will be interested in is -k. It forces qdel to kill your job even if there is some reason qdel normally wouldn't. Normally, try to use qdel job# to kill a job first, then try qdel -k job#. You can only kill your own jobs; system admins can kill other people's jobs if absolutely necessary.
If qdel -k does not successfully kill your job, try the following:
1) Run ps -f -u youruserid. That should get you a list of all the processes running under your userid. Find the ones associated with your batch job and get their PIDs (If you aren't sure, find the process running your shell script. Its children should have its PID in their PPID field.
2) Run kill -9 pid1 pid2 pid3 ....
3) If that doesn't work, check to make sure you got everything. If you're sure you did get everything, but your job didn't die, send email to help@ccstat.uky.edu.
Back to:
Computing Center
Research Systems
CCSTAT