Düzeltme Öner

Kaynak Tüketimi

Memory

shared_buffers

type: integer default: 1024 (8 MB) min: 16 (8kB) max: 1073741823 (8589934584kB) unit: 8kB context: postmaster restart: Gerektirir
<p>Sets the amount of memory the database server uses for shared memory buffers. The default is typically 128 megabytes (128MB), but might be less if your kernel settings will not support it (as determined during initdb). This setting must be at least 128 kilobytes. However, settings significantly higher than the minimum are usually needed for good performance. If this value is specified without units, it is taken as blocks, that is BLCKSZ bytes, typically 8kB. (Non-default values of BLCKSZ change the minimum value.) This parameter can only be set at server start.</p><p>If you have a dedicated database server with 1GB or more of RAM, a reasonable starting value for shared_buffers is 25% of the memory in your system. There are some workloads where even larger settings for shared_buffers are effective, but because PostgreSQL also relies on the operating system cache, it is unlikely that an allocation of more than 40% of RAM to shared_buffers will work better than a smaller amount. Larger settings for shared_buffers usually require a corresponding increase in max_wal_size, in order to spread out the process of writing large quantities of new or changed data over a longer period of time.</p><p>On systems with less than 1GB of RAM, a smaller percentage of RAM is appropriate, so as to leave adequate space for the operating system.</p>
Veritabanı sunucusunun shared memory buffers için kullandığı bellek miktarını ayarlar. Öntanımlı değeri 128 megabayttır (128MB). Bu ayar en az 128 kilobayt olabilir. İyi performans için minimumdan değerden daha yüksek ayarlar gereklidir. Bu değer birimsiz verilirse bloklar (BLCKSZ = 8kb) olarak alınır. Bu parametre yalnızca sunucu başlangıcında ayarlanabilir.

1 GB veya fazlası RAM’e sahip veritabanı sunucuları için sisteminizdeki belleğin %25’i makul bir shared_buffers başlangıç ​​değeridir. Daha büyük shared_buffers ayarlarının etkili olduğu bazı iş yükleri olabilir, ancak PostgreSQL aynı zamanda işletim sistemi önbelleğide kullandığı için RAM’in %40’ından fazlasının shared_buffers’a tahsis edilmesi daha küçük bir miktara kıyasla iyi bir performans göstermeyecektir.

huge_pages

type: enum default: try context: postmaster values: [off, on, try] restart: Gerektirir
<p>Controls whether huge pages are requested for the main shared memory area. Valid values are try (the default), on, and off. With huge_pages set to try, the server will try to request huge pages, but fall back to the default if that fails. With on, failure to request huge pages will prevent the server from starting up. With off, huge pages will not be requested.</p><p>At present, this setting is supported only on Linux and Windows. The setting is ignored on other systems when set to try.</p><p>The use of huge pages results in smaller page tables and less CPU time spent on memory management, increasing performance. For more details about using huge pages on Linux, see linux-huge-pages.</p><p>Huge pages are known as large pages on Windows. To use them, you need to assign the user right Lock Pages in Memory to the Windows user account that runs PostgreSQL. You can use Windows Group Policy tool (gpedit.msc) to assign the user right Lock Pages in Memory. To start the database server on the command prompt as a standalone process, not as a Windows service, the command prompt must be run as an administrator or User Access Control (UAC) must be disabled. When the UAC is enabled, the normal command prompt revokes the user right Lock Pages in Memory when started.</p><p>Note that this setting only affects the main shared memory area. Operating systems such as Linux, FreeBSD, and Illumos can also use huge pages (also known as super pages or large pages) automatically for normal memory allocation, without an explicit request from PostgreSQL. On Linux, this is called transparent huge pagestransparent huge pages (THP). That feature has been known to cause performance degradation with PostgreSQL for some users on some Linux versions, so its use is currently discouraged (unlike explicit use of huge_pages).</p>
Huge page kullanımını kontrol eder. Geçerli değerler, try (varsayılan), on ve off şeklindedir. huge_pages try ayarında sunucu huge page’ler istemeye çalışır, ancak başarısız olursa varsayılana geri döner. on ayarında huge page’lerin istenmemesi sunucunun başlamasını engelleyecektir. off ayarında huge page’ler istenmez.

temp_buffers

type: integer default: 1024 (8MB) min: 100 (800kB) max: 1073741823 (8589934584kB) unit: 8kB context: user
<p>Sets the maximum amount of memory used for temporary buffers within each database session. These are session-local buffers used only for access to temporary tables. If this value is specified without units, it is taken as blocks, that is BLCKSZ bytes, typically 8kB. The default is eight megabytes (8MB). (If BLCKSZ is not 8kB, the default value scales proportionally to it.) This setting can be changed within individual sessions, but only before the first use of temporary tables within the session; subsequent attempts to change the value will have no effect on that session.</p><p>A session will allocate temporary buffers as needed up to the limit given by temp_buffers. The cost of setting a large value in sessions that do not actually need many temporary buffers is only a buffer descriptor, or about 64 bytes, per increment in temp_buffers. However if a buffer is actually used an additional 8192 bytes will be consumed for it (or in general, BLCKSZ bytes).</p>
Her veritabanı oturumunda temporary buffers için kullanılan maksimum bellek miktarını ayarlar. Bu alanlar, yalnızca geçici tablolara erişim için kullanılan session-local arabellekleridir. Öntanımlı değeri 8 megabayttır (8MB). Bu ayar, bireysel oturumlar içinde yalnızca oturumdaki geçici tabloların ilk kullanımından önce değiştirilebilir. Değeri değiştirmeye yönelik sonraki girişimlerin o oturum üzerinde hiçbir etkisi olmayacaktır.

max_prepared_transactions

type: integer default: 0 min: 0 max: 262143 context: postmaster restart: Gerektirir
<p>Sets the maximum number of transactions that can be in the prepared state simultaneously (see sql-prepare-transaction). Setting this parameter to zero (which is the default) disables the prepared-transaction feature. This parameter can only be set at server start.</p><p>If you are not planning to use prepared transactions, this parameter should be set to zero to prevent accidental creation of prepared transactions. If you are using prepared transactions, you will probably want max_prepared_transactions to be at least as large as max_connections, so that every session can have a prepared transaction pending.</p><p>When running a standby server, you must set this parameter to the same or higher value than on the master server. Otherwise, queries will not be allowed in the standby server.</p>
Aynı anda prepared statede olabilecek maksimum transaction sayısını ayarlar. Parametrenin sıfıra (varsayılan değerdir) ayarlanması prepared-transaction özelliğini devre dışı bırakır. Bu parametre yalnızca sunucu başlangıcında ayarlanabilir.

Prepared transaction kullanmayı planlamıyorsanız yanlışlıkla oluşturulmasını önlemek için bu parametre sıfıra ayarlayın. Prepared transaction kullanırken max_prepared_transactions değerinin en az max_connections kadar olması önerilir. Böylece her oturum sırada bir prepared transactiona sahip olur.

Standby sunucuda bu parametre primary sunucudakiyle aynı veya daha yüksek bir değere ayarlanmalıdır. Aksi takdirde standby sunucuda sorgulara izin verilmez.

work_mem

type: integer default: 4096 (4MB) min: 64 (64kB) max: 2147483647 (2147483647kB) unit: kB context: user
<p>Sets the base maximum amount of memory to be used by a query operation (such as a sort or hash table) before writing to temporary disk files. If this value is specified without units, it is taken as kilobytes. The default value is four megabytes (4MB). Note that for a complex query, several sort or hash operations might be running in parallel; each operation will generally be allowed to use as much memory as this value specifies before it starts to write data into temporary files. Also, several running sessions could be doing such operations concurrently. Therefore, the total memory used could be many times the value of work_mem; it is necessary to keep this fact in mind when choosing the value. Sort operations are used for ORDER BY, DISTINCT, and merge joins. Hash tables are used in hash joins, hash-based aggregation, and hash-based processing of IN subqueries.</p><p>Hash-based operations are generally more sensitive to memory availability than equivalent sort-based operations. The memory available for hash tables is computed by multiplying work_mem by hash_mem_multiplier. This makes it possible for hash-based operations to use an amount of memory that exceeds the usual work_mem base amount.</p>
Sorgu operasyonları (ORDER BY, DISTINCT, merge joins, hash joins) tarafından kullanılacak maksimum bellek miktarını ayarlar. Bu değer birimsiz olarak verilirse kilobayt olarak alınır. Öntanımlı değeri 4 megabayttır (4MB). Her operasyon, verileri geçici dosyalara yazmaya başlamadan önce bu değer kadar bellek kullanabilir. Bu operasyonlar çalışan birkaç oturum aynı anda olabileceğinden, total kullanılan bellek work_mem değerinin birçok katı olabilir. Değeri seçerken bu gerçeği göz önünde bulundurun.

Hash-based operasyonlar kullanılabilir belleğe sort-based operasyonlara göre daha duyarlıdır. hash table’lar için kullanılabilir bellek work_mem ile hash_mem_multiplier çarpımından hesaplanır.

hash_mem_multiplier

type: real default: 1 min: 1 max: 1000 context: user
<p>Used to compute the maximum amount of memory that hash-based operations can use. The final limit is determined by multiplying work_mem by hash_mem_multiplier. The default value is 1.0, which makes hash-based operations subject to the same simple work_mem maximum as sort-based operations.</p><p>Consider increasing hash_mem_multiplier in environments where spilling by query operations is a regular occurrence, especially when simply increasing work_mem results in memory pressure (memory pressure typically takes the form of intermittent out of memory errors). A setting of 1.5 or 2.0 may be effective with mixed workloads. Higher settings in the range of 2.0 - 8.0 or more may be effective in environments where work_mem has already been increased to 40MB or more.</p>
Hash-based operasyonların kullanabileceği maksimum bellek miktarını hesaplamak için kullanılır. Nihai sınır work_mem‘in hash_mem_multiplier ile çarpılmasıyla belirlenir. Öntanımlı değer 1.0’dır.

maintenance_work_mem

type: integer default: 65536 (64MB) min: 1024 (1MB) max: 2147483647 (2147483647kB) unit: kB context: user
<p>Specifies the maximum amount of memory to be used by maintenance operations, such as VACUUM, CREATE INDEX, and ALTER TABLE ADD FOREIGN KEY. If this value is specified without units, it is taken as kilobytes. It defaults to 64 megabytes (64MB). Since only one of these operations can be executed at a time by a database session, and an installation normally doesn’t have many of them running concurrently, it’s safe to set this value significantly larger than work_mem. Larger settings might improve performance for vacuuming and for restoring database dumps.</p><p>Note that when autovacuum runs, up to autovacuum_max_workers times this memory may be allocated, so be careful not to set the default value too high. It may be useful to control for this by separately setting autovacuum_work_mem.</p>
VACUUM, CREATE INDEX ve ALTER TABLE ADD FOREIGN KEY gibi bakım operasyonlarında kullanılacak maksimum bellek miktarını belirtir. Bu değer birimsiz verildiğinde kilobayt olarak alınır. Öntanımlı değeri 64 megabayttır (64MB). Bir veritabanı oturumu tarafından aynı anda bu operasyonlardan yalnızca biri yürütülebilir ve normal kurulumda çoğu eşzamanlı olarak çalışmaz. Bu yüzden work_mem‘den daha büyük ayar değeri güvenlidir. Daha büyük ayarlar vakumlama ve veritabanı dumplarından geri yükleme performansını artırır.

autovacuum_work_mem

type: integer default: -1 min: -1 max: 2147483647 (2147483647 kB) unit: kB context: sighup
<p>Specifies the maximum amount of memory to be used by each autovacuum worker process. If this value is specified without units, it is taken as kilobytes. It defaults to -1, indicating that the value of maintenance_work_mem should be used instead. The setting has no effect on the behavior of VACUUM when run in other contexts.</p>
Her bir autovacuum worker process tarafından kullanılacak maksimum bellek miktarını belirtir. Bu değer birimsiz verildiğinde kilobayt olarak alınır. Öntanımlı değeri -1’dir ve bunun yerine maintenance_work_mem değerinin kullanılması gerektiğini belirtir.

logical_decoding_work_mem

type: integer default: 65536 (64MB) min: 64 (64kB) max: 2147483647 (2147483647 kB) unit: kB context: user
<p>Specifies the maximum amount of memory to be used by logical decoding, before some of the decoded changes are written to local disk. This limits the amount of memory used by logical streaming replication connections. It defaults to 64 megabytes (64MB). Since each replication connection only uses a single buffer of this size, and an installation normally doesn’t have many such connections concurrently (as limited by max_wal_senders), it’s safe to set this value significantly higher than work_mem, reducing the amount of decoded changes written to disk.</p>
Logical decoding tarafından kullanılacak maksimum bellek miktarını belirtir. Bu, logical streaming replication bağlantıları tarafından kullanılan bellek miktarını sınırlar. Öntanımlı olarak 64 megabayttır (64MB). Bu değeri work_mem‘den önemli ölçüde daha yüksek değerde ayarlamak diske yazılan decoded değişikliklerin miktarı azaltır.

max_stack_depth

type: integer default: 100 (100kB) min: 100 (100kB) max: 2147483647 (2147483647 kB) unit: kB context: superuser
<p>Specifies the maximum safe depth of the server’s execution stack. The ideal setting for this parameter is the actual stack size limit enforced by the kernel (as set by ulimit -s or local equivalent), less a safety margin of a megabyte or so. The safety margin is needed because the stack depth is not checked in every routine in the server, but only in key potentially-recursive routines. If this value is specified without units, it is taken as kilobytes. The default setting is two megabytes (2MB), which is conservatively small and unlikely to risk crashes. However, it might be too small to allow execution of complex functions. Only superusers can change this setting.</p><p>Setting max_stack_depth higher than the actual kernel limit will mean that a runaway recursive function can crash an individual backend process. On platforms where PostgreSQL can determine the kernel limit, the server will not allow this variable to be set to an unsafe value. However, not all platforms provide the information, so caution is recommended in selecting a value.</p>
Sunucunun kilobayt cinsinden maksimum execution stack derinliğini ayarlar. Bu parametre için ideal ayar çekirdek tarafından zorlanan mevcut stack boyutu sınırıdır. Bu değer birimsiz belirtilirse kilobayt olarak alınır. Öntanımlı ayar 2 megabayttır (2MB). Bu değer karmaşık fonksiyonların yürütülmesinde yeterli olmayabilir. Bu ayarı yalnızca süper kullanıcılar değiştirebilir.

shared_memory_type

type: enum default: mmap context: postmaster values: [sysv, mmap] restart: Gerektirir
<p>Specifies the shared memory implementation that the server should use for the main shared memory region that holds PostgreSQL’s shared buffers and other shared data. Possible values are mmap (for anonymous shared memory allocated using mmap), sysv (for System V shared memory allocated via shmget) and windows (for Windows shared memory). Not all values are supported on all platforms; the first supported option is the default for that platform. The use of the sysv option, which is not the default on any platform, is generally discouraged because it typically requires non-default kernel settings to allow for large allocations (see sysvipc).</p>
Ana shared memory alanı için sunucunun kullanması gereken shared memory implementasyonunu belirtir. Alabileceği değerler: mmap (mmap kullanılarak ayrılan anonymous shared memory için), sysv (shmget ile ayrılan System V shared memory için) ve windows (Windows shared memory için).

dynamic_shared_memory_type

type: enum default: posix context: postmaster values: [posix, sysv, mmap] restart: Gerektirir
<p>Specifies the dynamic shared memory implementation that the server should use. Possible values are posix (for POSIX shared memory allocated using shm_open), sysv (for System V shared memory allocated via shmget), windows (for Windows shared memory), and mmap (to simulate shared memory using memory-mapped files stored in the data directory). Not all values are supported on all platforms; the first supported option is the default for that platform. The use of the mmap option, which is not the default on any platform, is generally discouraged because the operating system may write modified pages back to disk repeatedly, increasing system I/O load; however, it may be useful for debugging, when the pg_dynshmem directory is stored on a RAM disk, or when other shared memory facilities are not available.</p>
Sunucunun kullanacağı dynamic shared memory implementasyonunu belirtir. Alabileceği değerler: posix (shm_open kullanılarak ayrılan POSIX shared memory için), sysv (shmget aracılığıyla ayrılan System V shared memory için), windows (Windows shared memory için) ve mmap (veri dizinindeki memory-mapped dosyaları kullanarak shared memory’i simüle etmek için). mmap seçeneğinin kullanılması genellikle tavsiye edilmez.

Disk

temp_file_limit

type: integer default: -1 min: -1 max: 2147483647 (2147483647kB) unit: kB context: superuser
<p>Specifies the maximum amount of disk space that a process can use for temporary files, such as sort and hash temporary files, or the storage file for a held cursor. A transaction attempting to exceed this limit will be canceled. If this value is specified without units, it is taken as kilobytes. -1 (the default) means no limit. Only superusers can change this setting.</p><p>This setting constrains the total space used at any instant by all temporary files used by a given PostgreSQL process. It should be noted that disk space used for explicit temporary tables, as opposed to temporary files used behind-the-scenes in query execution, does not count against this limit.</p>
Her işlem tarafından kullanılan total geçici dosyaların ( sort ve hash temporary files gibi) toplam boyutunu sınırlar. Bu sınırı aşmaya çalışan bir transaction iptal edilir. Bu değer birimsiz belirtilirse kilobayt olarak alınır. Öntanımlı -1 değeri sınır yok demektir. Bu ayarı yalnızca süper kullanıcılar değiştirebilir.

Bu ayarın, belirli bir PostgreSQL sürecinin kullandığı tüm geçici dosyaların herhangi bir anda kullanılan toplam alanı sınırladığına dikkat edin.

Çekirdek Kaynak Kullanımı

max_files_per_process

type: integer default: 1000 min: 64 max: 2147483647 context: postmaster restart: Gerektirir
<p>Sets the maximum number of simultaneously open files allowed to each server subprocess. The default is one thousand files. If the kernel is enforcing a safe per-process limit, you don’t need to worry about this setting. But on some platforms (notably, most BSD systems), the kernel will allow individual processes to open many more files than the system can actually support if many processes all try to open that many files. If you find yourself seeing Too many open files failures, try reducing this setting. This parameter can only be set at server start.</p>
Her sunucu süreci için eşzamanlı olarak açılabilecek maksimum dosya sayısını ayarlar. Varsayılan 1000 dosyadır. ‘Too many open files’ hatası ile karşılaşırsanız bu ayarı düşürmeyi deneyin. Bu parametre yalnızca sunucu başlangıcında ayarlanabilir.

Cost-based Vacuum Delay

VACUUM ve ANALYZE komutları yürütülürken sistem, gerçekleşen çeşitli I / O operasyonlarının tahmini maliyetini izleyen dahili bir sayaç tutar. Birikmiş maliyet vacuum_cost_limit ile belirtilen limite ulaştığında operasyonu gerçekleştiren süreç vacuum_cost_delay ile belirtilen süre boyunca uyutulur. Ardından sayacı sıfırlanarak çalışmaya devam eder.

Bu özelliğin amacı yöneticilere, bu komutların eşzamanlı veritabanı etkinliği üzerindeki I / O etkisini azaltmalarına olanak sağlamaktır. VACUUM ve ANALYZE gibi bakım komutlarının sistemin diğer veritabanı operasyonlarını gerçekleştirme becerisine fazla müdahale etmemesi çok önemlidir. Maliyete dayalı vakum gecikmesi, yöneticilerin bunu başarması için bir yol sunar.

Bu özellik, manuel olarak verilen VACUUM komutları için öntanımlı olarak devre dışı bırakılmıştır. Bunu etkinleştirmek isterseniz vacum_cost_delay değişkenini sıfır olmayan bir değere ayarlayın.

vacuum_cost_delay

type: real default: 0 (0ms) min: 0 (0ms) max: 100 (100ms) unit: milliseconds (ms) context: user
<p>The amount of time that the process will sleep when the cost limit has been exceeded. If this value is specified without units, it is taken as milliseconds. The default value is zero, which disables the cost-based vacuum delay feature. Positive values enable cost-based vacuuming.</p><p>When using cost-based vacuuming, appropriate values for vacuum_cost_delay are usually quite small, perhaps less than 1 millisecond. While vacuum_cost_delay can be set to fractional-millisecond values, such delays may not be measured accurately on older platforms. On such platforms, increasing VACUUM’s throttled resource consumption above what you get at 1ms will require changing the other vacuum cost parameters. You should, nonetheless, keep vacuum_cost_delay as small as your platform will consistently measure; large delays are not helpful.</p>
Maliyet sınırı aşıldığında sürecin uyuyacağı süre (Vacuum cost delay). Bu değer birimsiz verilirse milisaniye olarak alınır. Öntanımlı değer sıfırdır ve maliyete dayalı vakum gecikmesi özelliğini devre dışı bırakır. Pozitif değerler maliyete dayalı vakumlamaya izin verir.Maliyete dayalı vacuum kullanılırken vacuum_cost_delay için uygun değerler genellikle 1 milisaniye ile ifade edecek kadar çok küçüktür.

vacuum_cost_page_hit

type: integer default: 1 min: 0 max: 10000 context: user
<p>The estimated cost for vacuuming a buffer found in the shared buffer cache. It represents the cost to lock the buffer pool, lookup the shared hash table and scan the content of the page. The default value is one.</p>
Shared buffer cache’de bulunan bir buffer’ı vakumlamanın tahmini maliyeti. Öntanımlı değer 1’dir.

vacuum_cost_page_miss

type: integer default: 10 min: 0 max: 10000 context: user
<p>The estimated cost for vacuuming a buffer that has to be read from disk. This represents the effort to lock the buffer pool, lookup the shared hash table, read the desired block in from the disk and scan its content. The default value is 10.</p>
Diskten okunması gereken bir buffer’ı vakumlamanın tahmini maliyeti. Öntanımlı değer 10’dur.

vacuum_cost_page_dirty

type: integer default: 20 min: 0 max: 10000 context: user
<p>The estimated cost charged when vacuum modifies a block that was previously clean. It represents the extra I/O required to flush the dirty block out to disk again. The default value is 20.</p>
Vakum önceden temiz olan bir bloğu değiştirdiğinde alınan tahmini maliyet. Dirty bloğu tekrar diske geçirmek için gereken ekstra I / O’u temsil eder. Öntanımlı değer 20’dir.

vacuum_cost_limit

type: integer default: 200 min: 1 max: 10000 context: user
<p>The accumulated cost that will cause the vacuuming process to sleep. The default value is 200.</p>
Vakum sürecinin uyumasına neden olacak birikmiş maliyet. Öntanımlı değer 200’dür.

Background Writer

Background Writer ayrı bir PostgreSQL sunucu sürecidir. Background Writer “dirty”, yani yeni veya değiştirilmiş shared buffer’ları diske yazmakla görevlidir. Böylece, sunucu süreçlerinin kullanıcı sorgularını yazması nadiren beklenir veya hiçbir zaman beklenmez. Background Writer I / O yükünde net bir şekilde artışa neden olur, çünkü tekrar tekrar dirty olan bir page her checkpoint aralığında yalnızca bir kez yazılırken Background Writer tarafından birkaç kez yazabilir. Verilen parametreleri davranışları ihtiyaçlarınıza göre ayarlamak için kullanabilirsiniz.

bgwriter_delay

type: integer default: 200 (200ms) min: 10 (10ms) max: 1000 (10s) unit: milliseconds (ms) context: sighup
<p>Specifies the delay between activity rounds for the background writer. In each round the writer issues writes for some number of dirty buffers (controllable by the following parameters). It then sleeps for the length of bgwriter_delay, and repeats. When there are no dirty buffers in the buffer pool, though, it goes into a longer sleep regardless of bgwriter_delay. If this value is specified without units, it is taken as milliseconds. The default value is 200 milliseconds (200ms). Note that on many systems, the effective resolution of sleep delays is 10 milliseconds; setting bgwriter_delay to a value that is not a multiple of 10 might have the same results as setting it to the next higher multiple of 10. This parameter can only be set in the postgresql.conf file or on the server command line.</p>
Background Writer’ın aktif periyodları arasındaki süreyi belirtir. Background Writer her turda aşağıdaki parametreler ile kontrol edilen sayıdaki dirty buffer’ları diske işlerek bgwriter_delay boyunca uyur. Buffer pool’da dirty buffer olmadığında bgwriter_delay’e bakmaksızın daha uzun süre uykuda kalabilir. Bu değer birimsiz belirtilirse milisaniye olarak alınır. Öntanımlı değeri 200 milisaniyedir (200 ms). Birçok sistemde etkili değer 10 milisaniye olmakla bereaber bgwriter_delay’i 10’un katı olmayan bir değere ayarlamak, 10’un bir sonraki katına ayarlamakla aynı sonuçları verebilir. Bu parametre yalnızca postgresql.conf dosyasından ve sunucu komut satırından ayarlanabilir.

bgwriter_lru_maxpages

type: integer default: 100 min: 0 max: 1073741823 context: sighup
<p>In each round, no more than this many buffers will be written by the background writer. Setting this to zero disables background writing. (Note that checkpoints, which are managed by a separate, dedicated auxiliary process, are unaffected.) The default value is 100 buffers. This parameter can only be set in the postgresql.conf file or on the server command line.</p>
Her turda, Background Writer tarafından bgwriter_lru_maxpages değerinde buffer’dan fazlası yazılmaz. Bunu sıfıra ayarlamak, background writing’i devre dışı bırakır (checkpoints etkilenmez). Öntanımlı değeri 100 buffer’dır. Bu parametre yalnızca postgresql.conf dosyasından ve sunucu komut satırından ayarlanabilir.

bgwriter_lru_multiplier

type: real default: 2 min: 0 max: 10 context: sighup
<p>The number of dirty buffers written in each round is based on the number of new buffers that have been needed by server processes during recent rounds. The average recent need is multiplied by bgwriter_lru_multiplier to arrive at an estimate of the number of buffers that will be needed during the next round. Dirty buffers are written until there are that many clean, reusable buffers available. (However, no more than bgwriter_lru_maxpages buffers will be written per round.) Thus, a setting of 1.0 represents a just in time policy of writing exactly the number of buffers predicted to be needed. Larger values provide some cushion against spikes in demand, while smaller values intentionally leave writes to be done by server processes. The default is 2.0. This parameter can only be set in the postgresql.conf file or on the server command line.</p>
Her turda yazılan dirty buffer sayısı, son turlarda sunucu işlemleri tarafından ihtiyaç duyulan yeni buffer sayısına bağlıdır. Bir sonraki turda ihtiyaç duyulacak tahmini buffer sayısı, yakın zamandaki ortalama ihtiyacın bgwriter_lru_multiplier değeri ile çarpımından bulunur. dirty buffer’lar çok sayıda temiz, yeniden kullanılabilir buffer bulunana kadar yazılır. 1.0 ayarı ‘just in time’ ilkesini yani tam olarak ihtiyaç duyulan tahmini buffer sayısını yazmayı temsil eder. Daha büyük değerler talepteki ani artışlara karşı bir miktar buffer sağlar. Küçük değerler kasıtlı olarak yazma işlemini sunucu süreçlerine bırakır. Öntanımlı değeri 2.0’dır. Bu parametre yalnızca postgresql.conf dosyasından ve sunucu komut satırından ayarlanabilir.

bgwriter_flush_after

type: integer default: 64 (512kB) min: 0 (0kB) max: 256 (2MB) unit: 8kB context: sighup
<p>Whenever more than this amount of data has been written by the background writer, attempt to force the OS to issue these writes to the underlying storage. Doing so will limit the amount of dirty data in the kernel’s page cache, reducing the likelihood of stalls when an fsync is issued at the end of a checkpoint, or when the OS writes data back in larger batches in the background. Often that will result in greatly reduced transaction latency, but there also are some cases, especially with workloads that are bigger than shared_buffers, but smaller than the OS’s page cache, where performance might degrade. This setting may have no effect on some platforms. If this value is specified without units, it is taken as blocks, that is BLCKSZ bytes, typically 8kB. The valid range is between 0, which disables forced writeback, and 2MB. The default is 512kB on Linux, 0 elsewhere. (If BLCKSZ is not 8kB, the default and maximum values scale proportionally to it.) This parameter can only be set in the postgresql.conf file or on the server command line.</p>
Background Writer tarafından bu miktardan daha fazla veri yazıldığında, işletim sistemini bu verileri esas depolama alınan yazmaya zorlar. Bununla, çekirdeğin page cache’indeki dirty veri miktarını sınırlandırılır ve bir checkpoint sonunda fsync yayınlandığında veya işletim sistemi verileri daha büyük gruplar halinde arka planda geri yazdığında durma olasılığını düşürülür. Bu ayar bazı platformlarda hiç bir etkiye sahip olmayabilir. Bu değer birimsiz belirtilirse, blok yani BLCKSZ bayt (tipik olarak 8kB’dir) olarak alınır. Geçerli aralık, zorunlu geri yazmayı devre dışı bırakan 0 ile 2MB arasındadır. Linux’ta öntanımlı değer 512kB, diğer sistemlerde 0’dır. Bu parametre yalnızca postgresql.conf dosyasından ve sunucu komut satırından ayarlanabilir.

Asynchronous Davranış

effective_io_concurrency

type: integer default: 1 min: 0 max: 1000 context: user
<p>Sets the number of concurrent disk I/O operations that PostgreSQL expects can be executed simultaneously. Raising this value will increase the number of I/O operations that any individual PostgreSQL session attempts to initiate in parallel. The allowed range is 1 to 1000, or zero to disable issuance of asynchronous I/O requests. Currently, this setting only affects bitmap heap scans.</p><p>For magnetic drives, a good starting point for this setting is the number of separate drives comprising a RAID 0 stripe or RAID 1 mirror being used for the database. (For RAID 5 the parity drive should not be counted.) However, if the database is often busy with multiple queries issued in concurrent sessions, lower values may be sufficient to keep the disk array busy. A value higher than needed to keep the disks busy will only result in extra CPU overhead. SSDs and other memory-based storage can often process many concurrent requests, so the best value might be in the hundreds.</p><p>Asynchronous I/O depends on an effective posix_fadvise function, which some operating systems lack. If the function is not present then setting this parameter to anything but zero will result in an error. On some operating systems (e.g., Solaris), the function is present but does not actually do anything.</p><p>The default is 1 on supported systems, otherwise 0. This value can be overridden for tables in a particular tablespace by setting the tablespace parameter of the same name (see sql-altertablespace).</p>
Disk alt sistemi tarafından verimli bir şekilde işlenebilen eşzamanlı istek sayısı. Bu değerin yükseltilmesi, herhangi bir PostgreSQL sessionının paralel olarak başlatmaya çalıştığı I / O operasyonlarının sayısını artırır. İzin verilen aralık 1 ile 1000 arasıdır. 0 asynchronous I / O isteklerini devre dışı bırakır. Şu an için bu ayar sadece bitmap heap taramalarını etkilemektedir. Varsayılan, desteklenen sistemlerde 1, diğerlerinde 0’dır.

maintenance_io_concurrency

type: integer default: 10 min: 0 max: 1000 context: user
<p>Similar to effective_io_concurrency, but used for maintenance work that is done on behalf of many client sessions.</p><p>The default is 10 on supported systems, otherwise 0. This value can be overridden for tables in a particular tablespace by setting the tablespace parameter of the same name (see sql-altertablespace).</p>
İstemci oturumları adına yapılan bakım çalışmaları için kullanılır. Desteklenen sistemlerde öntanımlı değeri 10’dur, diğerlerinde 0’dır.

max_worker_processes

type: integer default: 8 min: 0 max: 262143 context: postmaster restart: Gerektirir
<p>Sets the maximum number of background processes that the system can support. This parameter can only be set at server start. The default is 8.</p><p>When running a standby server, you must set this parameter to the same or higher value than on the master server. Otherwise, queries will not be allowed in the standby server.</p><p>When changing this value, consider also adjusting max_parallel_workers, max_parallel_maintenance_workers, and max_parallel_workers_per_gather.</p>
Sistemin destekleyebileceği maksimum background süreç sayısını ayarlar. Bu parametre yalnızca sunucu başlangıcında ayarlanabilir. Öntanımlı değeri 8’dir. Standby sunucu çalıştırırken, bu parametre primary sunucudakiyle aynı veya daha yüksek bir değere ayarlanmalıdır. Aksi takdirde, standby sunucuda sorgulara izin verilmeyecektir.

Bu değer değiştirilirken max_parallel_workers, max_parallel_maintenance_workers ve max_parallel_workers_per_gather parametrelerinin ayarlanması düşünülebilir.

max_parallel_workers_per_gather

type: integer default: 2 min: 0 max: 1024 context: user
<p>Sets the maximum number of workers that can be started by a single Gather or Gather Merge node. Parallel workers are taken from the pool of processes established by max_worker_processes, limited by max_parallel_workers. Note that the requested number of workers may not actually be available at run time. If this occurs, the plan will run with fewer workers than expected, which may be inefficient. The default value is 2. Setting this value to 0 disables parallel query execution.</p><p>Note that parallel queries may consume very substantially more resources than non-parallel queries, because each worker process is a completely separate process which has roughly the same impact on the system as an additional user session. This should be taken into account when choosing a value for this setting, as well as when configuring other settings that control resource utilization, such as work_mem. Resource limits such as work_mem are applied individually to each worker, which means the total utilization may be much higher across all processes than it would normally be for any single process. For example, a parallel query using 4 workers may use up to 5 times as much CPU time, memory, I/O bandwidth, and so forth as a query which uses no workers at all.</p><p>For more information on parallel query, see parallel-query.</p>
Yürütme düğümü başına maksimum paralel işlem sayısını ayarlar. Tek bir Gather veya Gather Merge düğümü tarafından başlatılabilecek maksimum worker sayısını ayarlar. Paralel worker’lar max_worker_processes tarafından oluşturulmuş, max_parallel_workers ile sınırlandırılmış süreç havuzundan alınır. İstenen worker sayısı çalışma zamanında mevcut olmadığında, plan beklenenden daha az sayıda worker ile çalışarak verimsiz olabilir. Öntanımlı değeri 2’dir. Bu değerin 0 olarak ayarlanması paralel sorgu yürütmeyi devre dışı bırakır.

Paralel sorgular, paralel olmayan sorgularadan çok daha fazla kaynak tüketebilir. Çünkü her worker süreci sistem üzerinde ek bir kullanıcı oturumuyla hemen hemen aynı etkiye sahip olan tamamen ayrı bir süreçtir. work_mem gibi kaynak limitleri her bir worker için ayrı ayrı uygulanır. Paralel sorgu hakkında daha fazla bilgi için bkz .

max_parallel_maintenance_workers

type: integer default: 2 min: 0 max: 1024 context: user
<p>Sets the maximum number of parallel workers that can be started by a single utility command. Currently, the parallel utility commands that support the use of parallel workers are CREATE INDEX only when building a B-tree index, and VACUUM without FULL option. Parallel workers are taken from the pool of processes established by max_worker_processes, limited by max_parallel_workers. Note that the requested number of workers may not actually be available at run time. If this occurs, the utility operation will run with fewer workers than expected. The default value is 2. Setting this value to 0 disables the use of parallel workers by utility commands.</p><p>Note that parallel utility commands should not consume substantially more memory than equivalent non-parallel operations. This strategy differs from that of parallel query, where resource limits generally apply per worker process. Parallel utility commands treat the resource limit maintenance_work_mem as a limit to be applied to the entire utility command, regardless of the number of parallel worker processes. However, parallel utility commands may still consume substantially more CPU resources and I/O bandwidth.</p>
Tek bir utility program komutuyla başlatılabilen maksimum paralel worker sayısını ayarlar. Şu an için paralel worker kullanımını CREATE INDEX (B-tree indekslerde) ve VACUUM (FULL olmadan) işlemlerinde desteklenmektedir. Paralel workers max_worker_processes tarafından oluşturulmuş, max_parallel_workers ile sınırlandırılmış süreç havuzundan alınır. İstenen worker sayısı çalışma zamanında mevcut olamdığında utility program operasyonu beklenenden daha az sayıda worker ile çalışacaktır. Öntanımlı değeri 2’dir. Bu değerin 0 olarak ayarlanması utility program komutlarının paralel worker kullanmasını devre dışı bırakır.

max_parallel_workers

type: integer default: 8 min: 0 max: 1024 context: user
<p>Sets the maximum number of workers that the system can support for parallel operations. The default value is 8. When increasing or decreasing this value, consider also adjusting max_parallel_maintenance_workers and max_parallel_workers_per_gather. Also, note that a setting for this value which is higher than max_worker_processes will have no effect, since parallel workers are taken from the pool of worker processes established by that setting.</p>
Paralel operasyonlar için sistemin destekleyebileceği maksimum worker sayısını ayarlar. Varsayılan değeri 8’dir. Bu değeri artırırken veya azaltırken max_parallel_maintenance_workers ve max_parallel_workers_per_gather parametrelerini de ayarlamayı düşünün. Ayrıca, bu parametre değerinin max_worker_processes‘ten daha yüksek olan bir ayarı, paralel worker’lar bu ayar tarafından oluşturulan havuzundan alındığı için hiçbir etkisi olmayacağını unutmayın.

Kaynak:

[1]. PostgreSQL Documentation

[2]. postgresqlco.nf