Pertama, selalu gunakan PostgreSQL versi terbaru. Peningkatan kinerja selalu datang, jadi Anda mungkin membuang-buang waktu jika menyetel versi lama. Misalnya, PostgreSQL 9.2 secara signifikan meningkatkan kecepatan TRUNCATE dan tentu saja menambahkan pemindaian hanya indeks. Bahkan rilis kecil harus selalu diikuti; lihat kebijakan versi.
Jangan
Jangan TIDAK letakkan tablespace di RAMdisk atau penyimpanan lain yang tidak tahan lama.
Jika Anda kehilangan tablespace, seluruh database mungkin rusak dan sulit digunakan tanpa pekerjaan yang berarti. Ada sedikit keuntungan dari ini dibandingkan dengan hanya menggunakan UNLOGGED tabel dan memiliki banyak RAM untuk cache.
Jika Anda benar-benar menginginkan sistem berbasis ramdisk, initdb cluster baru di ramdisk dengan initdb ing instance PostgreSQL baru di ramdisk, jadi Anda memiliki instance PostgreSQL sekali pakai.
Konfigurasi server PostgreSQL
Saat menguji, Anda dapat mengonfigurasi server Anda untuk pengoperasian yang tidak tahan lama tetapi lebih cepat.
Ini adalah satu-satunya penggunaan yang dapat diterima untuk fsync=off pengaturan di PostgreSQL. Pengaturan ini cukup memberi tahu PostgreSQL untuk tidak repot dengan penulisan yang dipesan atau hal-hal buruk lainnya tentang perlindungan integritas data dan keamanan crash, memberinya izin untuk benar-benar membuang data Anda jika Anda kehilangan daya atau mengalami crash OS.
Tak perlu dikatakan, Anda tidak boleh mengaktifkan fsync=off dalam produksi kecuali Anda menggunakan Pg sebagai database sementara untuk data yang dapat Anda buat ulang dari tempat lain. Jika dan hanya jika Anda melakukan untuk mematikan fsync juga dapat mengaktifkan full_page_writes off, karena tidak ada gunanya lagi. Waspadalah terhadap fsync=off dan full_page_writes terapkan di cluster level, sehingga memengaruhi semua database di instance PostgreSQL Anda.
Untuk penggunaan produksi, Anda mungkin dapat menggunakan synchronous_commit=off dan atur commit_delay , karena Anda akan mendapatkan banyak manfaat yang sama seperti fsync=off tanpa risiko korupsi data raksasa. Anda memang memiliki jendela kecil hilangnya data terbaru jika Anda mengaktifkan async commit - tetapi hanya itu.
Jika Anda memiliki opsi untuk sedikit mengubah DDL, Anda juga dapat menggunakan UNLOGGED tabel di Hal 9.1+ untuk sepenuhnya menghindari pencatatan WAL dan mendapatkan peningkatan kecepatan nyata dengan biaya tabel terhapus jika server mogok. Tidak ada opsi konfigurasi untuk membuat semua tabel tidak masuk log, itu harus disetel selama CREATE TABLE . Selain bagus untuk pengujian, ini berguna jika Anda memiliki tabel yang penuh dengan data yang dihasilkan atau tidak penting dalam database yang berisi hal-hal yang Anda perlukan agar aman.
Periksa log Anda dan lihat apakah Anda mendapatkan peringatan tentang terlalu banyak pos pemeriksaan. Jika ya, Anda harus meningkatkan checkpoint_segments. Anda mungkin juga ingin menyetel checkpoint_completion_target untuk kelancaran penulisan.
Tune shared_buffers agar sesuai dengan beban kerja Anda. Ini bergantung pada OS, tergantung pada apa lagi yang terjadi dengan mesin Anda, dan memerlukan beberapa percobaan dan kesalahan. Defaultnya sangat konservatif. Anda mungkin perlu meningkatkan batas memori bersama maksimum OS jika Anda meningkatkan shared_buffers pada PostgreSQL 9.2 dan di bawahnya; 9.3 dan di atasnya mengubah cara mereka menggunakan memori bersama untuk menghindarinya.
Jika Anda hanya menggunakan beberapa koneksi yang melakukan banyak pekerjaan, tambah work_mem untuk memberi mereka lebih banyak RAM untuk dimainkan, dll. Hati-hati dengan work_mem yang terlalu tinggi pengaturan dapat menyebabkan masalah kehabisan memori karena per-sortir bukan per-koneksi sehingga satu kueri dapat memiliki banyak jenis bersarang. Anda hanya benar-benar harus menambah work_mem jika Anda dapat melihat jenis tumpah ke disk di EXPLAIN atau login dengan log_temp_files pengaturan (disarankan), tetapi nilai yang lebih tinggi juga memungkinkan Pg memilih paket yang lebih cerdas.
Seperti yang dikatakan oleh poster lain di sini, sebaiknya letakkan xlog dan tabel/indeks utama pada HDD terpisah jika memungkinkan. Partisi terpisah tidak ada gunanya, Anda benar-benar ingin drive terpisah. Pemisahan ini memiliki manfaat yang jauh lebih sedikit jika Anda menjalankan dengan fsync=off dan hampir tidak ada jika Anda menggunakan UNLOGGED tabel.
Terakhir, sesuaikan pertanyaan Anda. Pastikan random_page_cost . Anda dan seq_page_cost mencerminkan kinerja sistem Anda, pastikan effective_cache_size . Anda benar, dll. Gunakan EXPLAIN (BUFFERS, ANALYZE) untuk memeriksa rencana kueri individual, dan ubah auto_explain modul untuk melaporkan semua kueri lambat. Anda sering dapat meningkatkan kinerja kueri secara dramatis hanya dengan membuat indeks yang sesuai atau mengubah parameter biaya.
AFAIK tidak ada cara untuk mengatur seluruh database atau cluster sebagai UNLOGGED . Akan menarik untuk bisa melakukannya. Pertimbangkan untuk bertanya di milis PostgreSQL.
Penyetelan OS host
Ada beberapa penyetelan yang dapat Anda lakukan di tingkat sistem operasi juga. Hal utama yang mungkin ingin Anda lakukan adalah meyakinkan sistem operasi untuk tidak menghapus penulisan ke disk secara agresif, karena Anda benar-benar tidak peduli kapan/jika mereka membuatnya ke disk.
Di Linux Anda dapat mengontrol ini dengan dirty_* subsistem memori virtual pengaturan, seperti dirty_writeback_centisecs .
Satu-satunya masalah dengan menyetel pengaturan writeback menjadi terlalu kendur adalah bahwa flush oleh beberapa program lain dapat menyebabkan semua buffer akumulasi PostgreSQL juga di-flush, menyebabkan kemacetan besar sementara semuanya diblokir saat menulis. Anda mungkin dapat mengatasi ini dengan menjalankan PostgreSQL pada sistem file yang berbeda, tetapi beberapa flush mungkin berada di level perangkat atau seluruh host, bukan level sistem file, jadi Anda tidak dapat mengandalkannya.
Penyesuaian ini benar-benar membutuhkan bermain-main dengan pengaturan untuk melihat apa yang terbaik untuk beban kerja Anda.
Pada kernel yang lebih baru, Anda mungkin ingin memastikan bahwa vm.zone_reclaim_mode disetel ke nol, karena dapat menyebabkan masalah kinerja yang parah dengan sistem NUMA (kebanyakan sistem saat ini) karena interaksi dengan cara PostgreSQL mengelola shared_buffers .
Kueri dan penyetelan beban kerja
Ini adalah hal-hal yang membutuhkan perubahan kode; mereka mungkin tidak cocok untuk Anda. Beberapa hal yang mungkin bisa Anda terapkan.
Jika Anda tidak mengelompokkan pekerjaan ke dalam transaksi yang lebih besar, mulailah. Banyak transaksi kecil yang mahal, jadi Anda harus mengelompokkan barang kapan pun memungkinkan dan praktis untuk melakukannya. Jika Anda menggunakan komit async, ini kurang penting, tetapi tetap sangat disarankan.
Bila memungkinkan gunakan tabel sementara. Mereka tidak menghasilkan lalu lintas WAL, jadi mereka jauh lebih cepat untuk sisipan dan pembaruan. Terkadang ada baiknya menyeruput banyak data ke dalam tabel sementara, memanipulasinya sesuka Anda, lalu melakukan INSERT INTO ... SELECT ... untuk menyalinnya ke tabel akhir. Perhatikan bahwa tabel sementara adalah per sesi; jika sesi Anda berakhir atau Anda kehilangan koneksi, tabel temp akan hilang, dan tidak ada koneksi lain yang dapat melihat konten tabel temp sesi.
Jika Anda menggunakan PostgreSQL 9.1 atau yang lebih baru, Anda dapat menggunakan UNLOGGED tabel untuk data yang bisa Anda hilangkan, seperti status sesi. Ini terlihat di sesi yang berbeda dan dipertahankan di antara koneksi. Mereka terpotong jika server dimatikan dengan tidak benar sehingga tidak dapat digunakan untuk apa pun yang tidak dapat Anda buat ulang, tetapi sangat bagus untuk cache, tampilan terwujud, tabel status, dll.
Secara umum, jangan DELETE FROM blah; . Gunakan TRUNCATE TABLE blah; sebagai gantinya; itu jauh lebih cepat ketika Anda membuang semua baris dalam sebuah tabel. Memotong banyak tabel dalam satu TRUNCATE telepon jika Anda bisa. Ada peringatan jika Anda melakukan banyak TRUNCATES meja kecil berulang-ulang, meskipun; lihat:Kecepatan Pemotongan Postgresql
Jika Anda tidak memiliki indeks pada kunci asing, DELETE s yang melibatkan kunci utama yang dirujuk oleh kunci asing itu akan sangat lambat. Pastikan untuk membuat indeks seperti itu jika Anda berharap untuk DELETE dari tabel yang direferensikan. Indeks tidak diperlukan untuk TRUNCATE .
Jangan membuat indeks yang tidak Anda perlukan. Setiap indeks memiliki biaya pemeliharaan. Cobalah untuk menggunakan sekumpulan indeks minimal dan biarkan pemindaian indeks bitmap menggabungkannya daripada mempertahankan terlalu banyak indeks multi-kolom yang besar dan mahal. Jika indeks diperlukan, coba isi tabel terlebih dahulu, lalu buat indeks di akhir.
Perangkat Keras
Memiliki RAM yang cukup untuk menampung seluruh database adalah keuntungan besar jika Anda dapat mengelolanya.
Jika Anda tidak memiliki cukup RAM, semakin cepat penyimpanan Anda bisa mendapatkan yang lebih baik. Bahkan SSD murah membuat perbedaan besar pada karat yang berputar. Namun, jangan percaya SSD murah untuk produksi, SSD sering kali tidak aman dari kerusakan dan mungkin memakan data Anda.
Belajar
Buku Greg Smith, PostgreSQL 9.0 High Performance tetap relevan meskipun mengacu pada versi yang agak lama. Ini harus menjadi referensi yang berguna.
Bergabunglah dengan milis umum PostgreSQL dan ikuti.
Membaca:
- Menyetel server PostgreSQL Anda - wiki PostgreSQL
- Jumlah koneksi database - wiki PostgreSQL
