Change to kernel-resources
All,
Our Solaris section is out of date. We should change it to:
===================
Solaris 2.6 to 2.9 (Solaris 6 to Solaris 9)
The default maximum size of a shared memory segment is too low for
PostgreSQL. The relevant settings can be changed in /etc/system, for
example:
set shmsys:shminfo_shmmax=0x2000000
set shmsys:shminfo_shmmin=1
set shmsys:shminfo_shmmni=256
set shmsys:shminfo_shmseg=256
set semsys:seminfo_semmap=256
set semsys:seminfo_semmni=512
set semsys:seminfo_semmns=512
set semsys:seminfo_semmsl=32
You need to reboot for the changes to take effect.
See also
http://sunsite.uakom.sk/sunworldonline/swol-09-1997/swol-09-insidesolaris.html
for information on shared memory under Solaris.
Solaris 2.10 (Solaris 10) and OpenSolaris
In Solaris 10 and OpenSolaris, the default shared memory and semaphore
settings are good enough for most PostgreSQL applications. Solaris now
defaults to a SHMMAX of 1/4 of system RAM. If you need to increase this
in order to set shared memory settings slightly higher, you should use a
project setting associated with the "postgres" user. For example, run
the following as root:
projadd -c "PostgreSQL DB User" -K
"project.max-shm-memory=(privileged,8GB,deny)" -U postgres -G postgres
user.postgres
This command adds the user.postgres project and raises the shared memory
maximum for the "postgres" user to 8GB, and takes effect the next time
that user logs in. The above assumes that there isn't already a project
101, and that postgresql is run by the postgres user in the postgres
group. No reboot is required.
Other recommended kernel setting changes for database servers which will
have a large number of connections are:
project.max-shm-ids=(priv,32768,deny)
project.max-sem-ids=(priv,4096,deny)
project.max-msg-ids=(priv,4096,deny)
Additionally, if you are running PostgreSQL inside a zone, you may need
to raise the zone resource usage limits as well. See "Chapter2:
Projects and Tasks" in the Solaris 10 System Administrator's Guide for
more information on projects and prctl.
================
(and no, there's no reusable link to the solaris docs)
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
On Tue, May 11, 2010 at 4:41 PM, Josh Berkus <josh@agliodbs.com> wrote:
The above assumes that there isn't already a project
101,
I must be missing something, because I don't see the reference to 101.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
On 5/11/10 3:06 PM, Robert Haas wrote:
On Tue, May 11, 2010 at 4:41 PM, Josh Berkus <josh@agliodbs.com> wrote:
The above assumes that there isn't already a project
101,I must be missing something, because I don't see the reference to 101.
Editing error. I see another, moment for a new version.
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
Josh Berkus wrote:
On 5/11/10 3:06 PM, Robert Haas wrote:
On Tue, May 11, 2010 at 4:41 PM, Josh Berkus <josh@agliodbs.com> wrote:
The above assumes that there isn't already a project
101,I must be missing something, because I don't see the reference to 101.
Editing error. I see another, moment for a new version.
Did this get applied?
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
On Sat, May 29, 2010 at 10:36 PM, Bruce Momjian <bruce@momjian.us> wrote:
Josh Berkus wrote:
On 5/11/10 3:06 PM, Robert Haas wrote:
On Tue, May 11, 2010 at 4:41 PM, Josh Berkus <josh@agliodbs.com> wrote:
The above assumes that there isn't already a project
101,I must be missing something, because I don't see the reference to 101.
Editing error. I see another, moment for a new version.
Did this get applied?
No. Josh said he was going to send an updated version fixing the
editing error which I spotted, and never did.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
Josh, can I get a correct, updated version of this so I can add it to
our documentation?
---------------------------------------------------------------------------
Josh Berkus wrote:
All,
Our Solaris section is out of date. We should change it to:
===================
Solaris 2.6 to 2.9 (Solaris 6 to Solaris 9)
The default maximum size of a shared memory segment is too low for
PostgreSQL. The relevant settings can be changed in /etc/system, for
example:set shmsys:shminfo_shmmax=0x2000000
set shmsys:shminfo_shmmin=1
set shmsys:shminfo_shmmni=256
set shmsys:shminfo_shmseg=256set semsys:seminfo_semmap=256
set semsys:seminfo_semmni=512
set semsys:seminfo_semmns=512
set semsys:seminfo_semmsl=32You need to reboot for the changes to take effect.
See also
http://sunsite.uakom.sk/sunworldonline/swol-09-1997/swol-09-insidesolaris.html
for information on shared memory under Solaris.Solaris 2.10 (Solaris 10) and OpenSolaris
In Solaris 10 and OpenSolaris, the default shared memory and semaphore
settings are good enough for most PostgreSQL applications. Solaris now
defaults to a SHMMAX of 1/4 of system RAM. If you need to increase this
in order to set shared memory settings slightly higher, you should use a
project setting associated with the "postgres" user. For example, run
the following as root:projadd -c "PostgreSQL DB User" -K
"project.max-shm-memory=(privileged,8GB,deny)" -U postgres -G postgres
user.postgresThis command adds the user.postgres project and raises the shared memory
maximum for the "postgres" user to 8GB, and takes effect the next time
that user logs in. The above assumes that there isn't already a project
101, and that postgresql is run by the postgres user in the postgres
group. No reboot is required.Other recommended kernel setting changes for database servers which will
have a large number of connections are:project.max-shm-ids=(priv,32768,deny)
project.max-sem-ids=(priv,4096,deny)
project.max-msg-ids=(priv,4096,deny)Additionally, if you are running PostgreSQL inside a zone, you may need
to raise the zone resource usage limits as well. See "Chapter2:
Projects and Tasks" in the Solaris 10 System Administrator's Guide for
more information on projects and prctl.================
(and no, there's no reusable link to the solaris docs)
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com--
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
Having received no replies to my request for an updated doc, I am going
to let the issue drop.
---------------------------------------------------------------------------
Josh Berkus wrote:
All,
Our Solaris section is out of date. We should change it to:
===================
Solaris 2.6 to 2.9 (Solaris 6 to Solaris 9)
The default maximum size of a shared memory segment is too low for
PostgreSQL. The relevant settings can be changed in /etc/system, for
example:set shmsys:shminfo_shmmax=0x2000000
set shmsys:shminfo_shmmin=1
set shmsys:shminfo_shmmni=256
set shmsys:shminfo_shmseg=256set semsys:seminfo_semmap=256
set semsys:seminfo_semmni=512
set semsys:seminfo_semmns=512
set semsys:seminfo_semmsl=32You need to reboot for the changes to take effect.
See also
http://sunsite.uakom.sk/sunworldonline/swol-09-1997/swol-09-insidesolaris.html
for information on shared memory under Solaris.Solaris 2.10 (Solaris 10) and OpenSolaris
In Solaris 10 and OpenSolaris, the default shared memory and semaphore
settings are good enough for most PostgreSQL applications. Solaris now
defaults to a SHMMAX of 1/4 of system RAM. If you need to increase this
in order to set shared memory settings slightly higher, you should use a
project setting associated with the "postgres" user. For example, run
the following as root:projadd -c "PostgreSQL DB User" -K
"project.max-shm-memory=(privileged,8GB,deny)" -U postgres -G postgres
user.postgresThis command adds the user.postgres project and raises the shared memory
maximum for the "postgres" user to 8GB, and takes effect the next time
that user logs in. The above assumes that there isn't already a project
101, and that postgresql is run by the postgres user in the postgres
group. No reboot is required.Other recommended kernel setting changes for database servers which will
have a large number of connections are:project.max-shm-ids=(priv,32768,deny)
project.max-sem-ids=(priv,4096,deny)
project.max-msg-ids=(priv,4096,deny)Additionally, if you are running PostgreSQL inside a zone, you may need
to raise the zone resource usage limits as well. See "Chapter2:
Projects and Tasks" in the Solaris 10 System Administrator's Guide for
more information on projects and prctl.================
(and no, there's no reusable link to the solaris docs)
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com--
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
Bruce,
Had to look up some stuff given the splintering of Solaris:
==================
Solaris 2.6 to 2.9 (Solaris 6 to Solaris 9)
The default maximum size of a shared memory segment is too low for
PostgreSQL. The relevant settings can be changed in /etc/system, for
example:
set shmsys:shminfo_shmmax=0x2000000
set shmsys:shminfo_shmmin=1
set shmsys:shminfo_shmmni=256
set shmsys:shminfo_shmseg=256
set semsys:seminfo_semmap=256
set semsys:seminfo_semmni=512
set semsys:seminfo_semmns=512
set semsys:seminfo_semmsl=32
You need to reboot for the changes to take effect.
See also
http://sunsite.uakom.sk/sunworldonline/swol-09-1997/swol-09-insidesolaris.html
for information on shared memory under older versions of Solaris.
Solaris 2.10 (Solaris 10), OpenSolaris and most open-source Solaris
variants (Joyent, Illumos, etc.)
In Solaris 10 and OpenSolaris, the default shared memory and semaphore
settings are good enough for most PostgreSQL applications. Solaris now
defaults to a SHMMAX of 1/4 of system RAM. If you need to increase this
in order to set shared memory settings slightly higher, you should use a
project setting associated with the "postgres" user. For example, run
the following as root:
projadd -c "PostgreSQL DB User" -K
"project.max-shm-memory=(privileged,8GB,deny)" -U postgres -G postgres
user.postgres
This command adds the user.postgres project and raises the shared memory
maximum for the "postgres" user to 8GB, and takes effect the next time
that user logs in, or when you restart PostgreSQL (not reload). The
above assumes that PostgreSQL is run by the postgres user in the
postgres group. No reboot is required.
Other recommended kernel setting changes for database servers which will
have a large number of connections are:
project.max-shm-ids=(priv,32768,deny)
project.max-sem-ids=(priv,4096,deny)
project.max-msg-ids=(priv,4096,deny)
Additionally, if you are running PostgreSQL inside a zone, you may need
to raise the zone resource usage limits as well. See "Chapter2:
Projects and Tasks" in the Solaris 10 System Administrator's Guide for
more information on projects and prctl.
===================
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
On Mon, Feb 7, 2011 at 1:47 PM, Josh Berkus <josh@agliodbs.com> wrote:
Had to look up some stuff given the splintering of Solaris:
==================
Solaris 2.6 to 2.9 (Solaris 6 to Solaris 9)
The default maximum size of a shared memory segment is too low for
PostgreSQL. The relevant settings can be changed in /etc/system, for
example:
What should we do with this material?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On 3/2/11 8:35 AM, Robert Haas wrote:
On Mon, Feb 7, 2011 at 1:47 PM, Josh Berkus <josh@agliodbs.com> wrote:
Had to look up some stuff given the splintering of Solaris:
==================
Solaris 2.6 to 2.9 (Solaris 6 to Solaris 9)
The default maximum size of a shared memory segment is too low for
PostgreSQL. The relevant settings can be changed in /etc/system, for
example:What should we do with this material?
Hmmm. I think there are probably still people using Solaris 9 out
there, but not very many.
Maybe we should move obscure OSes to the wiki, and have a link to the
wiki in the docs?
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
On Wed, Mar 2, 2011 at 2:46 PM, Josh Berkus <josh@agliodbs.com> wrote:
On 3/2/11 8:35 AM, Robert Haas wrote:
On Mon, Feb 7, 2011 at 1:47 PM, Josh Berkus <josh@agliodbs.com> wrote:
Had to look up some stuff given the splintering of Solaris:
==================
Solaris 2.6 to 2.9 (Solaris 6 to Solaris 9)
The default maximum size of a shared memory segment is too low for
PostgreSQL. The relevant settings can be changed in /etc/system, for
example:What should we do with this material?
Hmmm. I think there are probably still people using Solaris 9 out
there, but not very many.Maybe we should move obscure OSes to the wiki, and have a link to the
wiki in the docs?
I've got no problem putting it in the docs; in fact, I'd prefer it.
But it'd be a lot easier to put it there if this were in the form of a
patch.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Robert Haas wrote:
On Wed, Mar 2, 2011 at 2:46 PM, Josh Berkus <josh@agliodbs.com> wrote:
On 3/2/11 8:35 AM, Robert Haas wrote:
On Mon, Feb 7, 2011 at 1:47 PM, Josh Berkus <josh@agliodbs.com> wrote:
Had to look up some stuff given the splintering of Solaris:
==================
Solaris 2.6 to 2.9 (Solaris 6 to Solaris 9)
? ?The default maximum size of a shared memory segment is too low for
PostgreSQL. The relevant settings can be changed in /etc/system, for
example:What should we do with this material?
Hmmm. ?I think there are probably still people using Solaris 9 out
there, but not very many.Maybe we should move obscure OSes to the wiki, and have a link to the
wiki in the docs?I've got no problem putting it in the docs; in fact, I'd prefer it.
But it'd be a lot easier to put it there if this were in the form of a
patch.
I did the markup and applied the attached doc patch.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +