tuning postgresql untuk sejumlah besar ram

29

Saya memiliki dua server yang identik (dalam hal perangkat keras), keduanya adalah instalasi standar windows server 2008 r2, dengan perangkat lunak minimal yang diinstal (pada dasarnya kode saya dan hal-hal yang diperlukan seperti jvm dll).

Di satu server, saya menjalankan sql server 2005, pada server kedua postgresql 9.1. Perbedaan kinerja antara 2 server ini sangat mengejutkan, ini sangat buruk pada postgresql sehingga saya menyesali pidato awal saya "mari kita gunakan postgresql alih-alih membayar lisensi server sql" kepada bos saya. Kita berbicara perbedaan 30 detik vs 15 menit untuk perintah yang sama, dan itu bukan hanya perintah yang satu ini, itu adalah pertanyaan atau perintah yang saya berikan. Keduanya memiliki data yang hampir sama (catatan dimasukkan dalam urutan yang berbeda), dan kedua database memiliki struktur / indeks yang sama persis dll.

Tapi saya berharap ini hanya masalah penyesuaian kinerja. Masalahnya adalah, sql server cukup banyak menggunakan semua 32 pertunjukan ram di server, sedangkan postgresl tidak menggunakan apa-apa, pasti kurang dari satu pertunjukan meskipun saya belum benar-benar mengetahuinya secara detail.

Bagaimana cara mendapatkan postgresql menggunakan 20+ pertunjukan ram? Server-server ini dibangun khusus untuk hal-hal basis data ini, jadi setiap ram yang tidak digunakan oleh database dan proses pendukung terbuang sia-sia menurut saya.

postgresql memory

— pengguna85116
sumber

4

Apakah Anda mengubah sesuatu ke penyetelan awal? Langkah 1: SET effective_cache_size=18G;(pengaturan default sangat rendah) BTW: dengan asumsi ini adalah mesin 64 bit (tidak ada PTE)

1

Anda benar-benar tidak memberi kami cukup untuk banyak membantu. Selain "Ini lambat" kami tidak tahu banyak tentang dataset Anda, bagaimana Anda mengaksesnya, jenis pertanyaan apa yang umumnya berjalan lambat, apa yang telah Anda lakukan untuk menyetel (dan mungkin salah mengatur) server Anda. Heck, pada mesin linux dengan banyak core dan saluran memori, Anda bisa mendapatkan kinerja jelek jauh sebelum Anda menginstal postgresql. Apakah Anda CPU atau IO terikat? Pengaturan non-default apa yang sudah Anda miliki? Jenis pertanyaan apa yang lambat?

— Scott Marlowe

2

Postgres tidak "menggunakan ram" seperti cara Anda membicarakannya. Itu bergantung pada cache halaman sistem file OS untuk sebagian besar cachingnya, jadi ketika Anda menonton ram ram pada sistem yang menjalankan postgres, Anda biasanya melihat banyak GB yang digunakan oleh buffer / cache OS, dan masing-masing proses backend postgres individu hanya menggunakan sedikit untuk masing-masing beberapa puluh MB.

— dbenhur

1

Lihat tautan ini: tekadempiere.blogspot.ae/2014/09/... Dan temukan nilai konfigurasi

— Sajeev

pertanyaan terkait, mungkin menarik: stackoverflow.com/questions/47311485/…

— mountainclimber

41

Ada banyak konstanta tweakable, diinisialisasi melalui postgres.conf. Yang paling penting adalah:

max_connections: jumlah sesi bersamaan
work_mem : jumlah maksimal memori yang akan digunakan untuk hasil antara seperti tabel hash, dan untuk menyortir
shared_buffers jumlah memori yang didedikasikan untuk ruang buffer 'yang disematkan'.
effective_cache_size jumlah memori yang diasumsikan digunakan oleh buffer LRU OS.
random_page_cost : perkiraan untuk biaya relatif dari pencarian disk.

max_connectionstidak boleh ditetapkan lebih tinggi dari yang dibutuhkan, koneksi sumber daya biaya bahkan ketika idle; dalam kebanyakan kasus koneksi akan menghabiskan lebih banyak waktu menunggu di dalam daripada menunggu di luar. (dengan harga konkurensi) Formula aturan praktis yang bagus adalah "jumlah spindel + jumlah prosesor + X"

work_memrumit: dapat diterapkan ke setiap subquery, jadi kueri dengan 5 HASHJOINSmungkin berharga 5 * work_mem. Dan untuk skenario terburuk, Anda juga harus memikirkan beberapa sesi mengkonsumsi jumlah ini (sekali lagi alasan untuk tetap max_connectionsrendah).

shared_buffersadalah (IMHO) berlebihan. Biasanya disarankan untuk mengaturnya menjadi sekitar 1/4 ... 1/2 dari semua memori "bebas" yang tersedia, tetapi saya cenderung menyimpannya rendah, dan mengatur effective_cache_sizeke semua memori "bebas" yang tersedia.

random_page_costadalah biaya pencarian + baca pada disk. Ini relatif terhadap sequential_disk_cost, yaitu 1. Default (4) untuk random_page_costdiatur terlalu tinggi untuk mesin modern dan penyimpanan jaringan, biasanya dapat diturunkan menjadi antara 2 dan 1.x. Untuk disk SSD Anda bahkan dapat mengaturnya ke 1.0, karena mencari hampir gratis di SSD.

— wildplasser
sumber

Luar biasa! Saya tidak pernah melihat arti dari efektif_cache_size, selalu bermain-main hanya dengan shared_buffers. Ini benar-benar membuat perbedaan besar. Saya menjalankan pgtune juga dan merekomendasikan 20GB 96 untuk digunakan untuk shard_buffers, tetapi 64GB untuk efektif_cache_size. Terima kasih!

1

FWIW, saya membahas ini dan pengaturan lainnya yang disarankan dalam dokumen Postgres, dan melakukan analisis untuk server kami .

— mlissner

Terima kasih banyak atas jawabannya. Bisakah saya bertanya apa yang direkomendasikan work_memketika max_connectionsdefault 100 dan RAM server 32GB (dedicated postgres server)? Saya tahu saya harus menyetel ini sendiri berdasarkan permintaan harian. Saya hanya ingin tahu apakah Anda dapat memberi saya nilai "satu ukuran cocok untuk semua jawaban" (atau nilai titik awal). Apakah 50MB terlalu besar? Terima kasih banyak.

— sgon00

Itu tergantung pada aktivitas bersamaan khas pada mesin Anda. 100 sesi menginginkan 50M (di atas 10..20M mereka) masing-masing mungkin cocok. Atau, mungkin tidak. Untuk mendapatkan kesan, monitor vmstat atau atas. Plus: itu tergantung pada permintaan Anda (dan yang lainnya). Lihat saja rencananya.

— wildplasser

@wildplasser terima kasih banyak atas jawaban cepatnya. Saya menemukan situs web pgtune.leopard.in.ua yang menarik . Saya pikir saya akan menggunakan 40MB sebagai titik awal dari saran dan tune berdasarkan itu. Tepuk tangan.

— sgon00

20

Pertimbangkan untuk menggunakan pgtune untuk membantu Anda mengatur konfigurasi PostgreSQL. Dari PgFoundry:

pgtune mengambil postgresql.conf default yang lemah dan memperluas server database menjadi sama kuatnya dengan perangkat keras yang digunakan

Konfigurasi default PostgreSQL sangat konservatif dan alat itu dimaksudkan untuk membantu dengan situasi yang tepat ini. Dokumentasinya ringan dibaca dan menggunakan alat ini sangat mudah.

Ingatlah bahwa tidak perlu menggunakan saran persis pgtune. Bermain dengan pengaturannya dan menonton perubahan yang dihasilkan pada file conf akan memberi Anda pemahaman yang lebih baik tentang konfigurasi PostgreSQL dan cara men-tweak secara manual.

— Paul Bellora
sumber

8

Pembaruan terakhir pgtune adalah pada tahun 2009, yaitu 5 tahun yang lalu dan masih terus bertambah. Saya bertanya-tanya apakah masih berlaku untuk seri 9.1-9.2-9.3.

— sorin

9

pgtune sekarang tersedia online

— Alfabravo

3

Jika setiap permintaan atau perintah berjalan lambat saya curiga bahwa:

Anda terhubung ke database untuk setiap permintaan yang Anda jalankan;
Anda telah mengonfigurasi beberapa jenis metode otentikasi, yang tidak berfungsi dan itu menghentikan permintaan Anda sampai metode otentikasi khusus ini habis waktu.

Bisakah Anda memberi tahu kami berapa banyak waktu yang diperlukan untuk menjalankan kueri select version()? Jika harus instan (0,16 ms di workstation saya).

— Tometzky
sumber

2

Jika SETIAP permintaan adalah sesuatu yang jauh lebih lambat sangat salah dengan server atau sesuatu. Dalam pengalaman saya masing-masing db memiliki beberapa hal itu lebih baik daripada yang lain, tetapi kinerja pgsql bijaksana mudah di bidang yang sama dengan server mssql.

Jadi, OS apa yang Anda jalankan pgsql? Perangkat keras apa? Pengaturan apa yang sudah Anda ubah? Seberapa besar dataset Anda? Apa contoh dari kueri yang buruk dan output dari analisis menjelaskan (Jalankan permintaan Anda seperti ini:

jelaskan analisis pilih ... sisa kueri di sini ...;

Poskan hasilnya ke http://explain.depesz.com/ dan poskan tautannya di sini.

— Scott Marlowe
sumber

1

Ya, setiap permintaan / perintah berjalan lambat, dan ya "sesuatu" sangat salah maka pertanyaan saya. Masalahnya adalah bahwa mssql memanfaatkan sepenuhnya ram yang tersedia di server (caching yang sangat berat) sedangkan psql tidak. Saya menghargai komentar dan saran, tetapi Anda pasti telah melewatkan sebagian besar pertanyaan saya dan baris subjek itu sendiri ... Saya hanya ingin tahu bagaimana mendapatkan psql untuk memanfaatkan ram yang tersedia; saat ini mencoba beberapa saran yang terdaftar oleh yang lain ...

— user85116

1

Menggunakan RAM Anda BUKAN masalahnya. Postgresql bergantung pada OS untuk melakukan sebagian besar caching. Jadi, tidak PERLU menggunakan semua RAM. Sekali lagi, Anda melewatkan sebagian besar poin saya. Anda memberi kami sedikit berharga untuk membantu Anda. Saya mengendarai 5000 TPS postgresql cluster sebagai mata pencarian. Anda dapat menerima saran saya, atau terus berpikir Anda tahu bagaimana cara pgsql bekerja dan berdebat.

— Scott Marlowe

@ user85116, tolong dengarkan Scott, kami sudah memiliki alur kerja dengan MySQL yang sangat tergantung pada latensi, jadi saat ini MySQL menggunakan ram 64GB untuk melakukan kueri itu dengan cepat, sedangkan hal yang sama dapat dicapai pada 2G Postgres dengan pandangan yang baru terwujud. Caching semua basis data ke dalam RAM tidak akan menyelesaikan masalah Anda, itu hanya membuatnya kurang terlihat. Jika Anda memiliki masalah yang sama dalam struktur DB Postgres tidak akan memperbaikinya untuk Anda atau mencoba menyembunyikannya.

— kworr