Optimizing Put Performance in Berkeley DB -
i started playing berkeley db few days ago i'm trying see if there's i've been missing when comes storing data fast possible.
here's info data: - comes in 512 byte chunks - chunks come in order - chunks deleted in fifo order - if lose data off end because of power failure that's ok long whole db isn't broken
after reading bunch of documentation seemed queue db wanted.
however, after trying test code fastest results 1mbyte per second looping through db->put db_append set. tried using transactions , bulk puts both of these slowed things down considerably didn't pursue them time. inserting fresh db created on nandflash chip on freescale i.mx35 dev board.
since we're looking @ least 2mbytes per second write speeds, wondering if there's missed can improve speeds since know hardware can write faster this.
try putting db_config:
set_flags db_txn_write_nosync set_flags db_txn_nosync
from experience, these increase write performance lot.
db_txn_nosync
if set, berkeley db not write or synchronously flush log on transaction commit or prepare. means transactions exhibit aci (atomicity, consistency, , isolation) properties, not d (durability); is, database integrity maintained, if application or system fails, possible number of committed transactions may undone during recovery. number of transactions @ risk governed how many log updates can fit log buffer, how operating system flushes dirty buffers disk, , how log checkpointed calling db_env->set_flags db_txn_nosync flag affects specified db_env handle (and other berkeley db handles opened within scope of handle). consistent behavior across environment, db_env handles opened in environment must either set db_txn_nosync flag or flag should specified in db_config configuration file.the db_txn_nosync flag may used configure berkeley db @ time during life of application.
db_txn_write_nosync
if set, berkeley db write, not synchronously flush, log on transaction commit or prepare. means transactions exhibit aci (atomicity, consistency, , isolation) properties, not d (durability); is, database integrity maintained, if system fails, possible number of committed transactions may undone during recovery. number of transactions @ risk governed how system flushes dirty buffers disk , how log checkpointed. calling db_env->set_flags db_txn_write_nosync flag affects specified db_env handle (and other berkeley db handles opened within scope of handle). consistent behavior across environment, db_env handles opened in environment must either set db_txn_write_nosync flag or flag should specified in db_config configuration file.the db_txn_write_nosync flag may used configure berkeley db @ time during life of application.
see http://www.mathematik.uni-ulm.de/help/berkeleydb/api_c/env_set_flags.html more details.
Comments
Post a Comment