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 1gVhwu-0001Pe-9N for pgsql-performance@arkaria.postgresql.org; Sat, 08 Dec 2018 19:07:36 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gVhws-0003pS-W2 for pgsql-performance@arkaria.postgresql.org; Sat, 08 Dec 2018 19:07:34 +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 1gVhws-0003js-J2 for pgsql-performance@lists.postgresql.org; Sat, 08 Dec 2018 19:07:34 +0000 Received: from sonic304-50.consmr.mail.gq1.yahoo.com ([98.137.68.232]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gVhwp-00059n-QT for pgsql-performance@lists.postgresql.org; Sat, 08 Dec 2018 19:07:33 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1544296050; bh=qRpIhWAHzKzjLe2X1MK3SuZzCO16ai5TCGPZJTtDUdI=; h=Subject:References:To:From:Date:In-Reply-To:From:Subject; b=Sv3FCScyTusRKPNKnDT9VU5f2Uc7AEfzOMyuLCTXXathk0v9DayuYwnsB+1Jr4mwhZKPXY3IHYdLsGmvVNlvLFsLjzTMz/f9pMvTGybgwGM2yr94UZNFxitDtvAvqTEOw4365VlYqM+xARCwGbFwnweQN1qjEmenvMTMMnzvCGX1PSjeNefYRV2nv8HrVqzygUIvu2MwM1jSnNzFrRoBvqxbNP7ao5qk+TFTjHpG+5igDdEze7ScPQ6/g+ISHnPXgyhgGa+pEuZM9YRjrYOvnTowgGz/h+BmFDKfaYwYa/U3h/hzQH5mX7nV8geJWvPyg867Oc8QvwwAC7lhEi5CeA== X-YMail-OSG: 8XD1eOkVM1nTDd18M.L8iZXrmKivdlMCxVyzihYMxRR9VsBDpIdSNj8wS5arOip .8jPFPzjk6rc7yo97kiZ30lBZyo5guOMStjL7H6BvUUUVvSe.EDn8_s78WjQwc_uZPs5gTsMAyl7 TOkzLQsqTXZr3z658M8zMfAY45ykjcTWgbc.J.xKyQ1_RwxdEmtgxHhgW8LP_eyOc0irU9DEWm7v CQJRMsY3l6kxG4yrhqX4KVIEKZdnEmwq.cJvvOjmqQwgkpeqykSK1mzu4iqcaQFpX7FKsoSytV.H JFQ8PAJJfuO9BN7wfEjum.zDuakyRuU7njunQfnCV0azuA8ZdisWmSmeaOlPB5xETZv0oJzf4OKI apg_o22jcQ7ry1uBq4JdP4C68yaFcupReGWOVnuiQkzkdn7gFBVSqaCQKEDYQIc5KZMqVkUy80d2 WKjAfndAcqmL9LDKMW8WAVhPc1EuRIr1yD1Q1v8T13gS.1EgkKYeq_qnKkDHbKmbaDpc0MI1mlCT c4lTNs5EWae0GZfDYMJsDoxBPA9vOnLevH5qfe0Watd5PI3r1g2eIj8Cy5kx_dinQsVwpIkCwLny 3K_E7QAHCBUEsFC2gCY_pbFR7Qutgy.F20da.l7rstQ_RFE3cD6Lqb3idheLVfBCeeG08LrIEp.T gt7XdzWvhZZL_qfhwmwvjnZ_6n7U5DwiCrGxMMcvnjS9DQfnn6yuqoaQbPz5nVUJtq0pIs5_Rc.m ozLXgd.ymfh4AXzx2urp4D0gZXDElQdcB7rGh50TVuqCnNc84xRbX8cmSXzq9f0Dw_Tkw7yyR6J6 oIq4BeekQ0VXBYVX8bgSxy4b9WBP79k.AAQ9HS0qVXMJgTBAN4zt4weXa1j_G3_IYcqP5a.tvhYQ Y33Ul8UhbUO8cZPS2DyBZWur2xG.kHFREnprzF.oepDK5cI.BsyONzz9bEMweI7vvAfPDkS1k99J WC8XbUZ.CkzsHL9l7g3x3mlxZm0bHS_2qk8QxkXhstMlsR5IpVOWNhaDyh8MB7HsECk1XC0MHj4h g461Y2h4qxszOiDHRdIkHLsFPFaD2HjCQljuNvTUYRFFvwLIyEhs- Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Sat, 8 Dec 2018 19:07:30 +0000 Received: from 50-243-150-81-static.hfc.comcastbusiness.net (EHLO [10.16.0.189]) ([50.243.150.81]) by smtp429.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID abc6a3bf82dd26de5432c47820f2b0a4; Sat, 08 Dec 2018 19:03:29 +0000 (UTC) Subject: Fwd: amazon aroura config - seriously overcommited defaults? (May be Off Topic) References: To: pgsql-performance@lists.postgresql.org From: Square Bob X-Forwarded-Message-Id: Message-ID: Date: Sat, 8 Dec 2018 12:03:27 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------0CE647ACE191F36DC5C40784" Content-Language: en-US List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk This is a multi-part message in MIME format. --------------0CE647ACE191F36DC5C40784 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit This question is probably more of a fit for the performance list, sorry for the cross post -------- Forwarded Message -------- Subject: amazon aroura config - seriously overcommited defaults? (May be Off Topic) Date: Sat, 8 Dec 2018 12:00:33 -0700 From: Square Bob To: pgsql-general@lists.postgresql.org 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 --------------0CE647ACE191F36DC5C40784 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

This question is probably more of a fit for the performance list, sorry for the cross post



-------- Forwarded Message --------
Subject: amazon aroura config - seriously overcommited defaults? (May be Off Topic)
Date: Sat, 8 Dec 2018 12:00:33 -0700
From: Square Bob <square_bob@yahoo.com>
To: pgsql-general@lists.postgresql.org


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



--------------0CE647ACE191F36DC5C40784--