Discussions
Categories
- 385K All Categories
- 2.6K Data
- 582 Big Data Appliance
- 2K Data Science
- 452.1K Databases
- 222.3K General Database Discussions
- 3.8K Java and JavaScript in the Database
- 32 Multilingual Engine
- 575 MySQL Community Space
- 479 NoSQL Database
- 7.9K Oracle Database Express Edition (XE)
- 3.1K ORDS, SODA & JSON in the Database
- 575 SQLcl
- 4K SQL Developer Data Modeler
- 187.7K SQL & PL/SQL
- 21.5K SQL Developer
- 12 Data Integration
- 12 GoldenGate
- 297.7K Development
- 3 Application Development
- 18 Developer Projects
- 140 Programming Languages
- 294.3K Development Tools
- 118 DevOps
- 3.1K QA/Testing
- 646.4K Java
- 30 Java Learning Subscription
- 37K Database Connectivity
- 185 Java Community Process
- 107 Java 25
- 22.2K Java APIs
- 138.3K Java Development Tools
- 165.3K Java EE (Java Enterprise Edition)
- 21 Java Essentials
- 172 Java 8 Questions
- 86K Java Programming
- 82 Java Puzzle Ball
- 65.1K New To Java
- 1.7K Training / Learning / Certification
- 13.8K Java HotSpot Virtual Machine
- 94.3K Java SE
- 13.8K Java Security
- 206 Java User Groups
- 24 JavaScript - Nashorn
- Programs
- 583 LiveLabs
- 41 Workshops
- 10.2K Software
- 6.7K Berkeley DB Family
- 3.6K JHeadstart
- 5.7K Other Languages
- 2.3K Chinese
- 191 Deutsche Oracle Community
- 1.1K Español
- 1.9K Japanese
- 240 Portuguese
when will Berkeley DB rebuild the B-tree Index if restart the application
Hi, I'm using Berkeley DB JE HA as store engine in our application. There were about 200,000,000 records stored in DB.
Our CacheMode is Evict_LN. Without the cache, there would be lots of random disk I/O in our application, which will cause large performance degradation.
When updating our service, we need to restart the JVM. I wonder when will Berkeley DB rebuild the cache in memory. Thank you.
Answers
-
In the context of your question, building the cache (B+ Tree) will be done almost at the beginning of restarting the process. Unless the cache is built, JE Environment is not ready for any operation. So, you can say that cache is built as part of the initialization of an JE HA environment. The B+ tree would actually be built from the .jdb files in the environment root.
Also, to estimate the size of this cache (this cache is in the JVM heap), there is a utility called DbCacheSize which would give an estimate of how much memory would be required for the cache. It is recommended that at least all the internal nodes of the B+ tree should fit in the cache, given that Evict_LN cache mode is used. Accordingly JVM heap size can be set based on other heap requirements: application requirements of heap, internal JVM usages of heap like GC overhead heap space requirements etc.
-
Thank you for your reply!
The cache size is about 6~7 GB of 200,000,000 records by running the DbCacheSize utility. However, when I restarted the JE application, the Java heap only occupied 1 GB memory. Only after I traverse all the records via a simple cursor(not a diskorderedcursor), the heap gradually reached the estimated size, which seems like a cache warm up process. In je.stat.csv, only several hundreds of BINs were cached at the beginning, when the traverse process ends, the number of cached BINs reached about 2,800,000, which was corresponding to the records count 200,000,000 and a nodeMaxEntry 128.
Maybe the b+tree wouldn't be built until the records were random accessed.