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 cursor behaviour consistent (ie automatically skip to next record at
end of a page) or to very clearly document this! It's pretty different
from kyoto/bdb interfaces in that (to my mind at least) it requires a
bit too much knowledge from the developer about the underlying structure
of the database which should be abstracted by the interface.
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 hammered
writing 10mb/sec (200txns) when they are capable of 100-200mb/sec
streaming writes... Does it do the same for you?
...
Kyoto writes async by default. You should do the same here, use
MDB_NOSYNC on the env_open.
MDB_NOSYNC makes no difference in my test case above - seeing exactly
the same memory, speed and disk patterns. Are you able to reproduce it?
Mark
