db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kristian Waagan (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-3791) Excessive memory usage when fetching small Clobs
Date Fri, 25 Jul 2008 13:45:31 GMT

     [ https://issues.apache.org/jira/browse/DERBY-3791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Kristian Waagan updated DERBY-3791:

    Derby Info: [Regression]  (was: [Regression, Patch Available])

That is about right.
Of course there is an exception, and I'm not sure how to handle it yet.
When a Clob is created with Connection.createClob and grows big enough, or a Clob is fetched
from the database and then modified, data is copied to a temporary file on disk.
If you then read from this Clob again, you get a stack that looks something like this (seen
from Clob.getCharacterStream):

As far as I can see, this stack will be unbuffered (in our Java code, don't know how the OS
can help here) after patch 1a is applied.
The code is getting pretty complex down in LOBStreamControl and LOBFile, so I think patch
1a has to be reworked to account for the buffering in a sensible way higher up in the stack
- probably in UTF8Reader.

I didn't see any performance degradation in suites.All with the patch, but that probably just
means we don't test this code path very well. I'll see if I can write a series of tests and
maybe put them under java/testing/org/apache/derbyTesting/perf/basic/jdbc/.

I'm clearing the patch available flag, patch 1a will not be committed.

> Excessive memory usage when fetching small Clobs
> ------------------------------------------------
>                 Key: DERBY-3791
>                 URL: https://issues.apache.org/jira/browse/DERBY-3791
>             Project: Derby
>          Issue Type: Bug
>          Components: JDBC
>    Affects Versions:,,,
>            Reporter: Kristian Waagan
>            Assignee: Kristian Waagan
>            Priority: Minor
>         Attachments: derby-3791-1a-buffer_fix.diff
> When investigating DERBY-3312 I found out that performance with the embedded driver has
decreased a lot as well.
> Analysis on trunk indicate excessive memory usage, causing high allocation and garbage
collection costs.
> I believe there was another major performance problem in 10.3, but it appears fixed in
trunk. I have not spent time identifying this problem.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message