Introduction
pg database in different business scenarios also need to be the best parameter for adjustment. The default is to ensure minimum resource consumption case, pg can be up and running, will not lead to any threat fatal. And in practice, the default parameters need to be optimized to maximize performance, this article describes some common configuration parameters.
parameter
pg default database after the installation there will be a postgresql.conf file in the data directory, this there are a lot of parameters to configure the database.
shared_buffers
PostgreSQL uses both its own buffer, use the kernel buffer IO. This means that the data will be stored in memory twice, first into PostgreSQL buffer, then the kernel buffer. This is called double buffering process. For most operating systems, this is the most effective parameter for parameter tuning. The effect of this parameter is set for the amount of private memory PostgreSQL cache.
The default value shared_buffers is set very low, because some machines and operating systems do not support the use of higher value. But in the most modern equipment, usually you need to increase the value of this parameter in order to obtain the best performance.
Recommended setting value of 25% of the total memory size of the machine, but can also try to set the lower and higher values according to the actual situation. The actual value depends on the amount of data size of the machine configuration and specific work. For example, if the working data set can easily be placed in memory, it can increase the value shared_buffers to contain the entire database, so that the entire working data set may remain in the cache.
In a production environment, the shared_buffers set to a large value can often provide very good performance, but should always pay attention to find a balance.
Shared_buffers view the current value:
postgres=# show shared_buffers;
shared_buffers
----------------
128MB
wal_buffers
PostgreSQL to WAL (write-ahead log) record in the buffer, then these buffers are flushed to disk. A default buffer size is defined wal_buffers 16MB, but if a large number of concurrent connections, then set to a high value may provide better performance.
View current wal_buffers values:
postgres=# show wal_buffers;
wal_buffers
-------------
4MB
(1 行记录)effective_cache_size
effective_cache_size can be used to provide an estimate of the amount of memory disk cache. It is only a recommended value, rather than the exact allocation of memory or cache size. It does not actually allocate memory, but will inform the amount of cache optimized kernel available. In the estimation of the cost index, such that the higher the value will be more likely to use an index scan, so that lower values would be more likely to use sequential scanning. When you set this parameter, you should also consider the PostgreSQL shared buffer and the kernel disk buffer will be used for PostgreSQL data files. The default value is 4GB.
View current effective_cache_size values:
postgres=# show effective_cache_size;
effective_cache_size
----------------------
4GB
(1 行记录)work_mem
This configuration is used to sort the composite. Sort memory much faster than the sort overflow to disk, set very high values may result in the deployment environment has a memory bottleneck, because this argument is sorted by user operation. If multiple users attempt to perform the sorting operation, the system will assign all users of space the size of the total number of work_mem * sorting operation. Global settings this parameter may cause memory usage is too high, it is strongly recommended to modify this parameter value at the session level. The default is 4MB.
View current work_mem values:
postgres=# show work_mem;
work_mem
----------
4MB
(1 行记录)maintenance_work_mem
maintenance_work_mem is memory settings for maintenance tasks. The default value is 64MB. Set the value for the performance improvement effect VACUUM, RESTORE, CREATE INDEX, ADD FOREIGN KEY and ALTER TABLE other operations significantly.
Maintenance_work_mem view the current value:
postgres=# show maintenance_work_mem;
maintenance_work_mem
----------------------
64MB
(1 行记录)
synchronous_commit
The effect of this parameter is returned to the client before the successful state, forced to submit WAL waiting to be written to disk. This is a trade-off between performance and reliability. If the application is designed to be the performance is more important than reliability, so close synchronous_commit. This means that there will be between the state and guarantee the success of the time difference is written to disk. In the case of a server crash, even if the client receive a success message at the time of filing, data may be lost.
View the current settings synchronous_commit of:
postgres=# show synchronous_commit;
synchronous_commit
--------------------
on
(1 行记录)checkpoint_timeout和checkpoint_completion_target
PostgreSQL will write the changes WAL. The checkpoint process will refresh the data into a data file. This is done when CHECKPOINT occur. This is an expensive operation, the whole process involves a lot of disk read / write operations. The user can issue commands CHECKPOINT any time when necessary, or automatically accomplished by the parameter checkpoint_timeout PostgreSQL and checkpoint_completion_target.
checkpoint_timeout parameter sets the time between the WAL checkpoints. Setting this too low can reduce crash recovery time, as more data is written to disk, but because each checkpoint will take up system resources, so it will hurt performance. This parameter can only be set on the server or the command line in the postgresql.conf file.
checkpoint_completion_target checkpoint targeting accomplished as part of the total time between checkpoints. The default value is 0.5. This parameter can only be set on the server or the command line in the postgresql.conf file. Checkpoint high frequency can affect performance.
View the current value of checkpoint_timeout and checkpoint_completion_target:
PostgreSQL will write the changes WAL. The checkpoint process will refresh the data into a data file. This is done when CHECKPOINT occur. This is an expensive operation, the whole process involves a lot of disk read / write operations. The user can issue commands CHECKPOINT any time when necessary, or automatically accomplished by the parameter checkpoint_timeout PostgreSQL and checkpoint_completion_target.
checkpoint_timeout parameter sets the time between the WAL checkpoints. Setting this too low can reduce crash recovery time, as more data is written to disk, but because each checkpoint will take up system resources, so it will hurt performance. This parameter can only be set on the server or the command line in the postgresql.conf file.
checkpoint_completion_target checkpoint targeting accomplished as part of the total time between checkpoints. The default value is 0.5.
This parameter can only be set on the server or the command line in the postgresql.conf file. Checkpoint high frequency can affect performance.
View the current value of checkpoint_timeout and checkpoint_completion_target:
postgres=# show checkpoint_timeout;
checkpoint_timeout
--------------------
5min
(1 行记录)
postgres=# show checkpoint_completion_target;
checkpoint_completion_target
------------------------------
0.5
(1 行记录)wal_keep_segments
The main parameter is the number of control wal file, for the next business scenarios frequent changes to the database, a short wal log will be very large, the corresponding directory is pg_xlog, sometimes, the size of the directory may be several hundreds of G, it is fast will the disk is full. Therefore, in order to control the size of the directory is reasonable, wal_keep_segments will generally controlled within a reasonable range. Because this parameter is too small, it will affect the flow start or replicate database. If too large, then, is said earlier, leading to wal log is very large, space is often very large, the system default is 0, indicating that the database does not save any wal log, but in practice there will still be a small amount of production.
Wal_keep_segments view the current value:
postgres=# show wal_keep_segments;
wal_keep_segments
-------------------
0
(1 行记录)
to sum up
Of course, but also many other parameters, this reference to some of the information online were consolidated. pg database currently no mysql far less popular in China, but as the oracle of the best alternative open source database, pg been improving, I believe pg relevant information will be more and more, which we need to continue to try, constantly sharing their own use pg experience of.