The Xen CPU collector keeps old values of instance loads for some time, even after they have moved away. In this way, we can still obtain a buest-guess load values for an instance before a new load value can be established on the new node.
For "replace primary" moves on an instance, however, the instance will visit 3 nodes in short succession. Therefore, keeping old data only for the time it takes to establish a new load on one node is not necessarily enough; the instance could be on the intermediate node for too short to establish a stable load value there. The theoretical minimum would be 2 times the threshold for accepting load data as stable; however, due to differences in the sampling time, play it safe and use 3 times this value. Note that balancing will prefer the load data from the node where the instance resides, whenever available; so no harm is done to the accuracy by keeping old values a bit longer. Signed-off-by: Klaus Aehlig <[email protected]> --- src/Ganeti/DataCollectors/XenCpuLoad.hs | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/Ganeti/DataCollectors/XenCpuLoad.hs b/src/Ganeti/DataCollectors/XenCpuLoad.hs index 10c39cd..3ced7ad 100644 --- a/src/Ganeti/DataCollectors/XenCpuLoad.hs +++ b/src/Ganeti/DataCollectors/XenCpuLoad.hs @@ -143,7 +143,8 @@ dcUpdate maybeCollector = do combinedValues withoutOld = Map.filter (liftA2 (&&) (not . Seq.null) - $ (>) (fromIntegral $ C.xentopAverageThreshold * 1000000) + $ (>) (fromIntegral + $ 3 * C.xentopAverageThreshold * 1000000) . (clockTimeToUSec now -) . clockTimeToUSec . fst . flip Seq.index 0) withinRange -- 2.5.0.rc2.392.g76e840b
