=head1 NAME public-inbox-tuning - tuning public-inbox =head1 DESCRIPTION public-inbox intends to support a wide variety of hardware. While we strive to provide the best out-of-the-box performance possible, tuning knobs are an unfortunate necessity in some cases. =over 4 =item 1 New inboxes: public-inbox-init -V2 =item 2 Optional Inline::C use =item 3 Performance on rotational hard disk drives =item 4 Btrfs (and possibly other copy-on-write filesystems) =item 5 Performance on solid state drives =item 6 Read-only daemons =item 7 Other OS tuning knobs =item 8 Scalability to many inboxes =back =head2 New inboxes: public-inbox-init -V2 If you're starting a new inbox (and not mirroring an existing one), the L<-V2|public-inbox-v2-format(5)> requires L, but is orders of magnitude more scalable than the original C<-V1> format. =head2 Optional Inline::C use Our optional use of L speeds up subprocess spawning from large daemon processes. To enable L, either set the C environment variable to point to a writable directory, or create C<~/.cache/public-inbox/inline-c> for any user(s) running public-inbox processes. If libgit2 development files are installed and L is enabled (described above), per-inbox C processes are replaced with a single L process running C in read-only daemons. libgit2 use will be available in public-inbox 1.7.0+ More (optional) L use will be introduced in the future to lower memory use and improve scalability. Note: L is required for L, but not public-inbox-* =head2 Performance on rotational hard disk drives Random I/O performance is poor on rotational HDDs. Xapian indexing performance degrades significantly as DBs grow larger than available RAM. Attempts to parallelize random I/O on HDDs leads to pathological slowdowns as inboxes grow. While C<-V2> introduced Xapian shards as a parallelization mechanism for SSDs; enabling C repurposes sharding as mechanism to reduce the kernel page cache footprint when indexing on HDDs. Initializing a mirror with a high C<--jobs> count to create more shards (in C<-V2> inboxes) will keep each shard smaller and reduce its kernel page cache footprint. Keep in mind excessive sharding imposes a performance penalty for read-only queries. Users with large amounts of RAM are advised to set a large value for C as documented in L. C users on Linux 4.0+ are advised to try the C<--perf-same_cpu_crypt> C<--perf-submit_from_crypt_cpus> switches of L to reduce I/O contention from kernel workqueue threads. =head2 Btrfs (and possibly other copy-on-write filesystems) L performance degrades from fragmentation when using large databases and random writes. The Xapian + SQLite indices used by public-inbox are no exception to that. public-inbox 1.6.0+ disables copy-on-write (CoW) on Xapian and SQLite indices on btrfs to achieve acceptable performance (even on SSD). Disabling copy-on-write also disables checksumming, thus C (or higher) configurations may be corrupt after unsafe shutdowns. Fortunately, these SQLite and Xapian indices are designed to recoverable from git if missing. Disabling CoW does not prevent all fragmentation. Large values of C also limit fragmentation during the initial index. Avoid snapshotting subvolumes containing Xapian and/or SQLite indices. Snapshots use CoW despite our efforts to disable it, resulting in fragmentation. L can be used to monitor fragmentation, and C may be necessary. Large filesystems benefit significantly from the C mount option documented in L. Older, non-CoW filesystems are generally work well out-of-the-box for our Xapian and SQLite indices. =head2 Performance on solid state drives While SSD read performance is generally good, SSD write performance degrades as the drive ages and/or gets full. Issuing C commands via L or similar is required to sustain write performance. Users of the Flash-Friendly File System L may benefit from optimizations found in SQLite 3.21.0+. Benchmarks are greatly appreciated. =head2 Read-only daemons L, L, and L are all designed for C10K (or higher) levels of concurrency from a single process. SMP systems may use C<--worker-processes=NUM> as documented in L for parallelism. The open file descriptor limit (C, C in L, C in L) may need to be raised to accommodate many concurrent clients. Transport Layer Security (IMAPS, NNTPS, or via STARTTLS) significantly increases memory use of client sockets, sure to account for that in capacity planning. =head2 Other OS tuning knobs Linux users: the C sysctl may need to be increased if handling thousands of inboxes (with L) to avoid out-of-memory errors from git. Other OSes may have similar tuning knobs (patches appreciated). =head2 Scalability to many inboxes git 2.33+ startup time is orders-of-magnitude faster and uses less memory when dealing with thousands of alternates required for thousands of inboxes. L allows any number of public-inboxes to share the same Xapian indices. =head1 CONTACT Feedback encouraged via plain-text mail to L Information for *BSDs and non-traditional filesystems especially welcome. Our archives are hosted at L, L, and other places =head1 COPYRIGHT Copyright 2020-2021 all contributors L License: AGPL-3.0+ L