On 23/08/13 04:55, Howard Chu wrote:
Howard Chu wrote:
Yes, I see it here, and I see the problem. LMDB was not originally
designed to
handle transactions of unlimited size. It originally had a txn
sizelimit of
about 512MB. In 0.9.7 we added some code to raise this limit, and it's
performing
Mark Zealey wrote:
On 23/08/13 04:55, Howard Chu wrote:
Howard Chu wrote:
Yes, I see it here, and I see the problem. LMDB was not originally
designed to
handle transactions of unlimited size. It originally had a txn
sizelimit of
about 512MB. In 0.9.7 we added some code to raise this limit, and
On 23/08/13 14:02, Howard Chu wrote:
Mark Zealey wrote:
4) Creating database with non-sequential keys is very bad (on 4gb
databases, 2* slower than kyoto - about 1h30 and uses more memory).
This was actually a typo - kyoto only takes about 20 minutes to generate
it so 4* slower. However,
I've found another weird - I have now converted the database to use
duplicates. Typically when I do mdb_cursor_get(... MDB_NEXT ) it will
set the key and value but I've found 1 place so far where I do it and on
the duplicate's second entry the value is set but the key is empty.
I don't see
Mark Zealey wrote:
I've found another weird - I have now converted the database to use
duplicates. Typically when I do mdb_cursor_get(... MDB_NEXT ) it will
set the key and value but I've found 1 place so far where I do it and on
the duplicate's second entry the value is set but the key is
Mark Zealey wrote:
On 23/08/13 17:08, Howard Chu wrote:
Mark Zealey wrote:
I've found another weird - I have now converted the database to use
duplicates. Typically when I do mdb_cursor_get(... MDB_NEXT ) it will
set the key and value but I've found 1 place so far where I do it
and on
the
On 23/08/13 18:54, Howard Chu wrote:
Mark Zealey wrote:
On 23/08/13 17:08, Howard Chu wrote:
Mark Zealey wrote:
I've found another weird - I have now converted the database to use
duplicates. Typically when I do mdb_cursor_get(... MDB_NEXT ) it
will
set the key and value but I've found 1
Hi Howard, I've now got lmdb working with powerdns in place of kyoto -
nice and easy to do thanks! Maximum DNS query load is a little better -
about 10-30% depending on use-case, but for us the main gain is that you
can have a writer going on at the same time - I was struggling a bit
with how to
--On Thursday, August 22, 2013 9:59 PM +0300 Mark Zealey
s...@markandruth.co.uk wrote:
5) pkgconfig/rpms would be really nice to have. Or do you expect it to
just be bundled with a project as eg the perl module does?
Debian and FreeBSD both have packages of the latest release 0.9.7. But no,
Mark Zealey wrote:
Hi Howard, I've now got lmdb working with powerdns in place of kyoto -
nice and easy to do thanks! Maximum DNS query load is a little better -
about 10-30% depending on use-case, but for us the main gain is that you
can have a writer going on at the same time - I was
On 22/08/13 23:37, Howard Chu wrote:
1) Can you update documentation to explain what happens when I do a
mdb_cursor_del() ? I am assuming it advances the cursor to the next
record (this seems to be the behaviour). However there is some sort of
bug with this assumption. Basically I have a loop
Mark Zealey wrote:
On 22/08/13 23:37, Howard Chu wrote:
1) Can you update documentation to explain what happens when I do a
mdb_cursor_del() ? I am assuming it advances the cursor to the next
record (this seems to be the behaviour). However there is some sort of
bug with this assumption.
On 23/08/13 00:07, Howard Chu wrote:
... as I said already, it does exactly what you said. When you've
deleted the last item on the page the cursor no longer points at a
valid node, so GET_CURRENT returns EINVAL.
OK I think that's a pretty big gotcha - it would be great to either make
the
Mark Zealey wrote:
I'm not doing *any* commits just one big txn for all the data...
The below C works fine up until i=4m (ie 500mb of residential memory
shown in top), then has massive slowdown, shared memory (again, as seen
in top) increases, waits about 20-30 seconds and then disks get
Howard Chu wrote:
Mark Zealey wrote:
I'm not doing *any* commits just one big txn for all the data...
The below C works fine up until i=4m (ie 500mb of residential memory
shown in top), then has massive slowdown, shared memory (again, as seen
in top) increases, waits about 20-30 seconds and
15 matches
Mail list logo
