|
|
|
|
|
|
| Author |
Message |
Sue
*nix forums beginner
Joined: 28 Jul 2005
Posts: 18
|
 Posted: Mon Jun 05, 2006 9:52 pm Post subject:
Re: Can't get fill factor high enough
|
|
|
Ron wrote:
| Quote: |
Sue,
If you can send us a test program (hopefully not to large and does not
require installation of other packages) that will compile cleanly and
some sample data I will review your application and try to figure out
what is going on. Please send the program and data as well as telling
us the version of Berkeley DB you are running and the OS. Send this
information to support... I'm not typing the @sleepycat.com due to
Spam.
Ron
|
Terrific. I think I've got a decent reproducer written, just verifying
that it truly
shows the same strangeness before sending it on.
Sue |
|
| Back to top |
|
 |
Ron
*nix forums Guru Wannabe
Joined: 01 Apr 2005
Posts: 157
|
| Posted: Fri Jun 02, 2006 3:28 pm Post subject:
Re: Can't get fill factor high enough
|
|
|
Sue wrote:
| Quote: | Ron wrote:
If you search on the newsgroup that you posted to you will find
several entries discussing integer keys on Little Endian Systems. I
believe that is the problem you are observing. There is also an FAQ in
our Developer Zone which discusses the problem and the solution.
The faq posting can be found here:
http://dev.sleepycat.com/resources/faq_show.html?id=70&back=%3Faction%3Dsearch
Alternatively you can search in this newsgroup and review a couple of
the responses.
Once you are set with that you may want to review this thread on
performance:
http://tinyurl.com/p6tes
Ron
Thank you Ron, but as I pointed out in the initial message, I've
already got the little endian issue addressed and I've read everything
here, on the Sleepycat website and elsewhere on the web without
success. I'm looking for out-of-the-ordinary suggestions here, as
I've tried everything else.
|
Sue,
If you can send us a test program (hopefully not to large and does not
require installation of other packages) that will compile cleanly and
some sample data I will review your application and try to figure out
what is going on. Please send the program and data as well as telling
us the version of Berkeley DB you are running and the OS. Send this
information to support... I'm not typing the @sleepycat.com due to
Spam.
Ron |
|
| Back to top |
|
|
Sue
*nix forums beginner
Joined: 28 Jul 2005
Posts: 18
|
| Posted: Thu Jun 01, 2006 6:49 pm Post subject:
Re: Can't get fill factor high enough
|
|
|
Ron wrote:
| Quote: |
If you search on the newsgroup that you posted to you will find
several entries discussing integer keys on Little Endian Systems. I
believe that is the problem you are observing. There is also an FAQ in
our Developer Zone which discusses the problem and the solution.
The faq posting can be found here:
http://dev.sleepycat.com/resources/faq_show.html?id=70&back=%3Faction%3Dsearch
Alternatively you can search in this newsgroup and review a couple of
the responses.
Once you are set with that you may want to review this thread on
performance:
http://tinyurl.com/p6tes
Ron
|
Thank you Ron, but as I pointed out in the initial message, I've
already got the little endian issue addressed and I've read everything
here, on the Sleepycat website and elsewhere on the web without
success. I'm looking for out-of-the-ordinary suggestions here, as
I've tried everything else. |
|
| Back to top |
|
|
Ron
*nix forums Guru Wannabe
Joined: 01 Apr 2005
Posts: 157
|
| Posted: Thu Jun 01, 2006 3:29 pm Post subject:
Re: Can't get fill factor high enough
|
|
|
Sue wrote:
| Quote: | I'm using Sleepycat 4.4.20, C API. I've been struggling trying to get
the fill factor for one of my databases higher than 51%, and failing
miserably. Hopefully someone has some ideas.
Database is a Btree, running on an Opteron Solaris 10 system. Page
size is set to 16384. Key size is 12 (1 32-bit integer and 1 64-bit
integer), and I've got an insert sort function that appears to be
working correctly. Data size is 28, if that matters. Duplicates are
not allowed in this database.
The key is an object ID (64-bit), with a 'container' ID (32-bit).
Neither is unique by itself, but the combination creates a unique ID.
I originally tried sorting on the 64-bit integer first, then the 32-bit
integer. This resulted in about a 55% fill rate, but was exceptionally
slow - presumably because there are a LOT more Objects than Containers.
Switching to using the container ID as the primary sort sped things up
by an order of magnitude (!), but the fill factor sank even lower, to
50%. Dumping the database didn't show anything that looked
extraordinary - getting 314 entries/leaf most times.
Questions are:
1. Any idea why there is such a huge speed difference when sorting on
the container ID vs. the object ID? (note: For retrieval purposes, it
may actually be better to keep it sorting this way, so I'm not
terrifically bothered by this, but I am very curious)
2. What could be causing such a low fill factor, and what can I do to
fix it?
|
If you search on the newsgroup that you posted to you will find
several entries discussing integer keys on Little Endian Systems. I
believe that is the problem you are observing. There is also an FAQ in
our Developer Zone which discusses the problem and the solution.
The faq posting can be found here:
http://dev.sleepycat.com/resources/faq_show.html?id=70&back=%3Faction%3Dsearch
Alternatively you can search in this newsgroup and review a couple of
the responses.
Once you are set with that you may want to review this thread on
performance:
http://tinyurl.com/p6tes
Ron |
|
| Back to top |
|
|
Sue
*nix forums beginner
Joined: 28 Jul 2005
Posts: 18
|
| Posted: Thu Jun 01, 2006 12:23 am Post subject:
Can't get fill factor high enough
|
|
|
I'm using Sleepycat 4.4.20, C API. I've been struggling trying to get
the fill factor for one of my databases higher than 51%, and failing
miserably. Hopefully someone has some ideas.
Database is a Btree, running on an Opteron Solaris 10 system. Page
size is set to 16384. Key size is 12 (1 32-bit integer and 1 64-bit
integer), and I've got an insert sort function that appears to be
working correctly. Data size is 28, if that matters. Duplicates are
not allowed in this database.
The key is an object ID (64-bit), with a 'container' ID (32-bit).
Neither is unique by itself, but the combination creates a unique ID.
I originally tried sorting on the 64-bit integer first, then the 32-bit
integer. This resulted in about a 55% fill rate, but was exceptionally
slow - presumably because there are a LOT more Objects than Containers.
Switching to using the container ID as the primary sort sped things up
by an order of magnitude (!), but the fill factor sank even lower, to
50%. Dumping the database didn't show anything that looked
extraordinary - getting 314 entries/leaf most times.
Questions are:
1. Any idea why there is such a huge speed difference when sorting on
the container ID vs. the object ID? (note: For retrieval purposes, it
may actually be better to keep it sorting this way, so I'm not
terrifically bothered by this, but I am very curious)
2. What could be causing such a low fill factor, and what can I do to
fix it?
Thank you, |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Fri Jan 09, 2009 6:13 am | All times are GMT
|
|
Guitar Lesson | Fashion Jewelry | Web Advertising | Credit Cards | Debt Consolidation
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
Databases
»
Berkeley DB
