Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gVhu6-00016c-5K for pgsql-general@arkaria.postgresql.org; Sat, 08 Dec 2018 19:04:42 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gVhu4-00084o-Lc for pgsql-general@arkaria.postgresql.org; Sat, 08 Dec 2018 19:04:40 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gVhu4-00084h-4u for pgsql-general@lists.postgresql.org; Sat, 08 Dec 2018 19:04:40 +0000 Received: from sonic314-47.consmr.mail.gq1.yahoo.com ([98.137.69.110]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gVhu1-00053h-1R for pgsql-general@lists.postgresql.org; Sat, 08 Dec 2018 19:04:38 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1544295875; bh=frYGCpPnrBccNw0ZsdxSIsoQoCjgFa7YCIqNrSQCIE0=; h=To:From:Subject:Date:From:Subject; b=QgcwNYIcN75UR9uIWigeY6DD1jHYUwBetkN8sCx/61+ShL2bq3QoNCYEal/I4CyMGknYzP15EvgUMFUPHO5dCMBxw6+aPzlzdQgIlhloW9BNz45ej1OaueauhUM1trsEWHXivDYFjVFE3X0ItQ7mZyx6avDjLPYW63Dms7mEdhtbHzuu9P+7uGvk+kvadorX/uOJgqlADrQDAiZfpaAE6ZuXUPrZcYk1MvAS/SbC3URPzhAp1yAxhdrGm72CBZdAUzvsIGEVnb0iu2u5gb9CS/2iFN23Ajw2isvKxowRMe0dNx3PYJJN7iyVVa1lgPRBlDWnXRhBrEBuQmkBHfm67w== X-YMail-OSG: 8OLYCAsVM1kgahwS8G5r2y6E27O4v9CS7nGcYllVWeqPY77nfbkIFuJWoy.TbQq _ryBs9Tq7PUY6O0JfqmjTNW7FDZ6WEX3vERc6mnUS0UNU8TpMcESf6WbWW2Qo_ODeWLqYJuDh.Rg 5c7BS34L5Y_VrtHysMdTyf86oWUQSg.vvx2jf9bIv8JfZDHGAvItFgVoFfAq7SqhD6LYAxPJy.Dc STSiIg6UEJk3cLiYGiWKMJv520m1lXKaZdA_WzDW8uePviiRfJNXx0WFVF.MxyNcJ0SLYu8sjNY6 n7X0Sd9WnPLW.qgEibbL6MnmY6LrahoXWkx75Nh4bp2DPtKlDbYONweCaA5VGDWxBCUApvJlCEhL BxzoFNxi_lDT_hOORO5mEjsvmjLPfi9E5.oLs8zcVnDapcW8TSYxazWhb02fB.SPZbm5EfWahi3_ yUNhhe2BMDhJumrk3qJtn.CnWZwQqK3zAPZXiQzdOXt8QP6wiGu9uMipNwODudO_4C17fCNUyx1A I1MXeLG3xsg6IiSN.TMJpo6vpDr36Sgtw8L0Q70qhYXym7rJaq65wFrJ71_eGrcgv5sHSaZhlf3y bwPy95BEe9fdJbRaBaM66wwqeS8lIM2yYkXdB38qXm8bZEUeZrWeRgikk1O_Qw_1bnuV7q8pTo6D t0byOQA9SiQaIXrJ.BDUHqP7UG9w6tPZwLq3aRt4W4a4d406qnrhyX.aMKtcgIH.21GJ2yfOHOgM S7LTb7I08H8T0eAItZ_N2Umd076v63hdOVLuXqQv.niomEcUeXZvNS2eGGoSVRyqELszZBjBi8r7 4VVCz9pb22fRfSiaN9ihfwErn3R164h5.XpeuwP6.6FiU.F5aHbAMSVqAGl6VEvqEOgL91sL3XmO hsFwFIfAeNQ3.Nopfpjn1QCfDHSVugGIr9VxtxxlYY8mB21IQcex6TC4_DgZ0M9B6wKYCAiLZDSz kBB0GF5ullRPW1KFyN4MetjyPJaWdte5WmLu1pxKljByCFyQbF5bQsVwz8w65.KpWBAet43A_nI7 MvrDLUtscYb7gs_ooWFik Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Sat, 8 Dec 2018 19:04:35 +0000 Received: from 50-243-150-81-static.hfc.comcastbusiness.net (EHLO [10.16.0.189]) ([50.243.150.81]) by smtp424.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 1d79c4d282985aed6c7fece32dc6a07a; Sat, 08 Dec 2018 19:00:34 +0000 (UTC) To: pgsql-general@lists.postgresql.org From: Square Bob Subject: amazon aroura config - seriously overcommited defaults? (May be Off Topic) Message-ID: Date: Sat, 8 Dec 2018 12:00:33 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk All; My apologies if this is off topic. Our company is moving to Aurora, In the past I would take care not to allow postgresql to over-commit memory beyond the actual memory on the server, which meant I would add the buffer pool + (work_mem * max_connections) + (maintenance_work_mem * autovacuum threads) However as I look at the aroura defaults they are all off the charts, for example, based on the calculations in the config (amazon doesn't make it easy, some settings are in pages, some are in kb, some are who knows what) I see the following settings as default in our aroura config: The instance size is db.r4.xlarge this instance size is listed as having 30.5GB of ram Here's the default settings: shared_buffers: {DBInstanceClassMemory/10922} which equates to 24GB work_mem:   64000 (kb) which equates to 65.5MB maintenance_work_mem: GREATEST({DBInstanceClassMemory/63963136*1024},65536) which equates to 4.2GB max_connections: LEAST({DBInstanceClassMemory/9531392},5000) which equates to 3,380 According to my math (If I got it right)  in a worst case scenario, if we maxed out max_connections, work_mem and maintenance_work_mem limits the db would request 247GB of memory Additionally amazon has set effective_cache_size = {DBInstanceClassMemory/10922} which equates to about 2.9MB (which given the other outlandish setting may be the only appropriate setting in the system) What the hell is amazon doing here? Am I missing the boat on tuning postgresql memory? Is amazon simply counting on the bet that users will never fully utilize an instance? Thanks in advance