... | ... | @@ -212,7 +212,9 @@ Pre-allocation of leases should significantly reduce the time to find a next ava |
|
|
|
|
|
In many cases the problem of degrading performance in nearly exhausted pools appears for smaller pools, e.g. /24, /16, simply because they are smaller. Very often new subnets and shared networks are added to extend the address space in the particular network segment. The pre-allocation is mostly useful in such cases when there are many small pools from which an address is to be picked. Such problem is less common in larger pools, e.g. /8. At the same time, the pre-allocation in the large pools takes considerably more time. Therefore, it seems to be a good idea to be able to disable pre-allocation on the pool level. The appropriate configuration knob should be available at pool, subnet, shared network and global levels. The default value for that knob should be "off" (pre-allocation disabled).
|
|
|
|
|
|
Creation of the new lease or deletion of the new lease (including lease updates via HA) will also have some additional overhead related to additional operations on the U-container. This, however, should not be visible as these operations are conducted in server's memory.
|
|
|
Creation of the new lease or deletion of the new lease (including lease updates via HA) will also have some additional overhead related to additional operations on the U-container. This, however, should not be visible in case of the Memfile backend as these operations are conducted in server's memory.
|
|
|
|
|
|
We're still debating whether for the SQL backends we should have dedicated SQL tables holding available leases or the available leases should be stored in memory as in case of the Memfile backend. The impact on the lease operations time will depend on that choice.
|
|
|
|
|
|
# Implementation Tasks
|
|
|
|
... | ... | |