dbTalk Databases Forums  

bad performance

comp.databases.berkeley-db comp.databases.berkeley-db


Discuss bad performance in the comp.databases.berkeley-db forum.



Reply
 
Thread Tools Display Modes
  #1  
Old   
Giambattista Bloisi
 
Posts: n/a

Default bad performance - 11-25-2003 , 06:50 AM






Hi,
I have an application that has an HASH db where I make a lot of data
update for each record.
Performance seems to be pretty good, but all the update seems to be reported
just in memory.
When I use the sync method after each update to synchronize them to the
file, the db became very slow (twice than gdbm).

There is another faster method to ensure that record are updated on file ?

Thanks,
Giambattista Bloisi



Reply With Quote
  #2  
Old   
Keith Bostic
 
Posts: n/a

Default Re: bad performance - 12-02-2003 , 07:46 AM






"Giambattista Bloisi" <DONT (AT) SPAM (DOT) ME> wrote

Quote:
I have an application that has an HASH db where I make a lot of data
update for each record. Performance seems to be pretty good, but all
the update seems to be reported just in memory. When I use the sync
method after each update to synchronize them to the file, the db
became very slow (twice than gdbm).
The sync method has to flush one, and possibly more database
pages, to disk. That means it's going to be slow.

I'm guessing your reason to flush the database to disk is to
ensure data durability (that is, to ensure that you don't lose
data when the application or system fails)? If durability is
what you want, you're only shrinking the window of possible data
loss by calling the sync method, you can still lose data if you
crash at the wrong time.

If you want durability, you should write a transactional
application, one that uses transactions to ensure durability,
not repeated calls to the sync method. In addition, a
transactional program will run much faster than calling sync
repeatedly.

Regards,
--keith

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Keith Bostic bostic (AT) sleepycat (DOT) com
Sleepycat Software Inc. keithbosticim (ymsgid)
118 Tower Rd. +1-781-259-3139
Lincoln, MA 01773 http://www.sleepycat.com


Reply With Quote
  #3  
Old   
Giambattista Bloisi
 
Posts: n/a

Default Re: bad performance - 12-05-2003 , 06:07 AM



Quote:
[...]
Thank you, I swiched to a transaction approach and performance are pretty
good. Gdbm remains a bit faster but it hasn't recoverability.
I noticed there is no way to set the maximum disk space used by log files,
even if using DB_LOG_AUTOREMOVE.
What happens in case of disk full ?

Thanks again,
Giambattista




Reply With Quote
  #4  
Old   
Keith Bostic
 
Posts: n/a

Default Re: bad performance - 12-08-2003 , 09:16 PM



"Giambattista Bloisi" <DONT (AT) SPAM (DOT) ME> wrote


Quote:
I swiched to a transaction approach and performance are pretty
good. Gdbm remains a bit faster but it hasn't recoverability.
I noticed there is no way to set the maximum disk space used by
log files, even if using DB_LOG_AUTOREMOVE. What happens in
case of disk full ?
If the disk fills up, then transactions that are modifying the
databases will start to fail, until disk space is made
available. Read operations will continue to succeed, of course.

Regards,
--keith

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Keith Bostic bostic (AT) sleepycat (DOT) com
Sleepycat Software Inc. keithbosticim (ymsgid)
118 Tower Rd. +1-781-259-3139
Lincoln, MA 01773 http://www.sleepycat.com


Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.