Call for testing new expiration and ovsqlite features

[Julien ÉLIE]

Hi Jesse,

>> Do you happen to have found a bit of time to test these new features?

I hope we have not lost some of your previous responses.  (I do not 
always check Mailman auto-discard notifications.)
I see that you are subscribed to this mailing list with the e-mail 
address jesse.rehmer@ but are sending messages with jrehmer@, which 
makes your messages be discarded.  FWIW, I have just added your jrehmer@ 
mail to the whitelist :)


> I have several scenarios for performance testing hissqlite and the
> bloom filter for expire/expireover, but need a bit of time to get
> testing in motion. My current focus is getting the "complete" Usenet
> archive (>5TB of articles from 1986 forward) online. Once I have
> this dataset in a ready state, I will clone it for testing hissqlite
> and the bloom filter. Based on the current runtime, I expect it to
> take another 5-7 days to have the spool in its entirety.
OK, thanks!  Keep us informed.


> Will also do tests on a fresh server comparing hisv6 against
> hissqlite for write/ingestion performance. Based on comments I saw
> from Kevin's benchmarks, I don't think there is a performance gain
> in this scenario, but is worth testing. Currently the server spends
> slightly more time writing history than to overview, which feels
> backwards:> ----> Jul 16 16:26:22 archive innd: [ID 702911 news.notice] ME time 
600000
> hishave 4001(521335) hiswrite 272940(521335) hissync 16574(2) idle
> 12463(255268) artclean 1142(521335) artwrite 9962(521325) artcncl
> 356(588) hisgrep/artcncl 85(593) hishave/artcncl 0(5) artlog/artcncl
> 0(5) overv 261973(521325) perl 50(521335) python 50(521335) nntpread
> 1868(255268) artparse 6108(766077) artlog 1480(521656) datamove
> 163(295799)> ---->
> Based on what I'm seeing from my current operation, history writes
> seem to be the least performant operation in INN.>
> This is probably worthy of a separate thread, but are there any
> additional filesystem performance tuning that should be done with
> INN on ZFS? I've understand the recommendation for a 4k recordsize
> when using hissqlite, and currently use ovsqlite on a separate ZFS
> dataset that is set to 64k recordsize (matching what I've set in
> ovsqlite.conf), but what about for CNFS buffers? Do you think there
> would be any gain to changing the recordsize for CNFS (currently
> using the default 128k recordsize).
I admit I do not know what other recommendations there would be for ZFS. 
  I relay the question on the mailing-list!

-- 
Julien ÉLIE

« J'ai été un homme dans un corps de femme. Avant ma naissance, bien
   entendu. » (Mike Bent)