Calculating Costs

Scope of this document

This document is intended to describe the way dCache calculates costs to determine the most appropriate pool for

General Scheme

Costs are generated by the Pools and frequently send to the PoolManager. The PoolManager uses these costs to determine where to store files coming from outside the system, and from where to fetch files requested by clients.

Generating Costs

Currently, pools are assumed to generate two different types of costs, which reflect the usage of disk space and the cpu load, subsequently called space cost and cpu cost resp.. The mechanism described here is true for MultiProtocolPool2.java 1.63.

Space Cost

The dCache distinguishes between three types of disk space within a pool. In addition, the space cost depends as well on how much space is needed. For further calculation this value is determined by :
   spaceNeeded = 3* max( 50MB , filesize ) ;
So the space cost is calculated :
    if spaceNeeded < F :
         spaceCost = spaceNeeded / F / breakEven
    else
         spaceCost = spaceNeeded / ( F + R )
The breakEven value is set to 250.0, which should be ok for most sites. It has to be :
    breakEven > <spaceOfLargestPool> / <spaceOfSmallestPool>
This value reflects that free space (F) is preferred compared to removable space (R).

Cpu Cost

A pool determines its load by comparing the actual number of movers (store,restore,client) to the maximum number of movers allowed.
First this is done for each mover type separatly (store/restore/client).
  moverCost(store/restore/client) = ( active + waiting ) / maxAllowed
Then the average is taken for each mover type where maxAllowed is not zero.
  moverCost(total) = ( moverCost(store) + moverCost(restore) + moverCost(client) ) / 3
  
  resp. for read only pools
  
  moverCost(total) = ( moverCost(restore) + moverCost(client) ) / 2
  
For a well balanced system, the cpu cost shouldn't exceed 1.0.

Merging Costs (PoolManagerV5 Rev. >= 1.4 only)

In order to make a decision, the PoolManager sometimes has to somehow merge these two types of costs to be able to compare different pools. Merging is needed for operations where files have to be created within the dCache space (restore and write from client). For the client read operation only the cpu cost is taken into account.

The merging algorithm is just a liniar combination of both costs:

   cost = spaceCostFromPool * spaceCostFactor + cpuCostFromPool * cpuCostFactor
The factors spaceCostFactor and cpuCostFactor are tunable parameters :
   set pool decision [-spacecostfactor=<scf>] [-cpucostfactor=<ccf>]

The scheme to generate, distribute and merge the cost data from the different pools suffers from the disadvantage that the PoolManager only gets a snapshot of the state of the whole system. Depending on the refresh rate of the pools this snapshot might become rather out of date. This in turn can result in a PoolManager decision which is no longer optimal for the overall system. Though statistics will ajust this behaviour over time, a huge bunch of requests sent at the same time may result in an unbalanced load for some pools.
In order to soften this behaviour the PoolManager randomizes the top n pool candicates for the restore operation (data from the HSM). n is set to 4 and can't be configured in Rev 1.4.


Command reference

Pool commands
   set heartbeat <heartBeat/seconds>
The heartbeat determines the interval in which the pools send an update of the current costs to the PoolManager. The more often this is done, the more precise the PoolManager decisions are. On the other hand can this communication accumulate to a rather high load. The value must not exceed 300.
   set breakeven <breakeven>
The breakeven value emphasises the attraction of free space compared to removable space. The default value is set to 250. There should be no need to change it.
PoolManager commands
   set pool decision [-spacecostfactor=<scf>] [-cpucostfactor=<ccf>]
This command defines the values for the factors of the linear combination to merge the cpu and the space costs. (See discussion above).
Patrick Fuhrmann (patrick.fuhrmann@desy.de) $Date: 2005/04/29 12:38:57 $