Red Hat Bugzilla – Bug 1294907
after a few successful appliance connections to VMDB, subsequent attempts to add additional appliances timeout
Last modified: 2016-09-21 10:18:55 EDT
Created attachment 1110642 [details]
tgz file contains two other tgz files for each of the two appliances described under 'Additional info'
Description of problem: long running sequence of sql queries initiated when a new appliance tries to insert itself into the VMDB timesout and the appliance is not associated with VMDB.
Version-Release number of selected component (if applicable):18.104.22.168
How reproducible: UNCERTAIN
Steps to Reproduce:
Actual results: multiple attempts to add a fourth appliance into an existing VMDB complex all fail with timeouts trying to add the new appliance into the VMDB.
Expected results: new appliance should be added into existing complex
a long running set of queries about various tables and relations are running longer than 5 minutes and evoke a timeout from the evm.log file. Customer modified to sql configuration file to capture all sql queries which are included in the attached set of logs.
A few items of note:
- Region # = 80. References to record ids that follow will assume that key prefix.
- first appliance is added with a key of '1'
- second appliance is added with a key of '2'
- third appliance added days after initial migration of database is added with a key of '634'
- the above gap in keys suggest that there is some kind of updating of the sequence field associated with the miq_servers table that may shed some light on what is happening.
- two key log sets from two appliances are provided: one from database owing appliance including postgresql.log referenced above and one from the appliance attempting to insert itself into the VMDB and timeout out.
- a copy of the database has been requested.
*** Bug 1294909 has been marked as a duplicate of this bug. ***
This BZ seems to be tracking the same issue as https://bugzilla.redhat.com/show_bug.cgi?id=1296335 do we want to consider these duplicates?
Yes, these are the same issue.
We perform many transactions. If the latency is above a local machine, then this can become painfully long.
Marking as a duplicate.
This is stemmed around the sheer quantity of sql queries performed at boot. probably associated with db seed process.
*** This bug has been marked as a duplicate of bug 1296335 ***