Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1YGtQv-0000pg-W7 for pgsql-admin@arkaria.postgresql.org; Thu, 29 Jan 2015 18:03:14 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1YGtQv-0001mf-FP for pgsql-admin@arkaria.postgresql.org; Thu, 29 Jan 2015 18:03:13 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1YGtQt-0001kX-RP for pgsql-admin@postgresql.org; Thu, 29 Jan 2015 18:03:11 +0000 Received: from mail.journyx.com ([209.163.206.41] helo=mail.int.journyx.com) by magus.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1YGtQg-0000od-D5 for pgsql-admin@postgresql.org; Thu, 29 Jan 2015 18:03:10 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.int.journyx.com (Postfix) with ESMTP id 8A9203002D5; Thu, 29 Jan 2015 12:02:53 -0600 (CST) Received: from mail.int.journyx.com ([127.0.0.1]) by localhost (mail.int.journyx.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id JuJxTzLl7WWp; Thu, 29 Jan 2015 12:02:53 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by mail.int.journyx.com (Postfix) with ESMTP id 5C6B3300344; Thu, 29 Jan 2015 12:02:53 -0600 (CST) X-Amavis-Modified: Mail body modified (using disclaimer) - mail.int.journyx.com X-Virus-Scanned: amavisd-new at mail.int.journyx.com Received: from mail.int.journyx.com ([127.0.0.1]) by localhost (mail.int.journyx.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id uxbVZp_LqMe2; Thu, 29 Jan 2015 12:02:53 -0600 (CST) Received: from mail.int.journyx.com (zimbra.int.journyx.com [192.168.100.5]) by mail.int.journyx.com (Postfix) with ESMTP id 2131A3002D5; Thu, 29 Jan 2015 12:02:53 -0600 (CST) Date: Thu, 29 Jan 2015 12:02:53 -0600 (CST) From: Scott Whitney Reply-To: Scott Whitney To: John Scalia Cc: pgsql-admin@postgresql.org Message-ID: <409239978.198205.1422554572999.JavaMail.zimbra@mail.int.journyx.com> In-Reply-To: <1630087617.198201.1422554556751.JavaMail.zimbra@mail.int.journyx.com> References: <54CA73CE.1050503@gmail.com> Subject: Re: hugepage configuration for V.9.4.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_198204_1396282072.1422554572998" X-Mailer: Zimbra 8.5.0_GA_3042 (ZimbraWebClient - GC40 (Win)/8.5.0_GA_3042) Thread-Topic: hugepage configuration for V.9.4.0 Thread-Index: 4i3UYW2VHvy+LxDNvgjmrhKtLzxoxg== X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-admin Precedence: bulk Sender: pgsql-admin-owner@postgresql.org ------=_Part_198204_1396282072.1422554572998 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Usually I tweak the kernel shmmax, shmmni and shmall values in /proc/sys. 4GB _might_ be too small, in fact, but tweaking those parameters ought to get you started at least. http://www.postgresql.org/docs/9.0/static/kernel-resources.html ----- On Jan 29, 2015, at 11:54 AM, John Scalia wrote: > I'm certain that I'm no expert for this one, as I've never had to configure this > parameter for anything prior, but I continue to get a startup error when I try > to use this. The > server is a VM running CentOS 6.5 with 4 Gb allocated to it. When I started > setting "huge_pages = on", the server reported: > %FATAL: could not map anonymous shared memory: Cannot allocate memory > %HINT: this error usually means that PostgreSQL's request for a shared memory > segment exceeded available memory, swap space, or huge pages. To reduce the > request size (currently > 1124876288 bytes), reduce PostgreSQL's shared memory usage, perhaps by reducing > shared_buffers or max_connections. > Further research showed that server's > /sys/kernel/mm/transparent_hugepage/enabled file contained "[always] madvise > never" > As I was concerned about the "always" setting, I used "cat madvise > " to the > file so it reported "always [madvise] never" I even set this in /etc/rc.local > and performed a reboot. > Regardless of which setting, however, I receive the same failure message. Per > its suggestions, my settings are shared_buffers = 1024Mb and max_connections = > 100. > Should I reduce these values? Is a 4 Gb test server too small to use huge_pages? > The server does run just fine with "huge_pages = try" or "off". What else > should I be checking? > -- > Jay > -- > Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-admin Journyx, Inc. 7600 Burnet Road #300 Austin, TX 78757 www.journyx.com p 512.834.8888 f 512.834.8858 Do you receive our promotional emails? You can subscribe or unsubscribe to those emails at http://go.journyx.com/emailPreference/e/4932/714 ------=_Part_198204_1396282072.1422554572998 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Usually I tweak the kernel shmmax, shmmni a= nd shmall values in /proc/sys.

4GB _might_ be too small, in fact, but tweaking those parameters ought to= get you started at least.

ht= tp://www.postgresql.org/docs/9.0/static/kernel-resources.html
----- On Jan 29, 2015= , at 11:54 AM, John Scalia <jayknowsunix@gmail.com> wrote:
=
I'm certain that I'm no expert for this one, as I've n= ever had to configure this parameter for anything prior, but I continue to = get a startup error when I try to use this. The
server is a VM running = CentOS 6.5 with 4 Gb allocated to it. When I started setting "huge_pages = =3D on", the server reported:

%FATAL: could not map anonymous shared= memory: Cannot allocate memory
%HINT: this error usually means that Pos= tgreSQL's request for a shared memory segment exceeded available memory, sw= ap space, or huge pages. To reduce the request size (currently
11248762= 88 bytes), reduce PostgreSQL's shared memory usage, perhaps by reducing sha= red_buffers or max_connections.

Further research showed that server'= s /sys/kernel/mm/transparent_hugepage/enabled file contained "[always] madv= ise never"

As I was concerned about the "always" setting, I used "ca= t madvise > " to the file so it reported "always [madvise] never" I even= set this in /etc/rc.local and performed a reboot.

Regardless of whi= ch setting, however, I receive the same failure message. Per its suggestion= s, my settings are shared_buffers =3D 1024Mb and max_connections =3D 100.
Should I reduce these values? Is a 4 Gb test server too small to use = huge_pages? The server does run just fine with "huge_pages =3D try" or "off= ". What else should I be checking?
--
Jay




--
S= ent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make ch= anges to your subscription:
http://www.postgresql.org/mailpref/pgsql-adm= in

=


Journyx, Inc.
7600 Burnet Road #300
Austin, TX 78757
www.journyx.com

p 512.834.8888 
f 512-834-8858 

Do you receive our promotional emails? You can subscribe or unsubscribe to those emails here. 

=0A
= ------=_Part_198204_1396282072.1422554572998--