Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1favNx-0000uj-4G for pgsql-performance@arkaria.postgresql.org; Thu, 05 Jul 2018 03:56:49 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1favNs-0006EE-Ko for pgsql-performance@arkaria.postgresql.org; Thu, 05 Jul 2018 03:56:44 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1favNr-0006E6-VQ for pgsql-performance@lists.postgresql.org; Thu, 05 Jul 2018 03:56:44 +0000 Received: from mail-io0-x22c.google.com ([2607:f8b0:4001:c06::22c]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1favNn-0001PM-DL for pgsql-performance@lists.postgresql.org; Thu, 05 Jul 2018 03:56:42 +0000 Received: by mail-io0-x22c.google.com with SMTP id l7-v6so6443903ioj.1 for ; Wed, 04 Jul 2018 20:56:38 -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=7QxI1xDDPAJ4t4JEiLHx8HuzPG0Zi7UgEbJAtA3wFFM=; b=PoWBtajIvfc5JTfpHdDCTs5EBtBFbdJTBBPYkS09Yn4lHzVavd01dYgjpBaLQC1t/0 mTmtVhJQLF+Kvj7pcKnFE5h3vkrwnHGp6gy9xsYXxBRH5jBEFmAu+d7JVtITedXEEWOt kf5JbdvP7ed1k7xZfOhJPN+r8F3oAcrgfQBNHFwuDELKcUMC8H6WI82dWhXHARjJwqoD pWvIoyI4t05voUTWVgjVVoOkOGgqfcqz15G+AlODVE7pZqE1x8plIrisY/xv7ph4fQoH 2JaKBmNKbXE2ek+jC4po1NKi3XJECf//w3tV6yg7JwVeTRUtAg0ts7V4XfpirCFpt9f9 JsEw== 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=7QxI1xDDPAJ4t4JEiLHx8HuzPG0Zi7UgEbJAtA3wFFM=; b=jEF39GB8ser0r1Kg0YcE1sSVxwAhrwcryAZXcDmKr5y/m/c7LJ2/Q+4jCDsL7mUuiV /niy7fsZClAhjSl/8NEZw/JLLjhuZK2ErhkSMKYfaxLRAAasPWMrEhdWJdnmxKRufiqs 6c0vRynxXFlYaUPBC5aJFBo9fzlGwxdAXswEz1BXFozY9rum6rkDhCNLWlR+jxcpfUjA sVMC2xO+sRu76+3apvXleGnGM4+kMNaawFp72YCUP21xNyQwIZaiXbG/tgIUTIGuETFX FZjyQZMUsb8x+zisia/hiqLjWYbDnZ/G4vU2ksGd9mPOIbxJjnpD4V52FBqdixEwhYQx dEow== X-Gm-Message-State: APt69E3l4+kl6yB4om1HqECeQwbYPwCsXtmtJP9QjX+yYJ3aG05EicER YmxnaleH5E/QAn/Mc27zI8ZXww== X-Google-Smtp-Source: AAOMgpdR4k7Sfj1Y56Imqe76G16vTcQFAK1SsGgqXxbh8LgERtci//4xTGi3oSH3ozUqIV+/9MXsYA== X-Received: by 2002:a6b:2b93:: with SMTP id r141-v6mr3374108ior.87.1530762998380; Wed, 04 Jul 2018 20:56:38 -0700 (PDT) Received: from pryzbyj (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id q3-v6sm2520252itc.22.2018.07.04.20.56.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Jul 2018 20:56:37 -0700 (PDT) Received: by pryzbyj (Postfix, from userid 1000) id 15279804E78; Wed, 4 Jul 2018 22:56:37 -0500 (CDT) Date: Wed, 4 Jul 2018 22:56:36 -0500 From: Justin Pryzby To: =?iso-8859-1?Q?Jos=E9_Mello_J=FAnior?= Cc: pgsql-performance@lists.postgresql.org Subject: Re: tcp_keepalives Message-ID: <20180705035636.GE7025@telsasoft.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hi, Sorry for my poor Portugese; I didn't translate back since I cannot verify its accuracy. On Wed, Jul 04, 2018 at 10:19:41AM -0300, José Mello Júnior wrote: > Pessoal, estou em um cliente que tem um servidor Linux (não sei qual > distribuição) mas de um tempo para cá está aparecendo uma mensagem sobre > excesso de conexões e então para de fazer conexões. translated: | Personally, I'm on a client that has a Linux server (I do not know which | one distribution) but from time to time a message is over connections | and then stop connections. TCP keepalives allow closing a connection which is already broken, such as due to NAT router "forgetting" about the connection (perhaps because it's idle, or perhaps because the router rebooted). Keepalives may also help to AVOID the connection from breaking in the first place, by continuing to send traffic on an otherwise idle connection. Is the connection from a client on a remote subnet ? If not, keepalives will have no effect. What is the current value of max_connections? And when you hit max_connections, causing new connections to be rejected, what are all the existing connections doing? SELECT backend_start, pid, datname, usename, state, left(query,222) FROM pg_stat_activity ORDER BY 1; Does the application keep connections opened forever ? Or does it keep opened the "record" number of connections opened from a multi-process or thread pool? Do you run both the client applications and the database server ? Are there many application connections at once ? You could check with: netstat -anpe |grep 5432 |grep PID I'd typically expect only one connection to postgres per client process. > Assistindo a uma palestra, o cidadão citou que se eu alterasse essa > configuração para 50, o postgresql começaria a matar as conexões com algum > tempo automaticamente. translated: | While attending a lecture, the citizen mentioned that if I changed this | setting to 50, postgresql would start killing the connections with some | time automatically. Unless I misunderstand, I wouldn't think so: TCP keepalives only close connections which are *already* broken. It's also possible that during a spike in transactions, clients are bogging each other down, and I recall some people have reported success using a connection pooler (like pgbouncer) to reject a small fraction of the clients during the peak, to allow the rest of the client requests to be quickly serviced, rather than all of them running slowly and many timing out. Justin