I tried When running PostgreSQL as one of my first experimentsor Oracle XE (APEX), and hit upon some nuances of shared memory, which may be helpful to relate herearise.
==== PostgreSQL ====One of the easiest ways to increase Postgres's performance is to turn up the shared_buffers parameter in the postgresql.conf file; this . This is basically the amount of shared memory which the postmaster will use for buffering everything: table data, indexes, etc. The default value is really small, and if you have RAM to spare you may want to crank it up to 128MB (that's 16384 shared buffers, for pgsql 8.1 and earlier) or even more. But if After changing shared_buffers, it then complains might complain that it couldn't allocate the shared memory, this page explains whyeven though plenty of memory exists.
PostgreSQL uses ==== Oracle XE ====A similar situation may occur when installing Oracle XE. The installation appears to succeed, but only the listener is running. No database instance is running. The database directory (/usr/lib/oracle/xe/oradata/XE) is empty. The log file /usr/lib/oracle/xe/app/oracle/admin/XE/bdump/alert_XE.log contains only a couple of lines that indicate success (but there should be many lines of output). Files in /usr/lib/oracle/xe/app/oracle/admin/XE/udump have an odd error "skgm warning: ENOSPC creating segment of size..." and suggest a change to the shared memory configuration, even though the shared memoryvalues are what Oracle recommends. As suchDuring installation, you have Oracle will add entries to /etc/sysctl.conf to check two things about the containerset shared memory parameters.
1. UBC's shmpages setting for this container. This dictates how many pages (one page is usually 4K, see [[memory page]] for more details) ==== Shared Memory ====There are available to the container, e.g. shmpages=16384 gives a limit of 64 MB of two things that control shared memoryin a container.
21. "/sbin/sysctl kernelThe shmpages setting for this container (check [[UBC]]).shmmax" This dictates how many pages (one page is usually 4K, see [[memory page]] for more details) are available to the container's self-imposed , e.g. shmpages=16384 gives a limit on how much of 64 MB of shared memory may be allocated in a single request, in bytes.
Get that? Not only does the HN impose a limit on 2. "/sbin/sysctl kernel.shmmax" This is the container's total self-imposed limit in bytes of how much shared memory usage, but the container itself has a setting for the maximum amount may be allocated in a single chunkrequest. You may check the shared memory configuration with "ipcs -l".
Some other notes:The HN imposes a limit on the container's total shared memory usage through shmpages, and the container itself imposes a limit on the container's total shared memory usage through kernel.shmmax. If the size of shmpages is less than kernel.shmmax, the database will not be able to allocate sufficient memory.
==== Notes ====* Note that shared Shared memory is part of taken from the container's overall memory usageallocation. It is not a second memory pool.
* Note that Other processes other than PostgreSQL may be using shared memory, and also that shmpages includes stuff things other than IPC shared memory (tmpfs, shmem, etc.) So don't . If this is the case for your container, set shmpages to exactly higher than the amount you want to give Postgresdatabase requires.
* The sysctl kernel.shmmax value set in the [[HN]]/[[CT0]] applies only to the [[HN]], not to [[container]]s.