From cs_dba@consistentstate.com Sat Apr 28 16:10:18 2012 Received: from makus.postgresql.org (makus.postgresql.org [98.129.198.125]) by mail.postgresql.org (Postfix) with ESMTP id A74B0358049 for ; Sat, 28 Apr 2012 13:10:18 -0300 (ADT) Received: from 74-93-229-125-colorado.hfc.comcastbusiness.net ([74.93.229.125] helo=mail.consistentstate.com) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1SOADw-0001Rj-Qf for pgsql-admin@postgresql.org; Sat, 28 Apr 2012 16:10:18 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.consistentstate.com (Postfix) with ESMTP id E995F3063CC for ; Sat, 28 Apr 2012 10:10:02 -0600 (MDT) X-Virus-Scanned: amavisd-new at consistentstate.com Received: from mail.consistentstate.com ([127.0.0.1]) by localhost (mail.consistentstate.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPJzztrmIGIw for ; Sat, 28 Apr 2012 10:10:02 -0600 (MDT) Received: from Issac.consistentstate.com (unknown [67.137.237.194]) by mail.consistentstate.com (Postfix) with ESMTPSA id 00240303BBD for ; Sat, 28 Apr 2012 10:10:01 -0600 (MDT) Message-ID: <4F9C1659.5070503@consistentstate.com> Date: Sat, 28 Apr 2012 10:10:01 -0600 From: Kevin Kempter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: pgsql-admin@postgresql.org Subject: Postgres shared memory error Content-Type: multipart/alternative; boundary="------------090102040801060100000808" X-Pg-Spam-Score: -0.9 (/) X-Archive-Number: 201204/147 X-Sequence-Number: 39483 This is a multi-part message in MIME format. --------------090102040801060100000808 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit All; I just want to be sure that I'm not causing myself greif. I have a kvm in the cloud that is supposed to have access to 32GB of ram. when I do a top I only see 1GB of ram, I've pinged the hosting provider, maybe it shows up as it's used? Anyway when I try and start postgres I see this: / $ 2012-04-28 12:00:33 EDT [6429]: [1-1] FATAL: XX000: could not create shared memory segment: Cannot allocate memory 2012-04-28 12:00:33 EDT [6429]: [2-1] DETAIL: Failed system call was shmget(key=5432001, size=7700914176, 03600). 2012-04-28 12:00:33 EDT [6429]: [3-1] HINT: This error usually means that PostgreSQL's request for a shared memory segment exceeded available memory or swap space. To reduce the request size (currently 7700914176 bytes), reduce PostgreSQL's shared_buffers parameter (currently 917504) and/or its max_connections parameter (currently 503). The PostgreSQL documentation contains more information about shared memory configuration. 2012-04-28 12:00:33 EDT [6429]: [4-1] LOCATION: InternalIpcMemoryCreate, pg_shmem.c:178 / Which means I should bump up shmmax like this: /# sysctl -w kernel.shmmax=7700914176/ and add it to /etc/sysctl.conf: /# tail /etc/sysctl.conf kernel.msgmax = 65536 # Controls the maximum shared segment size, in bytes kernel.shmmax = 68719476736 # Controls the maximum number of shared memory segments, in pages kernel.shmall = 4294967296 #PostgreSQL kernel.shmmax = 7700914176 / I assume I should have to tweak ONLY kernel.shmmax, am I correct? I'm also assuming that this is a KVM cloud host provider issue, i.e. it looks like I actually do not have 32G or ram. Does anyone disagree with my conclusions? Thanks in advance --------------090102040801060100000808 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit All;

I just want to be sure that I'm not causing myself greif.  I have a kvm in the cloud that is supposed to have access to 32GB of ram. when I do a top I only see 1GB of ram, I've pinged the hosting provider, maybe it shows up as it's used?

Anyway when I try and start postgres I see this:

 $ 2012-04-28 12:00:33 EDT [6429]: [1-1] FATAL:  XX000: could not create shared memory segment: Cannot allocate memory                    
2012-04-28 12:00:33 EDT [6429]: [2-1] DETAIL:  Failed system call was shmget(key=5432001, size=7700914176, 03600).                                             
2012-04-28 12:00:33 EDT [6429]: [3-1] HINT:  This error usually means that PostgreSQL's request for a shared memory segment exceeded available memory or swap space. To reduce the request size (currently 7700914176 bytes), reduce PostgreSQL's shared_buffers parameter (currently 917504) and/or its max_connections parameter (currently 503).                                                            
        The PostgreSQL documentation contains more information about shared memory configuration.                                                              
2012-04-28 12:00:33 EDT [6429]: [4-1] LOCATION:  InternalIpcMemoryCreate, pg_shmem.c:178 



Which means I should bump up shmmax like this:

# sysctl -w kernel.shmmax=7700914176


and add it to /etc/sysctl.conf:

# tail /etc/sysctl.conf                                                          
kernel.msgmax = 65536                                                                              
                                                                                                   
# Controls the maximum shared segment size, in bytes                                               
kernel.shmmax = 68719476736                                                                        
                                                                                                   
# Controls the maximum number of shared memory segments, in pages                                  
kernel.shmall = 4294967296                                                                         
                                                                                                   
#PostgreSQL                                                                                        
kernel.shmmax = 7700914176 



I assume I should have to tweak ONLY kernel.shmmax, am I correct?
I'm also assuming that this is a KVM cloud host provider issue, i.e. it looks like I actually do not have 32G or ram.  Does anyone disagree with my conclusions?

Thanks in advance



--------------090102040801060100000808-- From fhevia@gmail.com Sat Apr 28 16:33:08 2012 Received: from makus.postgresql.org (makus.postgresql.org [98.129.198.125]) by mail.postgresql.org (Postfix) with ESMTP id 26BD9358049 for ; Sat, 28 Apr 2012 13:33:08 -0300 (ADT) Received: from mail-pb0-f46.google.com ([209.85.160.46]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1SOAa3-0001mw-1v for pgsql-admin@postgresql.org; Sat, 28 Apr 2012 16:33:07 +0000 Received: by pbbrp8 with SMTP id rp8so1727628pbb.19 for ; Sat, 28 Apr 2012 09:32:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=jcw6PZ7GH6M5kNivtPfvVUSrtHUW/o9+KabUYNyvEE0=; b=UivF4Tt5WvLLUTMl7wfZxDq6GOImys9VtnW+xvEAIOvhCKuhkJFye1UrDf2I5rYrlO 8jYl4aqNklYoIrRuXdMlBnO+iJQ1A9cTf01OuGD4+9XczH8L9OJ3yv8GXXeBcM7wVxZ9 21mHCK8w9fwPNTj3OpTLvl9rCv9zHKIRZcSIhQVDcyO73LT6iLE2VL4y1c7AGDv5o0YN ioEM8P/DmvrKmRyU9xA+6iHdZ1IbY048HlVGHo5j1KqoIPGL2vC0HO1suSOmijoN1k04 f0UJvA2gqZRowkSU3Ef5I5rXfrLnVl6gtDlHKloadXStuXlD0IEXOcRHStVfRDcFahRG N9XA== Received: by 10.68.223.234 with SMTP id qx10mr9481318pbc.154.1335630774114; Sat, 28 Apr 2012 09:32:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.232.200 with HTTP; Sat, 28 Apr 2012 09:32:33 -0700 (PDT) In-Reply-To: <4F9C1659.5070503@consistentstate.com> References: <4F9C1659.5070503@consistentstate.com> From: Fernando Hevia Date: Sat, 28 Apr 2012 13:32:33 -0300 Message-ID: Subject: Re: Postgres shared memory error To: Kevin Kempter Cc: pgsql-admin@postgresql.org Content-Type: multipart/alternative; boundary=047d7b15fe0bd79a9204bebfc522 X-Pg-Spam-Score: -2.6 (--) X-Archive-Number: 201204/148 X-Sequence-Number: 39484 --047d7b15fe0bd79a9204bebfc522 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Apr 28, 2012 at 13:10, Kevin Kempter wrote: > All; > > I just want to be sure that I'm not causing myself greif. I have a kvm in > the cloud that is supposed to have access to 32GB of ram. when I do a top I > only see 1GB of ram, I've pinged the hosting provider, maybe it shows up as > it's used? > > What does the 'free' command show? > Anyway when I try and start postgres I see this: > * > $ 2012-04-28 12:00:33 EDT [6429]: [1-1] FATAL: XX000: could not create > shared memory segment: Cannot allocate memory > 2012-04-28 12:00:33 EDT [6429]: [2-1] DETAIL: Failed system call was > shmget(key=5432001, size=7700914176, > 03600). > 2012-04-28 12:00:33 EDT [6429]: [3-1] HINT: This error usually means that > PostgreSQL's request for a shared memory segment exceeded available memory > or swap space. To reduce the request size (currently 7700914176 bytes), > reduce PostgreSQL's shared_buffers parameter (currently 917504) and/or its > max_connections parameter (currently > 503). > The PostgreSQL documentation contains more information about > shared memory > configuration. > > 2012-04-28 12:00:33 EDT [6429]: [4-1] LOCATION: InternalIpcMemoryCreate, > pg_shmem.c:178 * > > > Which means I should bump up shmmax like this: > > *# sysctl -w kernel.shmmax=7700914176* > > > and add it to /etc/sysctl.conf: > > *# tail > /etc/sysctl.conf > kernel.msgmax = > 65536 > > > > # Controls the maximum shared segment size, in > bytes > kernel.shmmax = > 68719476736 > > > > # Controls the maximum number of shared memory segments, in > pages > kernel.shmall = > 4294967296 > > > > #PostgreSQL > > kernel.shmmax = 7700914176 * > > > I assume I should have to tweak ONLY kernel.shmmax, am I correct? > Correct. > I'm also assuming that this is a KVM cloud host provider issue, i.e. it > looks like I actually do not have 32G or ram. Does anyone disagree with my > conclusions? > > You haven't provided evidence on how much RAM your system sees. A free -m will show the total memory the system has and is being used. Regards. --047d7b15fe0bd79a9204bebfc522 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: base64 PGJyPjxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gU2F0LCBBcHIgMjgsIDIwMTIgYXQg MTM6MTAsIEtldmluIEtlbXB0ZXIgPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86 Y3NfZGJhQGNvbnNpc3RlbnRzdGF0ZS5jb20iPmNzX2RiYUBjb25zaXN0ZW50c3RhdGUuY29tPC9h PiZndDs8L3NwYW4+IHdyb3RlOjxicj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0 eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5n LWxlZnQ6MWV4Ij4KCgogIAoKICAgIAogIAogIDxkaXYgYmdjb2xvcj0iI0ZGRkZGRiIgdGV4dD0i IzAwMDAwMCI+CiAgICBBbGw7PGJyPgogICAgPGJyPgogICAgSSBqdXN0IHdhbnQgdG8gYmUgc3Vy ZSB0aGF0IEkmIzM5O20gbm90IGNhdXNpbmcgbXlzZWxmIGdyZWlmLqAgSSBoYXZlIGEKICAgIGt2 bSBpbiB0aGUgY2xvdWQgdGhhdCBpcyBzdXBwb3NlZCB0byBoYXZlIGFjY2VzcyB0byAzMkdCIG9m IHJhbS4KICAgIHdoZW4gSSBkbyBhIHRvcCBJIG9ubHkgc2VlIDFHQiBvZiByYW0sIEkmIzM5O3Zl IHBpbmdlZCB0aGUgaG9zdGluZwogICAgcHJvdmlkZXIsIG1heWJlIGl0IHNob3dzIHVwIGFzIGl0 JiMzOTtzIHVzZWQ/PGJyPgogICAgPGJyPgogICAgPC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+PGJy PjwvZGl2PjxkaXY+V2hhdCBkb2VzIHRoZSAmIzM5O2ZyZWUmIzM5OyBjb21tYW5kIHNob3c/PC9k aXY+PGRpdj48YnI+PC9kaXY+PGRpdj6gPC9kaXY+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1 b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7 cGFkZGluZy1sZWZ0OjFleCI+Cgo8ZGl2IGJnY29sb3I9IiNGRkZGRkYiIHRleHQ9IiMwMDAwMDAi PkFueXdheSB3aGVuIEkgdHJ5IGFuZCBzdGFydCBwb3N0Z3JlcyBJIHNlZSB0aGlzOjxicj4KICAg IDxpPjxzbWFsbD48YnI+CiAgICAgICAgoCQgMjAxMi0wNC0yOCAxMjowMDozMyBFRFQgWzY0Mjld OiBbMS0xXSBGQVRBTDqgIFhYMDAwOiBjb3VsZAogICAgICAgIG5vdCBjcmVhdGUgc2hhcmVkIG1l bW9yeSBzZWdtZW50OiBDYW5ub3QgYWxsb2NhdGUKICAgICAgICBtZW1vcnmgoKCgoKCgoKCgoKCg oKCgoKCgoCA8YnI+CiAgICAgICAgMjAxMi0wNC0yOCAxMjowMDozMyBFRFQgWzY0MjldOiBbMi0x XSBERVRBSUw6oCBGYWlsZWQgc3lzdGVtCiAgICAgICAgY2FsbCB3YXMgc2htZ2V0KGtleT01NDMy MDAxLCBzaXplPTc3MDA5MTQxNzYsCiAgICAgICAgMDM2MDApLqCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoCA8YnI+CiAgICAgICAgMjAxMi0wNC0yOCAxMjowMDoz MyBFRFQgWzY0MjldOiBbMy0xXSBISU5UOqAgVGhpcyBlcnJvciB1c3VhbGx5CiAgICAgICAgbWVh bnMgdGhhdCBQb3N0Z3JlU1FMJiMzOTtzIHJlcXVlc3QgZm9yIGEgc2hhcmVkIG1lbW9yeSBzZWdt ZW50CiAgICAgICAgZXhjZWVkZWQgYXZhaWxhYmxlIG1lbW9yeSBvciBzd2FwIHNwYWNlLiBUbyBy ZWR1Y2UgdGhlIHJlcXVlc3QKICAgICAgICBzaXplIChjdXJyZW50bHkgNzcwMDkxNDE3NiBieXRl cyksIHJlZHVjZSBQb3N0Z3JlU1FMJiMzOTtzCiAgICAgICAgc2hhcmVkX2J1ZmZlcnMgcGFyYW1l dGVyIChjdXJyZW50bHkgOTE3NTA0KSBhbmQvb3IgaXRzCiAgICAgICAgbWF4X2Nvbm5lY3Rpb25z IHBhcmFtZXRlciAoY3VycmVudGx5CiAgICAgICAgNTAzKS6goKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAKICAgICAgICA8YnI+CiAgICAg ICAgoKCgoKCgoCBUaGUgUG9zdGdyZVNRTCBkb2N1bWVudGF0aW9uIGNvbnRhaW5zIG1vcmUgaW5m b3JtYXRpb24KICAgICAgICBhYm91dCBzaGFyZWQgbWVtb3J5CiAgICAgICAgY29uZmlndXJhdGlv bi6goKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoAogICAgICAgIDxicj4KICAgICAgICAyMDEyLTA0LTI4IDEyOjAwOjMzIEVEVCBbNjQy OV06IFs0LTFdIExPQ0FUSU9OOqAKICAgICAgICBJbnRlcm5hbElwY01lbW9yeUNyZWF0ZSwgcGdf c2htZW0uYzoxNzigIDwvc21hbGw+PC9pPjxicj4KICAgIDxicj4KICAgIDxicj4KICAgIFdoaWNo IG1lYW5zIEkgc2hvdWxkIGJ1bXAgdXAgc2htbWF4IGxpa2UgdGhpczo8YnI+CiAgICA8YnI+CiAg ICA8aT48c21hbGw+IyBzeXNjdGwgLXcga2VybmVsLnNobW1heD03NzAwOTE0MTc2PC9zbWFsbD48 L2k+PGJyPgogICAgPGJyPgogICAgPGJyPgogICAgYW5kIGFkZCBpdCB0byAvZXRjL3N5c2N0bC5j b25mOjxicj4KICAgIDxicj4KICAgIDxpPjxzbWFsbD4jIHRhaWwKICAgICAgICAvZXRjL3N5c2N0 bC5jb25moKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoAogICAgICAgIDxicj4KICAgICAgICBrZXJuZWwubXNnbWF4ID0KICAgICAgICA2NTUz NqCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoAogICAgICAgIDxicj4KICAgICAgICCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAKICAgICAgICA8YnI+CiAgICAgICAgIyBDb250 cm9scyB0aGUgbWF4aW11bSBzaGFyZWQgc2VnbWVudCBzaXplLCBpbgogICAgICAgIGJ5dGVzoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAgPGJyPgogICAgICAg IGtlcm5lbC5zaG1tYXggPQogICAgICAgIDY4NzE5NDc2NzM2oKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgCiAgICAg ICAgPGJyPgogICAgICAgIKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oAogICAgICAgIDxicj4KICAgICAgICAjIENvbnRyb2xzIHRoZSBtYXhpbXVtIG51bWJlciBvZiBz aGFyZWQgbWVtb3J5IHNlZ21lbnRzLCBpbgogICAgICAgIHBhZ2VzoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoCA8YnI+CiAgICAgICAga2VybmVsLnNobWFsbCA9CiAgICAgICAgNDI5 NDk2NzI5NqCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAKICAgICAgICA8YnI+CiAgICAgICAgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgCiAgICAgICAgPGJyPgogICAgICAgICNQb3N0 Z3JlU1FMoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg oKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoAogICAgICAgIDxicj4KICAgICAg ICBrZXJuZWwuc2htbWF4ID0gNzcwMDkxNDE3NqAgPC9zbWFsbD48L2k+PGJyPgogICAgPGJyPgog ICAgPGJyPgogICAgSSBhc3N1bWUgSSBzaG91bGQgaGF2ZSB0byB0d2VhayBPTkxZIGtlcm5lbC5z aG1tYXgsIGFtIEkgY29ycmVjdD88YnI+PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+PGJyPjwvZGl2 PjxkaXY+Q29ycmVjdC48L2Rpdj48ZGl2PqA8L2Rpdj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxf cXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xp ZDtwYWRkaW5nLWxlZnQ6MWV4Ij4KCjxkaXYgYmdjb2xvcj0iI0ZGRkZGRiIgdGV4dD0iIzAwMDAw MCI+CiAgICBJJiMzOTttIGFsc28gYXNzdW1pbmcgdGhhdCB0aGlzIGlzIGEgS1ZNIGNsb3VkIGhv c3QgcHJvdmlkZXIgaXNzdWUsIGkuZS4KICAgIGl0IGxvb2tzIGxpa2UgSSBhY3R1YWxseSBkbyBu b3QgaGF2ZSAzMkcgb3IgcmFtLqAgRG9lcyBhbnlvbmUKICAgIGRpc2FncmVlIHdpdGggbXkgY29u Y2x1c2lvbnM/PGJyPgogICAgPGJyPjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2Pjxicj48L2Rpdj48 ZGl2PllvdSBoYXZlbiYjMzk7dCBwcm92aWRlZCBldmlkZW5jZSBvbiBob3cgbXVjaCBSQU0geW91 ciBzeXN0ZW0gc2Vlcy4gQSBmcmVlIC1tIHdpbGwgc2hvdyB0aGUgdG90YWwgbWVtb3J5IHRoZSBz eXN0ZW0gaGFzIGFuZCBpcyBiZWluZyB1c2VkLqA8L2Rpdj48ZGl2PqA8L2Rpdj48L2Rpdj5SZWdh cmRzLgo= --047d7b15fe0bd79a9204bebfc522-- From cs_dba@consistentstate.com Sat Apr 28 16:38:19 2012 Received: from makus.postgresql.org (makus.postgresql.org [98.129.198.125]) by mail.postgresql.org (Postfix) with ESMTP id 2A8F9358049 for ; Sat, 28 Apr 2012 13:38:19 -0300 (ADT) Received: from 74-93-229-125-colorado.hfc.comcastbusiness.net ([74.93.229.125] helo=mail.consistentstate.com) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1SOAf4-0001rv-4Y for pgsql-admin@postgresql.org; Sat, 28 Apr 2012 16:38:18 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.consistentstate.com (Postfix) with ESMTP id 884443063D9; Sat, 28 Apr 2012 10:38:05 -0600 (MDT) X-Virus-Scanned: amavisd-new at consistentstate.com Received: from mail.consistentstate.com ([127.0.0.1]) by localhost (mail.consistentstate.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0cSj75RxmOV; Sat, 28 Apr 2012 10:37:59 -0600 (MDT) Received: from Issac.consistentstate.com (unknown [67.137.237.194]) by mail.consistentstate.com (Postfix) with ESMTPSA id 0B9C53063CC; Sat, 28 Apr 2012 10:37:58 -0600 (MDT) Message-ID: <4F9C1CE6.20803@consistentstate.com> Date: Sat, 28 Apr 2012 10:37:58 -0600 From: Kevin Kempter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Fernando Hevia CC: pgsql-admin@postgresql.org Subject: Re: Postgres shared memory error References: <4F9C1659.5070503@consistentstate.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060500090602070107030707" X-Pg-Spam-Score: -0.9 (/) X-Archive-Number: 201204/149 X-Sequence-Number: 39485 This is a multi-part message in MIME format. --------------060500090602070107030707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 04/28/2012 10:32 AM, Fernando Hevia wrote: > > > On Sat, Apr 28, 2012 at 13:10, Kevin Kempter > > wrote: > > All; > > I just want to be sure that I'm not causing myself greif. I have > a kvm in the cloud that is supposed to have access to 32GB of ram. > when I do a top I only see 1GB of ram, I've pinged the hosting > provider, maybe it shows up as it's used? > > > What does the 'free' command show? > > Anyway when I try and start postgres I see this: > / > $ 2012-04-28 12:00:33 EDT [6429]: [1-1] FATAL: XX000: could not > create shared memory segment: Cannot allocate memory > 2012-04-28 12:00:33 EDT [6429]: [2-1] DETAIL: Failed system call > was shmget(key=5432001, size=7700914176, 03600). > 2012-04-28 12:00:33 EDT [6429]: [3-1] HINT: This error usually > means that PostgreSQL's request for a shared memory segment > exceeded available memory or swap space. To reduce the request > size (currently 7700914176 bytes), reduce PostgreSQL's > shared_buffers parameter (currently 917504) and/or its > max_connections parameter (currently 503). > The PostgreSQL documentation contains more information > about shared memory configuration. > 2012-04-28 12:00:33 EDT [6429]: [4-1] LOCATION: > InternalIpcMemoryCreate, pg_shmem.c:178 / > > > Which means I should bump up shmmax like this: > > /# sysctl -w kernel.shmmax=7700914176/ > > > and add it to /etc/sysctl.conf: > > /# tail /etc/sysctl.conf > kernel.msgmax = 65536 > > # Controls the maximum shared segment size, in bytes > kernel.shmmax = 68719476736 > > # Controls the maximum number of shared memory segments, in pages > kernel.shmall = 4294967296 > > #PostgreSQL > kernel.shmmax = 7700914176 / > > > I assume I should have to tweak ONLY kernel.shmmax, am I correct? > > > Correct. > > I'm also assuming that this is a KVM cloud host provider issue, > i.e. it looks like I actually do not have 32G or ram. Does anyone > disagree with my conclusions? > > > You haven't provided evidence on how much RAM your system sees. A free > -m will show the total memory the system has and is being used. > Regards. Free command: / # free total used free shared buffers cached Mem: 1020856 946804 74052 0 61280 796004 -/+ buffers/cache: 89520 931336 Swap: 0 0 0/ --------------060500090602070107030707 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 04/28/2012 10:32 AM, Fernando Hevia wrote:


On Sat, Apr 28, 2012 at 13:10, Kevin Kempter <cs_dba@consistentstate.com> wrote:
All;

I just want to be sure that I'm not causing myself greif.  I have a kvm in the cloud that is supposed to have access to 32GB of ram. when I do a top I only see 1GB of ram, I've pinged the hosting provider, maybe it shows up as it's used?


What does the 'free' command show?

 
Anyway when I try and start postgres I see this:

 $ 2012-04-28 12:00:33 EDT [6429]: [1-1] FATAL:  XX000: could not create shared memory segment: Cannot allocate memory                    
2012-04-28 12:00:33 EDT [6429]: [2-1] DETAIL:  Failed system call was shmget(key=5432001, size=7700914176, 03600).                                             
2012-04-28 12:00:33 EDT [6429]: [3-1] HINT:  This error usually means that PostgreSQL's request for a shared memory segment exceeded available memory or swap space. To reduce the request size (currently 7700914176 bytes), reduce PostgreSQL's shared_buffers parameter (currently 917504) and/or its max_connections parameter (currently 503).                                                            
        The PostgreSQL documentation contains more information about shared memory configuration.                                                              
2012-04-28 12:00:33 EDT [6429]: [4-1] LOCATION:  InternalIpcMemoryCreate, pg_shmem.c:178 



Which means I should bump up shmmax like this:

# sysctl -w kernel.shmmax=7700914176


and add it to /etc/sysctl.conf:

# tail /etc/sysctl.conf                                                          
kernel.msgmax = 65536                                                                              
                                                                                                   
# Controls the maximum shared segment size, in bytes                                               
kernel.shmmax = 68719476736                                                                        
                                                                                                   
# Controls the maximum number of shared memory segments, in pages                                  
kernel.shmall = 4294967296                                                                         
                                                                                                   
#PostgreSQL                                                                                        
kernel.shmmax = 7700914176 



I assume I should have to tweak ONLY kernel.shmmax, am I correct?

Correct.
 
I'm also assuming that this is a KVM cloud host provider issue, i.e. it looks like I actually do not have 32G or ram.  Does anyone disagree with my conclusions?


You haven't provided evidence on how much RAM your system sees. A free -m will show the total memory the system has and is being used. 
 
Regards.



Free command:

 # free
             total       used       free     shared    buffers     cached
Mem:       1020856     946804      74052          0      61280     796004
-/+ buffers/cache:      89520     931336
Swap:            0          0          0






--------------060500090602070107030707-- From fhevia@gmail.com Sun Apr 29 00:13:56 2012 Received: from makus.postgresql.org (makus.postgresql.org [98.129.198.125]) by mail.postgresql.org (Postfix) with ESMTP id 051DD35804A for ; Sat, 28 Apr 2012 21:13:56 -0300 (ADT) Received: from mail-pz0-f46.google.com ([209.85.210.46]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1SOHly-0008Vg-Rg for pgsql-admin@postgresql.org; Sun, 29 Apr 2012 00:13:55 +0000 Received: by dadz9 with SMTP id z9so2850874dad.33 for ; Sat, 28 Apr 2012 17:13:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=JYLIQ+UYxoBha4TV7c0sVRsaCtI2hMrZKF8+D5DO+x0=; b=ZfS24mczewE/NYyCy8sOtNPsipPx8wrUzIq3Jn2OQh4HAD2QTJOAlJZ8vbu3//3Mwa UzXzWdNOhqKGQmfxyFs2O4jP8aQN8vZvkqvE2buFHmbfthsMxX3PlF0xQVZ7UPie++Ft mZQE/c3bCCcrcsu++sJIfVdOmirDEI1lb+eRgVhUtMy8b9YGsfLwWWbxMFheYx/fVib9 cXrBdxYZjkDTi22d3j4fg0gRJ/MrxJMCZlR+rKEhccQB4dZwUdvabkrOfMn0qfNgvu2Q V7WvGuzaor1elfllT8PMjgPXFvYwqh2poRGZb2V1RuQx79hS4fBkxdvGV+fkuCwIA/61 pmCA== Received: by 10.68.129.130 with SMTP id nw2mr3401717pbb.133.1335658422219; Sat, 28 Apr 2012 17:13:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.232.200 with HTTP; Sat, 28 Apr 2012 17:13:22 -0700 (PDT) In-Reply-To: <4F9C1CE6.20803@consistentstate.com> References: <4F9C1659.5070503@consistentstate.com> <4F9C1CE6.20803@consistentstate.com> From: Fernando Hevia Date: Sat, 28 Apr 2012 21:13:22 -0300 Message-ID: Subject: Re: Postgres shared memory error To: Kevin Kempter Cc: pgsql-admin@postgresql.org Content-Type: multipart/alternative; boundary=047d7b10ccb5cc345604bec635c1 X-Pg-Spam-Score: -2.6 (--) X-Archive-Number: 201204/152 X-Sequence-Number: 39488 --047d7b10ccb5cc345604bec635c1 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Apr 28, 2012 at 13:37, Kevin Kempter wrote: > > Free command: > > * # free > total used free shared buffers cached > Mem: 1020856 946804 74052 0 61280 796004 > -/+ buffers/cache: 89520 931336 > Swap: 0 0 0* > > > You are right. Your system has only 1 GB RAM. --047d7b10ccb5cc345604bec635c1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, Apr 28, 2012 at 13:37, Kevin Kem= pter <cs_dba@consistentstate.com> wrote:
=20 =20 =20

Free command:

=A0# free
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 total=A0=A0=A0=A0=A0=A0 used= =A0=A0=A0=A0=A0=A0 free=A0=A0=A0=A0 shared=A0=A0=A0 buffers=A0=A0=A0=A0 cached
Mem:=A0=A0=A0=A0=A0=A0 1020856=A0=A0=A0=A0 946804=A0=A0=A0=A0=A0 74= 052=A0=A0=A0=A0=A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0 61280=A0=A0=A0=A0 796004
-/+ buffers/cache:=A0=A0=A0=A0=A0 89520=A0=A0=A0=A0 931336
Swap:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0=A0=A0=A0=A0= 0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0




=A0You are right. Your s= ystem has only 1 GB RAM.
--047d7b10ccb5cc345604bec635c1--