Managing Ephemeral Configuration Database Space
SUMMARY Configure options for ephemeral database instances to more effectively manage the amount of space that the database uses.
Junos devices maintain versions of ephemeral configuration database objects with every commit. Thus, any change to the ephemeral database, whether it is an addition, modification, or deletion, increases the size of the database. As a result, the database only increases in size over time. Depending on the size of the ephemeral configuration and the changes to the database, the database can consume a large amount of disk space, become fragmented, and could potentially run into the maximum database size. You can manage the space that an ephemeral database instance uses by configuring different options.
In supported releases, Junos devices, by default, perform cyclic versioning when you commit an ephemeral instance. Cyclic versioning reclaims the space occupied by objects deleted in a previous database version. To manage the space consumed by the ephemeral database, you can configure the device to:
-
Adjust cyclic versioning as appropriate for your operations.
-
Resize an ephemeral database when it meets specific criteria.
Benefits of Cyclic Versioning and Resizing
-
More efficiently manage ephemeral configuration database space as required for a given environment.
-
Reduce database fragmentation for improved performance.
-
Prevent an ephemeral configuration database from running into the maximum database size.
Understanding Cyclic Versioning
Junos devices maintain versioning for ephemeral database objects, and as a result, the database also retains and stores deleted objects. A deletion is characterized by:
-
Explicitly deleting the configuration.
-
Changing the value of a configuration attribute.
-
Reordering elements during a load update operation.
Cyclic versioning reclaims the space occupied by objects that were deleted in a previous version of the database. The cyclic version value determines the ephemeral database version in which the system reclaims deleted objects during a commit operation. The default cyclic version value for each ephemeral database instance is 10. Thus, on devices that support cyclic versioning, the system, by default, reclaims the space occupied by deleted configuration objects with each commit. You can modify the setting on a per-instance basis. To disable cyclic versioning, set the cyclic version value to 0.
For example, if you use the default cyclic version value of 10, then:
-
After the 11th commit (version 11), the device reclaims the space occupied by objects that were deleted in version 1.
-
After the 12th commit (version 12), the device reclaims the space occupied by objects that were deleted in version 2.
-
After the 13th commit (version 13), the device reclaims the space occupied by objects that were deleted in version 3.
This process continues with each subsequent commit operation. As illustrated in the previous example, the version from which the system reclaims deleted objects during the current commit operation is:
version to reclaim = current version - cyclic version
When the system resizes the database, the system keeps only the active configuration objects and resets the version for each object to the latest version. As a result, the system does not reclaim deleted objects again until after you execute commit operations equal to the cyclic version value.
In earlier releases and on devices that do not use cyclic versioning, the ephemeral database default behavior is to purge the database when it reaches the maximum allowable version. A purge operation reclaims the space used by deleted objects but requires all processes to read the full configuration. A database purge operation involves:
-
Creating a new database.
-
Copying only the active configuration objects from the current database into the new database.
-
Setting the version for all active configuration objects in the new database to version 1.
Understanding Ephemeral Database Resizing
Resizing an ephemeral database might be necessary if cyclic versioning is enabled and you make frequent changes to the database that involve deleting or reordering elements. On devices that support cyclic versioning, the system automatically reclaims the space occupied by deleted objects during a commit operation. However, the system might or might not reallocate the freed space for new configuration objects when you update the database. If the system does not reallocate the space, then the database can become fragmented over time. Resizing an ephemeral database reclaims the space occupied by all deleted objects and defragments the database, which can improve performance.
A database resize operation involves:
-
Creating a new database.
-
Copying only the active configuration objects from the current database into the new database.
-
Setting the version for all active configuration objects in the new database to the latest version.
As with the static configuration database, you can configure Junos devices to resize the ephemeral configuration database. After you configure database resizing, Junos devices resize the ephemeral database during a commit operation if the database's space exceeds the specified thresholds. You can modify the thresholds for each ephemeral instance.
The system resizes the database when the database size meets the criteria for both of the following configuration statements:
-
database-size-diff—Minimum difference between the database size and the actual usage. Default is 100 MB. -
database-size-on-disk—Minimum configuration database size on disk. Default is 450 MB.
For example, if you configure the device to use the default values, then the system resizes the database when the database size on disk exceeds 450 MB and the database size is 100 MB greater than the actual database usage.
For information about configuring database resizing, see Resize an Ephemeral Database Instance.
Use the show system configuration database usage command to display
the database's disk space usage. The command displays the current database size on
disk, the actual database usage, and the maximum size of the database.
user@host> show system configuration database usage ephemeral-instance default Maximum size of the database: 692.49 MB Current database size on disk: 1.50 MB Actual database usage: 1.49 MB Available database space: 691.01 MB
Configure Cyclic Versioning
Junos devices, by default, use a cyclic version value of 10. When configuring the cyclic version value, the best practice is to use a smaller value if you perform frequent commit operations for scaled configurations that reorder elements or delete many objects or attributes. A smaller value causes the device to store deleted objects for fewer versions of the database and thus use less disk space overall. In these cases, we recommend a value of 2 or 3. Otherwise, you can use a larger cyclic version value, such as the default value of 10.
If a Junos process misses reading more commits than the configured cyclic version value, it must read the full configuration because the delta between the versions is no longer available. This effect might happen more frequently if you configure smaller cyclic version values.
To specify the cyclic version value that the device uses to reclaim the space occupied by deleted objects during a commit operation:
Resize an Ephemeral Database Instance
After you configure the device to resize the database, the device resizes the database after a commit operation on that database when it meets the specified criteria. After successfully resizing the database, the device emits the following message:
Database resize completed
Change History Table
Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.