summaryrefslogtreecommitdiff
path: root/NEWS
diff options
context:
space:
mode:
authorIlya Maximets <i.maximets@ovn.org>2023-03-27 21:42:59 +0200
committerIlya Maximets <i.maximets@ovn.org>2023-04-24 22:42:25 +0200
commit08449bb470c9f99f8bdc13a14d8ef91bd0b4be4f (patch)
tree06d280a494bbd87ce21829be1196b520a08d4a09 /NEWS
parent4d6cdd8e0d86d2b3b6866aaacf327d8c5e7092df (diff)
downloadopenvswitch-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--NEWS10
1 files changed, 10 insertions, 0 deletions
diff --git a/NEWS b/NEWS
index 1155bfbb1..cfd466663 100644
--- a/NEWS
+++ b/NEWS
@@ -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: