Call for testing new expiration and ovsqlite features

[Kevin Bowling]

On Fri, Jul 17, 2026 at 12:45 AM Julien ÉLIE <julien at trigofacile.com> wrote:
>
> 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.

csiph.com is running w/hissqlite, the conversion took about 1.5hrs
limited by older SAS flash SSDs.  The expected benefit is observed on
my heavy read side, and no need for the innd pause and rebuild history
every night is an operational/availability win.

The write amplification bugs me and I don't know what to do about it
right now.  It's not a big problem during steady state, but conversion
and especially flood filling will create a ton of extra I/O.  On fast
NVMe you may get something like 100k history writes/sec, I wouldn't
think that would serve as an ultimate bottleneck like Jesse is seeing
with hisv6 but we need some empirical data.  It might also make
hissqlite not great for HDDs.. only SSD.

Jesse, playing around with history-bench would be useful for me in
addition to your real world testing.

>
> > 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!

Probably worth setting primarycache=all for pathoverview and
pathhistory datasets.  It is critical that the record size matches the
SQLite pagesize.  atime off, lz4 are good all around defaults.  Both
datasets should ideally be on flash storage.  Flash is less critical
for the actual spool, and it doesn't need specific tuning, atime=off
and lz4 defaults would be good.

Also which OS are you running zfs on?

> --
> Julien ÉLIE
>
> « J'ai été un homme dans un corps de femme. Avant ma naissance, bien
>    entendu. » (Mike Bent)
>
> --
> inn-workers mailing list
> inn-workers at lists.isc.org
> https://lists.isc.org/mailman/listinfo/inn-workers