Closed GoogleCodeExporter closed 8 years ago
I am surprised of what you suppose about JIRA and about this graph, without
giving any other measured metrics.
Moreover, the maximum of connections may perhaps be related to the "used jdbc
connections" graph, but it is pointless to relate the maximum to the "active
jdbc connections".
Note that "active jdbc connections" is the number of connections executing a
SQL query. (Fetching the result of a SQL query or rendering a http response do
not count in "active jdbc connections".)
In fact, your graph seems correct to me.
So I think that we can close this issue as invalid.
OK?
Original comment by evernat@free.fr
on 14 Feb 2014 at 9:39
Last week I got JIRA running out of database connections (30), and after this I
installed Java Melody, hopping that it will help me track the connections, so I
would know if they are lost or was just a very short peak.
My JIRA instance is under heady load and I do see 1-2 db connections, never
more than this, even while jira is performing a background reindex.
Original comment by sorin.sb...@gmail.com
on 18 Feb 2014 at 6:15
Attachments:
I still think that the "active jdbc connections" graph is correct.
Given that PDF report, what has happen is probably:
- starting just before 14h00, 18 Feb, cpu is completely saturated (almost 100%
until 14h30),
- at about 14h30, this high cpu causes active threads and system load average
to skyrocket in just 1 or 2 minutes (86 active threads and system load of 29
were recorded), but jdbc connections seem still ok,
- in this situation, your server is now in limbo and can't answer to anyone,
- the jdbc connections may have reached the maximum of 30, but given that all
users were trying again and again to have a sign of life from the server,
that's probably just a side effect,
- of course, the server finally crashed or was killed.
So, I think that you can:
- either increase cpu resources,
- or find why cpu was saturated (take thread dumps next time with
http://host/monitoring?part=threadsDump). And you may start with why getting
the batch.css from your server is slow (which is probably the root cause and
which is a known issue in JIRA servers for several reasons).
If I am right, I have saved many thousand dollars from your frustrated users
and boss.
Original comment by evernat@free.fr
on 20 Feb 2014 at 11:17
As said before, the "active jdbc connections" graph is correct.
So resolving the issue as invalid.
Original comment by evernat@free.fr
on 8 Mar 2014 at 10:01
Original issue reported on code.google.com by
sorin.sb...@gmail.com
on 9 Feb 2014 at 12:55Attachments: