New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Performance regression introduced in 9.4-1202 #394

Closed
schlosna opened this Issue Oct 10, 2015 · 5 comments

Comments

Projects
None yet
3 participants
@schlosna
Contributor

schlosna commented Oct 10, 2015

After the changes in cddcd18 (in 9.4-1202 release), we have seen increased contention in TypeInfoCache. Under high concurrency (e.g. 64 concurrent DB connections), we have seen a 5x degradation in performance with 9.4-1202 compared to 9.4-1201.

Stack Trace                                                                          Percentage(%)
org.postgresql.jdbc2.TypeInfoCache.getSQLType(String)                                6.4
  org.postgresql.jdbc2.TypeInfoCache.getSQLType(int)                                 6.4
    org.postgresql.jdbc2.AbstractJdbc2ResultSet.getSQLType(int)                      6.4
      org.postgresql.jdbc2.AbstractJdbc2ResultSet.internalGetObject(int, Field)      3
        org.postgresql.jdbc3.AbstractJdbc3ResultSet.internalGetObject(int, Field)    3
          org.postgresql.jdbc4.AbstractJdbc4ResultSet.internalGetObject(int, Field)  3
            org.postgresql.jdbc2.AbstractJdbc2ResultSet.getObject(int)               3
              com.zaxxer.hikari.proxy.HikariResultSetProxy.getObject(int)            3
      org.postgresql.jdbc4.AbstractJdbc4ResultSet.internalGetObject(int, Field)      2
        org.postgresql.jdbc2.AbstractJdbc2ResultSet.getObject(int)                   2
          com.zaxxer.hikari.proxy.HikariResultSetProxy.getObject(int)                2
      org.postgresql.jdbc3.AbstractJdbc3ResultSet.internalGetObject(int, Field)      1.4
        org.postgresql.jdbc4.AbstractJdbc4ResultSet.internalGetObject(int, Field)    1.4
          org.postgresql.jdbc2.AbstractJdbc2ResultSet.getObject(int)                 1.4
            com.zaxxer.hikari.proxy.HikariResultSetProxy.getObject(int)              1.4

vlsi added a commit to Gordiychuk/pgjdbc that referenced this issue Oct 12, 2015

fix: avoid memory leak when redeploying pgjdbc
FAST_NUMBER_FAILED is used as a control-flow-exception pattern, thus it does not require a stacktrace.
It turns out Throwable might store strong reference to a class, thus it might result in OutOfMemory

closes pgjdbc#394

vlsi added a commit to Gordiychuk/pgjdbc that referenced this issue Oct 12, 2015

fix: avoid memory leak when redeploying pgjdbc
FAST_NUMBER_FAILED is used as a control-flow-exception pattern, thus it does not require a stacktrace.
It turns out Throwable might store strong reference to a class, thus it might result in OutOfMemory

closes pgjdbc#394
@vlsi

This comment has been minimized.

Member

vlsi commented Oct 13, 2015

Well, I did not intend to fix this particular issue via d7cab7b. That was a typo.

@davecramer

This comment has been minimized.

Member

davecramer commented Oct 13, 2015

? Does this need to be reverted ?

Dave Cramer

On 13 October 2015 at 06:53, Vladimir Sitnikov notifications@github.com
wrote:

Well, I did not intend to fix this particular issue via d7cab7b
d7cab7b.
That was a typo.


Reply to this email directly or view it on GitHub
#394 (comment).

@vlsi

This comment has been minimized.

Member

vlsi commented Oct 13, 2015

No it does not. d7cab7b fixes problem reported in http://comments.gmane.org/gmane.comp.db.postgresql.jdbc/22111 (AbstractJdbc2ResultSet.FAST_NUMBER_FAILED brings class loader leak)

@schlosna

This comment has been minimized.

Contributor

schlosna commented Oct 20, 2015

Should this be reopened?

@vlsi

This comment has been minimized.

Member

vlsi commented Oct 20, 2015

It should not. We have #393.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment