Penyetelan Linux untuk meningkatkan kinerja PostgreSQL. Ilya Kosmodemyansky

Transkrip laporan tahun 2015 oleh Ilya Kosmodemyansky "Penyetelan Linux untuk meningkatkan kinerja PostgreSQL"

Penafian: Saya perhatikan bahwa laporan ini bertanggal November 2015 - lebih dari 4 tahun telah berlalu dan banyak waktu telah berlalu. Versi 9.4 yang dibahas dalam laporan tidak lagi didukung. Selama 4 tahun terakhir, 5 rilis baru PostgreSQL telah dirilis, dan 15 versi kernel Linux telah dirilis. Jika Anda menulis ulang bagian-bagian ini, Anda akan mendapatkan laporan yang berbeda. Namun di sini kami mempertimbangkan penyetelan dasar Linux untuk PostgreSQL, yang masih relevan hingga saat ini.

Nama saya Ilya Kosmodemyansky. Saya bekerja di PostgreSQL-Consulting. Dan sekarang saya akan berbicara sedikit tentang apa yang harus dilakukan dengan Linux sehubungan dengan database pada umumnya dan PostgreSQL pada khususnya, karena prinsipnya sangat mirip.

Apa yang akan kita bicarakan? Jika Anda berkomunikasi dengan PostgreSQL, sampai batas tertentu Anda harus menjadi admin UNIX. Apa artinya? Jika kita membandingkan Oracle dan PostgreSQL, maka di Oracle Anda harus menjadi 80% admin database DBA dan 20% admin Linux.

Dengan PostgreSQL, segalanya menjadi sedikit lebih rumit. Dengan PostgreSQL Anda perlu memiliki pemahaman yang lebih baik tentang cara kerja Linux. Sekaligus berlari sedikit mengejar lokomotif, karena akhir-akhir ini semuanya sudah diupdate dengan cukup baik. Dan kernel baru dirilis, dan fungsionalitas baru muncul, kinerja meningkat, dll.

Mengapa kita berbicara tentang Linux? Bukan karena kita menghadiri konferensi Linux Peter, tetapi karena dalam kondisi modern salah satu sistem operasi yang paling dibenarkan untuk menggunakan database pada umumnya dan PostgreSQL pada khususnya adalah Linux. Karena FreeBSD sayangnya berkembang ke arah yang sangat aneh. Dan akan ada masalah baik dengan kinerja maupun banyak hal lainnya. Kinerja PostgreSQL pada Windows umumnya merupakan masalah serius yang terpisah, berdasarkan fakta bahwa Windows tidak memiliki memori bersama yang sama dengan UNIX, sedangkan PostgreSQL terikat dengan hal ini, karena ini adalah sistem multi-proses.

Dan menurut saya semua orang kurang tertarik dengan barang eksotik seperti Solaris, jadi ayo pergi.

Distribusi Linux modern memiliki lebih dari 1 opsi syctl, bergantung pada cara Anda membangun kernel. Pada saat yang sama, jika kita melihat kacang-kacangan yang berbeda, kita dapat menyesuaikan sesuatu dengan berbagai cara. Ada parameter sistem file tentang cara memasangnya. Jika Anda memiliki pertanyaan tentang cara memulainya: apa yang harus diaktifkan di BIOS, cara mengkonfigurasi perangkat keras, dll.

Ini adalah volume yang sangat besar yang dapat didiskusikan selama beberapa hari, dan bukan dalam satu laporan singkat, tapi sekarang saya akan fokus pada hal-hal penting, bagaimana menghindari penggaruk yang dijamin akan mencegah Anda menggunakan database dengan baik di Linux jika Anda jangan perbaiki mereka. Dan pada saat yang sama, poin pentingnya adalah banyak parameter default yang tidak disertakan dalam pengaturan yang benar untuk database. Artinya, secara default, ini akan berfungsi buruk atau tidak berfungsi sama sekali.

Target penyetelan tradisional apa yang ada di Linux? Saya rasa karena Anda semua berurusan dengan administrasi Linux, tidak ada kebutuhan khusus untuk menjelaskan apa targetnya.

Anda dapat menyetel:

• CPU.
• Penyimpanan.
• Penyimpanan.
• Lainnya. Kita akan membicarakan hal ini di akhir untuk camilan. Bahkan, misalnya, parameter seperti kebijakan penghematan energi dapat mempengaruhi kinerja dengan cara yang sangat tidak terduga dan bukan cara yang paling menyenangkan.

Apa spesifikasi PostgreSQL dan database secara umum? Masalahnya adalah Anda tidak dapat mengubah satu hal pun dan melihat bahwa kinerja kami telah meningkat secara signifikan.

Ya, gadget seperti itu memang ada, tetapi database adalah hal yang rumit. Ia berinteraksi dengan semua sumber daya yang dimiliki server dan lebih memilih untuk berinteraksi secara maksimal. Jika Anda melihat rekomendasi Oracle saat ini tentang cara menggunakan OS host, itu akan seperti lelucon tentang kosmonaut Mongolia - beri makan anjing dan jangan sentuh apa pun. Mari kita berikan database semua sumber daya, database itu sendiri yang akan menyelesaikan semuanya.

Pada prinsipnya, sampai batas tertentu, situasinya persis sama dengan PostgreSQL. Perbedaannya adalah database belum dapat mengambil semua sumber daya untuk dirinya sendiri, mis. di suatu tempat di tingkat Linux Anda perlu menyelesaikan semuanya sendiri.

Ide utamanya bukanlah untuk memilih satu target dan mulai menyetelnya, misalnya memori, CPU atau sejenisnya, tetapi untuk menganalisis beban kerja dan mencoba meningkatkan throughput sebanyak mungkin sehingga beban yang dibuat oleh programmer yang baik itu. bagi kami, termasuk pengguna kami.

Berikut adalah gambar untuk menjelaskan apa itu. Ada buffer OS Linux dan ada memori bersama dan ada buffer bersama PostgreSQL. PostgreSQL, tidak seperti Oracle, bekerja secara langsung hanya melalui buffer kernel, yaitu agar halaman dari disk dapat masuk ke memori bersama, halaman tersebut harus melalui buffer kernel dan kembali, situasi yang persis sama.

Disk berada di bawah sistem ini. Saya menggambar ini sebagai disk. Faktanya, mungkin ada pengontrol RAID, dll.

Dan input-output ini dengan satu atau lain cara terjadi melalui masalah ini.

PostgreSQL adalah database klasik. Ada halaman di dalamnya. Dan semua input dan output terjadi menggunakan halaman. Kami meningkatkan blok ke dalam memori dengan halaman. Dan jika tidak terjadi apa-apa, kita hanya membacanya, kemudian secara bertahap mereka menghilang dari cache ini, dari buffer bersama dan berakhir kembali di disk.

Jika kita mengganti sesuatu di suatu tempat, maka seluruh halaman ditandai kotor. Saya menandainya di sini dengan warna biru. Artinya halaman ini harus disinkronkan dengan penyimpanan blok. Maksudnya kalau kita buat kotor kita buat entry di WAL. Dan pada suatu saat yang indah, sebuah fenomena yang disebut pos pemeriksaan datang. Dan informasi dicatat dalam log ini bahwa dia telah tiba. Dan ini berarti semua halaman kotor yang ada di sini pada saat itu di buffer bersama ini disinkronkan dengan disk penyimpanan menggunakan fsync melalui buffer kernel.

Mengapa hal ini dilakukan? Jika kita kehilangan tegangan, maka kita tidak mendapatkan situasi dimana semua data hilang. Memori yang terus-menerus, yang diceritakan semua orang kepada kami, sejauh ini ada dalam teori basis data - ini adalah masa depan yang cerah, yang tentu saja kami perjuangkan dan kami menyukainya, tetapi untuk saat ini mereka hidup dalam waktu minus 20 tahun. Dan tentunya semua itu perlu diawasi.

Dan tugas memaksimalkan throughput adalah menyempurnakan semua tahapan ini sehingga semuanya bergerak maju dan mundur dengan cepat. Memori bersama pada dasarnya adalah cache halaman. Di PostgreSQL kami mengirimkan kueri pemilihan atau sesuatu, itu mengambil data ini dari disk. Mereka berakhir di buffer bersama. Oleh karena itu, agar ini berfungsi lebih baik, harus ada banyak memori.

Agar semua ini berfungsi dengan baik dan cepat, Anda perlu mengkonfigurasi sistem operasi dengan benar di semua tahap. Dan pilihlah perangkat keras yang seimbang, karena jika Anda mengalami ketidakseimbangan di suatu tempat, Anda dapat membuat banyak memori, tetapi tidak akan dilayani dengan kecepatan yang memadai.

Dan mari kita bahas masing-masing poin ini.

Untuk membuat halaman-halaman ini bergerak bolak-balik lebih cepat, Anda perlu melakukan hal berikut:

• Pertama, Anda perlu bekerja lebih efisien dengan memori.
• Kedua, transisi ketika halaman dari memori berpindah ke disk harus lebih efisien.
• Dan ketiga, harus ada disk yang bagus.

Jika Anda memiliki 512 GB RAM di server dan semuanya berakhir di hard drive SATA tanpa cache apa pun, maka seluruh server database tidak hanya berubah menjadi labu, tetapi labu dengan antarmuka SATA. Anda akan langsung menemuinya. Dan tidak ada yang bisa menyelamatkanmu.

Mengenai poin pertama tentang ingatan, ada tiga hal yang dapat membuat hidup menjadi sangat sulit.

Yang pertama adalah NUMA. NUMA adalah sesuatu yang dibuat untuk meningkatkan kinerja. Tergantung pada beban kerja, berbagai hal dapat dioptimalkan. Dan dalam bentuknya yang baru saat ini, ini tidak terlalu baik untuk aplikasi seperti database yang secara intensif menggunakan buffer bersama cache halaman.

Pendeknya. Bagaimana cara mengetahui jika ada yang salah dengan NUMA? Anda mengalami ketukan yang tidak menyenangkan, tiba-tiba beberapa CPU kelebihan beban. Pada saat yang sama, Anda menganalisis kueri di PostgreSQL dan melihat bahwa tidak ada hal serupa di sana. Kueri ini tidak boleh terlalu intensif CPU. Anda bisa menangkapnya untuk waktu yang lama. Lebih mudah menggunakan rekomendasi yang benar sejak awal tentang cara mengkonfigurasi NUMA untuk PostgreSQL.

Apa yang sebenarnya terjadi? NUMA adalah singkatan Akses Memori Non-Seragam. Apa gunanya? Anda memiliki CPU, di sebelahnya ada memori lokalnya. Dan interkoneksi memori ini dapat menarik memori dari CPU lain.

Jika kamu lari numactl --hardware, maka Anda akan mendapatkan lembaran sebesar itu. Antara lain, akan ada bidang jarak. Akan ada angka - 10-20, kira-kira seperti itu. Angka-angka ini tidak lebih dari jumlah lompatan untuk mengambil memori jarak jauh ini dan menggunakannya secara lokal. Pada prinsipnya, ide yang bagus. Hal ini mempercepat kinerja dengan baik pada berbagai beban kerja.

Sekarang bayangkan Anda memiliki satu CPU yang pertama-tama mencoba menggunakan memori lokalnya, kemudian mencoba menarik memori lain melalui interkoneksi untuk sesuatu. Dan CPU ini mendapatkan seluruh cache halaman PostgreSQL Anda - itu saja, beberapa gigabyte. Anda selalu mendapatkan kasus terburuk, karena pada CPU biasanya hanya terdapat sedikit memori dalam modul itu sendiri. Dan semua memori yang dilayani melewati interkoneksi ini. Ternyata lambat dan menyedihkan. Dan prosesor Anda yang melayani node ini terus-menerus kelebihan beban. Dan waktu akses memori ini buruk, lambat. Ini adalah situasi yang tidak Anda inginkan jika Anda menggunakan ini untuk database.

Oleh karena itu, pilihan database yang lebih tepat adalah sistem operasi Linux tidak mengetahui apa yang terjadi di sana sama sekali. Sehingga ia mengakses memori sebagaimana adanya.

Mengapa demikian? Tampaknya yang terjadi adalah sebaliknya. Ini terjadi karena satu alasan sederhana: kita memerlukan banyak memori untuk cache halaman - puluhan, ratusan gigabyte.

Dan jika kita mengalokasikan semua ini dan menyimpan data kita di sana, maka keuntungan dari penggunaan cache akan jauh lebih besar daripada keuntungan dari akses yang rumit ke memori. Dan dengan demikian kita akan mendapatkan keuntungan yang jauh dibandingkan dengan fakta bahwa kita akan mengakses memori secara lebih efisien menggunakan NUMA.

Oleh karena itu, ada dua pendekatan di sini saat ini, hingga masa depan yang cerah telah tiba, dan database itu sendiri tidak dapat mengetahui CPU mana yang sedang berjalan dan dari mana ia perlu menarik sesuatu.

Oleh karena itu, pendekatan yang benar adalah menonaktifkan NUMA sama sekali, misalnya saat melakukan boot ulang. Dalam kebanyakan kasus, kemenangannya sangat besar sehingga pertanyaan mana yang lebih baik tidak muncul sama sekali.

Ada pilihan lain. Kami menggunakannya lebih sering daripada yang pertama, karena ketika klien datang kepada kami untuk meminta dukungan, me-reboot server adalah masalah besar baginya. Dia punya bisnis di sana. Dan mereka mengalami masalah karena NUMA. Oleh karena itu, kami mencoba menonaktifkannya dengan cara yang tidak terlalu invasif dibandingkan reboot, namun hati-hati untuk memeriksa apakah itu dinonaktifkan. Karena, seperti yang ditunjukkan oleh pengalaman, ada baiknya kita menonaktifkan NUMA pada proses induk PostgreSQL, tetapi itu tidak harus berfungsi sama sekali. Kita perlu memeriksa dan melihat apakah dia benar-benar mati.

Ada postingan bagus dari Robert Haas. Ini adalah salah satu commiter PostgreSQL. Salah satu pengembang utama dari semua jeroan ayam itik tingkat rendah. Dan jika Anda mengikuti link dari postingan ini, mereka menggambarkan beberapa cerita penuh warna tentang bagaimana NUMA mempersulit hidup orang-orang. Begini, pelajari checklist system administrator apa saja yang perlu dikonfigurasi di server agar database kita bisa bekerja dengan baik. Pengaturan ini perlu ditulis dan diperiksa, karena jika tidak, maka hasilnya tidak akan terlalu baik.

Harap dicatat bahwa ini berlaku untuk semua pengaturan yang akan saya bicarakan. Tapi biasanya database dikumpulkan dalam mode master-slave untuk toleransi kesalahan. Jangan lupa untuk melakukan pengaturan ini pada slave karena suatu saat Anda akan mengalami kecelakaan dan Anda akan beralih ke slave dan akan menjadi master.

Dalam situasi darurat, ketika semuanya sangat buruk, telepon Anda terus-menerus berdering dan atasan Anda datang membawa tongkat besar, Anda tidak akan punya waktu untuk berpikir untuk memeriksanya. Dan akibatnya bisa sangat buruk.

Poin selanjutnya adalah halaman besar. Halaman besar sulit untuk diuji secara terpisah, dan tidak ada gunanya melakukannya, meskipun ada tolok ukur yang dapat melakukan hal ini. Mereka mudah untuk di Google.

Apa gunanya? Anda memiliki server yang tidak terlalu mahal dengan banyak RAM, misalnya lebih dari 30 GB. Anda tidak menggunakan halaman besar. Ini berarti Anda pasti memiliki overhead dalam hal penggunaan memori. Dan overhead ini jauh dari yang paling menyenangkan.

Mengapa demikian? Jadi apa yang terjadi? Sistem operasi mengalokasikan memori dalam jumlah kecil. Ini sangat nyaman, itulah yang terjadi secara historis. Dan jika kita menjelaskannya secara detail, OS harus menerjemahkan alamat virtual menjadi alamat fisik. Dan proses ini bukan yang paling sederhana, sehingga OS menyimpan hasil operasi ini dalam Translation Lookaside Buffer (TLB).

Dan karena TLB adalah cache, semua masalah yang melekat pada cache muncul dalam situasi ini. Pertama, jika Anda memiliki banyak RAM dan semuanya dialokasikan dalam jumlah kecil, maka buffer ini menjadi sangat besar. Dan jika cache-nya besar, pencarian di dalamnya akan lebih lambat. Overheadnya sehat dan memakan ruang, yaitu RAM dikonsumsi oleh sesuatu yang salah. Kali ini.

Dua - semakin banyak cache yang tumbuh dalam situasi seperti ini, semakin besar kemungkinan Anda akan kehilangan cache. Dan efisiensi cache ini menurun dengan cepat seiring bertambahnya ukurannya. Oleh karena itu, sistem operasi hadir dengan pendekatan sederhana. Ini telah digunakan di Linux sejak lama. Itu muncul di FreeBSD belum lama ini. Tapi kita berbicara tentang Linux. Ini adalah halaman yang sangat besar.

Dan di sini perlu dicatat bahwa halaman besar, sebagai sebuah ide, pada awalnya didorong oleh komunitas termasuk Oracle dan IBM, yaitu produsen basis data yang sangat percaya bahwa ini akan berguna untuk basis data juga.

Dan bagaimana ini bisa berteman dengan PostgreSQL? Pertama, halaman besar harus diaktifkan di kernel Linux.

Kedua, mereka harus ditentukan secara eksplisit oleh parameter sysctl - berapa jumlahnya. Nomor-nomor di sini berasal dari beberapa server lama. Anda dapat menghitung berapa banyak buffer bersama yang Anda miliki sehingga halaman besar dapat ditampung di sana.

Dan jika seluruh server Anda didedikasikan untuk PostgreSQL, maka titik awal yang baik adalah mengalokasikan 25% RAM ke buffer bersama, atau 75% jika Anda yakin database Anda pasti cocok dengan 75% ini. Titik awal satu. Dan pertimbangkan, jika Anda memiliki RAM 256 GB, maka Anda akan memiliki buffer besar sebesar 64 GB. Hitung kira-kira dengan margin tertentu - berapa angka ini yang harus ditetapkan.

Sebelum versi 9.2 (jika saya tidak salah, sejak versi 8.2), PostgreSQL dapat dihubungkan dengan halaman besar menggunakan perpustakaan pihak ketiga. Dan hal ini harus selalu dilakukan. Pertama, Anda memerlukan kernel untuk dapat mengalokasikan halaman besar dengan benar. Dan kedua, agar aplikasi yang bekerja dengannya dapat menggunakannya. Ini tidak akan digunakan begitu saja. Karena PostgreSQL mengalokasikan memori dalam gaya sistem 5, ini dapat dilakukan menggunakan libhugetlbfs - ini adalah nama lengkap perpustakaan.

Di 9.3, kinerja PostgreSQL ditingkatkan saat bekerja dengan memori dan metode alokasi memori sistem 5 ditinggalkan. Semua orang sangat senang, karena jika tidak, Anda mencoba menjalankan dua instance PostgreSQL pada satu mesin, dan dia mengatakan saya tidak memiliki cukup memori bersama. Dan dia mengatakan bahwa sysctl perlu diperbaiki. Dan ada sysctl yang masih perlu Anda reboot, dll. Secara umum, semua orang senang. Namun alokasi memori mmap menghentikan penggunaan halaman yang besar. Sebagian besar klien kami menggunakan buffer bersama yang besar. Dan kami sangat menyarankan untuk tidak beralih ke 9.3, karena di sana overhead mulai dihitung dalam persentase yang baik.

Namun komunitas memperhatikan masalah ini dan di 9.4 mereka mengerjakan ulang acara ini dengan sangat baik. Dan di 9.4 sebuah parameter muncul di postgresql.conf di mana Anda dapat mengaktifkan atau menonaktifkan coba.

Mencoba adalah pilihan teraman. Saat PostgreSQL dimulai, ketika ia mengalokasikan memori bersama, ia mencoba mengambil memori ini dari halaman yang sangat besar. Dan jika tidak berhasil, maka akan kembali ke pilihan normal. Dan jika Anda memiliki FreeBSD atau Solaris, Anda dapat mencobanya, selalu aman.

Jika aktif, maka itu tidak akan dimulai jika tidak dapat memilih dari halaman yang besar. Ini tentang siapa dan apa yang lebih baik. Tetapi jika Anda sudah mencobanya, periksa apakah Anda benar-benar telah menyoroti apa yang Anda perlukan, karena ada banyak ruang untuk kesalahan. Saat ini fungsi ini hanya berfungsi di Linux.

Satu lagi catatan kecil sebelum kita melangkah lebih jauh. Halaman besar yang transparan belum tentang PostgreSQL. Dia tidak bisa menggunakannya secara normal. Dan dengan halaman Transparan yang sangat besar untuk beban kerja seperti itu, ketika diperlukan sebagian besar memori bersama, manfaatnya hanya datang dalam volume yang sangat besar. Jika Anda memiliki memori terabyte maka ini mungkin berguna. Jika kita berbicara tentang aplikasi sehari-hari, ketika Anda memiliki memori 32, 64, 128, 256 GB di mesin Anda, maka halaman besar yang biasa adalah Ok, dan kami cukup menonaktifkan Transparan.

Dan yang terakhir tentang ingatan tidak berhubungan langsung dengan buah, itu bisa sangat merusak hidup Anda. Semua throughput akan sangat dipengaruhi oleh fakta bahwa server terus-menerus bertukar.

Dan ini akan sangat tidak menyenangkan dalam beberapa hal. Dan masalah utamanya adalah kernel modern berperilaku sedikit berbeda dari kernel Linux lama. Dan hal ini cukup tidak menyenangkan untuk diinjak, karena ketika kita berbicara tentang semacam pekerjaan dengan swap, itu berakhir dengan kedatangan OOM-killer yang terlalu dini. Dan pembunuh OOM, yang tidak tiba tepat waktu dan menghapus PostgreSQL, tidak menyenangkan. Semua orang akan mengetahui hal ini, hingga pengguna terakhir.

Apa yang terjadi? Anda memiliki banyak RAM di sana, semuanya berfungsi dengan baik. Tapi entah kenapa server hang di swap dan melambat karenanya. Tampaknya ada banyak kenangan, tapi ini terjadi.

Sebelumnya, kami menyarankan pengaturan vm.swappiness ke nol, yaitu menonaktifkan swap. Sebelumnya, tampaknya RAM 32 GB dan buffer bersama yang sesuai adalah jumlah yang sangat besar. Tujuan utama dari pertukaran ini adalah untuk mendapatkan tempat membuang kerak jika kita terjatuh. Dan itu tidak lagi terpenuhi secara khusus. Lalu apa yang akan kamu lakukan dengan kerak ini? Ini adalah tugas yang tidak terlalu jelas mengapa swap diperlukan, terutama dengan ukuran seperti itu.

Namun pada kernel yang lebih modern, yaitu versi ketiga, perilakunya telah berubah. Dan jika Anda menyetel swap ke nol, yaitu mematikannya, maka cepat atau lambat, meskipun masih ada sisa RAM, pembunuh OOM akan datang kepada Anda untuk membunuh konsumen yang paling intensif. Karena dia akan menganggap bahwa dengan beban kerja seperti itu kita masih punya sedikit sisa dan kita akan melompat keluar, yaitu bukan untuk menghentikan proses sistem, tetapi untuk menyelesaikan sesuatu yang kurang penting. Yang kurang penting ini adalah konsumen intensif memori bersama, yaitu postmaster. Dan setelah itu akan lebih baik jika pangkalannya tidak perlu dipulihkan.

Oleh karena itu, sekarang defaultnya, sejauh yang saya ingat, sebagian besar distribusi berada di sekitar 6, yaitu pada titik mana Anda harus mulai menggunakan swap tergantung pada berapa banyak memori yang tersisa. Kami sekarang merekomendasikan pengaturan vm.swappiness = 1, karena ini secara praktis mematikannya, tetapi tidak memberikan efek yang sama seperti dengan pembunuh OOM yang tiba-tiba datang dan mematikan semuanya.

Apa berikutnya? Ketika kita berbicara tentang kinerja database dan secara bertahap beralih ke disk, semua orang mulai bingung. Karena kebenaran bahwa disk itu lambat dan memorinya cepat sudah tidak asing lagi bagi semua orang sejak kecil. Dan semua orang tahu bahwa database akan mengalami masalah kinerja disk.

Masalah kinerja utama PostgreSQL yang terkait dengan lonjakan pos pemeriksaan tidak terjadi karena disk lambat. Hal ini kemungkinan besar disebabkan oleh fakta bahwa bandwidth memori dan disk tidak seimbang. Namun, hal tersebut mungkin tidak seimbang di tempat yang berbeda. PostgreSQL tidak dikonfigurasi, OS tidak dikonfigurasi, perangkat keras tidak dikonfigurasi, dan perangkat keras salah. Dan masalah ini tidak terjadi hanya jika semuanya berjalan sebagaimana mestinya, yaitu tidak ada beban, atau pengaturan dan perangkat keras dipilih dengan baik.

Apa itu dan seperti apa bentuknya? Biasanya orang yang bekerja dengan PostgreSQL sudah terlibat dalam masalah ini lebih dari satu kali. saya akan menjelaskannya. Seperti yang saya katakan, PostgreSQL secara berkala membuat pos pemeriksaan untuk membuang halaman kotor di memori bersama ke disk. Jika kita memiliki memori bersama dalam jumlah besar, maka pos pemeriksaan mulai memberikan dampak yang intensif pada disk, karena ia membuang halaman-halaman ini dengan fsync. Itu tiba di buffer kernel dan ditulis ke disk menggunakan fsync. Dan jika volume bisnis ini besar, maka kita dapat mengamati dampak yang tidak menyenangkan, yaitu penggunaan disk yang sangat besar.

Di sini saya punya dua gambar. Sekarang saya akan menjelaskan apa itu. Ini adalah dua grafik yang berkorelasi waktu. Grafik pertama adalah pemanfaatan disk. Di sini mencapai hampir 90% saat ini. Jika Anda mengalami kegagalan database dengan disk fisik, dengan pemanfaatan pengontrol RAID sebesar 90%, maka ini adalah berita buruk. Artinya sedikit lagi maka akan mencapai 100 dan I/O akan berhenti.

Jika Anda memiliki array disk, ceritanya sedikit berbeda. Itu tergantung pada bagaimana konfigurasinya, jenis arraynya, dll.

Dan secara paralel, grafik dari tampilan internal postgres dikonfigurasi di sini, yang memberitahukan bagaimana pos pemeriksaan terjadi. Dan warna hijau di sini menunjukkan berapa banyak buffer, halaman-halaman kotor ini, yang pada saat itu tiba di pos pemeriksaan ini untuk sinkronisasi. Dan inilah hal utama yang perlu Anda ketahui di sini. Kami melihat bahwa kami memiliki banyak halaman di sini dan pada titik tertentu kami mencapai papan, yaitu, kami menulis dan menulis, di sini sistem disk jelas sangat sibuk. Dan pos pemeriksaan kami memiliki dampak yang sangat kuat pada disk. Idealnya, situasinya akan terlihat seperti ini, yaitu rekaman yang kita miliki lebih sedikit di sini. Dan kita bisa memperbaikinya dengan pengaturan agar tetap seperti ini. Artinya, daur ulangnya kecil, tapi di suatu tempat kami menulis sesuatu di sini.

Apa yang perlu dilakukan untuk mengatasi masalah ini? Jika Anda telah menghentikan IO di bawah database, ini berarti semua pengguna yang datang untuk memenuhi permintaan mereka akan menunggu.

Jika Anda melihat dari sudut pandang Linux, jika Anda menggunakan perangkat keras yang bagus, mengkonfigurasinya dengan benar, mengkonfigurasi PostgreSQL secara normal sehingga membuat pos pemeriksaan ini lebih jarang, menyebarkannya dari waktu ke waktu antara satu sama lain, maka Anda masuk ke parameter default Debian. Untuk sebagian besar distribusi Linux, ini gambarnya: vm.dirty_ratio=20, vm.dirty_background_ratio=10.

Apa artinya? Satu setan pembilas muncul dari kernel 2.6. Pdglush, tergantung pada siapa yang menggunakan yang mana, yang terlibat dalam membuang halaman kotor di latar belakang dari buffer kernel dan membuang ketika halaman kotor perlu dibuang, apa pun yang terjadi, ketika membuang latar belakang tidak membantu.

Kapan latar belakang muncul? Ketika 10% dari total RAM yang tersedia di server ditempati oleh halaman kotor di buffer kernel, fungsi penghapusan khusus dipanggil di latar belakang. Mengapa itu menjadi latar belakang? Sebagai parameter, ini memperhitungkan berapa banyak halaman yang akan dihapuskan. Dan, katakanlah, dia menghapus N halaman. Dan untuk sementara benda ini tertidur. Lalu dia datang lagi dan menyalin beberapa halaman lagi.

Ini adalah cerita yang sangat sederhana. Masalahnya di sini seperti kolam renang, kalau dialirkan ke satu pipa, dia mengalir ke pipa yang lain. Pos pemeriksaan kami telah tiba dan jika mengirimkan beberapa halaman kotor untuk dibuang, maka secara bertahap semuanya akan terselesaikan dengan rapi dari buffer kernel pgflush.

Jika halaman-halaman kotor ini terus terakumulasi, mereka terakumulasi hingga 20%, setelah itu prioritas OS adalah menghapus semuanya ke disk, karena listrik akan mati dan semuanya akan buruk bagi kita. Kami akan kehilangan data ini, misalnya.

Apa triknya? Triknya adalah bahwa parameter ini di dunia modern adalah 20 dan 10% dari total RAM yang ada pada mesin, parameter tersebut benar-benar mengerikan dalam hal throughput sistem disk apa pun yang Anda miliki.

Bayangkan Anda memiliki RAM 128 GB. 12,8 GB masuk ke sistem disk Anda. Dan tidak peduli cache apa yang Anda miliki di sana, tidak peduli array apa yang Anda miliki di sana, cache tersebut tidak akan bertahan lama.

Oleh karena itu, kami menyarankan Anda segera menyesuaikan angka-angka ini berdasarkan kemampuan pengontrol RAID Anda. Saya langsung membuat rekomendasi di sini untuk pengontrol yang memiliki cache 512 MB.

Semuanya dianggap sangat sederhana. Anda dapat memasukkan vm.dirty_background dalam byte. Dan pengaturan ini membatalkan dua pengaturan sebelumnya. Entah rasionya secara default, atau rasio dengan byte diaktifkan, maka rasio dengan byte akan berfungsi. Tetapi karena saya seorang konsultan DBA dan bekerja dengan klien yang berbeda, saya mencoba menggambar sedotan dan oleh karena itu, jika dalam byte, maka dalam byte. Tidak ada yang memberikan jaminan bahwa admin yang baik tidak akan menambahkan lebih banyak memori ke server, mem-boot ulangnya, dan angkanya akan tetap sama. Hitung saja angka-angka ini agar semuanya sesuai dengan jaminan.

Apa yang terjadi jika Anda tidak cocok? Saya telah menulis bahwa pembilasan apa pun dapat dihentikan secara efektif, namun sebenarnya ini hanyalah sebuah kiasan. Sistem operasi memiliki masalah besar - memiliki banyak halaman kotor, sehingga IO yang dihasilkan klien Anda dihentikan secara efektif, yaitu aplikasi datang untuk mengirim kueri sql ke database, ia menunggu. Setiap input/output ke dalamnya adalah prioritas terendah, karena database ditempati oleh sebuah pos pemeriksaan. Dan kapan dia akan menyelesaikannya sama sekali tidak jelas. Dan ketika Anda telah mencapai pembilasan non-latar belakang, itu berarti semua IO Anda ditempati olehnya. Dan sampai semuanya berakhir, Anda tidak akan melakukan apa pun.

Ada dua poin penting lainnya di sini yang berada di luar cakupan laporan ini. Pengaturan ini harus sesuai dengan pengaturan di postgresql.conf, yaitu pengaturan pos pemeriksaan. Dan sistem disk Anda harus dikonfigurasi secara memadai. Jika Anda memiliki cache pada RAID, maka cache tersebut harus memiliki baterai. Orang membeli RAID dengan cache yang bagus tanpa baterai. Jika Anda memiliki SSD di RAID, maka itu harus server, harus ada kapasitor di sana. Berikut adalah daftar periksa terperinci. Tautan ini berisi laporan saya tentang cara mengkonfigurasi disk kinerja di PostgreSQL. Ada semua daftar periksa di sana.

Apa lagi yang bisa membuat hidup menjadi sangat sulit? Ini adalah dua parameter. Mereka relatif baru. Secara default, mereka dapat disertakan dalam aplikasi yang berbeda. Dan mereka dapat membuat hidup menjadi sulit jika mereka tidak diaktifkan dengan benar.

Ada dua hal yang relatif baru. Mereka sudah muncul di inti ketiga. Ini adalah sched_migration_cost dalam nanodetik dan sched_autogroup_enabled, yang merupakan satu secara default.

Dan bagaimana mereka menghancurkan hidup Anda? Apa itu sched_migration_cost? Di Linux, penjadwal dapat memigrasikan proses dari satu CPU ke CPU lainnya. Dan untuk PostgreSQL, yang menjalankan kueri, migrasi ke CPU lain sama sekali tidak jelas. Dari sudut pandang sistem operasi, saat Anda berpindah jendela antara openoffice dan terminal, ini mungkin bagus, tapi untuk database ini sangat buruk. Oleh karena itu, kebijakan yang masuk akal adalah menetapkan biaya_migrasi ke nilai yang besar, setidaknya beberapa ribu nanodetik.

Apa artinya ini bagi penjadwal? Selama ini prosesnya dianggap masih panas. Artinya, jika Anda memiliki transaksi jangka panjang yang telah melakukan sesuatu dalam waktu lama, penjadwal akan memahami hal ini. Dia akan berasumsi bahwa hingga batas waktu ini berlalu, tidak perlu memigrasikan proses ini ke mana pun. Jika pada saat yang sama suatu proses melakukan sesuatu, maka proses tersebut tidak akan dimigrasikan ke mana pun, ia akan bekerja secara diam-diam pada CPU yang dialokasikan untuknya. Dan hasilnya luar biasa.

Poin kedua adalah autogroup. Ada ide bagus untuk beban kerja tertentu yang tidak terkait dengan database modern - ini adalah mengelompokkan proses berdasarkan terminal virtual tempat proses tersebut diluncurkan. Ini berguna untuk beberapa tugas. Dalam praktiknya, PostgreSQL adalah sistem multi-proses dengan prefork yang dijalankan dari satu terminal. Anda memiliki penulis kunci, pos pemeriksaan, dan semua permintaan klien Anda akan dikelompokkan ke dalam satu penjadwal, per CPU. Dan mereka akan menunggu di sana secara serempak hingga dia bebas, agar bisa saling mengganggu dan membuatnya sibuk lebih lama. Ini adalah cerita yang sama sekali tidak diperlukan jika terjadi beban seperti itu dan oleh karena itu perlu dimatikan.

Rekan saya Alexei Lesovsky melakukan pengujian dengan pgbench sederhana, di mana ia meningkatkan biaya_migrasi berdasarkan urutan besarnya dan mematikan grup otomatis. Perbedaan pada perangkat keras yang buruk hampir 10%. Ada diskusi di milis postgres di mana orang-orang memberikan hasil perubahan serupa pada kecepatan kueri mempengaruhi 50%. Ada cukup banyak cerita seperti itu.

Dan terakhir, tentang kebijakan penghematan energi. Hebatnya lagi Linux kini bisa digunakan di laptop. Dan itu seharusnya menghabiskan baterai dengan baik. Namun tiba-tiba ternyata hal ini juga bisa terjadi pada server.

Terlebih lagi, jika Anda menyewa server dari beberapa hoster, maka hoster yang “baik” tidak peduli bahwa Anda memiliki kinerja yang lebih baik. Tugas mereka adalah memastikan bahwa zat besi mereka digunakan seefisien mungkin. Oleh karena itu, secara default mereka dapat mengaktifkan mode hemat daya laptop di sistem operasi.

Jika Anda menggunakan hal ini di server dengan database dengan beban berat, maka pilihan Anda adalah acpi_cpufreq + permormance. Bahkan dengan ondemand pun akan ada masalah.

Intel_pstate adalah driver yang sedikit berbeda. Dan sekarang preferensi diberikan kepada yang ini, karena lebih lambat dan berfungsi lebih baik.

Dan karenanya, gubernur hanya kinerja. Sesuai permintaan, hemat daya, dan lainnya bukan tentang Anda.

Hasil analisis penjelasan PostgreSQL mungkin berbeda beberapa kali lipat jika Anda mengaktifkan penghematan daya, karena secara praktis CPU di bawah database Anda akan berjalan dengan cara yang benar-benar tidak dapat diprediksi.

Item ini mungkin disertakan secara default. Perhatikan baik-baik untuk melihat apakah mereka mengaktifkannya secara default. Ini bisa menjadi masalah yang sangat besar.

Dan pada akhirnya, saya ingin mengucapkan terima kasih kepada orang-orang dari tim DBA Konsultasi PosgreSQL kami, yaitu Max Boguk dan Alexei Lesovsky, yang membuat kemajuan dalam hal ini setiap hari. Dan kami berusaha melakukan yang terbaik yang kami bisa untuk klien kami sehingga semuanya berhasil untuk mereka. Ini seperti instruksi keselamatan penerbangan. Segala sesuatu di sini ditulis dengan darah. Masing-masing kacang ini ditemukan dalam proses suatu masalah. Saya senang membaginya dengan Anda.

Pertanyaan:

Terima kasih! Jika, misalnya, sebuah perusahaan ingin menghemat uang dan menempatkan database dan logika aplikasi di satu server, atau jika perusahaan mengikuti tren arsitektur layanan mikro yang modis, di mana PostgreSQL berjalan dalam sebuah container. Apa triknya? Sysctl akan mempengaruhi seluruh kernel secara global. Saya belum pernah mendengar sysctl divirtualisasikan sehingga berfungsi secara terpisah pada sebuah wadah. Hanya ada cgroup dan hanya ada sebagian kendali disana. Bagaimana Anda bisa hidup dengan ini? Atau jika Anda menginginkan kinerja, jalankan PostgreSQL di server perangkat keras terpisah dan sesuaikan?

Kami menjawab pertanyaan Anda dalam tiga cara. Jika kita tidak berbicara tentang server perangkat keras yang dapat disetel, dll., santai saja, semuanya akan berfungsi dengan baik tanpa pengaturan ini. Jika Anda memiliki beban sedemikian rupa sehingga Anda perlu membuat pengaturan ini, maka Anda akan datang ke server besi lebih awal daripada pengaturan ini.

Apa masalahnya? Jika ini adalah mesin virtual, kemungkinan besar Anda akan mengalami banyak masalah, misalnya, dengan kenyataan bahwa pada sebagian besar mesin virtual, latensi disk sangat tidak konsisten. Bahkan jika throughput disk baik, kemudian satu transaksi I/O gagal yang tidak terlalu mempengaruhi rata-rata throughput yang terjadi pada saat checkpoint atau pada saat penulisan ke WAL, maka database akan sangat menderita karenanya. Dan Anda akan menyadarinya sebelum Anda mengalami masalah ini.

Jika Anda memiliki NGINX di server yang sama, Anda juga akan mengalami masalah yang sama. Dia akan berjuang untuk memori bersama. Dan Anda tidak akan membahas masalah yang dijelaskan di sini.

Namun di sisi lain, beberapa parameter ini akan tetap relevan bagi Anda. Misalnya, atur dirty_ratio dengan sysctl agar tidak terlalu gila - bagaimanapun, ini akan membantu. Dengan satu atau lain cara, Anda akan berinteraksi dengan disk. Dan itu akan terjadi menurut pola yang salah. Ini umumnya merupakan default untuk parameter yang saya tunjukkan. Dan bagaimanapun juga, lebih baik mengubahnya.

Namun mungkin ada masalah dengan NUMA. VmWare, misalnya, bekerja dengan baik dengan NUMA dengan pengaturan yang berlawanan. Dan di sini Anda harus memilih - server besi atau server non-besi.

Saya punya pertanyaan terkait Amazon AWS. Mereka memiliki gambar yang telah dikonfigurasi sebelumnya. Salah satunya disebut Amazon RDS. Apakah ada pengaturan khusus untuk sistem operasi mereka?

Memang ada pengaturannya, tapi pengaturannya berbeda. Di sini kita mengkonfigurasi sistem operasi dalam hal bagaimana database akan menggunakan hal ini. Dan ada parameter yang menentukan kemana kita harus pergi sekarang, seperti pembentukan. Artinya, kita memerlukan begitu banyak sumber daya, sekarang kita akan memakannya habis. Setelah ini, Amazon RDS memperketat sumber daya ini, dan kinerja menurun di sana. Ada cerita tersendiri tentang bagaimana orang-orang mulai mengacaukan masalah ini. Bahkan terkadang cukup berhasil. Tapi ini tidak ada hubungannya dengan pengaturan OS. Ini seperti meretas cloud. Itu cerita yang berbeda.

Mengapa halaman transparan besar tidak berpengaruh dibandingkan dengan TLB besar?

Jangan berikan. Hal ini dapat dijelaskan dengan banyak cara. Namun nyatanya mereka tidak memberikannya. Bagaimana sejarah PostgreSQL? Saat startup, ia mengalokasikan sebagian besar memori bersama. Transparan atau tidaknya sama sekali tidak relevan. Fakta bahwa mereka menonjol pada awalnya menjelaskan segalanya. Dan jika ada banyak memori dan Anda perlu membangun kembali segmen shared_memory, maka halaman transparan yang besar akan relevan. Di PostgreSQL, itu hanya dialokasikan dalam jumlah besar di awal dan hanya itu, dan kemudian tidak ada hal istimewa yang terjadi di sana. Anda tentu saja dapat menggunakannya, tetapi ada kemungkinan shared_memory rusak saat mengalokasikan ulang sesuatu. PostgreSQL tidak mengetahui hal ini.

Sumber: www.habr.com