Transkrip laporan 2015 dening Ilya Kosmodemyansky "Linux tuning kanggo nambah kinerja PostgreSQL"
Penafian: Aku nyathet yen laporan iki tanggal November 2015 - luwih saka 4 taun wis liwati lan akeh wektu wis liwati. Versi 9.4 sing dibahas ing laporan ora didhukung maneh. Sajrone 4 taun kepungkur, 5 rilis PostgreSQL anyar wis dirilis, lan 15 versi kernel Linux wis dirilis. Yen sampeyan nulis maneh wacana kasebut, sampeyan bakal entuk laporan sing beda. Nanging ing kene kita nimbang tuning Linux dhasar kanggo PostgreSQL, sing isih relevan saiki.
Jenengku Ilya Kosmodemyansky. Aku kerja ing PostgreSQL-Consulting. Lan saiki aku bakal ngomong sethithik babagan apa sing kudu dilakoni karo Linux ing hubungane karo basis data umum lan PostgreSQL khususe, amarga prinsip-prinsip kasebut meh padha.
Apa sing bakal kita guneman? Yen sampeyan komunikasi karo PostgreSQL, mula sampeyan kudu dadi admin UNIX. Iki artine apa? Yen kita mbandhingake Oracle lan PostgreSQL, banjur ing Oracle sampeyan kudu dadi 80% admin database DBA lan 20% admin Linux.
Kanthi PostgreSQL, iku luwih rumit. Kanthi PostgreSQL sampeyan kudu duwe pangerten sing luwih apik babagan cara kerja Linux. Lan ing wektu sing padha, mlaku sethithik sawise lokomotif, amarga akhir-akhir iki kabeh wis dianyari kanthi apik. Lan kernel anyar dirilis, lan fungsi anyar katon, kinerja nambah, etc.
Napa kita ngomong babagan Linux? Ora kabeh amarga kita ana ing konferensi Linux Peter, nanging amarga ing kahanan modern salah siji saka sistem operasi paling sabdho kanggo nggunakake database ing umum lan PostgreSQL utamané Linux. Amarga FreeBSD, sayangé, berkembang ing sawetara arah sing aneh banget. Lan bakal ana masalah karo kinerja lan akeh perkara liyane. Kinerja PostgreSQL ing Windows umume minangka masalah serius sing kapisah, adhedhasar kasunyatan manawa Windows ora duwe memori sing padha karo UNIX, dene PostgreSQL kabeh ana gandhengane karo iki, amarga iku sistem multi-proses.
Lan aku mikir kabeh wong kurang kasengsem ing eksotik kaya Solaris, mula ayo.
Distribusi Linux modern duwe luwih saka 1 opsi syctl, gumantung carane sampeyan mbangun kernel. Ing wektu sing padha, yen kita ndeleng macem-macem kacang, kita bisa nyetel macem-macem cara. Ana paramèter sistem file babagan carane nginstal. Yen sampeyan duwe pitakon babagan carane miwiti: apa sing kudu diaktifake ing BIOS, carane ngatur hardware, lsp.
Iki minangka volume gedhe banget sing bisa dirembug sajrone pirang-pirang dina, lan ora ing siji laporan singkat, nanging saiki aku bakal fokus ing bab-bab sing penting, kepiye carane nyingkiri rake sing dijamin bakal nyegah sampeyan nggunakake database kanthi apik ing Linux yen sampeyan aja dibenerake. Lan ing wektu sing padha, titik penting yaiku akeh parameter standar sing ora kalebu ing setelan sing bener kanggo database. Tegese, kanthi standar bakal bisa digunakake kanthi ora apik utawa ora.
Apa target tuning tradisional sing ana ing Linux? Aku mikir yen sampeyan kabeh ngurusi administrasi Linux, ora ana prelu nerangake apa target.
Sampeyan bisa nyetel:
- CPU.
- Memori.
- Lumbung.
- Liyane. Kita bakal ngomong babagan iki ing pungkasan kanggo cemilan. Malah, contone, paramèter kayata kabijakan hemat energi bisa mengaruhi kinerja kanthi cara sing ora bisa ditebak lan dudu cara sing paling nyenengake.
Apa spesifik PostgreSQL lan database umume? Masalahe yaiku sampeyan ora bisa ngapiki kacang lan ndeleng manawa kinerja kita saya tambah akeh.
Ya, ana gadget kaya ngono, nanging database minangka perkara sing rumit. Iku sesambungan karo kabeh sumber daya sing server wis lan luwih seneng sesambungan kanggo kebekan. Yen sampeyan ndeleng rekomendasi Oracle saiki babagan cara nggunakake OS host, bakal kaya guyon babagan kosmonot Mongolia - Feed asu lan ora ndemek apa-apa. Ayo menehi database kabeh sumber daya, database dhewe bakal ngurutake kabeh.
Ing asas, kanggo sawetara ombone kahanan persis padha karo PostgreSQL. Bentenane yaiku database durung bisa njupuk kabeh sumber daya kanggo awake dhewe, yaiku ing endi wae ing tingkat Linux sampeyan kudu ngurutake kabeh dhewe.
Ide utama ora kanggo milih target siji lan miwiti tuning, contone, memori, CPU utawa liyane, nanging kanggo njelasno beban kerja lan nyoba kanggo nambah throughput sabisane supaya beban sing digawe programer apik. kanggo kita, kalebu pangguna.
Punika gambar kanggo nerangake apa iku. Ana buffer OS Linux lan ana memori sing dienggo bareng lan ana buffer sing dienggo bareng PostgreSQL. PostgreSQL, ora kaya Oracle, bisa langsung mung liwat buffer kernel, yaiku, supaya kaca saka disk bisa mlebu ing memori sing dienggo bareng, kudu ngliwati buffer kernel lan bali, kahanan sing padha.
Disk urip ing sistem iki. Aku nggambar iki minangka disk. Nyatane, bisa uga ana pengontrol RAID, lsp.
Lan input-output iki salah siji cara utawa liyane kedadeyan liwat prakara iki.
PostgreSQL minangka basis data klasik. Ana kaca ing njero. Lan kabeh input lan output dumadi nggunakake kaca. We are mundhakaken pamblokiran menyang memori karo kaca. Lan yen ora ana apa-apa, kita mung maca, banjur mboko sithik ilang saka cache iki, saka buffer sing dienggo bareng lan bali menyang disk.
Yen kita ngganti soko nang endi wae, banjur kabeh kaca ditandhani minangka reged. Aku menehi tandha ing kene nganggo warna biru. Lan iki tegese kaca iki kudu disinkronake karo panyimpenan blok. Yaiku, nalika kita nggawe reged, kita nggawe entri ing WAL. Lan ing sawetara wektu sing apik banget, kedadeyan sing diarani checkpoint teka. Lan informasi dicathet ing log iki yen dheweke wis teka. Lan iki tegese kabeh kaca reged sing ana ing wayahe ing buffer sing dienggo bareng iki disinkronake karo disk panyimpenan nggunakake fsync liwat buffer kernel.
Yagene iki ditindakake? Yen kita ilang voltase, banjur kita ora njaluk kahanan sing kabeh data ilang. Memori sing terus-terusan, sing dicritakake saben wong, saiki ana ing teori database - iki minangka masa depan sing cerah, sing mesthi diupayakake lan kita seneng, nanging saiki padha manggon ing minus 20 taun. Lan, mesthi, kabeh iki kudu dipantau.
Lan tugas kanggo ngoptimalake throughput yaiku nyempurnakake kabeh tahapan kasebut supaya kabeh bisa maju lan maju kanthi cepet. Memori sing dienggo bareng yaiku cache kaca. Ing PostgreSQL kita ngirim pitakonan pilih utawa soko, njupuk data iki saka disk. Padha rampung ing buffer sambungan. Mulane, supaya bisa luwih apik, kudu akeh memori.
Supaya kabeh iki bisa digunakake kanthi apik lan cepet, sampeyan kudu ngatur sistem operasi kanthi bener ing kabeh tahapan. Lan milih hardware imbang, amarga yen sampeyan ora seimbang ing sawetara panggonan, sampeyan bisa nggawe akeh memori, nanging ora bakal dilayani kanthi kacepetan sing cukup.
Lan ayo padha ngliwati saben titik kasebut.
Kanggo nggawe kaca iki bali-bali luwih cepet, sampeyan kudu entuk ing ngisor iki:
- Kaping pisanan, sampeyan kudu bisa luwih efisien nganggo memori.
- Kapindho, transisi iki nalika kaca saka memori menyang disk kudu luwih efisien.
- Lan katelu, kudu ana disk apik.
Yen sampeyan duwe 512 GB RAM ing server lan kabeh rampung ing hard drive SATA tanpa cache, banjur kabeh server database dadi ora mung waluh, nanging waluh karo antarmuka SATA. Sampeyan bakal mbukak menyang langsung. Lan ora ana sing bakal nylametake sampeyan.
Babagan titik pisanan kanthi memori, ana telung perkara sing bisa nggawe urip angel banget.
Sing pertama yaiku NUMA. NUMA minangka barang sing digawe kanggo nambah kinerja. Gumantung ing beban kerja, macem-macem bisa dioptimalake. Lan ing wangun anyar sing saiki, iku ora apik banget kanggo aplikasi kayata database sing intensif nggunakake cache kaca buffer sambungan.
Cekakipun. Kepiye carane sampeyan bisa ngerti yen ana sing salah karo NUMA? Sampeyan duwe sawetara jenis ketukan karu, dumadakan sawetara CPU overloaded. Ing wektu sing padha, sampeyan nganalisa pitakon ing PostgreSQL lan ndeleng manawa ora ana sing padha. Pitakonan kasebut ora kudu intensif CPU. Sampeyan bisa nyekel iki kanggo dangu. Luwih gampang nggunakake rekomendasi sing bener saka wiwitan babagan carane ngatur NUMA kanggo PostgreSQL.
Ana apa tenan? NUMA singkatan saka Non-Uniform Memory Access. Apa gunane? Sampeyan duwe CPU, ing jejere ana memori lokal. Lan memori iki interconnects bisa narik munggah memori saka CPU liyane.
Yen sampeyan mlayu numactl --hardware, banjur sampeyan bakal entuk sheet gedhe. Antarane liyane, bakal ana lapangan jarak. Bakal ana nomer - 10-20, kaya ngono. Nomer iki ora luwih saka jumlah hop kanggo njupuk memori remot iki lan nggunakake lokal. Ing asas, idea apik. Iki nyepetake kinerja kanthi apik ing sawetara beban kerja.
Saiki mbayangno sing duwe siji CPU pisanan nyoba nggunakake memori lokal, banjur nyoba kanggo narik munggah memori liyane liwat interconnect kanggo soko. Lan CPU iki entuk kabeh cache halaman PostgreSQL sampeyan - mung sawetara gigabyte. Sampeyan mesthi entuk kasus paling awon, amarga ing CPU biasane ana memori cilik ing modul kasebut. Lan kabeh memori sing dilayani liwat interconnects iki. Pranyata alon lan sedhih. Lan prosesor sampeyan sing layanan simpul iki saya overloaded. Lan wektu akses memori iki ala, alon. Iki kahanan sing sampeyan ora pengin yen sampeyan nggunakake iki kanggo database.
Mulane, pilihan sing luwih bener kanggo database yaiku sistem operasi Linux ora ngerti apa sing kedadeyan ing kana. Supaya bisa ngakses memori kaya sing ditindakake.
Kok ngono? Iku bakal katon sing kudu dadi cara liyane. Iki kedadeyan kanthi alesan sing prasaja: kita butuh akeh memori kanggo cache kaca - puluhan, atusan gigabyte.
Lan yen kita nyedhiakke kabeh iki lan cache data kita ana, banjur gain saka nggunakake cache bakal Ngartekno luwih saka gain saka akses angel kuwi kanggo memori. Lan kanthi mangkono kita bakal entuk manfaat sing ora bisa dibandhingake karo kasunyatan manawa kita bakal ngakses memori kanthi luwih efisien nggunakake NUMA.
Mulane, ana loro pendekatan ing wayahe, nganti mangsa padhang wis teka, lan database dhewe ora bisa kanggo ngerti kang CPU lagi mlaku lan ngendi iku perlu kanggo narik soko saka.
Mulane, pendekatan sing bener yaiku mateni NUMA kabeh, contone, nalika rebooting. Ing kasus paling, winnings saka urutan gedhene sing pitakonan kang luwih apik ora njedhul ing kabeh.
Ana pilihan liyane. Kita nggunakake luwih kerep tinimbang sing pisanan, amarga nalika klien teka kanggo dhukungan, rebooting server minangka masalah gedhe kanggo dheweke. Dheweke duwe bisnis ing kana. Lan dheweke ngalami masalah amarga NUMA. Mulane, kita nyoba mateni kanthi cara sing kurang invasif tinimbang urip maneh, nanging ati-ati kanggo mriksa manawa dipateni. Amarga, minangka pengalaman nuduhake, iku apik yen kita mateni NUMA ing proses PostgreSQL tuwane, nanging ora perlu iku bakal bisa. Kita kudu mriksa lan ndeleng yen dheweke pancene dipateni.
Ana kirim apik dening Robert Haas. Iki minangka salah sawijining committers PostgreSQL. Salah sawijining pangembang utama kabeh giblets tingkat rendah. Lan yen sampeyan ngetutake tautan saka kiriman iki, dheweke nggambarake sawetara crita sing warni babagan carane NUMA nggawe urip angel kanggo wong. Deleng, sinau dhaptar priksa administrator sistem babagan apa sing kudu dikonfigurasi ing server supaya database bisa digunakake kanthi apik. Setelan iki kudu ditulis lan dicenthang, amarga yen ora, ora bakal apik banget.
Elinga yen iki ditrapake kanggo kabeh setelan sing bakal dakkandhakake. Nanging biasane database diklumpukake ing mode master-budak kanggo toleransi fault. Aja lali nggawe setelan iki ing abdi amarga ing sawijining dina sampeyan bakal ngalami kacilakan lan sampeyan bakal pindhah menyang abdi lan bakal dadi master.
Ing kahanan darurat, nalika kabeh ala banget, telpon sampeyan terus muni lan bos sampeyan mlaku nganggo tongkat gedhe, sampeyan ora bakal duwe wektu kanggo mikir babagan mriksa. Lan asil bisa cukup bilai.
Titik sabanjure yaiku kaca gedhe. Kaca ageng angel dites kanthi kapisah, lan ora ana gunane, sanajan ana benchmark sing bisa nindakake iki. Padha gampang kanggo Google.
Apa gunane? Sampeyan duwe server ora larang banget karo akeh RAM, contone, luwih saka 30 GB. Sampeyan ora nggunakake kaca gedhe. Iki tegese sampeyan mesthi duwe overhead babagan panggunaan memori. Lan overhead iki adoh saka sing paling nyenengake.
Kok ngono? Dadi apa sing kedadeyan? Sistem operasi allocates memori ing bêsik cilik. Iku trep banget, iku carane kedaden historis. Lan yen kita rinci, OS kudu nerjemahake alamat virtual menyang alamat fisik. Lan proses iki ora paling gampang, supaya OS caches asil operasi iki ing Translation Lookaside Buffer (TLB).
Lan wiwit TLB minangka cache, kabeh masalah sing ana ing cache muncul ing kahanan iki. Kaping pisanan, yen sampeyan duwe akeh RAM lan kabeh diparengake ing potongan cilik, banjur buffer iki dadi gedhe banget. Lan yen cache gedhe, banjur nggoleki liwat iku luwih alon. Overhead sehat lan butuh ruang, yaiku RAM dikonsumsi kanthi salah. wektu iki.
Loro - liyane cache mundak akeh ing kahanan kaya mengkono, sing liyane kamungkinan iku sing bakal duwe cache miss. Lan efisiensi cache iki suda kanthi cepet amarga ukurane mundhak. Mulane, sistem operasi teka karo pendekatan prasaja. Iku wis digunakake ing Linux kanggo dangu. Ora suwe iki muncul ing FreeBSD. Nanging kita ngomong babagan Linux. Iki minangka kaca gedhe.
Lan ing kene kudu dicathet yen kaca ageng, minangka gagasan, wiwitane didorong dening komunitas sing kalebu Oracle lan IBM, yaiku manufaktur basis data banget mikir yen iki uga migunani kanggo database.
Lan kepiye carane bisa dadi kanca karo PostgreSQL? Kaping pisanan, kaca gedhe kudu diaktifake ing kernel Linux.
Kapindho, kudu kasebut kanthi tegas dening parameter sysctl - pira ana. Nomer kene saka sawetara server lawas. Sampeyan bisa ngetung pirang-pirang buffer sing dienggo bareng supaya kaca gedhe bisa pas ing kana.
Lan yen kabeh server sampeyan darmabakti kanggo PostgreSQL, mula titik wiwitan sing apik yaiku nyedhiyakake 25% RAM kanggo buffer sing dienggo bareng, utawa 75% yen sampeyan yakin manawa database sampeyan bakal pas karo 75%. Titik wiwitan siji. Lan nimbang, yen sampeyan duwe 256 GB RAM, banjur, sampeyan bakal duwe 64 GB saka buffer gedhe. Ngitung kira-kira karo sawetara wates - apa tokoh iki kudu disetel.
Sadurunge versi 9.2 (yen aku ora salah, wiwit versi 8.2), iku bisa kanggo nyambung PostgreSQL karo kaca ageng nggunakake perpustakaan pihak katelu. Lan iki kudu tansah rampung. Pisanan, sampeyan butuh kernel supaya bisa ngalokasikan kaca gedhe kanthi bener. Lan, kapindho, supaya aplikasi sing bisa digunakake bisa digunakake. Ora mung bakal digunakake kanthi cara kasebut. Wiwit PostgreSQL diparengake memori ing sistem 5 gaya, iki bisa rampung nggunakake libhugetlbfs - iki jeneng lengkap perpustakaan.
Ing 9.3, kinerja PostgreSQL saya apik nalika nggarap memori lan metode alokasi memori sistem 5 ditinggalake. Saben uwong seneng banget, amarga digunakake sampeyan nyoba kanggo mbukak loro PostgreSQL kedadean ing siji mesin, lan ngandika yen aku ora duwe memori sambungan cukup. Lan dheweke ujar manawa sysctl kudu didandani. Lan ana sysctl sing isih kudu urip maneh, lan liya-liyane. Umume, kabeh wong seneng. Nanging alokasi memori mmap nyuwil panggunaan kaca ageng. Umume klien kita nggunakake buffer sing dienggo bareng gedhe. Lan kita banget dianjurake ora ngalih menyang 9.3, amarga nduwur sirah ana wiwit diwilang ing persentasi apik.
Nanging masyarakat mbayar manungsa waé kanggo masalah iki lan ing 9.4 padha reworked acara iki banget. Lan ing 9.4 parameter muncul ing postgresql.conf sing bisa ngaktifake nyoba, urip utawa mateni.
Coba minangka pilihan sing paling aman. Nalika PostgreSQL diwiwiti, nalika ngalokasi memori sing dienggo bareng, dheweke nyoba njupuk memori iki saka kaca gedhe. Lan yen ora bisa, banjur bali menyang pilihan normal. Lan yen sampeyan duwe FreeBSD utawa Solaris, sampeyan bisa nyoba, mesthi aman.
Yen aktif, mula ora diwiwiti yen ora bisa milih saka kaca gedhe. Ing kene wis babagan sapa lan apa sing luwih apik. Nanging yen sampeyan wis nyoba, priksa manawa sampeyan pancene duwe apa sing kudu disorot, amarga ana akeh ruang kanggo kesalahan. Saiki fungsi iki mung bisa digunakake ing Linux.
Siji cathetan cilik liyane sadurunge kita nerusake. Kaca-kaca gedhe sing transparan dudu babagan PostgreSQL. Dheweke ora bisa digunakake kanthi normal. Lan kanthi kaca gedhe Transparan kanggo beban kerja kasebut, nalika sepotong memori sing dienggo bareng dibutuhake, entuk manfaat mung kanthi volume sing gedhe banget. Yen sampeyan duwe terabyte memori, iki bisa uga dimainake. Yen kita ngomong babagan aplikasi saben dinten liyane, nalika sampeyan duwe 32, 64, 128, 256 GB memori ing mesin, banjur kaca ageng biasanipun Ok, lan kita mung mateni Transparan.
Lan bab pungkasan babagan memori ora langsung ana hubungane karo fruitut, bisa ngrusak urip sampeyan. Kabeh throughput bakal kena pengaruh banget amarga server terus-terusan ganti.
Lan iki bakal banget ora nyenengake ing sawetara cara. Lan masalah utama yaiku kernel modern tumindak rada beda karo kernel Linux lawas. Lan bab iki cukup karu langkah ing, amarga nalika kita pirembagan bab sawetara jenis karya karo pertukaran, iku ends karo rawuh untimely saka OOM-pembunuh. Lan pembunuh OOM, sing ora teka ing wektu sing tepat lan ngeculake PostgreSQL, ora nyenengake. Saben uwong bakal ngerti babagan iki, yaiku, nganti pangguna pungkasan.
Apa sing kedadeyan? Sampeyan duwe jumlah gedhe saka RAM ana, kabeh dianggo uga. Nanging sakperangan alesan server macet ing swap lan slows mudhun amarga iki. Iku bakal katon yen ana akeh memori, nanging iki kedadeyan.
Sadurunge, kita menehi saran kanggo nyetel vm.swappiness menyang nol, yaiku mateni swap. Sadurunge, misale jek 32 GB RAM lan buffer sing cocog karo jumlah gedhe. Tujuan utama swap yaiku duwe papan kanggo mbuwang kerak yen tiba. Lan iku ora ana maneh utamané kawujud. Banjur apa sing arep sampeyan tindakake karo kerak iki? Iki minangka tugas sing ora jelas kenapa swap dibutuhake, utamane kanthi ukuran kasebut.
Nanging ing luwih modern, yaiku versi katelu saka kernel, prilaku wis diganti. Lan yen sampeyan nyetel swap menyang nul, yaiku mateni, banjur cepet utawa mengko, sanajan isih ana RAM, pembunuh OOM bakal teka kanggo sampeyan kanggo mateni konsumen sing paling intensif. Amarga dheweke bakal nganggep manawa beban kerja kaya ngono isih ana lan kita bakal mlumpat, yaiku, ora kanggo ngrampungake proses sistem, nanging kanggo ngetrapake sing kurang penting. Sing kurang penting iki bakal dadi konsumen memori sing dienggo bareng, yaiku postmaster. Lan sawise iku bakal apik yen basa ora kudu dibalèkaké.
Mulane, saiki standar, minangka adoh aku elinga, paling distribusi nang endi wae watara 6, IE ing titik apa sampeyan kudu miwiti nggunakake swap gumantung pinten memori isih. Disaranake saiki setelan vm.swappiness = 1, amarga iki prakteke mateni, nanging ora menehi efek padha karo OOM-pembunuh sing ndadak teka lan matèni kabèh.
Apa sabanjure? Nalika kita pirembagan bab kinerja database lan mboko sithik pindhah menyang disk, saben wong wiwit nyekel sirahe. Amarga bebener sing disk alon lan memori cepet menowo kanggo everyone wiwit cilik. Lan kabeh wong ngerti yen database bakal duwe masalah kinerja disk.
Masalah kinerja PostgreSQL utama sing ana gandhengane karo lonjakan checkpoints ora kedadeyan amarga disk alon. Iki paling mungkin amarga kasunyatan manawa memori lan bandwidth disk ora seimbang. Nanging, bisa uga ora seimbang ing macem-macem papan. PostgreSQL ora dikonfigurasi, OS ora dikonfigurasi, hardware ora dikonfigurasi lan hardware ora bener. Lan masalah iki ora mung kedadeyan yen kabeh kedadeyan, yaiku, ora ana beban, utawa setelan lan hardware dipilih kanthi apik.
Apa iku lan apa iku katon kaya? Biasane wong sing nggarap PostgreSQL wis mlebu ing perkara iki luwih saka sepisan. Aku bakal nerangake. Kaya sing dakkandhakake, PostgreSQL sacara periodik nggawe checkpoints kanggo mbuwang kaca sing reged ing memori sing dienggo bareng menyang disk. Yen kita duwe jumlah gedhe saka memori sambungan, banjur checkpoint wiwit duwe impact intensif ing disk, amarga dumps kaca iki karo fsync. Teka ing buffer kernel lan ditulis menyang disk nggunakake fsync. Lan yen volume bisnis iki gedhe, mula kita bisa mirsani efek sing ora nyenengake, yaiku panggunaan disk sing gedhe banget.
Ing kene aku duwe rong gambar. Aku saiki bakal nerangake apa iku. Iki minangka rong grafik sing ana hubungane karo wektu. Grafik pisanan yaiku panggunaan disk. Ing kene tekan meh 90% ing wektu iki. Yen sampeyan duwe kegagalan database karo disk fisik, kanthi panggunaan pengontrol RAID ing 90%, mula iki warta ala. Iki tegese luwih sethithik lan bakal tekan 100 lan I / O bakal mandheg.
Yen sampeyan duwe array disk, banjur crita rada beda. Iku gumantung carane diatur, apa jenis array, etc.
Lan kanthi podo karo, grafik saka tampilan postgres internal dikonfigurasi ing kene, sing ngandhani kepiye titik pamriksan kasebut. Lan werna ijo ing kene nuduhake pirang-pirang buffer, kaca-kaca sing reged iki, ing wektu iku teka ing checkpoint iki kanggo sinkronisasi. Lan iki bab utama sampeyan kudu ngerti kene. Kita weruh yen kita duwe akeh kaca ing kene lan ing sawetara titik kita kenek papan, yaiku, kita nulis lan nulis, ing kene sistem disk jelas banget sibuk. Lan checkpoint kita duwe pengaruh banget ing disk. Saenipun, kahanan kudu katon luwih kaya iki, yaiku kurang rekaman ing kene. Lan kita bisa ndandani karo setelan supaya bakal terus kaya iki. Yaiku, daur ulang cilik, nanging ing endi wae kita nulis apa wae ing kene.
Apa sing kudu ditindakake kanggo ngatasi masalah iki? Yen sampeyan wis mandheg IO ing basis data, iki tegese kabeh pangguna sing teka kanggo nepaki panjaluke bakal ngenteni.
Yen sampeyan ndeleng saka sudut pandang Linux, yen sampeyan njupuk hardware sing apik, dikonfigurasi kanthi bener, ngatur PostgreSQL kanthi normal supaya checkpoints iki kurang asring, nyebarake wektu antarane saben liyane, banjur sampeyan pindhah menyang paramèter Debian standar. Kanggo distribusi Linux paling akeh, iki gambar: vm.dirty_ratio=20, vm.dirty_background_ratio=10.
Iki artine apa? Siji setan flushing muncul saka kernel 2.6. Pdglush, gumantung sing nggunakake kang, kang melu latar mburi discarding kaca reged saka buffer kernel lan discarding nalika iku perlu kanggo discard kaca reged ana prakara apa, nalika backgrouind discarding ora bantuan.
Nalika latar mburi teka? Nalika 10% saka total RAM kasedhiya ing server dikuwasani dening kaca reged ing buffer kernel, fungsi write-off khusus disebut ing latar mburi. Kok dadi latar mburi? Minangka paramèter, nimbang pira kaca sing kudu ditulis. Lan, ayo ngomong, dheweke nulis N kaca. Lan kanggo sawetara wektu iki dadi turu. Banjur dheweke teka maneh lan nyalin sawetara kaca liyane.
Iki crita sing prasaja banget. Masalah ing kene kaya kolam renang, yen diwutahake menyang pipa siji, banjur mili menyang liyane. Checkpoint kita teka lan yen ngirim sawetara kaca reged kanggo discarding, banjur mboko sithik bab kabèh bakal ditanggulangi rapi saka pgflush buffer kernel.
Yen kaca-kaca sing reged iki terus nglumpukake, padha nglumpukake nganti 20%, sawise iku prioritas OS kanggo nulis kabeh bab menyang disk, amarga daya bakal gagal lan kabeh bakal ala kanggo kita. Kita bakal kelangan data iki, contone.
Apa trik? Trik punika paramèter iki ing donya modern 20 lan 10% saka total RAM ing mesin, padha pancen monstrous ing syarat-syarat throughput saka sembarang sistem disk sing duwe.
Mbayangno sampeyan duwe 128 GB RAM. 12,8 GB teka ing sistem disk sampeyan. Lan ana prakara apa cache sampeyan duwe ana, ana prakara apa Uploaded ana, padha ora bakal punika dangu.
Mulane, disaranake sampeyan langsung nyetel angka kasebut adhedhasar kemampuan pengontrol RAID sampeyan. Aku langsung menehi rekomendasi ing kene kanggo pengontrol sing duwe cache 512 MB.
Kabeh dianggep prasaja banget. Sampeyan bisa sijine vm.dirty_background ing bita. Lan setelan kasebut mbatalake loro sadurunge. Salah siji rasio minangka standar, utawa sing duwe bita diaktifake, banjur sing nganggo bita bakal bisa digunakake. Nanging amarga aku konsultan DBA lan bisa karo klien beda, Aku nyoba kanggo tarik jerami lan mulane, yen ing bita, banjur ing bita. Ora ana sing menehi jaminan manawa admin sing apik ora bakal nambah memori ing server, urip maneh, lan angka kasebut bakal tetep padha. Mung ngetung nomer iki supaya kabeh pas karo jaminan.
Apa sing kedadeyan yen sampeyan ora cocog? Aku wis nulis sing flushing sembarang èfèktif mandegake, nanging nyatane iki tokoh wicara. Sistem operasi duwe masalah gedhe - akeh kaca sing reged, mula IO sing digawe klien sampeyan mandheg kanthi efektif, yaiku aplikasi wis teka kanggo ngirim query sql menyang database, lagi ngenteni. Sembarang input / output kasebut minangka prioritas paling murah, amarga database dikuwasani dening checkpoint. Lan nalika dheweke bakal rampung ora jelas. Lan yen sampeyan wis ngrambah flushing non-latar mburi, iku tegese kabeh IO wis dikuwasani dening. Lan nganti rampung, sampeyan ora bakal nindakake apa-apa.
Ana rong poin sing luwih penting ing kene sing ora ana ing lingkup laporan iki. Setelan iki kudu cocog karo setelan ing postgresql.conf, yaiku setelan checkpoints. Lan sistem disk sampeyan kudu dikonfigurasi kanthi cukup. Yen sampeyan duwe cache ing RAID, mula kudu baterei. Wong tuku RAID karo cache apik tanpa baterei. Yen sampeyan duwe SSD ing RAID, mula kudu dadi server, kudu ana kapasitor. Punika daftar mriksa rinci. Link iki ngemot laporan babagan carane ngatur disk kinerja ing PostgreSQL. Ana kabeh checklists iki.
Apa maneh sing bisa nggawe urip angel banget? Iki rong paramèter. Padha relatif anyar. Kanthi gawan, padha bisa kalebu ing macem-macem aplikasi. Lan bisa nggawe urip kaya angel yen diuripake kanthi ora bener.
Ana rong perkara sing relatif anyar. Dheweke wis muncul ing inti katelu. Iki minangka sched_migration_cost ing nanodetik lan sched_autogroup_enabled, sing minangka standar.
Lan kepiye carane ngrusak urip sampeyan? Apa sched_migration_cost? Ing Linux, panjadwal bisa migrasi proses saka siji CPU menyang liyane. Lan kanggo PostgreSQL, sing nglakokake pitakon, migrasi menyang CPU liyane ora jelas. Saka sudut pandang sistem operasi, nalika sampeyan ngalih windows antarane openoffice lan terminal, iki bisa uga apik, nanging kanggo database iki ala banget. Mulane, kabijakan sing cukup kanggo nyetel migration_cost menyang sawetara nilai gedhe, paling sethithik sawetara ewu nanodetik.
Apa tegese iki kanggo panjadwal? Bakal dianggep yen ing wektu iki proses isih panas. Sing, yen sampeyan duwe transaksi long-mlaku sing wis nindakake soko kanggo dangu, panjadwal bakal ngerti iki. Dheweke bakal nganggep yen nganti wektu entek iki liwati, ora perlu migrasi proses iki menyang ngendi wae. Yen ing wektu sing padha proses nindakake soko, iku ora bakal pindhah menyang ngendi wae, bakal quietly bisa ing CPU sing wis diparengake kanggo. Lan asile apik banget.
Titik kapindho yaiku autogroup. Ana ide sing apik kanggo beban kerja tartamtu sing ora ana hubungane karo database modern - iki kanggo nglumpukake proses miturut terminal virtual sing diluncurake. Iki trep kanggo sawetara tugas. Ing laku, PostgreSQL minangka sistem multi-proses kanthi prefork sing mlaku saka terminal siji. Sampeyan duwe panulis kunci, checkpoint, lan kabeh panjaluk klien sampeyan bakal diklompokake dadi siji panjadwal, saben CPU. Lan padha bakal ngenteni ing kono bebarengan kanggo wong kanggo free, supaya ngganggu saben liyane lan supaya wong dikuwasani maneh. Iki minangka crita sing ora perlu yen ana beban kasebut lan mulane kudu dipateni.
Kolegaku Alexey Lesovsky nindakake tes kanthi pgbench sing prasaja, ing ngendi dheweke nambah migration_cost kanthi urutan gedhene lan mateni autogroup. Bentenipun ing hardware ala meh 10%. Ana diskusi ing mailing list postgres ing ngendi wong menehi asil owah-owahan sing padha karo kacepetan pitakon kena pengaruh 50%. Ana cukup akeh crita kaya ngono.
Lan pungkasane, babagan kebijakan hemat daya. Sing apik yaiku Linux saiki bisa digunakake ing laptop. Lan mesthine bakal nggunakake baterei kanthi apik. Nanging dumadakan dadi metu sing iki uga bisa kelakon ing server.
Kajaba iku, yen sampeyan nyewa server saka sawetara hoster, mula hoster "apik" ora peduli yen sampeyan duwe kinerja sing luwih apik. Tugase yaiku kanggo mesthekake yen wesi digunakake kanthi efisien. Mula, kanthi standar bisa ngaktifake mode hemat daya laptop ing sistem operasi.
Yen sampeyan nggunakake barang iki ing server kanthi database ing beban abot, banjur pilihan sampeyan acpi_cpufreq + permormance. Malah kanthi ondemand bakal ana masalah.
Intel_pstate minangka pembalap sing rada beda. Lan saiki preferensi diwenehake kanggo iki, amarga mengko lan luwih apik.
Lan, miturut, gubernur mung kinerja. Ondemand, powersave lan liya-liyane dudu babagan sampeyan.
Asil saka njelasake analisis PostgreSQL bisa beda-beda miturut sawetara urutan gedhene yen sampeyan ngaktifake powersave, amarga sacoro prakteke CPU ing database bakal mlaku kanthi cara sing ora bisa diprediksi.
Item kasebut bisa uga kalebu kanthi gawan. Delengen kanthi ati-ati kanggo ndeleng yen wis diuripake kanthi gawan. Iki bisa dadi masalah gedhe banget.
Lan ing pungkasan, aku pengin ngucapake matur nuwun marang wong lanang saka tim PosgreSQL-Consulting DBA, yaiku Max Boguk lan Alexey Lesovsky, sing saben dina maju ing perkara iki. Lan kita nyoba kanggo nindakake sing paling apik kanggo klien kita supaya kabeh bisa kanggo wong-wong mau. Iku kaya karo instruksi safety aviation. Kabeh ing kene ditulis nganggo getih. Saben kacang iki ditemokake ing proses sawetara masalah. Aku seneng bareng karo sampeyan.
Pitakonan:
Matur nuwun! Yen, contone, perusahaan pengin ngirit dhuwit lan nyelehake database lan logika aplikasi ing siji server, utawa yen perusahaan ngetutake tren modern arsitektur microservice, ing PostgreSQL mlaku ing wadhah. Apa trik? Sysctl bakal mengaruhi kabeh kernel global. Aku wis ora krungu saka sysctls piye wae virtualized supaya padha bisa kapisah ing wadhah. Mung ana cgroup lan mung ana bagean saka kontrol ana. Kepiye carane sampeyan bisa urip karo iki? Utawa yen sampeyan pengin kinerja, banjur mbukak PostgreSQL ing server hardware kapisah lan nyetel iku?
Kita mangsuli pitakon sampeyan kanthi telung cara. Yen kita ora ngomong babagan server hardware sing bisa disetel, lan liya-liyane, banjur santai, kabeh bakal bisa digunakake tanpa setelan kasebut. Yen sampeyan duwe beban kaya sampeyan kudu nggawe setelan kasebut, mula sampeyan bakal teka ing server wesi luwih awal tinimbang setelan kasebut.
Apa masalahe? Yen iki mesin virtual, sampeyan bakal duwe akeh masalah, contone, karo kasunyatan sing paling mesin virtual latensi disk cukup inconsistent. Sanajan throughput disk apik, banjur siji transaksi I / O gagal sing ora mengaruhi throughput rata-rata sing kedadeyan nalika checkpoint utawa nalika nulis menyang WAL, mula database bakal nandhang sangsara banget saka iki. Lan sampeyan bakal weruh iki sadurunge sampeyan nemoni masalah kasebut.
Yen sampeyan duwe NGINX ing server sing padha, sampeyan uga bakal duwe masalah sing padha. Dheweke bakal perang kanggo memori bareng. Lan sampeyan ora bakal nemokake masalah sing diterangake ing kene.
Nanging ing sisih liya, sawetara paramèter kasebut isih cocog karo sampeyan. Contone, nyetel dirty_ratio karo sysctl supaya ora dadi edan - ing kasus apa wae, iki bakal mbantu. Salah siji cara utawa liyane, sampeyan bakal duwe interaksi karo disk. Lan bakal miturut pola sing salah. Iki umume standar kanggo paramèter sing dituduhake. Lan ing kasus apa wae, luwih becik ngganti.
Nanging bisa uga ana masalah karo NUMA. VmWare, contone, bisa uga karo NUMA karo setelan ngelawan persis. Lan ing kene sampeyan kudu milih - server wesi utawa non-wesi.
Aku duwe pitakonan sing ana gandhengane karo Amazon AWS. Dheweke duwe gambar sing wis dikonfigurasi. Salah sijine yaiku Amazon RDS. Apa ana setelan khusus kanggo sistem operasi?
Ana setelan ana, nanging setelan beda. Kene kita ngatur sistem operasi ing syarat-syarat carane database bakal nggunakake bab iki. Lan ana paramèter sing nemtokake ngendi kita kudu pindhah saiki, kayata mbentuk. Tegese, kita butuh akeh sumber daya, saiki bakal dipangan. Sawise iki, Amazon RDS ngencengi sumber daya kasebut, lan kinerja mudhun ing kana. Ana crita individu babagan carane wong-wong mulai ngganggu perkara iki. Kadhangkala malah cukup sukses. Nanging iki ora ana hubungane karo setelan OS. Iku kaya hacking awan. Beda critane.
Napa kaca gedhe Transparan ora ana pengaruhe dibandhingake karo TLB Ageng?
Aja menehi. Iki bisa diterangake kanthi pirang-pirang cara. Nanging nyatane dheweke mung ora menehi. Apa sejarah PostgreSQL? Ing wiwitan, iku allocates Piece gedhe saka memori sambungan. Apa dheweke transparan utawa ora, ora ana hubungane. Kasunyatan sing padha ngadeg metu ing wiwitan nerangake kabeh. Lan yen ana akeh memori lan sampeyan kudu mbangun maneh bagean shared_memory, banjur kaca gedhe Transparan bakal cocog. Ing PostgreSQL, iku mung diparengake ing cuwilan ageng ing wiwitan lan iku, lan banjur ora ana khusus mengkono ana. Sampeyan bisa, mesthi, nggunakake, nanging ana kasempatan kanggo njaluk korupsi shared_memory nalika re-allocates soko. PostgreSQL ora ngerti babagan iki.
Source: www.habr.com