205a8b3037
Secure RBAC, along with numerous periodics, and even some common API access patterns heavily access the ironic database and sometimes cause queries across multiple columns to match nodes to return. None of this is bad, but what is bad is we didn't have indexes on these columns. This change adds docs, and the schema upgrade to create the column indexes, and a release note to provide more visible documentation for operators. It must be stressed that this does *not* improve query times when all records are asked for on a database connection. Also adds an upgrade check in to raise a warning for operator visibility. Story: 2008863 Task: 42392 Change-Id: I76821c032180a58d0f99d31110fbe0f844c0cb3f
36 lines
1.5 KiB
YAML
36 lines
1.5 KiB
YAML
---
|
|
upgrade:
|
|
- |
|
|
The ``ironic-dbsync upgrade`` command for this verison of ironic will add
|
|
additional database indexes on the ``nodes`` table columns below.
|
|
Depending on database size and complexity, this will take time to complete
|
|
for every single index to be created. On MySQL or MariaDB, these indexes
|
|
will only be created if an index does not already exist matching the
|
|
field name with "_idx"
|
|
appended.:
|
|
|
|
* ``owner``
|
|
* ``lessee``
|
|
* ``driver``
|
|
* ``provision_state``
|
|
* ``reservation``
|
|
* ``conductor_group``
|
|
* ``resource_class``
|
|
|
|
An example of the SQL commands to generate these indexes can be found
|
|
in the `tuning <htts://docs.openstack.org/ironic/latest/admin/tuning.html>`_
|
|
documentation.
|
|
|
|
In testing with mock data, each column took approximately about 4 seconds
|
|
per column to be indexed on a database with 115,000 rows. The existing
|
|
database size, and underlying server load will casue this time to vary.
|
|
Sample queries also reduced result generation from an average of ``0.40``
|
|
seconds to an average of ``0.02`` seconds with a test data set.
|
|
fixes:
|
|
- |
|
|
Improves lower level performance issues with database activity where some
|
|
often queried columns were not indexed when the database model was created,
|
|
or as the model evolved. Operators seeking to pre-create these indexes may
|
|
do so prior to upgrading. Please consult the
|
|
`tuning`_ documentation in the Administrator's guide for the queries to leverage.
|