Mengkonfigurasi PostgreSQL untuk kinerja penulisan


30

Salah satu server PostgreSQL saya menampung beberapa (1-3) database yang menerima aliran data konstan. Data tidak terstruktur secara khusus, itu berjumlah waktu saat ini dan berbagai data yang diamati untuk instan tertentu. Kecepatan data cukup tinggi; itu berhasil sekitar satu gigabyte sehari untuk satu database, sekitar sepersepuluh dari itu untuk yang lain. Saya tidak berharap tingkat ini meningkat. Kinerja membaca adalah prioritas yang jauh lebih rendah dan saat ini dapat diterima.

Dalam log saya punya pesan ini:

LOG:  checkpoints are occurring too frequently (15 seconds apart)
HINT:  Consider increasing the configuration parameter "checkpoint_segments".

Nilai ini saat ini diatur ke 16, yang merupakan milik pgtune.

Pengaturan apa yang harus saya pertimbangkan untuk meningkatkan kinerja penulisan? Saya lebih suka menjaga keamanan sebanyak mungkin. Mengingat volume data yang masuk, saya bisa menerima kehilangan beberapa data baru-baru ini dalam kegagalan selama sebagian besar data masih utuh.

Sunting: Saya menggunakan PostgreSQL 9.0 untuk saat ini, tetapi saya berencana untuk meningkatkan ke 9.1. Saya tidak memposting detail perangkat keras karena walaupun saya mengakui pentingnya mereka, saya akhirnya akan perlu melakukan optimasi ini pada beberapa mesin dengan perangkat keras yang sangat beragam. Jika perangkat keras sangat penting untuk jawabannya, tolong beri saya informasi umum sehingga saya dapat menerapkan jawaban untuk mesin dengan konfigurasi perangkat keras yang berbeda.


Bisakah Anda memposting versi Anda dan sebaiknya beberapa detail tentang perangkat keras penyimpanan Anda?
Jack Douglas

Apakah Anda bertambah checkpoint_segmentssesuai anjuran? Apa yang terjadi?
a_horse_with_no_name

3
Sumber daya lain yang sangat baik untuk pertanyaan semacam ini adalah Gregory Smith 's buku PostgreSQL 9.0 High Performance .
jp

Jawaban:


24

1 Gigabyte sehari tidak setinggi itu dari beban tulis. Sebarkan sepanjang hari, yang menghasilkan sekitar 50 kbytes per detik. USB thumb drive yang lambat bisa mengatasinya. Saya mengasumsikan itu lebih meledak. Seperti yang disarankan a_horse_with_no_name, tambah segmen pos pemeriksaan. 100 atau lebih tidak biasa.

Kemudian tingkatkan checkpoint_timeouthingga 1 jam, dan lihat tingkatkan Anda checkpoint_completion_targetke sesuatu yang mendekati 1.0 (100%). Target penyelesaian memberi tahu PostgreSQL cara agresif menulis di latar belakang sehingga x% selesai sebelum menjalankan pos pemeriksaan, yang memaksa semua data untuk ditulis sekaligus dari WAL dan akan memperlambat sistem untuk merayapi saat sedang terjadi.

Alasan Anda biasanya tidak menetapkannya menjadi 100% adalah bahwa cukup umum untuk menulis ke blok yang sama lebih dari satu kali, dan dengan menunda WAL menulis ke toko utama, Anda mencegah blok yang sama ditulis dua kali tanpa alasan.

Jika tidak mungkin Anda akan menulis ke blok yang sama lebih dari satu kali sebelum batas waktu Anda habis, yaitu yang Anda lakukan hanyalah memasukkan lalu mengaturnya cukup tinggi masuk akal untuk menaikkannya menjadi 0,9 atau lebih. Hal terburuk yang akan terjadi adalah Anda akan menulis sedikit lebih sering daripada yang seharusnya Anda perlukan, tetapi dampak pos pemeriksaan akan sangat berkurang.


Volume tulis sebenarnya hampir sepenuhnya seragam: ini adalah penyimpanan data untuk perangkat lunak pemantauan perangkat keras yang melakukan jajak pendapat setiap detik, terus menerus, 24x7. Saya bisa menghitung laju data yang tepat, tetapi agak berfluktuasi ketika programmer menambah dan menghapus titik monitor.
Daniel Lyons

1
Nah, jika nilainya 1G sehari dan lancar, maka hampir semua subsistem dapat menangani beban tulis, Anda hanya ingin membuatnya tetap lancar, yang target penyelesaian pos pemeriksaan ditetapkan mendekati 1.0 dan batas waktu pemeriksaan yang lama akan membuat Anda menyerah.
Scott Marlowe

10

Dalam sistem yang sangat 'tulis berat', Anda cenderung dibatasi oleh tingkat WAL yang dapat ditulis selama aktivitas puncak.

Jika Anda benar-benar dapat "menerima kehilangan beberapa data terbaru dalam kegagalan" Anda dapat mematikan komit sinkron yang:

bisa menjadi alternatif yang berguna ketika kinerja lebih penting daripada kepastian yang tepat tentang daya tahan transaksi

Jika Anda dapat mengubah perangkat keras Anda, Anda dapat mempertimbangkan salah satu dari ini untuk mengoptimalkan penulisan:

  • RAID10 melalui RAID5
  • Banyak spindle (mungkin berarti 2,5 "bukannya 3,5" misalnya)
  • SAS melalui SATA
  • 15K lebih dari 10K drive
  • SSD

--edit

Berdasarkan komentar Anda pada jawaban luar biasa @ Scott : "Volume penulisan sebenarnya hampir sepenuhnya seragam", dan kecepatan data tersirat "50 kbytes per detik", saya ragu Anda perlu melakukan apa pun yang berisiko kehilangan data. Mungkin akan membantu untuk mengetahui parameter pengaturan Anda yang lain.


3
Jika masalah kinerja penulisan, pengontrol yang didukung baterai antara OS dan hard drive yang berputar dapat membuat perbedaan yang BESAR.
Scott Marlowe

5

Anda juga dapat memeriksa frekuensi / ukuran komit Anda: Saya mengalami masalah baru-baru ini di mana saya mencoba memperbarui> 1 juta catatan dalam satu transaksi. Saya mendapat pesan log yang mirip dengan yang dijelaskan oleh OP, tetapi transaksi tidak dapat diselesaikan bahkan setelah beberapa jam. Ketika saya memecah tulisan menjadi beberapa transaksi yang lebih kecil (sekitar 10.000 catatan), total waktu yang dibutuhkan turun menjadi sekitar 15 menit.

Apa yang saya pikirkan terjadi adalah Postgres menghabiskan begitu banyak waktu menulis log sehingga checkpoint_timeout berlalu sebelum dapat membuat kemajuan besar dalam menyimpan catatan. Saya tidak yakin apakah penjelasan itu cocok. Saya masih mendapatkan peringatan, tetapi semua penulisan akhirnya diproses. Namun, saya membutuhkan (dan menemukan) solusi yang terprogram daripada yang membutuhkan konfigurasi ulang basis data.

Lihat juga http://www.postgresql.org/docs/9.3/static/wal-configuration.html

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.