db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: order by
Date Thu, 02 Mar 2006 17:32:09 GMT
please note that your memory estimates for cache size could be way off,
I haven't seen the ddl for the table so not sure.  In some cases derby
will default to 32k pages rather than 4k (basically if there are blob or 
clob columns).  The page size is also user setable, but I assume that is 
not a factor here.  Also there is more overhead
per page than just the page, most of the overhead is per row per page
so if rows are very small compared to page size it is significant (on
the order of one object per row).

With memory leaks I usually recommend setting the cache size even 
smaller than 1000, say 100.  That way it is even quicker to tell the
difference between expected cache memory growth and some real problem.

Kristian Waagan wrote:
> Thomas Vatter wrote:
> 
>> Kristian Waagan <Kristian.Waagan@...> writes:
>>
>> ...
>>
>>
>> Hello Kristian,
>>
>> I'm doing this on a Windows XP system, I start all java processes with 
>> -Xmx1024m, I had a try with 2048 but the process did not start so I 
>> stayed with 1024. "Between 912 and 960" is the total usage for the 
>> machine, read from the task-manager. I have thought about it, derbys 
>> pageSize is 4k, I have increased pageCacheSize from 1.000 to 10.000, 
>> resulting in 40mb steps, this would explain that memory "ends" before 
>> 1024 is reached. Yes, I was unprecise for shortness with the word 
>> "record". I should have said "record in the main database table" or 
>> "dataset".
>> But you are right, a dataset (or line) in my spreadsheet has around 30 
>> fields only. I had the network server running on the described 
>> machine, because I am testing how derby performes in the network 
>> situation, because in the single user situation I have typically less 
>> data.
>>
>> tom
>>
>>
> 
> Okay, thank you for the answers.
> 
> Just to be clear, I would have tried running the Derby network server on 
> a separate machine, and see where the the memory usage goes sky-high; 
> the database machine or the application code machine.
> 
> You could also try running Derby with the default page cache size (1000 
> pages ~ 4MB) and *not* alter the JVM memory options. Performance could 
> go down, but if you are having problems with a memory leak it would show 
> pretty fast by getting an OutOfMemoryException.
> 
> 
> 
> 
> -- 
> Kristian
> 
> 


Mime
View raw message