Bug #5955

Frontend overprovisioning multicore glideins

Added by Igor Sfiligoi over 6 years ago. Updated about 6 years ago.

Parag Mhashilkar
Target version:
Start date:
Due date:
% Done:


Estimated time:
First Occurred:
Occurs In:


The Frontend logic for calculating the number of glideins to requests assumes one job per glidein;
which may not be true for multicore glideins.

This results in requesting too many glideins, especially when there are only a few matching jobs in the queue.

Related issues

Related to GlideinWMS - Bug #2441: Accounting issues for new glidein typesNew01/31/2012


#1 Updated by Parag Mhashilkar over 6 years ago

  • Target version changed from v3_2_6 to v3_2_7

#2 Updated by Burt Holzman over 6 years ago

  • Priority changed from Normal to High

#3 Updated by Parag Mhashilkar over 6 years ago

Talked to Igor about this issue as this affects/needs coordination with the operations.

Proposal (Draft)

  • Entry should be configured with GLIDEIN_CPUS and it should be advertised as part of the glidefactory classad. GLIDEIN_CPUS can be a numeric value or auto. This scheme works well with numeric value but not auto. In case of auto, there is no good way of identifying the info unless we assume a number.
  • Frontend uses GLIDEIN_CPUS from the glidefactory classad. If not available, or set to AUTO assumes 1.
  • Frontend looks for RequestCpus in the jobs classad to determine the cpus requested. If not specified, assumes 1.
  • When frontend tries to figure out the sites for every job, we request glideins at sites that provide N+ cpus only.
  • Frontend tries to figure best number of glideins it should request per entry in this case and makes the request accordingly.

Known Issues

  • There is no costing and all the sites are treated equal.

#4 Updated by Parag Mhashilkar over 6 years ago

  • Status changed from New to Feedback
  • Assignee changed from Parag Mhashilkar to Marco Mambelli

I am done with my testing and this should be good for review. Changes are in the branch v3/5955

#5 Updated by Marco Mambelli over 6 years ago

  • Assignee changed from Marco Mambelli to Parag Mhashilkar

Feedback sent (in short ready to be committed)

#6 Updated by Parag Mhashilkar over 6 years ago

  • Status changed from Feedback to Resolved

Merged into respective branches.

#7 Updated by Parag Mhashilkar about 6 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF