Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jid4x-0003Qf-Jj for pgsql-performance@arkaria.postgresql.org; Tue, 09 Jun 2020 12:10:07 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jid4w-0003GA-Cy for pgsql-performance@arkaria.postgresql.org; Tue, 09 Jun 2020 12:10:06 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jid4w-0003G3-1s for pgsql-performance@lists.postgresql.org; Tue, 09 Jun 2020 12:10:06 +0000 Received: from mail-io1-xd2a.google.com ([2607:f8b0:4864:20::d2a]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jid4s-0005GW-DT for pgsql-performance@lists.postgresql.org; Tue, 09 Jun 2020 12:10:04 +0000 Received: by mail-io1-xd2a.google.com with SMTP id q8so22411042iow.7 for ; Tue, 09 Jun 2020 05:10:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=vXOiOvnUT95k+F0P9sC09IY39qjI3nfTjQEtLrNXMkc=; b=S41WJJiT4Lvu/F1ZiHjUCW9hZBqiwqUEb5gBAp1pX1ADvgfhcu3AK2be6UXVO0asqR P+CRZJ+itRVj+sUTKnxmZO4YQ0o4F9+O5qJlmu0ivX/n9h/l+5OHXgaCw2gMQsLFtW9r RkWKUBuD4fdY6RC3IVcmfWjWwX5QzVeAxKxNWdo/nguaXG73kDPT7bRI8wukmelLVI8N Gb4K9R3CWY97pzYRWEYRBmjsCEdN84UojC/CVjy81Z2lpq63R+fBt5lM420DLPgRLcmN hdparGz30GyCtXLqXyK6Bgou4FBYVVKPcCjJSdA5cMVIMdRVGTJCNwW1rOYtSr5soHNM 6chQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=vXOiOvnUT95k+F0P9sC09IY39qjI3nfTjQEtLrNXMkc=; b=fHpHq74nEw5ht9ciLRENji+F5nN+Mpj3cmWjElfzoCLsnUCKEiEiD1H/MHKTGQvKjW ZWH/Q9G/l3SO7wFSNOJfrjmOq5qpOcr0PvduD4IPnJlZIeUqOUzA7RcmpgZ8VYkodovK JrHNsry2ttAnNE+TuSlcNqmFIDen29Fi/LYCNRKNp+BHqqxYFoZjX9tyGXCAwa2zB6bb yyKOfIScuUTCooDM1QrM0ZXs9lEfvhODXZfcmmOK3EmJJBOuJVHOR7btejLV3anlDvyG Zmgke8N57DAVTlSfOpnhY3qWZ1mLuZ4CBWD+sNROCBVc4Te+KJ4qT4CtGsEpG3I6imrp qjww== X-Gm-Message-State: AOAM533ntYBQNQsNRJBpun7aAwXJWrGMhz8wPkND0ZD8ERu3S8J9Lrm1 txrEr2/r8qSG5xJt9mpX5RKIeA== X-Google-Smtp-Source: ABdhPJyGZpaEhUd8gcdhJ1Mwm6ZfTSne9jPeAQIN1I/qDQmrSY4vOHmLP8px5ieC6+pPnSFxEonGHQ== X-Received: by 2002:a05:6638:419:: with SMTP id q25mr25601958jap.99.1591704601401; Tue, 09 Jun 2020 05:10:01 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id q15sm7234032ioh.45.2020.06.09.05.10.00 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jun 2020 05:10:00 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id D1DF3800121; Tue, 9 Jun 2020 07:09:59 -0500 (CDT) Date: Tue, 9 Jun 2020 07:09:59 -0500 From: Justin Pryzby To: Krzysztof Olszewski Cc: Pavel Stehule , Pgsql Performance Subject: Re: Postgresql server gets stuck at low load Message-ID: <20200609120959.GC22473@telsasoft.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Tue, Jun 09, 2020 at 01:54:21PM +0200, Krzysztof Olszewski wrote: > I had hugepage's off and on, problems still occurs, > thanx for "perf top" suggestion, > pt., 5 cze 2020 o 13:38 Pavel Stehule napisał(a): > > pá 5. 6. 2020 v 12:07 odesílatel Krzysztof Olszewski napsal: > > > >> I have problem with one of my Postgres production server. Server works > >> fine almost always, but sometimes without any increase of transactions or > >> statements amount, machine gets stuck. Cores goes up to 100%, load up to > >> 160%. When it happens then there are problems with connect to database and > >> even it will succeed, simple queries works several seconds instead of > >> milliseconds.Problem sometimes stops after a period a time (e.g. 35 min), > >> sometimes we must restart Postgres, Linux, or even KVM (which exists as > >> virtualization host). > >> > >> My hardware > >> 56 cores (Intel Core Processor (Skylake, IBRS)) > >> 400 GB RAM > >> RAID10 with about 40k IOPS > >> > >> shared_buffers 64000 MB > >> > >> In correlation with stucks i see informations in kernel log about > >> NMI watchdog: BUG: soft lockup - CPU#25 stuck for 23s! [postmaster:33935] > > > > https://www.postgresql.org/message-id/CAHyXU0yAsVxoab2PcyoCuPjqymtnaE93v7bN4ctv2aNi92fefA%40mail.gmail.com > > > > Can be interesting a reply on Merlin's question from mail/. > > > > cat /sys/kernel/mm/redhat_transparent_hugepage/enabled > > cat /sys/kernel/mm/redhat_transparent_hugepage/defrag try this: echo 2 |sudo /sys/kernel/mm/ksm/run https://www.postgresql.org/message-id/20170718180152.GE17566%40telsasoft.com -- Justin