Write: 0xecf6eb0, 4096: There is not enough space on the disk.

Question

Our applications occasionally get the error in the function specified by set_errcall: "[prefix] write: 0xecf6eb0, 4096: There is not enough space on the disk. " Preceded by "DB00.db: write failed for page"
There most certainly is enough space on disk for one. In this most recent case, the Db::put's succeeded for a full hour before finally failing with an out of space error. At which point, I now have 30 log files and my own log files are filled with Berkeley error callbacks.
How come the set_errcall doesn't return an integer error code? If it did, we would be able to analyze that and decide any action to take. In this example, I might consider closing down all handles and checkpointing then removing logs since maybe the number of logs has gotten to large. Analyzing a string doesn't make sense since that might change with Berkeley versions.
Anyway, can anyone give any advice as to why we would get an out of space error (with plenty of disk space.) And also how to handle such an error.
Edited by: AMARCIONEK on Jun 3, 2009 10:10 AM

Answer 1

The platform is C++ API version 4.7.25 running on Windows Server 2003 Enterprise SP2. The database is on an NTFS disk. We have tested database files up to 20GB in size. The following is my config.
m_pDbEnvironment->set_cachesize(0, 10 * 1024 * 1024, 1);
m_pDbEnvironment->set_lg_max(20000000);
m_pDbEnvironment->set_lg_bsize(10 * 1024 * 1024);
m_pDbEnvironment->set_mp_max_write(4, 0);
m_pDbEnvironment->set_mp_mmapsize(2 * 1024 * 1024);
m_pDbEnvironment->set_mp_max_openfd(1);
// set the alloc methods into the environment
m_pDbEnvironment->set_alloc(QPRT_ALLOC, QPRT_REALLOC, QPRT_FREE);
m_pDbEnvironment->set_lk_detect(DB_LOCK_YOUNGEST);
m_pDbEnvironment->set_timeout(500000, DB_SET_LOCK_TIMEOUT);
m_pDbEnvironment->set_timeout(200000, DB_SET_TXN_TIMEOUT);
m_pDbEnvironment->set_flags(DB_REGION_INIT, 1);
m_pDbEnvironment->set_tx_max(5000);
m_pDbEnvironment->set_flags(DB_TXN_WRITE_NOSYNC, 1);
m_pDbEnvironment->log_set_config(DB_LOG_ZERO, 1);
m_pDbEnvironment->set_lk_max_lockers(5000);
m_pDbEnvironment->set_lk_max_locks(5000);
m_pDbEnvironment->set_lk_max_objects(5000);
m_pDbEnvironment->open((zKSz)sPath,     DB_CREATE | DB_INIT_LOCK | DB_INIT_LOG | DB_INIT_MPOOL |
                                   DB_THREAD | DB_INIT_TXN | DB_RECOVER | DB_LOCKDOWN,
                                   0);
We also checkpoint every 2 to 5 minutes with a 5MB threshold. We also explicitly call pDbEnvironment->log_archive(kpNil, DB_ARCH_REMOVE) after checkpointing.
Primary and (up to 4) secondary databases are opened with DB_CREATE | DB_AUTO_COMMIT flags.
I'd also appreciate any suggestions as to how to lower the memory footprint used by Berkeley. Ever since we've integrated this DB, our memory usage has been too large and inconsistent. There are 6 independent environments the product uses during runtime. Each of these environments have a primary database and (up to 4) secondary databases, which are all opened with DB_CREATE | DB_AUTO_COMMIT flags.
Just recently we have added a memp_trickle every 5 seconds at 40% (Anything lower and it has no affect in the environment, in other words, db_stat shows dirty pages forced from the cached instead of trickled.) We are trying to reproduce this issue at this point.