Different Resource Management Strategies with Grid Engine


This HOWTO discusses the PROs and CONs of different approaches for managing resources. It originates from a response to the question "How can I minimize the delay of a load sensor tracking software licenses?" asked in the Sun SupportForum. The answer was:

It's quite natural that load sensors have a delay. It can't be prevented and for this reason using load sensors is only the 3rd best approach to manage license consumption.

  • The best way for managing licenses is the use of consumable resources (CR). Floating licenses can easily be managed with a global CR. Node-locked licenses can be managed in an analogous fashion. If you don't consider interactive use of your licenses you usually need only CRs and don't have to bother about load sensors delay.

  • If you need the licenses also for your interactive jobs we suggest the use of

    qrsh <resource_request> appl

    to achieve also interactive license consumption being gathered by Grid Engine. To make the use of qrsh invisible for your users the qrsh command can be either put in a script wrapper behaving like the original application, or you can use qtcsh to achieve transparency.

  • If it is not practicable for you to start interactive license-bound jobs through Grid Engine you can use the consumable resource setup as described above in combination with your load sensor for the same resource attribute. Grid Engine uses both information sources and does its best to derive from this how much of the resource is really available. Unfortunately, due to the loadsensor's delay, it can't be 100% excluded that batch jobs are dispatched and started although the license has been aquired by an interactive job. In this situation, however, batch jobs can react by explicitly triggering a rerun returning 99 as an exit status (collision detection). Load correction can sometimes help to reduce the number of reruns but it is only a solution, if you have an almost homogenous job profile.