diff options
author | Ilya Maximets <i.maximets@ovn.org> | 2023-03-27 21:42:59 +0200 |
---|---|---|
committer | Ilya Maximets <i.maximets@ovn.org> | 2023-04-24 22:42:25 +0200 |
commit | 08449bb470c9f99f8bdc13a14d8ef91bd0b4be4f (patch) | |
tree | 06d280a494bbd87ce21829be1196b520a08d4a09 /NEWS | |
parent | 4d6cdd8e0d86d2b3b6866aaacf327d8c5e7092df (diff) | |
download | openvswitch-08449bb470c9f99f8bdc13a14d8ef91bd0b4be4f.tar.gz |
ovsdb: Perform conversion with no data for clustered databases.
Currently, database schema conversion in case of clustered database
produces a transaction record with both new schema and converted
database data. So, the sequence of events is following:
1. Get the new schema.
2. Convert the database to a new schema.
3. Translate the newly converted database into JSON.
4. Write the schema + data JSON to the storage.
5. Destroy converted version of a database.
6. Read schema + data JSON from the storage and parse.
7. Create a new database from a parsed database data.
8. Replace current database with the new one.
Most of these steps are very computationally expensive. Also,
conversion to/from JSON is much more expensive than direct database
conversion with ovsdb_convert() that can make use of shallow data
copies.
Instead of doing all that, let's make use of previously introduced
ability to not write the converted data into the storage. The process
will look like this then:
1. Get the new schema.
2. Convert the database to a new schema
(to verify that it is possible).
3. Write the schema to the storage.
4. Destroy converted version of a database.
5. Read the new schema from the storage and parse.
6. Convert the database to a new schema.
7. Replace current database with the new one.
Most of the operations here are performed on the small schema object,
instead of the actual database data. Two remaining data operations
(actual conversion) are noticeably faster than conversion to/from
JSON due to reference counting and shallow data copies.
Steps 4-6 can be optimized later to not convert twice on the
process that initiates the conversion.
The change results in following performance improvements in conversion
of OVN_Southbound database schema from version 20.23.0 to 20.27.0
(measured on a single-server RAFT cluster with no clients):
| Before | After
+---------+-------------------+---------+------------------
DB size | Total | Max poll interval | Total | Max poll interval
--------+---------+-------------------+---------+------------------
542 MB | 47 sec. | 26 sec. | 15 sec. | 10 sec.
225 MB | 19 sec. | 10 sec. | 6 sec. | 4.5 sec.
542 MB database had 19.5 M atoms, 225 MB database had 7.5 M atoms.
Overall performance improvement is about 3x.
Also, note that before this change database conversion basically
doubles the database file on disk. Now it only writes a small
schema JSON.
Since the change requires backward-incompatible database file format
changes, documentation is updated on how to perform an upgrade.
Handled the same way as we did for the previous incompatible format
change in 2.15 (column diffs).
Reported-at: https://mail.openvswitch.org/pipermail/ovs-discuss/2022-December/052140.html
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Acked-by: Dumitru Ceara <dceara@redhat.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Diffstat (limited to 'NEWS')
-rw-r--r-- | NEWS | 10 |
1 files changed, 10 insertions, 0 deletions
@@ -1,5 +1,15 @@ Post-v3.1.0 -------------------- + - OVSDB: + * Changed format in which ovsdb schema conversion operations are stored in + clustered database files. Such operations are now allowed to contain + the bare schema (without data). This allows to significantly improve + the schema conversion performance. + New ovsdb-server process will be able to read old database format, but + old processes will *fail* to read database created by the new one, if + conversion operation is present. For the cluster service model follow + upgrade instructions in 'Upgrading from version 3.1 and earlier to 3.2 + and later' section of ovsdb(7). - IPFIX template and statistics intervals can now be configured through two new options in the IPFIX table: 'template_interval' and 'stats_interval'. - Linux kernel datapath: |