Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WSoBV-0007oi-K8 for pgsql-performance@arkaria.postgresql.org; Wed, 26 Mar 2014 13:48:01 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1WSoBV-0004ZP-4M for pgsql-performance@arkaria.postgresql.org; Wed, 26 Mar 2014 13:48:01 +0000 Received: from makus.postgresql.org ([2001:4800:7903:4::125]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WSoBT-0004ZB-RN; Wed, 26 Mar 2014 13:48:00 +0000 Received: from dub0-omc4-s4.dub0.hotmail.com ([157.55.2.79]) by makus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WSoBK-0008MF-I4; Wed, 26 Mar 2014 13:47:58 +0000 Received: from DUB128-DS14 ([157.55.2.71]) by dub0-omc4-s4.dub0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 26 Mar 2014 06:47:48 -0700 X-TMN: [vog8C1SywLSMAdl9xuSK8x5+xV0omMnQ] X-Originating-Email: [markella_skembri@hotmail.com] Message-ID: From: Markella Skempri To: "Martin French" CC: , References: <1395836511.796897979@f327.i.mail.ru> In-Reply-To: Subject: Re: Why shared_buffers max is 8GB? Date: Wed, 26 Mar 2014 13:47:47 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0089_01CF48F9.F9120CC0" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3522.110 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3522.110 X-OriginalArrivalTime: 26 Mar 2014 13:47:48.0777 (UTC) FILETIME=[F98BA990:01CF48F9] X-Pg-Spam-Score: 0.4 (/) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org ------=_NextPart_000_0089_01CF48F9.F9120CC0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Thanks Martin,=20 However this is a database dedicated server and nothing much else is = running on it. Also, I never saw this happening with 9.2 =E2=80=93 but I = can=E2=80=99t vouch for the size of files that I was uploading.=20 From: Martin French=20 Sent: Wednesday, March 26, 2014 1:32 PM To: Markella Skempri=20 Cc: desmodemone ; ik@postgresql-consulting.com ; Alexey Vasiliev ; = pgsql-performance@postgresql.org ; = pgsql-performance-owner@postgresql.org=20 Subject: Re: [PERFORM] Why shared_buffers max is 8GB? > I wanted to follow up from this question. I=E2=80=99m running on 9.3.4 = > My DB server has 32GB ram so I have assigned 8GB=20 > shared_buffer_memory. It is quite a big db but with not much=20 > traffic. When there is traffic, it=E2=80=99s usually big.=20 > =20 > Lately, the kernel has been killing the postmaster for having=20 > assigned too much shared memory. Latest crash was when loading a 500MB = file.=20 > =20 > Should I reduce the shared buffers in order for this to be more = robust?=20 > =20 > Thanks=20 > Markella=20 It may be that other memory settings are contributing towards this = (work_mem, maintenance_work_mem, max_connections etc).=20 I would suggest that the OOM killer is working as intended and something = is not quite right within the config.=20 You may want to review the memory consumption at peak times taking into = consideration anything else running on the machine.=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Romax Technology Limited=20 A limited company registered in England and Wales. Registered office: Rutherford House=20 Nottingham Science and Technology Park=20 Nottingham=20 NG7 2PZ=20 England Registration Number: 2345696 VAT Number: 526 246 746 Telephone numbers: +44 (0)115 951 88 00 (main) For other office locations see: http://www.romaxtech.com/Contact =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D E-mail: info@romaxtech.com Website: www.romaxtech.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Confidentiality Statement This transmission is for the addressee only and contains information = that is confidential and privileged. Unless you are the named addressee, or authorised to receive it on = behalf of the addressee=20 you may not copy or use it, or disclose it to anyone else.=20 If you have received this transmission in error please delete from your = system and contact the sender. Thank you for your cooperation. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ------=_NextPart_000_0089_01CF48F9.F9120CC0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
 
Thanks Martin,
However this is a database dedicated = server and=20 nothing much else is running on it. Also, I never saw this happening = with 9.2 =E2=80=93=20 but I can=E2=80=99t vouch for the size of  files that I was = uploading.=20
 
Sent: Wednesday, March 26, 2014 1:32 PM
Cc: desmodemone ; ik@postgresql-consulting.com= ; Alexey = Vasiliev=20 ; pgsql-performance@postgr= esql.org=20 ; pgsql-performance-= owner@postgresql.org=20
Subject: Re: [PERFORM] Why shared_buffers max is=20 8GB?
 

> I wanted to follow up from this question. I=E2=80=99m = running on=20 9.3.4
> My DB server has 32GB ram = so I have=20 assigned 8GB
> shared_buffer_memory. It is quite a big db but = with not=20 much
> traffic. When there is traffic, it=E2=80=99s usually big.=20
> 
> Lately, the kernel has been killing the postmaster for = having=20
> assigned too much shared memory. Latest crash was when loading = a 500MB=20 file.
>  =
> Should I reduce the shared buffers in order for this to be = more=20 robust?
>  =
> Thanks
> = Markella=20

It may be that other memory settings are = contributing=20 towards this (work_mem, maintenance_work_mem, max_connections etc).=20

I would suggest that the OOM = killer is=20 working as intended and something is not quite right within the config.=20

You may want to review the memory = consumption at peak times taking into consideration anything else = running on the=20 machine.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

Romax=20 Technology Limited
A limited company registered in England and=20 Wales.
Registered office:
Rutherford House
Nottingham Science = and=20 Technology Park
Nottingham
NG7 2PZ
England
Registration = Number:=20 2345696
VAT Number: 526 246 746

Telephone numbers:
+44 = (0)115 951=20 88 00 (main)

For other office locations see:
http://www.romaxtech.com/Contact
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
E-mail:=20 info@romaxtech.com
Website: www.romaxtech.com
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Confidentiality=20 Statement
This transmission is for the addressee only and contains=20 information that is confidential and privileged.
Unless you are the = named=20 addressee, or authorised to receive it on behalf of the addressee =
you may=20 not copy or use it, or disclose it to anyone else.
If you have = received this=20 transmission in error please delete from your system and contact the = sender.=20 Thank you for your=20 cooperation.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=20
------=_NextPart_000_0089_01CF48F9.F9120CC0--