summaryrefslogtreecommitdiff
path: root/ovsdb/ovsdb.h
diff options
context:
space:
mode:
authorIlya Maximets <i.maximets@ovn.org>2022-07-01 01:34:07 +0200
committerIlya Maximets <i.maximets@ovn.org>2022-07-13 20:33:14 +0200
commit3cd2cbd684e023682d04dd11d2640b53e4725790 (patch)
treea5c4c2c89b2a90e6132b000087c39021f99f4b90 /ovsdb/ovsdb.h
parent485ac63d10f8af22030c8b71de77094eee4f0672 (diff)
downloadopenvswitch-3cd2cbd684e023682d04dd11d2640b53e4725790.tar.gz
ovsdb: Prepare snapshot JSON in a separate thread.
Conversion of the database data into JSON object, serialization and destruction of that object are the most heavy operations during the database compaction. If these operations are moved to a separate thread, the main thread can continue processing database requests in the meantime. With this change, the compaction is split in 3 phases: 1. Initialization: - Create a copy of the database. - Remember current database index. - Start a separate thread to convert a copy of the database into serialized JSON object. 2. Wait: - Continue normal operation until compaction thread is done. - Meanwhile, compaction thread: * Convert database copy to JSON. * Serialize resulted JSON. * Destroy original JSON object. 3. Finish: - Destroy the database copy. - Take the snapshot created by the thread. - Write on disk. The key for this schema to be fast is the ability to create a shallow copy of the database. This doesn't take too much time allowing the thread to do most of work. Database copy is created and destroyed only by the main thread, so there is no need for synchronization. Such solution allows to reduce the time main thread is blocked by compaction by 80-90%. For example, in ovn-heater tests with 120 node density-heavy scenario, where compaction normally takes 5-6 seconds at the end of a test, measured compaction times was all below 1 second with the change applied. Also, note that these measured times are the sum of phases 1 and 3, so actual poll intervals are about half a second in this case. Only implemented for raft storage for now. The implementation for standalone databases can be added later by using a file offset as a database index and copying newly added changes from the old file to a new one during ovsdb_log_replace(). Reported-at: https://bugzilla.redhat.com/2069108 Acked-by: Dumitru Ceara <dceara@redhat.com> Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Diffstat (limited to 'ovsdb/ovsdb.h')
-rw-r--r--ovsdb/ovsdb.h24
1 files changed, 24 insertions, 0 deletions
diff --git a/ovsdb/ovsdb.h b/ovsdb/ovsdb.h
index ec2d235ec..2f77821e0 100644
--- a/ovsdb/ovsdb.h
+++ b/ovsdb/ovsdb.h
@@ -72,6 +72,24 @@ struct ovsdb_txn_history_node {
struct ovsdb_txn *txn;
};
+struct ovsdb_compaction_state {
+ pthread_t thread; /* Thread handle. */
+
+ struct ovsdb *db; /* Copy of a database data to compact. */
+
+ struct json *data; /* 'db' as a serialized json. */
+ struct json *schema; /* 'db' schema json. */
+ uint64_t applied_index; /* Last applied index reported by the storage
+ * at the moment of a database copy. */
+
+ /* Completion signaling. */
+ struct seq *done;
+ uint64_t seqno;
+
+ uint64_t init_time; /* Time spent by the main thread preparing. */
+ uint64_t thread_time; /* Time spent for compaction by the thread. */
+};
+
struct ovsdb {
char *name;
struct ovsdb_schema *schema;
@@ -101,6 +119,9 @@ struct ovsdb {
struct ovs_list txn_forward_new;
/* Hash map for transactions that are already sent and waits for reply. */
struct hmap txn_forward_sent;
+
+ /* Database compaction. */
+ struct ovsdb_compaction_state *snap_state;
};
struct ovsdb *ovsdb_create(struct ovsdb_schema *, struct ovsdb_storage *);
@@ -124,6 +145,9 @@ struct json *ovsdb_execute(struct ovsdb *, const struct ovsdb_session *,
struct ovsdb_error *ovsdb_snapshot(struct ovsdb *, bool trim_memory)
OVS_WARN_UNUSED_RESULT;
+void ovsdb_snapshot_wait(struct ovsdb *);
+bool ovsdb_snapshot_in_progress(struct ovsdb *);
+bool ovsdb_snapshot_ready(struct ovsdb *);
void ovsdb_replace(struct ovsdb *dst, struct ovsdb *src);