Thread: 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=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 > > -- > 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=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 > > -- > 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. + diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml new file mode 100644 index 4a989df..c369229 *** a/doc/src/sgml/runtime.sgml --- b/doc/src/sgml/runtime.sgml *************** sysctl -w kern.sysv.shmall *** 1028,1041 **** <varlistentry> ! <term><systemitem class="osname">Solaris</></term> <indexterm><primary>Solaris</><secondary>IPC configuration</></> <listitem> <para> ! At least in version 2.6, the default maximum size of a shared ! memory segment is too low for <productname>PostgreSQL</>. The ! relevant settings can be changed in <filename>/etc/system</>, ! for example: <programlisting> set shmsys:shminfo_shmmax=0x2000000 set shmsys:shminfo_shmmin=1 --- 1028,1041 ---- <varlistentry> ! <term><systemitem class="osname">Solaris</> 2.6 to 2.9 (Solaris ! 6 to Solaris 9)</term> <indexterm><primary>Solaris</><secondary>IPC configuration</></> <listitem> <para> ! The default maximum size of a shared memory segment is too low for ! <productname>PostgreSQL</>. The relevant settings can be changed in ! <filename>/etc/system</>, for example: <programlisting> set shmsys:shminfo_shmmax=0x2000000 set shmsys:shminfo_shmmin=1 *************** set semsys:seminfo_semmni=512 *** 1047,1060 **** set semsys:seminfo_semmns=512 set semsys:seminfo_semmsl=32 </programlisting> ! You need to reboot for the changes to take effect. </para> <para> ! See also <ulink ! url="http://sunsite.uakom.sk/sunworldonline/swol-09-1997/swol-09-insidesolaris.html"></> ! for information on shared memory under ! <productname>Solaris</>. </para> </listitem> </varlistentry> --- 1047,1105 ---- set semsys:seminfo_semmns=512 set semsys:seminfo_semmsl=32 </programlisting> ! You need to reboot for the changes to take effect. See also ! <ulink url="http://sunsite.uakom.sk/sunworldonline/swol-09-1997/swol-09-insidesolaris.html"></ulink> ! for information on shared memory under older versions of Solaris. </para> + </listitem> + </varlistentry> + <varlistentry> + <term><systemitem class="osname">Solaris</> 2.10 (Solaris + 10)</term> + <term><systemitem class="osname">OpenSolaris</></term> + <indexterm><primary>Solaris</><secondary>IPC configuration</></> + <listitem> <para> ! In Solaris 10 and OpenSolaris, the default shared memory and ! semaphore settings are good enough for most ! <productname>PostgreSQL</> applications. Solaris now defaults ! to a <varname>SHMMAX</> of one-quarter of system <acronym>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 <literal>postgres</> user. For example, run the ! following as <literal>root</>: ! <programlisting> ! projadd -c "PostgreSQL DB User" -K "project.max-shm-memory=(privileged,8GB,deny)" -U postgres -G postgres user.postgres ! </programlisting> ! </para> ! ! <para> ! This command adds the <literal>user.postgres</> project and ! raises the shared memory maximum for the <literal>postgres</> ! user to 8GB, and takes effect the next time that user logs ! in, or when you restart <productname>PostgreSQL</> (not reload). ! The above assumes that <productname>PostgreSQL</> is run by ! the <literal>postgres</> user in the <literal>postgres</> ! group. No server reboot is required. ! </para> ! ! <para> ! Other recommended kernel setting changes for database servers which will ! have a large number of connections are: ! <programlisting> ! project.max-shm-ids=(priv,32768,deny) ! project.max-sem-ids=(priv,4096,deny) ! project.max-msg-ids=(priv,4096,deny) ! </programlisting> ! </para> ! ! <para> ! Additionally, if you are running <productname>PostgreSQL</> ! inside a zone, you may need to raise the zone resource usage ! limits as well. See "Chapter2: Projects and Tasks" in the ! <citetitle>Solaris 10 System Administrator's Guide</> for more ! information on <literal>projects</> and <command>prctl</>. </para> </listitem> </varlistentry>