db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steffen Kuche (Updated) (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DERBY-5555) Execution Time with a Statement 1 ms with a PreparedStatement 3 minutes
Date Fri, 23 Dec 2011 12:06:31 GMT

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

Steffen Kuche updated DERBY-5555:
---------------------------------

    Description: 
Sounds incrediable? Test it by yourself with the attached program.

The issued reased up because of AMQ-3644, but it is actually a derby problem so I post the
issue here as well.

Derby writes multiple gigabyte of temporary files in its tmp directory during one select statement.
Afterwards these temporary files are deleted and rebuild by the next Statement. 

You can find a Test-Program (import it as a Maven-Eclipse project) which reproduces this issue.
This program creates a derby database with a the activemq Message table and fills it with
data (2000 Messages, this can take several hours). I assumed 3MB for one message as our messages
contain same binary data and has an average size of 3MB.

After the database is built one time a Statement and one time a PreparedStatment is used to
retrieve the next messages.
The Statement takes about 1 ms and the PreparedStatement about 258805 ms. Also the second
PreparedStatement takes as much time.

Here are the temporary files created by derby during the select Statement:

{noFormat}
insgesamt 5,4G
 287M 2011-12-23 09:48 T1324630116288.tmp
 287M 2011-12-23 09:49 T1324630116289.tmp
 287M 2011-12-23 09:49 T1324630116290.tmp
 287M 2011-12-23 09:49 T1324630116291.tmp
 287M 2011-12-23 09:49 T1324630116292.tmp
 287M 2011-12-23 09:49 T1324630116293.tmp
 287M 2011-12-23 09:50 T1324630116294.tmp
 287M 2011-12-23 09:50 T1324630116295.tmp
 287M 2011-12-23 09:50 T1324630116296.tmp
 287M 2011-12-23 09:50 T1324630116297.tmp
 287M 2011-12-23 09:51 T1324630116298.tmp
 287M 2011-12-23 09:51 T1324630116299.tmp
 287M 2011-12-23 09:51 T1324630116300.tmp
 287M 2011-12-23 09:51 T1324630116301.tmp
 287M 2011-12-23 09:51 T1324630116302.tmp
 287M 2011-12-23 09:52 T1324630116303.tmp
 287M 2011-12-23 09:52 T1324630116304.tmp
 287M 2011-12-23 09:52 T1324630116305.tmp
 284M 2011-12-23 09:52 T1324630116306.tmp
{noFormat}


  was:
Sounds incrediable? Test it by yourself with the attached program.

The issued reased up because of AMQ-3644, but it is actually a derby problem so I post the
issue here as well.

Derby writes multiple gigabyte of temporary files in its tmp directory during one select statement.
Afterwards these temporary files are deleted and rebuild by the next Statement. 

You can find a Test-Program (import it as a Maven-Eclipse project) which reproduces this issue.
This program creates a derby database with a the activemq Message table and fills it with
data (2000 Messages, this can take several hours). I assumed 3MB for one message as our messages
contain same binary data and has an average size of 3MB.

After the database is built one time a Statement and one time a PreparedStatment is used to
retrieve the next messages.
The Statement takes about 1 ms and the PreparedStatement about 258805 ms. Also the second
PreparedStatement takes as much time.

Here are the temporary files created by derby during the select Statement:
{noFormat}
insgesamt 5,4G
 287M 2011-12-23 09:48 T1324630116288.tmp
 287M 2011-12-23 09:49 T1324630116289.tmp
 287M 2011-12-23 09:49 T1324630116290.tmp
 287M 2011-12-23 09:49 T1324630116291.tmp
 287M 2011-12-23 09:49 T1324630116292.tmp
 287M 2011-12-23 09:49 T1324630116293.tmp
 287M 2011-12-23 09:50 T1324630116294.tmp
 287M 2011-12-23 09:50 T1324630116295.tmp
 287M 2011-12-23 09:50 T1324630116296.tmp
 287M 2011-12-23 09:50 T1324630116297.tmp
 287M 2011-12-23 09:51 T1324630116298.tmp
 287M 2011-12-23 09:51 T1324630116299.tmp
 287M 2011-12-23 09:51 T1324630116300.tmp
 287M 2011-12-23 09:51 T1324630116301.tmp
 287M 2011-12-23 09:51 T1324630116302.tmp
 287M 2011-12-23 09:52 T1324630116303.tmp
 287M 2011-12-23 09:52 T1324630116304.tmp
 287M 2011-12-23 09:52 T1324630116305.tmp
 284M 2011-12-23 09:52 T1324630116306.tmp
{noFormat}


    
> Execution Time with a Statement 1 ms with a PreparedStatement 3 minutes
> -----------------------------------------------------------------------
>
>                 Key: DERBY-5555
>                 URL: https://issues.apache.org/jira/browse/DERBY-5555
>             Project: Derby
>          Issue Type: Bug
>            Reporter: Steffen Kuche
>
> Sounds incrediable? Test it by yourself with the attached program.
> The issued reased up because of AMQ-3644, but it is actually a derby problem so I post
the issue here as well.
> Derby writes multiple gigabyte of temporary files in its tmp directory during one select
statement. Afterwards these temporary files are deleted and rebuild by the next Statement.

> You can find a Test-Program (import it as a Maven-Eclipse project) which reproduces this
issue.
> This program creates a derby database with a the activemq Message table and fills it
with data (2000 Messages, this can take several hours). I assumed 3MB for one message as our
messages contain same binary data and has an average size of 3MB.
> After the database is built one time a Statement and one time a PreparedStatment is used
to retrieve the next messages.
> The Statement takes about 1 ms and the PreparedStatement about 258805 ms. Also the second
PreparedStatement takes as much time.
> Here are the temporary files created by derby during the select Statement:
> {noFormat}
> insgesamt 5,4G
>  287M 2011-12-23 09:48 T1324630116288.tmp
>  287M 2011-12-23 09:49 T1324630116289.tmp
>  287M 2011-12-23 09:49 T1324630116290.tmp
>  287M 2011-12-23 09:49 T1324630116291.tmp
>  287M 2011-12-23 09:49 T1324630116292.tmp
>  287M 2011-12-23 09:49 T1324630116293.tmp
>  287M 2011-12-23 09:50 T1324630116294.tmp
>  287M 2011-12-23 09:50 T1324630116295.tmp
>  287M 2011-12-23 09:50 T1324630116296.tmp
>  287M 2011-12-23 09:50 T1324630116297.tmp
>  287M 2011-12-23 09:51 T1324630116298.tmp
>  287M 2011-12-23 09:51 T1324630116299.tmp
>  287M 2011-12-23 09:51 T1324630116300.tmp
>  287M 2011-12-23 09:51 T1324630116301.tmp
>  287M 2011-12-23 09:51 T1324630116302.tmp
>  287M 2011-12-23 09:52 T1324630116303.tmp
>  287M 2011-12-23 09:52 T1324630116304.tmp
>  287M 2011-12-23 09:52 T1324630116305.tmp
>  284M 2011-12-23 09:52 T1324630116306.tmp
> {noFormat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message