db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jerry Lampi <...@sdsusa.com>
Subject Proper configuration for a very busy DB?
Date Mon, 30 Sep 2013 19:28:39 GMT
We have about 30 clients that connect to our version Derby DB.

The clients are programs that gather data from the operating system of 
their host and then store that data in the DB, including FTP activity.  
Sometimes, the clients get huge flurries of data all at once and Derby 
is unable to handle the influx of requests; inserts, updates, etc.  In 
addition, the clients are written so that if they are unable to talk to 
the DB, they queue up as much data as possible and then write it to the 
DB when the DB becomes available.

This client queuing is a poor design, and places greater stress on the 
DB, as when the 30 clients finally do talk to the DB, they all dump data 
at once.  The clients do not know about one another and therefore do not 
attempt any throttling or cooperation when dumping on the DB.

The net effect of all this is that the DB is too slow to keep up with 
the clients.  As clients try to feed data to the DB, it cannot accept it 
as fast as desired and this results in the clients queueing more data, 
exacerbating the issue.

So the DB is very busy.  The only significant thing we have done thus 
far is change the derby.storage.pageCacheSize=5000 and increase Java 
heap to 1536m.

Is there a configuration considered optimal for a VERY busy Derby DB?



avast! Antivirus: Outbound message clean.
Virus Database (VPS): 130930-0, 09/30/2013
Tested on: 9/30/2013 2:28:40 PM
avast! - copyright (c) 1988-2013 AVAST Software.

View raw message