From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-4.0 required=3.0 tests=ALL_TRUSTED,AWL,BAYES_00 shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 45BD31F462; Thu, 6 Jun 2019 20:54:54 +0000 (UTC) Date: Thu, 6 Jun 2019 20:54:54 +0000 From: Eric Wong To: Konstantin Ryabitsev Cc: meta@public-inbox.org Subject: Re: how's memory usage on public-inbox-httpd? Message-ID: <20190606205454.xgqfy6w6h6kbxdes@dcvr> References: <20181201194429.d5aldesjkb56il5c@dcvr> <20190606190455.GA17362@chatter.i7.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20190606190455.GA17362@chatter.i7.local> List-Id: Konstantin Ryabitsev wrote: > Is that normal, and if not, what can I do to help troubleshoot where it's > all going? Oh, another thing is to check if any of that is from mmap-ed files or if its all anon heap memory. The SQLite I'm using from Debian doesn't seem to mmap files (I've never had to look too hard at tuning SQLite) and I don't think libxapian uses mmap at all either (just pread). But LKML's sqlite files are huge. I know git(1) will mmap entire packs into memory. If/when public-inbox start supporting Git::Raw (libgit2) or even Cache::FastMmap, then yeah; process sizes will look a lot bigger.