|
History
| Log In
|
|
|
|
Upgrade is running raw measurement delete from eam_measurement for 11 hours on performance stack which is running Postgres8.2.5.
DELETE FROM EAM_MEASUREMENT WHERE measurement_class='R' Link to root cause bug which will be fixed in 3.2.2 and 4.0
I have fixed the problem with deletes from EAM_MEASUREMENT taking too long via There are still some slow statements: DELETE FROM EAM_MEASUREMENT_TEMPL WHERE default_interval=0 This is because there is no index on default_interval. I'll log another bug to handle this case. The other slow part is the migrations info the HQ_AVAIL_DATA_RLE for availability, but I'm not sure what we can do about that. On second thought, we don't need an index on default_interval for normal HQ operation. I'm going to close this ticket, please retest and post upgrade times. (on gsx1 since we have complete times for this upgrade) If they are unacceptable, we can create a temporary index on this column so deletes occur quickly. It still takes 90 minutes and 5 seconds in build 652
The upgrade of hq.hyperic.net's DB took 221 minutes 7 seconds before failing creating the index noted in Fixes have gone in for both the RLE upgrade and Measurement upgrade. Please retest. It still takes 26 minutes 25 seconds to upgrade.Attached is a hq-install.log.debug
Upgrade points that are slow : [dbupgrade] Upgrading 3.96.7 -> 3.97 [schema-addColumn] >>>>> Adding column RESOURCE_ID (type=INTEGER) to table [dbupgrade] Upgrading 3.102 -> 3.103 [schema-addColumn] >>>>> Adding column RESOURCE_ID (type=INTEGER) to table EAM_EVENT_LOG [dbupgrade] Upgrading 3.105 -> 3.105.1 [availRLEUpgrade] *** UPGRADE TASK: migrating availability data to Run Length Encoded Availability |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Developer
Reopened
Major
Upgrade takes around 26 minutes 25 seconds to complete
I noticed this problem with GSX1's database when I loaded it locally on my machine. However, demo's database which is 2x the size completed in a few minutes. Do you have other environments we can test? Maybe it's confined to upgrades which use postgres 8.1?