Priority Policy
In this section:
GridUnesp uses a priority system based on Fair Share to ensure balanced use of computational resources among all users and research groups.
How Priority Affects Jobs
The priority calculated by Fair Share directly influences the execution order of jobs in the queue.
Listing Jobs in Priority Order
squeue -o "%.18i %.9Q %.8j %.8u %.10V %.6D %R" --sort=-p,i --states=PD
Example output:
JOBID PRIORITY NAME USER SUBMIT_TIM NODES NODELIST(REASON)
2847404 296816 force1.s yoda 2022-03-31 1 (Priority)
2838783_12 222821 dark1.sh vader 2022-03-15 1 (Priority)
2838783_14 222821 dark1.sh vader 2022-03-15 1 (Priority)
2844502 185817 crucio1. valdemo+ 2022-03-28 1 (Priority)
2848555 50480 vulcano. spock 2022-04-01 4 (Priority)
Notes:
The PRIORITY column shows the numeric priority value
Jobs with higher priority (larger number) run first
Priority is dynamic and changes as:
New jobs are submitted
Running jobs finish
Time passes (14-day half-life)
Factors That Influence Priority
Recent cluster usage
The more you used in the last 14 days, the lower your priority
Every 14 days, the “counter” is gradually reset
Number of users in the group
Groups with many users have smaller slices per person
Encourages groups to manage usage internally
Job size
Jobs that request many resources may have their priority adjusted
The system seeks a balance between large and small jobs
Wait time
Jobs that wait a long time gradually gain priority
Prevents starvation (jobs that never run)
However, jobs that require a short processing time have a greater chance of obtaining resources more quickly.
Tips to Improve Your Priority
✅ Do:
Request only what you need
#SBATCH -t 02:00:00 # If your job runs in 1h30, don't request 24h #SBATCH --mem=8G # If it uses 6G, don't request 64G
Distribute usage over time
Avoid submitting hundreds of jobs at once
Spread submissions over days/weeks
Use job arrays for many small jobs
#SBATCH --array=1-1000 # 1000 small jobs #SBATCH --ntasks=1 #SBATCH --time=01:00:00
Monitor your Fair Share regularly
sshare -U $USER
❌ Avoid:
Monopolizing resources with very large and long jobs
Requesting resources far above what is needed
Leaving jobs running that could have already finished
Understanding the 14-Day Half-Life
The system uses an exponential decay with a 14-day half-life:
Day 0: Maximum usage (minimum priority)
Day 14: The “weight” of the usage drops by half
Day 28: The “weight” drops to 1/4 of the original value
And so on…
This means that:
If you used many resources today, your priority tends toward the initial value as the days pass
The system gradually “forgets” old usage
Everyone has a chance to recover priority after periods of inactivity
Practical Example
Let’s follow a user over time:
Week 1: João submits few jobs: high priority (0.9)
sshare -U joao
# FairShare = 0.901
Week 2: João submits many jobs: priority drops
sshare -U joao
# FairShare = 0.452
Week 3: João keeps using a lot: very low priority
sshare -U joao
# FairShare = 0.187
Week 4: João reduces usage: priority starts to recover
sshare -U joao
# FairShare = 0.223
Weeks 5-6: With moderate usage: priority tends toward the initial value
sshare -u joao
# FairShare = 0.854
Command Summary
Command |
Description |
|---|---|
|
View Fair Share of all users |
|
View only your Fair Share |
|
View your group’s Fair Share |
|
View your jobs sorted by decreasing priority ( |
|
List pending jobs in order of decreasing priority ( |
See also
Running Simulations - How to submit jobs
Optimizing Performance - Tips for optimizing resources
Best Practices - General recommendations