User Tools

Site Tools


wiki:postgres:pg_tune_kurs_kernelresources

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

wiki:postgres:pg_tune_kurs_kernelresources [2017/09/28 12:21] (current)
Line 1: Line 1:
 +====== Kernel Resourcen einstellen ======
 +
 +  * [[http://​www.postgresql.org/​docs/​9.0/​interactive/​kernel-resources.html|Managing Kernel Resources]]. \\
 +  * [[http://​www.kaltenbrunner.cc/​blog/​index.php?/​archives/​21-8.3-vs.-8.2-a-simple-benchmark.html|Benchmark und Tuning von PostgreSQL8]]
 +
 +===== Shared Memory =====
 +"​Shared Memory ( = "​gemeinsam genutzter Speicher"​). Zwei oder mehrere Prozesse nutzen einen bestimmten Teil des Hintergrundspeichers (RAM)..."​ [[http://​de.wikipedia.org/​wiki/​Shared_memory|mehr davon auf Wikipedia...]].
 +  shmall ... [Bytes oder Blöcke] ... "Total amount of shared memory available"​
 +  shmmax ... [Bytes] ​ ... "​Maximum size of shared memory segment"​
 +  1 Block = 8 kB = 8129 Bytes
 +
 +\\
 +PostgreSQL alloziert nur ein Segment (shmmax ist die maximale Größe eines Segments). **shmall muß größer als shmmax** sein.\\
 +\\
 +Im shared memory liegen die shared_buffers,​ logs, der Cache für x_log u.v.m. Von PostgreSQL wird insgesamt ungefähr um 10% mehr shared_memory verbraucht als von **shared_buffers** alleine.\\
 +Faustregel: ~40% der gesamten Memory für die **shared_buffers**. (z.B.: auf der ibm 16GB von 32GB)\\
 +\\
 +Umso höher die shared memory size umso mehr Transaktionen pro Sekunde - sh.: [[http://​www.kaltenbrunner.cc/​blog/​index.php?/​archives/​21-8.3-vs.-8.2-a-simple-benchmark.html|Benchmark und Tuning von PostgreSQL8]]. Allerdings wenn shared_buffers höher angesetzt werden als die Datenmenge in der Datenbank, dann sinken die Transaktionen pro Sekunde wieder, da die Verwaltung "​dieser Dinge" nicht gratis ist.\\
 +
 +  test# SELECT pg_database_size('​bfw'​);​
 +
 +
 +===== Linux Memory overcommit =====
 +Es kann passieren, daß der Kernel den größten Prozess killt und dies ist normalerweise PostgreSQL. Deshalb sollte man unbedingt **Memory Overcommit ausschalten**. Sh. [[ibm_pg_install|Installation von PostgreSQL auf der "​ibm"​]]. Dies kann v.a. deshalb passieren, da der Kernel mehr Memory vergibt als physisch vorhanden ist, weil er annimmt, daß nicht der ganze angeforderte Speicher auch wirklich verbraucht wird (vgl. Finanzkrise - Banken können z.B. jetzt nur mehr das ~10-fache von dem an Kredit vergeben was sie wirklich haben).
 +
 +===== Checkpoints =====
 +Siehe v.a. [[http://​developer.postgresql.org/​pgdocs/​postgres/​wal-configuration.html|PostgreSQLdevel Dokumentation:​ WAL Configuration]].\\
 +
 +  test# SHOW checkpoint_segments;​
 +  test# SHOW checkpoint_timeout;​
 +  test# SHOW checkpoint_completion_target;​
 +  test# SHOW checkpoint_warning;​
 +
 +
 +=== checkpoint_segments ===
 +
 +1 Segment = 16MB\\
 +checkpoint_segments gibt an nach wievielen Segmenten ein Check Point gesetzt wird.\\
 +Wenn z.b. = 10, dann wird seltener ein Checkpoint gesetzt als wenn = 3.\\
 +Wenn checkpoint_segments=3,​ dann befinden sich in **/​data/​pg_xlog** 8 Dateien ( 3 * 2 + 2 ); 2x jedes Transaktion-Log + 2 in Reserve.\\
 +Die Transaktion-Logs sind **nur für den Fehlerfall**,​ sonst werden sie nie gelesen.
 +
 +=== checkpoint_timeout ===
 +
 +Wenn diese Zeit überschritten wird, so wird jedenfalls ein Checkpoint gesetzt (wenn die Anzahl der checkpoint_segments in dieser Zeit nicht erreicht wurde). Also entweder checkpoint_segments voll oder checkpoint_timeout
 +
 +=== checkpoint_completion_target ===
 +  default: checkpoint_timeout = 5min und checkpoint_completion_target = 0.5
 +  -> PostgreSQL versucht die Daten in 2.5 Minuten zu schreiben (anstatt z.B. in 1 min)
 +
 +Gibt an wie schnell dirty buffers bereinigt werden sollen; Oder genauer, PostgreSQL versucht die Daten **langsamer** zu schreiben um I/O-spikes zu verhindern (überläßt mehr Bandbreite zum schreiben für andere Aufgaben wie SELECT etc. )\\
 +Tip von Hans Schönig: **Generell: Segmente erhöhen schneller wenn viel und oft insert, update, delete und checkpoint_completion_target hochstellen**. Siehe auch [[http://​www.depesz.com/​index.php/​2010/​11/​03/​checkpoint_completion_target/​|Postgresql.conf Understanding checkpoint_completion_target]].
 +
 +=== checkpoint_warning ===
 +Wenn Checkpoints zeitlich enger hintereinander passieren als checkpoint_warning Sekunden, wird eine Meldung in das Serverlog geschrieben welche vorschlägt die checkpoint_segments zu erhöhen.
 +
 +===== Filesystem mit noatime mounten =====
 +In /etc/fstab setzen. Dies bedeutet, das Lesezugriffe nicht länger eine //atime// Information (last access time) bedingen. Wenn //noatime// nicht gesetzt ist bedeutet dies, dass jeder Lesezugriff auch eine Schreiboperation bedingt. Also kann //noatime// die Performance signifikant erhöhen. Siehe [[ibm_pg_install#​partition_mit_noatime_mounten|"​ibm"​ pg mit noatime]].
 +
 +===== maintenance_work_mem =====
 +Ist dynamisch alloziert\\
 +Wird sowohl für Vacuum als auch für die Indexerstellung benötigt.
 +  - Vacuum
 +Vacuum auf Tabelle -> wenn mehr "​Mist"/​trash in der Tabelle ist als sich das System in  16MB (default maintenance_work_mem) merken kann, dann muß es öter parsen und das ist sehr langsam. Daher raufsetzen. Vacuum geht die Tabelle durch und schaut wo trash ist. Da maintenance_work_mem dynamisch alloziert ist kann man bei 128MB viel trash bauen.
 +
 +  - Index erstellen
 +Index erstellen bzw. aufrecht erhalten = "​Umsortieren von Daten"​. Hierfür wird ebenfalls die maintenance_work_mem herangezogen.
 +
 +===== max_connections =====
 +Nicht zu viel einstellen. 100 ist z.b. o.k.
 +
 +===== wal_buffers =====
 +wal_buffers = 8MB und fertig.
 +
 +===== synchronous_commit =====
 +synchronous_commit = off -> es wird gesammelt und es werden z.B. nur 5 fsync pro Sekunde geschickt wenn **wal_writer_delay** auf 200ms gestellt ist.
 +
 +===== wal_writer_delay =====
 +
 +
 +
 +
 +
  
wiki/postgres/pg_tune_kurs_kernelresources.txt · Last modified: 2017/09/28 12:21 (external edit)