During installation, PureMessage automatically adjusts the PostgreSQL database in an attempt to improve performance. If the adjustments are successful, PureMessage displays a confirmation message. If the adjustments fail, it is likely due to the shared memory configuration of your system. PureMessage will revert the changes and create a postgresql.conf.recommended file that contains appropriate system settings. This tuning guide provides recommendations for hardware usage, system allocation and configuration, and settings for shared memory and semaphores.
Important: The PureMessage installer assumes that the Database Server role is installing PostgreSQL on a system with 1GB of RAM. If more than 1GB of RAM is available, you should follow these instructions to improve the performance of PostgreSQL.
PostgreSQL, like other transactional RDBMS's, is I/O intensive for updates. A fast SCSI disk array is the single greatest performance factor. After the I/O subsystem, RAM is the next most significant factor, followed by CPU speed. Expect to use up to 4 GB of RAM.
PostgreSQL competes with other system processes for disk access and OS disk cache, which can make the database and the other processes perform poorly under load. For optimal performance in high-volume deployments, the Database server role (PostgreSQL) should be installed on a separate server from other PureMessage roles (for example, the Mail Filter role and Mail Transfer Agent role). This is particularly important in deployments with multiple mail-filtering servers.
PostgreSQL uses Write-Ahead Logging (WAL) for transactions to protect against data loss. For high traffic systems, the performance of this logging can be increased by moving the log file (pg_xlog) to its own disk.
For example, to move pg_xlog to its own disk and symbolically link it to the default $PGDATA directory:
RAID 5 with 3 disks, though it is a standard configuration, is the slowest array configuration possible for PostgreSQL. A RAID 5 configuration performs as much as two times slower for pg_xlog traffic. This also can give you as little as 50% of the query speed as running on a plain SCSI disk. We recommend RAID 1, 1+0 or 0+1 for any set of 2, 4 or 6 disks.
PostgreSQL requires semaphore ("sem") and shared memory ("shm") resources. System limits on these resources will restrict the number of concurrent database connections, and affect performance. On Solaris systems, the default system resource parameters are set too low and must be increased.
Detailed instructions on configuring kernel parameters for running PostgreSQL, with formulas for deriving reasonable settings, are available in the "Managing Kernel Resources" section of the PostgreSQL documentation. The PureMessage installation script attempts to set this minimally, but if it is unable to do so, or if you want to reconfigure what it has set, then this section has guidelines for appropriate settings and instructions for making these changes manually.
The table below shows the recommended minimum shared memory (SHM) settings, based on the RAM installed on the machine that is running the PureMessage Database server role (PostgreSQL). On a dedicated PureMessage database server, the SHM setting should represent at least one half of the machine's physical RAM .
Make the changes that are applicable to your operating system and version, in accordance with the table above. These changes must be made as the root user.
kernel.shmall=[SHM in bytes from the table above] kernel.shmmax=[SHM in bytes from the table above]
$ sysctl -w kernel.shmall=[SHM in bytes from the table above] $ sysctl -w kernel.shmmax=[SHM in bytes from the table above]
Adjustments to the shared_buffers and effective_cache_size settings of PostgreSQL may be required.
Detailed instructions on configuring PostgreSQL run-time parameters can be found in the "Run-time Configuration" section of the PostgreSQL documentation.
In general, shared_buffers and effective_cache_size can be set according to the guidelines below. To change these settings:
Shared memory is not the total memory PostgreSQL can work with; rather it is the block of dedicated memory PostgreSQL uses for active operations, and it should be a minority of the total RAM on the machine. This is because PostgreSQL must dynamically allocate memory per connection (process) for sorts, for in-memory hash tables, and for other activities that don't use shared memory.
On a single-server PureMessage deployment, milters consume a large amount of memory. So the milters should run with a concurrency limit that leaves enough physical memory for PostgreSQL.
The output of this command will look, in part, something like:
slot#1: pid=34207 vsz=78.9 acc=1/1/1 req=1
(RAM for PostgreSQL x (<server RAM in GB> - 1)) / milter size in MB = optimum milter concurrency limit
So, in this example, this would be:
(1024 x (4 - 1)) / 79 = 39 milters
$ pmx-config concurrency_limit 39
Every comment submitted here is read (by a human) but we do not reply to specific technical questions. If you need technical support please post a question to our community. Alternatively for licensed products open a support ticket.