Penalaan Linux untuk meningkatkan prestasi PostgreSQL. Ilya Kosmodemyansky

Transkrip laporan 2015 oleh Ilya Kosmodemyansky "Penalaan Linux untuk meningkatkan prestasi PostgreSQL"

Penafian: Saya ambil perhatian bahawa laporan ini bertarikh November 2015 - lebih daripada 4 tahun telah berlalu dan banyak masa telah berlalu. Versi 9.4 yang dibincangkan dalam laporan tidak lagi disokong. Sepanjang 4 tahun yang lalu, 5 keluaran baharu PostgreSQL telah dikeluarkan, dan 15 versi kernel Linux telah dikeluarkan. Jika anda menulis semula petikan ini, anda akan mendapat laporan yang berbeza. Tetapi di sini kami mempertimbangkan penalaan Linux asas untuk PostgreSQL, yang masih relevan hari ini.

Nama saya Ilya Kosmodemyansky. Saya bekerja di PostgreSQL-Consulting. Dan sekarang saya akan bercakap sedikit tentang apa yang perlu dilakukan dengan Linux berhubung dengan pangkalan data secara umum dan PostgreSQL khususnya, kerana prinsipnya agak serupa.

Apa yang akan kita bincangkan? Jika anda berkomunikasi dengan PostgreSQL, maka sedikit sebanyak anda perlu menjadi pentadbir UNIX. Apakah maksudnya? Jika kita membandingkan Oracle dan PostgreSQL, maka dalam Oracle anda perlu menjadi 80% pentadbir pangkalan data DBA dan 20% pentadbir Linux.

Dengan PostgreSQL ia sedikit lebih rumit. Dengan PostgreSQL anda perlu mempunyai pemahaman yang lebih baik tentang cara Linux berfungsi. Dan pada masa yang sama, berlari sedikit selepas lokomotif, kerana kebelakangan ini semuanya telah dikemas kini dengan agak baik. Dan kernel baharu dikeluarkan, dan fungsi baharu muncul, prestasi bertambah baik, dsb.

Mengapa kita bercakap tentang Linux? Bukan sama sekali kerana kami berada di persidangan Linux Peter, tetapi kerana dalam keadaan moden salah satu sistem pengendalian yang paling wajar untuk menggunakan pangkalan data secara umum dan PostgreSQL khususnya adalah Linux. Kerana FreeBSD, malangnya, berkembang dalam arah yang sangat pelik. Dan akan ada masalah dengan prestasi dan dengan banyak perkara lain. Prestasi PostgreSQL pada Windows secara amnya merupakan isu serius yang berasingan, berdasarkan fakta bahawa Windows tidak mempunyai memori bersama yang sama seperti UNIX, manakala PostgreSQL semuanya terikat dengan ini, kerana ia adalah sistem berbilang proses.

Dan saya rasa semua orang kurang berminat dengan eksotik seperti Solaris, jadi mari kita pergi.

Pengedaran Linux moden mempunyai lebih 1 pilihan syctl, bergantung pada cara anda membina kernel. Pada masa yang sama, jika kita melihat kacang yang berbeza, kita boleh menyesuaikan sesuatu dalam pelbagai cara. Terdapat parameter sistem fail tentang cara melekapkannya. Jika anda mempunyai soalan tentang cara memulakannya: apa yang perlu didayakan dalam BIOS, cara mengkonfigurasi perkakasan, dsb.

Ini adalah volum yang sangat besar yang boleh dibincangkan selama beberapa hari, dan bukan dalam satu laporan ringkas, tetapi sekarang saya akan memberi tumpuan kepada perkara penting, bagaimana untuk mengelakkan rake yang dijamin menghalang anda daripada menggunakan pangkalan data anda dengan baik di Linux jika anda jangan betulkan mereka. Dan pada masa yang sama, perkara penting ialah banyak parameter lalai tidak termasuk dalam tetapan yang betul untuk pangkalan data. Iaitu, secara lalai ia akan berfungsi dengan buruk atau tidak sama sekali.

Apakah sasaran penalaan tradisional yang terdapat di Linux? Saya fikir memandangkan anda semua berurusan dengan pentadbiran Linux, tidak ada keperluan khusus untuk menerangkan sasaran itu.

Anda boleh menala:

• CPU.
• Ingatan.
• Penyimpanan.
• Lain-lain. Kita akan bercakap tentang ini pada penghujung untuk snek. Malah, sebagai contoh, parameter seperti dasar penjimatan tenaga boleh menjejaskan prestasi dengan cara yang sangat tidak dapat diramalkan dan bukan cara yang paling menyenangkan.

Apakah spesifikasi PostgreSQL dan pangkalan data secara umum? Masalahnya ialah anda tidak boleh mengubah suai mana-mana kacang individu dan melihat bahawa prestasi kami telah meningkat dengan ketara.

Ya, terdapat alat sedemikian, tetapi pangkalan data adalah perkara yang kompleks. Ia berinteraksi dengan semua sumber yang ada pada pelayan dan lebih suka berinteraksi sepenuhnya. Jika anda melihat cadangan semasa Oracle tentang cara menggunakan OS hos, ia akan menjadi seperti jenaka tentang angkasawan Mongolia itu - beri makan anjing itu dan jangan sentuh apa-apa. Mari kita berikan pangkalan data semua sumber, pangkalan data itu sendiri akan menyusun segala-galanya.

Pada dasarnya, sedikit sebanyak keadaannya adalah sama dengan PostgreSQL. Perbezaannya ialah pangkalan data masih belum dapat mengambil semua sumber untuk dirinya sendiri, iaitu di suatu tempat di peringkat Linux anda perlu menyusun semuanya sendiri.

Idea utama bukanlah untuk memilih satu sasaran dan mula menalanya, sebagai contoh, memori, CPU atau sesuatu seperti itu, tetapi untuk menganalisis beban kerja dan cuba meningkatkan daya pemprosesan sebanyak mungkin supaya beban yang dicipta oleh pengaturcara yang baik. untuk kami, termasuk pengguna kami.

Berikut adalah gambar untuk menerangkan apa itu. Terdapat penimbal OS Linux dan terdapat memori dikongsi dan terdapat penimbal dikongsi PostgreSQL. PostgreSQL, tidak seperti Oracle, berfungsi secara langsung hanya melalui penimbal kernel, iaitu, untuk halaman dari cakera untuk masuk ke dalam memori kongsinya, ia mesti melalui penimbal kernel dan kembali, situasi yang sama.

Cakera hidup di bawah sistem ini. Saya melukis ini sebagai cakera. Malah, mungkin terdapat pengawal RAID, dsb.

Dan input-output ini satu cara atau yang lain berlaku melalui perkara ini.

PostgreSQL ialah pangkalan data klasik. Terdapat halaman di dalam. Dan semua input dan output berlaku menggunakan halaman. Kami meningkatkan blok ke dalam ingatan dengan halaman. Dan jika tiada apa-apa yang berlaku, kami hanya membacanya, kemudian secara beransur-ansur ia hilang dari cache ini, dari penimbal yang dikongsi dan berakhir kembali pada cakera.

Jika kita menggantikan sesuatu di suatu tempat, maka keseluruhan halaman ditandakan sebagai kotor. Saya menandakan mereka di sini dengan warna biru. Dan ini bermakna halaman ini mesti disegerakkan dengan storan blok. Maksudnya, bila kita buat kotor, kita buat entry dalam WAL. Dan pada masa yang indah, fenomena yang dipanggil pusat pemeriksaan datang. Dan maklumat telah direkodkan dalam log ini bahawa dia telah tiba. Dan ini bermakna bahawa semua halaman kotor yang berada di sini pada masa itu dalam penimbal kongsi ini telah disegerakkan dengan cakera storan menggunakan fsync melalui penimbal kernel.

Mengapa ini dilakukan? Jika kami kehilangan voltan, maka kami tidak mendapat situasi bahawa semua data telah hilang. Memori yang berterusan, yang semua orang memberitahu kami, sejauh ini dalam teori pangkalan data - ini adalah masa depan yang cerah, yang kami, sudah tentu, berusaha dan kami menyukainya, tetapi buat masa ini mereka hidup dalam tolak 20 tahun. Dan, sudah tentu, semua ini perlu dipantau.

Dan tugas memaksimumkan daya tampung adalah untuk memperhalusi semua peringkat ini supaya semuanya bergerak ke sana ke mari dengan cepat. Memori yang dikongsi pada asasnya ialah cache halaman. Dalam PostgreSQL kami menghantar pertanyaan pilih atau sesuatu, ia mendapatkan semula data ini daripada cakera. Mereka berakhir dalam penimbal yang dikongsi. Oleh itu, untuk ini berfungsi dengan lebih baik, mesti ada banyak ingatan.

Agar semua ini berfungsi dengan baik dan cepat, anda perlu mengkonfigurasi sistem pengendalian dengan betul pada semua peringkat. Dan pilih perkakasan yang seimbang, kerana jika anda mempunyai ketidakseimbangan di beberapa tempat, maka anda boleh membuat banyak memori, tetapi ia tidak akan diservis pada kelajuan yang mencukupi.

Dan mari kita melalui setiap titik ini.

Untuk menjadikan halaman ini berulang alik dengan lebih pantas, anda perlu mencapai perkara berikut:

• Pertama, anda perlu bekerja dengan lebih cekap dengan ingatan.
• Kedua, peralihan ini apabila halaman dari memori pergi ke cakera sepatutnya lebih cekap.
• Dan ketiga, mesti ada cakera yang baik.

Jika anda mempunyai 512 GB RAM dalam pelayan dan semuanya berakhir pada pemacu keras SATA tanpa sebarang cache, maka keseluruhan pelayan pangkalan data bertukar menjadi bukan sahaja labu, tetapi labu dengan antara muka SATA. Anda akan menghadapinya secara langsung. Dan tiada apa yang akan menyelamatkan anda.

Mengenai titik pertama dengan ingatan, terdapat tiga perkara yang boleh menyukarkan hidup.

Yang pertama ialah NUMA. NUMA adalah perkara yang dibuat untuk meningkatkan prestasi. Bergantung pada beban kerja, perkara yang berbeza boleh dioptimumkan. Dan dalam bentuk terkininya yang baharu, ia tidak begitu baik untuk aplikasi seperti pangkalan data yang secara intensif menggunakan penimbal kongsi cache halaman.

Secara ringkas. Bagaimanakah anda boleh mengetahui jika ada sesuatu yang tidak kena dengan NUMA? Anda mengalami beberapa jenis ketukan yang tidak menyenangkan, tiba-tiba beberapa CPU terlebih beban. Pada masa yang sama, anda menganalisis pertanyaan dalam PostgreSQL dan melihat bahawa tiada apa-apa yang serupa di sana. Pertanyaan ini seharusnya tidak terlalu intensif CPU. Anda boleh menangkap ini untuk masa yang lama. Lebih mudah untuk menggunakan pengesyoran yang betul dari awal lagi tentang cara mengkonfigurasi NUMA untuk PostgreSQL.

Apa sebenarnya yang berlaku? NUMA adalah singkatan kepada Non-Uniform Memory Access. Apa gunanya? Anda mempunyai CPU, di sebelahnya terdapat memori tempatannya. Dan memori ini saling bersambung boleh menarik memori daripada CPU lain.

Jika anda berlari numactl --hardware, maka anda akan mendapat helaian yang begitu besar. Antara lain, akan ada medan jarak. Akan ada nombor - 10-20, sesuatu seperti itu. Nombor ini tidak lebih daripada bilangan lompatan untuk mengambil memori jauh ini dan menggunakannya secara setempat. Pada dasarnya, idea yang baik. Ini mempercepatkan prestasi dengan baik di bawah pelbagai beban kerja.

Sekarang bayangkan bahawa anda mempunyai satu CPU mula-mula cuba menggunakan memori tempatannya, kemudian cuba menarik memori lain melalui sambungan untuk sesuatu. Dan CPU ini mendapat keseluruhan cache halaman PostgreSQL anda - itu sahaja, beberapa gigabait. Anda sentiasa mendapat kes terburuk, kerana pada CPU biasanya terdapat sedikit memori dalam modul itu sendiri. Dan semua memori yang diservis melalui sambungan ini. Ternyata perlahan dan sedih. Dan pemproses anda yang menyediakan nod ini sentiasa terlebih beban. Dan masa capaian memori ini adalah buruk, perlahan. Ini adalah situasi yang anda tidak mahu jika anda menggunakan ini untuk pangkalan data.

Oleh itu, pilihan yang lebih tepat untuk pangkalan data adalah untuk sistem pengendalian Linux tidak tahu apa yang berlaku di sana sama sekali. Supaya ia mengakses memori seperti yang dilakukannya.

Kenapa begitu? Nampaknya ia sepatutnya sebaliknya. Ini berlaku untuk satu sebab mudah: kita memerlukan banyak memori untuk cache halaman - puluhan, ratusan gigabait.

Dan jika kami memperuntukkan semua ini dan men-cache data kami di sana, maka keuntungan daripada menggunakan cache akan jauh lebih besar daripada keuntungan daripada akses yang rumit kepada ingatan. Oleh itu, kami akan mendapat manfaat yang tidak dapat dibandingkan dengan fakta bahawa kami akan mengakses memori dengan lebih cekap menggunakan NUMA.

Oleh itu, terdapat dua pendekatan di sini pada masa ini, sehingga masa depan yang cerah telah tiba, dan pangkalan data itu sendiri tidak dapat mengetahui CPU yang mana ia sedang berjalan dan dari mana ia perlu menarik sesuatu.

Oleh itu, pendekatan yang betul adalah untuk melumpuhkan NUMA sama sekali, sebagai contoh, apabila but semula. Dalam kebanyakan kes, kemenangan adalah dalam urutan magnitud sedemikian sehingga persoalan mana yang lebih baik tidak timbul sama sekali.

Ada pilihan lain. Kami menggunakannya lebih kerap daripada yang pertama, kerana apabila pelanggan datang kepada kami untuk mendapatkan sokongan, but semula pelayan adalah masalah besar baginya. Dia ada urusan di sana. Dan mereka mengalami masalah kerana NUMA. Oleh itu, kami cuba melumpuhkannya dengan cara yang kurang invasif berbanding but semula, tetapi berhati-hati untuk memastikan ia dilumpuhkan. Kerana, seperti yang ditunjukkan oleh pengalaman, ada baiknya kami melumpuhkan NUMA pada proses PostgreSQL induk, tetapi tidak semestinya ia akan berfungsi. Kita perlu menyemak dan melihat bahawa dia benar-benar dimatikan.

Terdapat jawatan yang baik oleh Robert Haas. Ini adalah salah satu daripada committer PostgreSQL. Salah satu pembangun utama semua giblet peringkat rendah. Dan jika anda mengikuti pautan dari siaran ini, mereka menerangkan beberapa cerita berwarna-warni tentang bagaimana NUMA menyusahkan orang ramai. Lihat, kaji senarai semak pentadbir sistem tentang perkara yang perlu dikonfigurasikan pada pelayan agar pangkalan data kami berfungsi dengan baik. Tetapan ini perlu ditulis dan disemak, kerana jika tidak, ia tidak akan menjadi sangat baik.

Sila ambil perhatian bahawa ini terpakai pada semua tetapan yang akan saya bincangkan. Tetapi biasanya pangkalan data dikumpul dalam mod tuan-hamba untuk toleransi kesalahan. Jangan lupa untuk membuat tetapan ini pada hamba kerana suatu hari nanti anda akan mengalami kemalangan dan anda akan bertukar kepada hamba dan ia akan menjadi tuan.

Dalam keadaan kecemasan, apabila segala-galanya sangat teruk, telefon anda sentiasa berdering dan bos anda datang berlari dengan kayu besar, anda tidak akan mempunyai masa untuk berfikir tentang menyemak. Dan hasilnya boleh menjadi sangat buruk.

Perkara seterusnya ialah halaman yang besar. Halaman yang besar sukar untuk diuji secara berasingan, dan tidak ada gunanya berbuat demikian, walaupun terdapat penanda aras yang boleh melakukan ini. Mereka mudah untuk Google.

Apa gunanya? Anda mempunyai pelayan yang tidak terlalu mahal dengan RAM yang banyak, contohnya, lebih daripada 30 GB. Anda tidak menggunakan halaman yang besar. Ini bermakna anda pasti mempunyai overhed dari segi penggunaan memori. Dan overhed ini jauh dari yang paling menyenangkan.

Kenapa begitu? Jadi apa yang berlaku? Sistem pengendalian memperuntukkan memori dalam kepingan kecil. Ia sangat mudah, begitulah ia berlaku dari segi sejarah. Dan jika kita pergi secara terperinci, OS mesti menterjemah alamat maya kepada alamat fizikal. Dan proses ini bukanlah yang paling mudah, jadi OS menyimpan cache hasil operasi ini dalam Penimbalan Lookaside Terjemahan (TLB).

Dan kerana TLB ialah cache, semua masalah yang wujud dalam cache timbul dalam situasi ini. Pertama, jika anda mempunyai banyak RAM dan semuanya diperuntukkan dalam ketulan kecil, maka penimbal ini menjadi sangat besar. Dan jika cache adalah besar, maka carian melaluinya adalah lebih perlahan. Overhed adalah sihat dan ia sendiri mengambil ruang, iaitu RAM sedang digunakan oleh sesuatu yang tidak betul. Kali ini.

Dua - semakin banyak cache berkembang dalam keadaan sedemikian, semakin besar kemungkinan anda akan mengalami kehilangan cache. Dan kecekapan cache ini berkurangan dengan cepat apabila saiznya bertambah. Oleh itu, sistem pengendalian datang dengan pendekatan yang mudah. Ia telah digunakan dalam Linux untuk masa yang lama. Ia muncul dalam FreeBSD tidak lama dahulu. Tetapi kita bercakap tentang Linux. Ini adalah halaman yang besar.

Dan di sini perlu diperhatikan bahawa halaman besar, sebagai idea, pada mulanya didorong oleh komuniti yang termasuk Oracle dan IBM, iaitu pengeluar pangkalan data sangat berpendapat bahawa ini akan berguna untuk pangkalan data juga.

Dan bagaimana ini boleh berkawan dengan PostgreSQL? Pertama, halaman besar mesti didayakan dalam kernel Linux.

Kedua, mereka mesti dinyatakan secara eksplisit oleh parameter sysctl - berapa banyak yang ada. Nombor di sini adalah dari beberapa pelayan lama. Anda boleh mengira bilangan penimbal kongsi yang anda miliki supaya halaman besar boleh dimuatkan di sana.

Dan jika keseluruhan pelayan anda didedikasikan untuk PostgreSQL, maka titik permulaan yang baik adalah untuk memperuntukkan sama ada 25% daripada RAM kepada penimbal yang dikongsi, atau 75% jika anda pasti bahawa pangkalan data anda pasti sesuai dengan 75%. Titik permulaan satu. Dan pertimbangkan, jika anda mempunyai 256 GB RAM, maka, sewajarnya, anda akan mempunyai 64 GB penampan besar. Kira kira-kira dengan sedikit jidar - angka ini harus ditetapkan.

Sebelum versi 9.2 (jika tidak silap saya, sejak versi 8.2), adalah mungkin untuk menyambungkan PostgreSQL dengan halaman besar menggunakan perpustakaan pihak ketiga. Dan ini harus selalu dilakukan. Pertama, anda memerlukan kernel untuk dapat memperuntukkan halaman besar dengan betul. Dan, kedua, supaya aplikasi yang berfungsi dengan mereka boleh menggunakannya. Ia tidak akan digunakan begitu sahaja. Oleh kerana PostgreSQL memperuntukkan memori dalam gaya sistem 5, ini boleh dilakukan menggunakan libhugetlbfs - ini ialah nama penuh perpustakaan.

Dalam 9.3, prestasi PostgreSQL telah dipertingkatkan apabila bekerja dengan memori dan kaedah peruntukan memori sistem 5 telah ditinggalkan. Semua orang sangat gembira, kerana jika tidak, anda cuba menjalankan dua contoh PostgreSQL pada satu mesin, dan dia mengatakan bahawa saya tidak mempunyai memori kongsi yang mencukupi. Dan dia mengatakan bahawa sysctl perlu diperbetulkan. Dan terdapat sysctl sedemikian yang anda masih perlu but semula, dll. Secara umum, semua orang gembira. Tetapi peruntukan memori mmap mematahkan penggunaan halaman yang besar. Kebanyakan pelanggan kami menggunakan penimbal kongsi yang besar. Dan kami sangat mengesyorkan untuk tidak beralih kepada 9.3, kerana overhed di sana mula dikira dalam peratusan yang baik.

Tetapi masyarakat memberi perhatian kepada masalah ini dan dalam 9.4 mereka mengolah semula acara ini dengan baik. Dan dalam 9.4 parameter muncul dalam postgresql.conf di mana anda boleh mendayakan cuba, hidupkan atau matikan.

Cuba adalah pilihan paling selamat. Apabila PostgreSQL bermula, apabila ia memperuntukkan memori yang dikongsi, ia cuba merebut memori ini dari halaman yang besar. Dan jika ia tidak berfungsi, maka ia akan kembali ke pemilihan biasa. Dan jika anda mempunyai FreeBSD atau Solaris, maka anda boleh mencuba, ia sentiasa selamat.

Jika dihidupkan, maka ia tidak akan bermula jika ia tidak dapat memilih daripada halaman yang besar. Di sini sudah mengenai siapa dan apa yang lebih bagus. Tetapi jika anda telah mencuba, maka semak bahawa anda benar-benar mempunyai perkara yang anda perlukan untuk diserlahkan, kerana terdapat banyak ruang untuk kesilapan. Pada masa ini fungsi ini hanya berfungsi pada Linux.

Satu lagi nota kecil sebelum kita pergi lebih jauh. Halaman besar yang telus bukan lagi mengenai PostgreSQL. Dia tidak boleh menggunakannya secara normal. Dan dengan halaman besar Telus untuk beban kerja sedemikian, apabila sekeping besar memori dikongsi diperlukan, faedah hanya datang dengan jumlah yang sangat besar. Jika anda mempunyai terabait memori maka ini mungkin akan dimainkan. Jika kita bercakap tentang lebih banyak aplikasi setiap hari, apabila anda mempunyai 32, 64, 128, 256 GB memori pada mesin anda, maka halaman besar yang biasa adalah Ok, dan kami hanya melumpuhkan Transparent.

Dan perkara terakhir tentang ingatan tidak berkaitan langsung dengan fruitut, ia benar-benar boleh merosakkan hidup anda. Semua daya pengeluaran akan sangat dipengaruhi oleh fakta bahawa pelayan sentiasa bertukar-tukar.

Dan ini akan menjadi sangat tidak menyenangkan dalam beberapa cara. Dan masalah utama ialah kernel moden berkelakuan sedikit berbeza daripada kernel Linux lama. Dan perkara ini agak tidak menyenangkan untuk dipijak, kerana apabila kita bercakap tentang beberapa jenis kerja dengan swap, ia berakhir dengan ketibaan pembunuh OOM yang tidak tepat pada masanya. Dan pembunuh OOM, yang tidak tiba tepat pada masanya dan menjatuhkan PostgreSQL, adalah tidak menyenangkan. Semua orang akan tahu tentang ini, iaitu, sehingga pengguna terakhir.

Apa yang sedang berlaku? Anda mempunyai jumlah RAM yang besar di sana, semuanya berfungsi dengan baik. Tetapi atas sebab tertentu pelayan hang dalam pertukaran dan perlahan kerana ini. Nampaknya terdapat banyak ingatan, tetapi ini berlaku.

Sebelum ini, kami menasihatkan menetapkan vm.swappiness kepada sifar, iaitu melumpuhkan swap. Sebelum ini, nampaknya 32 GB RAM dan penimbal kongsi yang sepadan adalah jumlah yang besar. Tujuan utama swap adalah untuk mempunyai tempat untuk membuang kerak jika kita jatuh. Dan ia tidak lagi dipenuhi secara khusus. Dan kemudian apa yang anda akan lakukan dengan kerak ini? Ini adalah tugas yang tidak begitu jelas mengapa pertukaran diperlukan, terutamanya saiz sedemikian.

Tetapi dalam versi yang lebih moden, iaitu versi ketiga kernel, tingkah laku telah berubah. Dan jika anda menetapkan swap kepada sifar, iaitu mematikannya, kemudian lambat laun, walaupun terdapat sedikit RAM yang tinggal, pembunuh OOM akan datang kepada anda untuk membunuh pengguna yang paling intensif. Kerana dia akan menganggap bahawa dengan beban kerja seperti itu kita masih mempunyai sedikit lagi dan kita akan melompat keluar, iaitu, bukan untuk memakukan proses sistem, tetapi untuk memakukan sesuatu yang kurang penting. Yang kurang penting ini akan menjadi pengguna intensif memori bersama, iaitu tuan pos. Dan selepas itu ia akan menjadi baik jika pangkalannya tidak perlu dipulihkan.

Oleh itu, kini lalai, sejauh yang saya ingat, kebanyakan pengedaran berada di sekitar 6, iaitu pada titik mana anda harus mula menggunakan swap bergantung pada berapa banyak memori yang tinggal. Kami kini mengesyorkan menetapkan vm.swappiness = 1, kerana ini boleh mematikannya, tetapi tidak memberikan kesan yang sama seperti pembunuh OOM yang tiba-tiba tiba dan membunuh semuanya.

Apa yang akan datang? Apabila kita bercakap tentang prestasi pangkalan data dan secara beransur-ansur bergerak ke arah cakera, semua orang mula meraih kepala mereka. Kerana kebenaran bahawa cakera adalah perlahan dan ingatan yang cepat adalah biasa kepada semua orang dari zaman kanak-kanak. Dan semua orang tahu bahawa pangkalan data akan mempunyai masalah prestasi cakera.

Masalah prestasi PostgreSQL utama yang dikaitkan dengan lonjakan pusat pemeriksaan tidak berlaku kerana cakera perlahan. Ini berkemungkinan besar disebabkan oleh fakta bahawa memori dan lebar jalur cakera tidak seimbang. Walau bagaimanapun, mereka mungkin tidak seimbang di tempat yang berbeza. PostgreSQL tidak dikonfigurasikan, OS tidak dikonfigurasikan, perkakasan tidak dikonfigurasikan dan perkakasan tidak betul. Dan masalah ini tidak berlaku hanya jika semuanya berlaku seperti yang sepatutnya, iaitu sama ada tiada beban, atau tetapan dan perkakasan dipilih dengan baik.

Apakah itu dan bagaimana rupanya? Biasanya orang yang bekerja dengan PostgreSQL telah memasuki perkara ini lebih daripada sekali. Saya akan terangkan. Seperti yang saya katakan, PostgreSQL secara berkala membuat pusat pemeriksaan untuk membuang halaman kotor dalam memori kongsi ke cakera. Jika kita mempunyai sejumlah besar memori yang dikongsi, maka pusat pemeriksaan mula memberi kesan intensif pada cakera, kerana ia membuang halaman ini dengan fsync. Ia tiba dalam penimbal kernel dan ditulis ke cakera menggunakan fsync. Dan jika jumlah perniagaan ini besar, maka kita dapat melihat kesan yang tidak menyenangkan, iaitu penggunaan cakera yang sangat besar.

Di sini saya mempunyai dua gambar. Saya sekarang akan menerangkan apa itu. Ini adalah dua graf berkorelasi masa. Graf pertama ialah penggunaan cakera. Di sini ia mencapai hampir 90% pada masa ini. Jika anda mengalami kegagalan pangkalan data dengan cakera fizikal, dengan penggunaan pengawal RAID pada 90%, maka ini adalah berita buruk. Ini bermakna lebih sedikit dan ia akan mencapai 100 dan I/O akan berhenti.

Jika anda mempunyai tatasusunan cakera, maka ia adalah cerita yang sedikit berbeza. Ia bergantung pada cara ia dikonfigurasikan, jenis tatasusunannya, dsb.

Dan secara selari, graf daripada paparan postgres dalaman dikonfigurasikan di sini, yang memberitahu bagaimana pusat pemeriksaan berlaku. Dan warna hijau di sini menunjukkan berapa banyak penimbal, halaman kotor ini, pada masa itu tiba di pusat pemeriksaan ini untuk penyegerakan. Dan ini adalah perkara utama yang anda perlu tahu di sini. Kami melihat bahawa kami mempunyai banyak halaman di sini dan pada satu ketika kami mencapai papan, iaitu, kami menulis dan menulis, di sini sistem cakera jelas sangat sibuk. Dan pusat pemeriksaan kami mempunyai kesan yang sangat kuat pada cakera. Sebaik-baiknya, keadaan sepatutnya kelihatan lebih seperti ini, iaitu kami kurang rakaman di sini. Dan kita boleh membetulkannya dengan tetapan supaya ia akan terus menjadi seperti ini. Iaitu, kitar semula adalah kecil, tetapi di suatu tempat kami menulis sesuatu di sini.

Apakah yang perlu dilakukan untuk mengatasi masalah ini? Jika anda telah menghentikan IO di bawah pangkalan data, ini bermakna semua pengguna yang datang untuk memenuhi permintaan mereka akan menunggu.

Jika anda melihat dari sudut pandangan Linux, jika anda mengambil perkakasan yang baik, mengkonfigurasinya dengan betul, mengkonfigurasi PostgreSQL secara normal supaya ia menjadikan pusat pemeriksaan ini kurang kerap, menyebarkannya dari semasa ke semasa antara satu sama lain, kemudian anda melangkah ke parameter Debian lalai. Untuk kebanyakan pengedaran Linux, ini ialah gambar: vm.dirty_ratio=20, vm.dirty_background_ratio=10.

Apakah maksudnya? Satu syaitan flushing muncul dari kernel 2.6. Pdglush, bergantung kepada siapa yang menggunakan yang mana, yang terlibat dalam membuang latar belakang halaman kotor dari penimbal kernel dan membuang apabila perlu untuk membuang halaman kotor tidak kira apa, apabila membuang latar belakang tidak membantu.

Bilakah latar belakang datang? Apabila 10% daripada jumlah RAM yang tersedia pada pelayan diduduki oleh halaman kotor dalam penimbal kernel, fungsi hapus kira khas dipanggil di latar belakang. Mengapa ia latar belakang? Sebagai parameter, ia mengambil kira bilangan halaman untuk dihapus kira. Dan, katakan, dia menghapuskan N halaman. Dan untuk seketika perkara ini tertidur. Dan kemudian dia datang lagi dan menyalin beberapa halaman lagi.

Ini adalah cerita yang sangat mudah. Masalahnya di sini adalah seperti kolam renang, apabila ia menuang ke dalam satu paip, ia mengalir ke dalam yang lain. Pusat pemeriksaan kami tiba dan jika ia menghantar beberapa halaman kotor untuk dibuang, maka secara beransur-ansur semuanya akan diselesaikan dengan kemas dari pgflush penimbal kernel.

Jika halaman kotor ini terus terkumpul, ia terkumpul sehingga 20%, selepas itu keutamaan OS adalah untuk menghapuskan keseluruhannya ke cakera, kerana kuasa akan gagal dan semuanya akan menjadi buruk bagi kita. Kami akan kehilangan data ini, sebagai contoh.

Apa muslihatnya? Caranya ialah parameter di dunia moden ini adalah 20 dan 10% daripada jumlah RAM yang ada pada mesin, ia benar-benar dahsyat dari segi daya pemprosesan mana-mana sistem cakera yang anda miliki.

Bayangkan anda mempunyai 128 GB RAM. 12,8 GB tiba dalam sistem cakera anda. Dan tidak kira apa cache yang anda ada di sana, tidak kira apa susunan yang anda ada di sana, ia tidak akan bertahan selama itu.

Oleh itu, kami mengesyorkan agar anda segera melaraskan nombor ini berdasarkan keupayaan pengawal RAID anda. Saya segera membuat cadangan di sini untuk pengawal yang mempunyai 512 MB cache.

Semuanya dianggap sangat mudah. Anda boleh meletakkan vm.dirty_background dalam bait. Dan tetapan ini membatalkan dua yang sebelumnya. Sama ada nisbah adalah secara lalai, atau yang mempunyai bait diaktifkan, maka nisbah yang mempunyai bait akan berfungsi. Tetapi kerana saya seorang perunding DBA dan bekerja dengan pelanggan yang berbeza, saya cuba melukis penyedut minuman dan oleh itu, jika dalam bait, maka dalam bait. Tiada siapa yang memberi jaminan bahawa pentadbir yang baik tidak akan menambah lebih banyak memori pada pelayan, but semula, dan angka itu akan kekal sama. Hanya kira nombor ini supaya semuanya sesuai di sana dengan jaminan.

Apa yang berlaku jika anda tidak sesuai? Saya telah menulis bahawa sebarang pembilasan dihentikan dengan berkesan, tetapi sebenarnya ini adalah kiasan. Sistem pengendalian mempunyai masalah besar - ia mempunyai banyak halaman kotor, jadi IO yang dihasilkan oleh pelanggan anda dihentikan dengan berkesan, iaitu aplikasi telah datang untuk menghantar pertanyaan sql ke pangkalan data, ia sedang menunggu. Sebarang input/output kepadanya adalah keutamaan paling rendah, kerana pangkalan data diduduki oleh pusat pemeriksaan. Dan bila dia akan selesai, ia sama sekali tidak jelas. Dan apabila anda telah mencapai pembilasan bukan latar belakang, ini bermakna semua IO anda diduduki olehnya. Dan sehingga ia berakhir, anda tidak akan melakukan apa-apa.

Terdapat dua lagi perkara penting di sini yang berada di luar skop laporan ini. Tetapan ini harus sepadan dengan tetapan dalam postgresql.conf, iaitu tetapan pusat pemeriksaan. Dan sistem cakera anda mesti dikonfigurasikan dengan secukupnya. Jika anda mempunyai cache pada RAID, maka ia mesti mempunyai bateri. Orang ramai membeli RAID dengan cache yang baik tanpa bateri. Jika anda mempunyai SSD dalam RAID, maka ia mestilah pelayan, mesti ada kapasitor di sana. Berikut adalah senarai semak terperinci. Pautan ini mengandungi laporan saya tentang cara mengkonfigurasi cakera prestasi dalam PostgreSQL. Terdapat semua senarai semak ini di sana.

Apa lagi yang boleh menyusahkan hidup? Ini adalah dua parameter. Mereka agak baru. Secara lalai, ia boleh disertakan dalam aplikasi yang berbeza. Dan mereka boleh menyukarkan hidup jika dihidupkan secara tidak betul.

Terdapat dua perkara yang agak baru. Mereka telah pun muncul dalam teras ketiga. Ini ialah sched_migration_cost dalam nanosaat dan sched_autogroup_enabled, iaitu satu secara lalai.

Dan bagaimana mereka merosakkan hidup anda? Apakah kos_hijrah_jadual? Di Linux, penjadual boleh memindahkan proses dari satu CPU ke CPU yang lain. Dan untuk PostgreSQL, yang melaksanakan pertanyaan, berhijrah ke CPU lain adalah tidak jelas sama sekali. Dari sudut pandangan sistem pengendalian, apabila anda menukar tetingkap antara pejabat terbuka dan terminal, ini mungkin bagus, tetapi untuk pangkalan data ini sangat buruk. Oleh itu, dasar yang munasabah adalah untuk menetapkan migration_cost kepada beberapa nilai yang besar, sekurang-kurangnya beberapa ribu nanosaat.

Apakah maksud ini untuk penjadual? Ia akan dianggap bahawa pada masa ini proses masih panas. Iaitu, jika anda mempunyai urus niaga lama yang telah melakukan sesuatu untuk masa yang lama, penjadual akan memahami perkara ini. Dia akan menganggap bahawa sehingga tamat masa ini berlalu, proses ini tidak perlu dipindahkan ke mana-mana sahaja. Jika pada masa yang sama proses melakukan sesuatu, maka ia tidak akan dipindahkan ke mana-mana, ia akan berfungsi secara senyap pada CPU yang diperuntukkan kepadanya. Dan hasilnya sangat baik.

Titik kedua ialah autogroup. Terdapat idea yang baik untuk beban kerja tertentu yang tidak berkaitan dengan pangkalan data moden - ini adalah untuk mengumpulkan proses mengikut terminal maya dari mana ia dilancarkan. Ini mudah untuk beberapa tugas. Dalam amalan, PostgreSQL ialah sistem berbilang proses dengan prefork yang berjalan dari satu terminal. Anda mempunyai penulis kunci, pusat pemeriksaan dan semua permintaan pelanggan anda akan dikumpulkan ke dalam satu penjadual, setiap CPU. Dan mereka akan menunggu di sana serentak untuk dia bebas, untuk mengganggu satu sama lain dan membuat dia sibuk lebih lama. Ini adalah cerita yang tidak diperlukan sama sekali dalam kes beban sedemikian dan oleh itu ia perlu dimatikan.

Rakan sekerja saya Alexey Lesovsky melakukan ujian dengan pgbench mudah, di mana dia meningkatkan migration_cost mengikut urutan magnitud dan mematikan autogroup. Perbezaan pada perkakasan yang buruk adalah hampir 10%. Terdapat perbincangan mengenai senarai mel postgres di mana orang memberikan hasil perubahan yang serupa kepada kelajuan pertanyaan dipengaruhi 50%. Terdapat banyak cerita sebegitu.

Dan akhirnya, mengenai dasar penjimatan kuasa. Perkara yang baik ialah Linux kini boleh digunakan pada komputer riba. Dan ia kononnya akan menggunakan bateri dengan baik. Tetapi tiba-tiba ternyata ini juga boleh berlaku pada pelayan.

Lebih-lebih lagi, jika anda menyewa pelayan daripada beberapa hoster, maka hoster yang "baik" tidak peduli bahawa anda mempunyai prestasi yang lebih baik. Tugas mereka adalah untuk memastikan bahawa besi mereka digunakan dengan seefisien mungkin. Oleh itu, secara lalai mereka boleh mendayakan mod penjimatan kuasa komputer riba pada sistem pengendalian.

Jika anda menggunakan bahan ini pada pelayan dengan pangkalan data di bawah beban berat, maka pilihan anda ialah acpi_cpufreq + permormance. Walaupun dengan ondemand akan ada masalah.

Intel_pstate ialah pemacu yang sedikit berbeza. Dan sekarang keutamaan diberikan kepada yang ini, kerana ia kemudian dan berfungsi dengan lebih baik.

Dan, oleh itu, gabenor hanyalah prestasi. Ondemand, jimat kuasa dan segala-galanya bukan tentang anda.

Keputusan explain analysis PostgreSQL mungkin berbeza mengikut beberapa susunan magnitud jika anda mendayakan powersave, kerana secara praktikalnya CPU di bawah pangkalan data anda akan berjalan dengan cara yang tidak dapat diramalkan sepenuhnya.

Item ini mungkin disertakan secara lalai. Lihat dengan teliti untuk melihat sama ada mereka menghidupkannya secara lalai. Ini boleh menjadi masalah yang sangat besar.

Dan pada akhirnya, saya ingin mengucapkan terima kasih kepada lelaki dari pasukan DBA PosgreSQL-Consulting kami, iaitu Max Boguk dan Alexey Lesovsky, yang membuat kemajuan dalam perkara ini setiap hari. Dan kami cuba melakukan yang terbaik untuk pelanggan kami supaya semuanya berfungsi untuk mereka. Ia seperti arahan keselamatan penerbangan. Semuanya di sini ditulis dalam darah. Setiap kacang ini ditemui dalam proses beberapa jenis masalah. Saya gembira untuk berkongsi dengan anda.

Soalan:

Terima kasih! Jika, sebagai contoh, sebuah syarikat ingin menjimatkan wang dan meletakkan pangkalan data dan logik aplikasi pada satu pelayan, atau jika syarikat itu mengikuti trend bergaya seni bina perkhidmatan mikro, di mana PostgreSQL dijalankan dalam bekas. Apa muslihatnya? Sysctl akan menjejaskan keseluruhan kernel secara global. Saya tidak pernah mendengar tentang sysctls entah bagaimana dimayakan supaya ia berfungsi secara berasingan pada bekas. Hanya ada cgroup dan hanya ada sebahagian daripada kawalan di sana. Bagaimana anda boleh hidup dengan ini? Atau jika anda mahukan prestasi, kemudian jalankan PostgreSQL pada pelayan perkakasan yang berasingan dan talakannya?

Kami menjawab soalan anda dalam kira-kira tiga cara. Jika kita tidak bercakap tentang pelayan perkakasan yang boleh ditala, dsb., kemudian berehat, semuanya akan berfungsi dengan baik tanpa tetapan ini. Jika anda mempunyai beban sedemikian sehingga anda perlu membuat tetapan ini, maka anda akan datang ke pelayan besi lebih awal daripada tetapan ini.

Apa masalahnya? Jika ini adalah mesin maya, kemungkinan besar anda akan menghadapi banyak masalah, contohnya, dengan fakta bahawa pada kebanyakan mesin maya kependaman cakera agak tidak konsisten. Walaupun daya tampung cakera adalah baik, maka satu transaksi I/O yang gagal yang tidak banyak mempengaruhi daya tampung purata yang berlaku pada masa pemeriksaan atau semasa menulis kepada WAL, maka pangkalan data akan mengalami masalah ini. Dan anda akan melihat ini sebelum anda menghadapi masalah ini.

Jika anda mempunyai NGINX pada pelayan yang sama, anda juga akan mengalami masalah yang sama. Dia akan berjuang untuk ingatan bersama. Dan anda tidak akan sampai kepada masalah yang diterangkan di sini.

Tetapi sebaliknya, beberapa parameter ini masih berkaitan dengan anda. Sebagai contoh, tetapkan dirty_ratio dengan sysctl supaya ia tidak begitu gila - dalam apa jua keadaan, ini akan membantu. Satu cara atau yang lain, anda akan mempunyai interaksi dengan cakera. Dan ia akan mengikut corak yang salah. Ini biasanya lalai untuk parameter yang saya tunjukkan. Dan dalam apa jua keadaan adalah lebih baik untuk mengubahnya.

Tetapi mungkin terdapat masalah dengan NUMA. VmWare, sebagai contoh, berfungsi dengan baik dengan NUMA dengan tetapan yang bertentangan. Dan di sini anda perlu memilih - pelayan besi atau bukan besi.

Saya mempunyai soalan berkaitan Amazon AWS. Mereka mempunyai imej yang diprakonfigurasikan. Salah satunya dipanggil Amazon RDS. Adakah terdapat sebarang tetapan tersuai untuk sistem pengendalian mereka?

Terdapat tetapan di sana, tetapi tetapan itu berbeza. Di sini kami mengkonfigurasi sistem pengendalian dari segi bagaimana pangkalan data akan menggunakan perkara ini. Dan terdapat parameter yang menentukan ke mana kita harus pergi sekarang, seperti membentuk. Iaitu, kita memerlukan begitu banyak sumber, kita kini akan memakannya. Selepas ini, Amazon RDS mengetatkan sumber ini, dan prestasi menurun di sana. Terdapat cerita individu tentang bagaimana orang mula kacau dengan perkara ini. Kadang-kadang agak berjaya. Tetapi ini tiada kaitan dengan tetapan OS. Ia seperti menggodam awan. Itu cerita yang berbeza.

Mengapa halaman besar Telus tidak mempunyai kesan berbanding dengan TLB Besar?

Jangan beri. Ini boleh dijelaskan dalam pelbagai cara. Tetapi sebenarnya mereka tidak memberikannya. Apakah sejarah PostgreSQL? Pada permulaan, ia memperuntukkan sekeping besar memori bersama. Sama ada mereka telus atau tidak adalah tidak relevan sama sekali. Hakikat bahawa mereka menonjol pada permulaan menjelaskan segala-galanya. Dan jika terdapat banyak memori dan anda perlu membina semula segmen shared_memory, maka halaman besar Telus akan menjadi relevan. Dalam PostgreSQL, ia hanya diperuntukkan dalam sebahagian besar pada permulaan dan itu sahaja, dan kemudian tiada perkara istimewa berlaku di sana. Anda boleh, sudah tentu, menggunakannya, tetapi terdapat peluang untuk mendapat rasuah shared_memory apabila ia memperuntukkan semula sesuatu. PostgreSQL tidak tahu tentang ini.

Sumber: www.habr.com