From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <e@80x24.org>
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,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 14FAA1F953
	for <meta@public-inbox.org>; Thu,  4 Nov 2021 00:17:54 +0000 (UTC)
Date: Thu, 4 Nov 2021 00:17:54 +0000
From: Eric Wong <e@80x24.org>
To: meta@public-inbox.org
Subject: Re: httpd memory usage?
Message-ID: <20211104001753.GA20698@dcvr>
References: <20210904235305.GA22009@dcvr>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20210904235305.GA22009@dcvr>
List-Id: <meta.public-inbox.org>

Eric Wong <e@80x24.org> wrote:
> Is it high for anybody else?  I'm not seeing it for small
> instances (e.g. the instance that's powering
> public-inbox.org/{git,meta} is fine, but with lots of entries my
> lore mirror @ https://yhbt.net/lore/ the main sbrk heap seems to
> be growing slowly without bounds.

After the Encode leak workaround fix
<https://public-inbox.org/meta/20211016232301.20463-1-e@80x24.org/>
and a bunch of scratchpad reductions, it should be at an
all time low.

64-bit instances should be below 80 MB unless you're serving
gigantic messages/attachments (that are usually spam).

> I think I'll need to finish porting mwrap over to Perl/XS
> (from Ruby/C)...

It's working well enough: https://80x24.org/mwrap-perl.git
(still unreleased, though, might take a few more years :P)