Bug 999165
Summary: | Frequent statement timeouts while updating availabilities | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Other] RHQ Project | Reporter: | John Sanda <jsanda> | ||||||
Component: | Core Server | Assignee: | Jay Shaughnessy <jshaughn> | ||||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Mike Foley <mfoley> | ||||||
Severity: | urgent | Docs Contact: | |||||||
Priority: | urgent | ||||||||
Version: | 4.9 | CC: | hrupp, mfoley | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | Unspecified | ||||||||
OS: | Unspecified | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2015-12-21 13:59:34 UTC | Type: | Bug | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Bug Depends On: | |||||||||
Bug Blocks: | 998945 | ||||||||
Attachments: |
|
Description
John Sanda
2013-08-20 20:38:33 UTC
Created attachment 788652 [details]
The server log
Created attachment 788653 [details]
postgres log
Is that still an issue or just temporary? Could this be related to the jdbc driver version that we use as 9.2-1000 seems to have introduced query timeouts: http://jdbc.postgresql.org/changes.html#version_9.2-1000 I personally did not see those timeouts yet. I think this is related to bug 1000584. I have not see the timeouts in my local environment. I only encountered them in test environments with less resources (CPU, memory, etc.). This was filed before our recent mergeAvail changes. The GWT times BZ may have solved this. But as the original description talks about backfilling, it may also be something else. Let's see if the recent changes helped to solve this issue. commit d01bb14a36a1121d377dc2445d1456c611c37007 Author: Jay Shaughnessy <jshaughn> Date: Mon Dec 9 14:13:52 2013 -0500 I did a visual inspection of code looking for things that may contribute to the slow updates and/or timeouts reported in these BZs. In general the updates for availReports (infrequent but can spike in certain scenarios, 1 per avail report) and availPing (frequent, 1 per minute per agent) should be very fast and not in themselves be an issue. Slowness in these queries is likely caused by the Agent table being locked by some other longer running transaction. Everything looked pretty clean with one exception. When backfilling an agent due to an agent shutdown or suspect job detection, it looked like we may have locked th agent table for the duration of the backfilling, which can be a fairly large operation for a big agent inventory. I'm not sure this is the problem, but this commit should allevaite the Agent table locking while the backfilling is performed. Also: - move some inline JPA updates on the Agent to be NamedQuery in the Agent entity. No need to build those every time we update an agent ping time. Closing, no follow up after fix 2 years ago. |