From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) by sourceware.org (Postfix) with ESMTPS id 133CB3973034 for ; Sat, 19 Sep 2020 14:00:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 133CB3973034 Received: by mail-lj1-x236.google.com with SMTP id u4so7340656ljd.10 for ; Sat, 19 Sep 2020 07:00:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=g/HB7/2GUVnkXSMUVLqGovK5gjiXQoUQqBRD0jViA18=; b=q7XScEf22NHeF5r+5oouUgnTxg4TxqMqGeGMS+QoJhNq3JZlVuanbrQwX4+/gef24j QVZuWlaR6sYrShcbxqVJAXpsL2CcyMzU9EN93QBAPe6cJ2SQicJ1PlKHD7/FY6jUdOgN d5Zy42BY9hLs4WW8EThkjhgcucJrbR3jpuydZDCZtleWYuWi9X2CH69ZkbUBvB5oI3Mo dbyndqmf1iRHyD6IdmQxQYc/4ixZFQDN46c+Dykf4Ro00sdLGdAx4TfrRvhnbMRBdrmn Wea7rS/Ou7HKOcc7SW4SEKyhUqvGaG683YPVmv34zDnSmjrGeXkftXw5u7mCd5GHgXaz 3THA== X-Gm-Message-State: AOAM53049KhUNkP9PAtbKcz7YgLivTL4jkoCqVADkUz1xcy4QHD0/7cX jeSwQ2MB9hRb1C9dD0a3b/y4OGftu5sBRI5IjSZYgEMqyhY= X-Google-Smtp-Source: ABdhPJzAxXzUy4AKP8hGwQ9jDsfC6jMFzJA+bKIWvynBrL2jqNvP+O6T9lL70tHJAAAec1CujaYGpDW+GZXy3HuR/2M= X-Received: by 2002:a2e:84d6:: with SMTP id q22mr12250544ljh.70.1600524057582; Sat, 19 Sep 2020 07:00:57 -0700 (PDT) MIME-Version: 1.0 References: <71a1cf97a5a9801a2aaf146e5584b63add4dcd2e.camel@yandex.ru> In-Reply-To: <71a1cf97a5a9801a2aaf146e5584b63add4dcd2e.camel@yandex.ru> From: Xavier Roche Date: Sat, 19 Sep 2020 16:00:46 +0200 Message-ID: Subject: Re: Abnormal memory usage with glibc 2.31 related to trimming strategy ? To: libc-help@sourceware.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2020 14:01:01 -0000 Hi Konstantin, On Fri, Sep 18, 2020 at 6:45 PM Konstantin Kharlamov wrote: > `glibc.malloc.tcache_count`: "If set to zero, the per-thread cache is > effectively disabled." > So what you can do is to play with this tunable to see if it affects the > behavior you see. Thanks for pointing me to this setting I did indeed miss. Unfortunately it did not improve the situation (GLIBC_TUNABLES=glibc.malloc.tcache_count=0), as the process started to slowly grow as usual, now eating more than 50GB of released memory. Looking at the malloc.c code, it seem that the thread cache can not be the culprit: blocks are rather small (governed by get_max_fast() limit) So this is probably related to another issue; possibly the number of heaps ? The only workaround for now seems to be to call malloc_trim(0) on a regular (ie. with a period of 30 seconds) basis. But this is a rather unfortunate workaround. Regards, -- Xavier Roche -