Tuning Linux pikeun ningkatkeun kinerja PostgreSQL. Ilya Kosmodemyansky

Transkrip laporan 2015 ku Ilya Kosmodemyansky "Linux tuning pikeun ningkatkeun kinerja PostgreSQL"

Bantahan: Kuring dicatet yén laporan ieu tanggal Nopémber 2015 - leuwih ti 4 taun geus kaliwat tur loba waktu geus kaliwat. Versi 9.4 anu dibahas dina laporan henteu dirojong deui. Salila 4 taun katukang, 5 sékrési PostgreSQL anyar parantos dileupaskeun, sareng 15 versi kernel Linux parantos dileupaskeun. Lamun anjeun nulis balik passages ieu, anjeun bakal mungkas nepi ka laporan béda. Tapi di dieu urang nganggap tuning Linux dasar pikeun PostgreSQL, anu masih relevan ayeuna.

Nami abdi Ilya Kosmodemyansky. Abdi damel di PostgreSQL-Consulting. Sareng ayeuna kuring bakal ngobrol sakedik ngeunaan naon anu kudu dilakukeun sareng Linux dina hubungan database sacara umum sareng PostgreSQL khususna, sabab prinsipna sami.

Naon anu bakal urang bahas? Upami anjeun komunikasi sareng PostgreSQL, maka dugi ka sababaraha anjeun kedah janten admin UNIX. Naon éta hartosna? Upami urang ngabandingkeun Oracle sareng PostgreSQL, maka di Oracle anjeun kedah janten 80% admin database DBA sareng 20% ​​admin Linux.

Kalawan PostgreSQL éta saeutik leuwih pajeulit. Kalayan PostgreSQL anjeun kedah gaduh pamahaman anu langkung saé ngeunaan kumaha Linux jalanna. Sarta dina waktos anu sareng, ngajalankeun saeutik sanggeus lokomotif, sabab lately sagalana geus diropéa rada nicely. Sareng kernel énggal dileupaskeun, sareng fungsionalitas énggal muncul, kinerja ningkat, jsb.

Naha urang ngobrol ngeunaan Linux? Henteu pisan sabab kami dina konferensi Linux Peter, tapi kusabab dina kaayaan modéren salah sahiji sistem operasi anu paling diyakinkeun pikeun ngagunakeun database sacara umum sareng PostgreSQL khususna nyaéta Linux. Kusabab FreeBSD, hanjakalna, ngembang dina sababaraha arah anu anéh. Sareng bakal aya masalah sareng kinerja sareng seueur hal anu sanés. Kinerja PostgreSQL dina Windows sacara umum mangrupikeun masalah anu serius, dumasar kana kanyataan yén Windows henteu gaduh mémori anu sami sareng UNIX, sedengkeun PostgreSQL sadayana terikat sareng ieu, sabab éta mangrupikeun sistem multi-prosés.

Sareng kuring pikir sadayana kirang resep kana eksotik sapertos Solaris, janten hayu urang angkat.

Distribusi Linux modern ngagaduhan langkung ti 1 pilihan syctl, gumantung kana kumaha anjeun ngawangun kernel. Dina waktos anu sami, upami urang ningali kacangan anu béda, urang tiasa nyaluyukeun hiji hal ku sababaraha cara. Aya parameter sistem file ngeunaan cara masangana. Upami anjeun gaduh patarosan ngeunaan kumaha ngamimitianana: naon anu diaktipkeun dina mios, kumaha ngonpigurasikeun hardware, jsb.

Ieu volume anu ageung pisan anu tiasa dibahas dina sababaraha dinten, sareng sanés dina hiji laporan pondok, tapi ayeuna kuring bakal difokuskeun hal-hal anu penting, kumaha carana ngahindarkeun rake anu dijamin nyegah anjeun ngagunakeun database anjeun dina Linux upami anjeun ulah ngabenerkeun aranjeunna. Sareng dina waktos anu sami, titik anu penting nyaéta seueur parameter standar henteu kalebet dina setélan anu leres pikeun pangkalan data. Nyaéta, sacara standar bakal dianggo kirang atanapi henteu pisan.

Naon target tuning tradisional anu aya di Linux? Kuring nyangka yén saprak anjeun sadayana ngurus administrasi Linux, teu aya kabutuhan khusus pikeun ngajelaskeun naon tujuanana.

Anjeun tiasa nyetél:

• CPUs.
• Ingetan.
• Neundeun.
• Lain. Urang bakal ngobrol ngeunaan ieu di ahir pikeun snack. Malah, contona, parameter kayaning kawijakan hemat energi bisa mangaruhan kinerja dina pisan unpredictable teu cara paling pikaresepeun.

Naon spésifikasi PostgreSQL sareng pangkalan data sacara umum? Masalahna nyaéta yén anjeun moal tiasa ngarobih kacangan individu sareng ningali yén pagelaran kami parantos ningkat sacara signifikan.

Leres, aya gadget sapertos kitu, tapi database mangrupikeun hal anu kompleks. Éta berinteraksi sareng sadaya sumber daya anu dipiboga ku pangladén sareng langkung milih berinteraksi sacara lengkep. Upami anjeun ningali saran ayeuna Oracle ngeunaan cara ngagunakeun OS host, éta bakal sapertos guyonan ngeunaan kosmonot Mongol - pakan anjing sareng henteu noél nanaon. Hayu urang masihan database sadaya sumber daya, database sorangan bakal nyortir sagalana kaluar.

Sacara prinsip, pikeun extent sababaraha kaayaan persis sarua jeung PostgreSQL. Bédana nyaéta pangkalan data henteu acan tiasa nyandak sadaya sumber pikeun dirina, nyaéta dimana waé dina tingkat Linux anjeun kedah nyortir sadayana nyalira.

Gagasan utama henteu milih target tunggal sareng mimitian nyetélana, contona, mémori, CPU atanapi anu sapertos kitu, tapi pikeun nganalisis beban kerja sareng nyobian ningkatkeun throughput sabisa-bisa supados beban anu didamel ku programer anu saé. pikeun urang, kaasup pamaké urang.

Ieu gambar pikeun ngajelaskeun naon éta. Aya panyangga OS Linux sareng aya mémori anu dibagi sareng aya panyangga dibagikeun PostgreSQL. PostgreSQL, teu kawas Oracle, jalan langsung ngan ngaliwatan panyangga kernel, nyaéta, dina urutan pikeun kaca ti disk pikeun meunangkeun kana memori dibagikeun na, eta kudu ngaliwatan panyangga kernel na deui, kaayaan anu sarua pasti.

Disk hirup dina sistem ieu. Kuring ngagambar ieu salaku disk. Kanyataanna, meureun aya hiji RAID controller, jsb.

Jeung input-output ieu salah sahiji cara atawa sejen lumangsung ngaliwatan masalah ieu.

PostgreSQL mangrupikeun pangkalan data klasik. Aya kaca di jerona. Sareng sadaya input sareng kaluaran lumangsung nganggo halaman. Kami ngangkat blok kana mémori nganggo halaman. Sareng upami teu aya anu kajantenan, urang ngan ukur maca aranjeunna, teras laun-laun ngaleungit tina cache ieu, tina panyangga anu dibagi sareng ditungtungan deui dina disk.

Lamun urang ngaganti hal wae, teras sakabéh kaca ditandaan salaku kotor. Kuring nandaan aranjeunna di dieu biru. Sareng ieu hartosna halaman ieu kedah disingkronkeun sareng panyimpen blok. Nyaeta, nalika urang nyieun kotor, urang nyieun entri dina WAL. Sareng dina waktos anu saé dina waktosna, fenomena anu disebut checkpoint sumping. Sareng inpormasi kacatet dina log ieu yén anjeunna parantos sumping. Sareng ieu ngandung harti yén sadaya halaman kotor anu aya di dieu dina waktos éta dina panyangga anu dibagikeun ieu disingkronkeun sareng disk panyimpenan nganggo fsync ngalangkungan panyangga kernel.

Naha ieu dilakukeun? Upami urang kaleungitan tegangan, maka urang henteu nampi kaayaan yén sadaya data leungit. Memori pengkuh, anu sadayana nyarioskeun ka urang, dugi ka téori database - ieu mangrupikeun masa depan anu cerah, anu urang, tangtosna, narékahan sareng urang resep, tapi pikeun ayeuna aranjeunna hirup dikurangan 20 taun. Sareng, tangtosna, sadaya ieu kedah diawaskeun.

Sareng tugas pikeun maksimalkeun throughput nyaéta pikeun nyaluyukeun sadaya tahapan ieu supados sadayana gancang maju-mudik. Memori dibagikeun dasarna mangrupa cache kaca. Dina PostgreSQL kami ngirimkeun pamundut pilih atanapi naon waé, éta nyandak data ieu tina disk. Aranjeunna réngsé dina panyangga dibagikeun. Sasuai, pikeun ieu jalan hadé, kudu aya loba memori.

Supados sadayana ieu tiasa dianggo kalayan saé sareng gancang, anjeun kedah leres ngonpigurasikeun sistem operasi dina sadaya tahapan. Jeung milih hardware saimbang, sabab lamun boga hiji teu saimbangna di sababaraha tempat, mangka anjeun bisa nyieun loba memori, tapi moal serviced di speed cukup.

Sareng hayu urang ngaliwat unggal titik ieu.

Pikeun ngajantenkeun halaman ieu mudik langkung gancang, anjeun kedah ngahontal ieu:

• Anu mimiti, anjeun kedah damel langkung éfisién sareng mémori.
• Kadua, transisi ieu nalika halaman tina mémori lebet kana disk kedah langkung éfisién.
• Jeung katilu, kudu aya disk alus.

Upami Anjeun gaduh 512 GB RAM dina server jeung sakabéh éta ends up dina hard drive Kang Tata tanpa cache, lajeng sakabéh server database robah jadi teu ngan waluh a, tapi waluh jeung panganteur Kang Tata. Anjeun bakal ngajalankeun kana eta langsung. Jeung nanaon bakal nyalametkeun anjeun.

Ngeunaan titik kahiji kalawan memori, aya tilu hal anu bisa nyieun hirup pisan hésé.

Anu kahiji nyaéta NUMA. NUMA mangrupikeun hal anu didamel pikeun ningkatkeun kinerja. Gumantung kana beban kerja, hal anu béda tiasa dioptimalkeun. Sareng dina bentuk ayeuna anu énggal, éta henteu saé pisan pikeun aplikasi sapertos pangkalan data anu sacara intensif ngagunakeun panyangga anu dibagikeun cache halaman.

Singketna. Kumaha anjeun tiasa terang upami aya anu salah dina NUMA? Anjeun gaduh sababaraha jenis sambel pikaresepeun, dumadakan sababaraha CPU overloaded. Dina waktos anu sami, anjeun nganalisis patarosan dina PostgreSQL sareng ningali yén teu aya anu sami. queries ieu teu kudu jadi CPU intensif. Anjeun tiasa nyekel ieu keur lila. Langkung gampang ngagunakeun rekomendasi anu leres ti mimiti kumaha ngonpigurasikeun NUMA pikeun PostgreSQL.

Aya naon sih? NUMA nangtung pikeun Aksés Mémori Non-Seragam. Naon gunana? Anjeun gaduh CPU a, gigireun eta aya memori lokal na. Sarta memori ieu interconnects bisa narik nepi memori ti CPUs séjén.

Lamun lumpat numactl --hardware, mangka anjeun bakal meunang saperti lambar badag. Diantara hal séjén, bakal aya lapangan jarak. Bakal aya nomer - 10-20, sapertos kitu. Angka-angka ieu henteu langkung seueur tibatan jumlah hops pikeun nyandak mémori jauh ieu sareng dianggo sacara lokal. Sacara prinsip, mangrupakeun ide nu sae. Ieu nyepetkeun kinerja saé dina sauntuyan beban kerja.

Ayeuna bayangkeun yén anjeun gaduh hiji CPU heula nyobian nganggo mémori lokalna, teras nyobian narik mémori anu sanés liwat interkonéksi pikeun hiji hal. Sareng CPU ieu nampi sadayana cache halaman PostgreSQL anjeun - éta, sababaraha gigabyte. Anjeun salawasna meunang kasus awon, sabab dina CPU biasana aya saeutik memori dina modul sorangan. Sareng sadaya mémori anu dilayanan ngalangkungan sambungan ieu. Tétéla lalaunan jeung sedih. Sareng prosesor anjeun anu ngalayanan titik ieu terus-terusan overload. Jeung waktu aksés memori ieu goréng, slow. Ieu mangrupikeun kaayaan anu anjeun henteu hoyong upami anjeun nganggo ieu pikeun pangkalan data.

Ku alatan éta, pilihan anu langkung leres pikeun pangkalan data nyaéta pikeun sistem operasi Linux henteu terang naon anu aya di dinya. Sangkan aksés memori sakumaha eta.

Kunaon éta? Ieu bakal sigana nu kudu sabalikna. Ieu lumangsung pikeun hiji alesan basajan: urang kudu loba memori pikeun kaca cache - puluhan, ratusan gigabytes.

Sareng upami urang nyayogikeun sadayana ieu sareng nyéépkeun data urang di dinya, maka kauntungan tina ngagunakeun cache bakal langkung ageung tibatan kauntungan tina aksés anu rumit kana mémori. Sarta kami bakal nguntungkeun incomparably dibandingkeun kanyataan yén kami bakal ngakses memori leuwih éfisién maké NUMA.

Ku alatan éta, aya dua pendekatan di dieu dina momen, nepi ka mangsa nu bakal datang caang geus anjog, sarta database sorangan teu bisa angka kaluar nu CPUs eta ngajalankeun on na dimana eta perlu narik hal ti.

Ku alatan éta, pendekatan anu bener nyaéta nganonaktipkeun NUMA sadayana, contona, nalika rebooting. Dina kalolobaan kasus, kameunangan anu ageungna sapertos kitu sual anu mana anu langkung saé henteu timbul.

Aya pilihan séjén. Kami nganggo éta langkung sering tibatan anu munggaran, sabab nalika klien sumping ka kami pikeun ngadukung, rebooting server mangrupikeun masalah anu ageung pikeun anjeunna. Anjeunna boga bisnis di dinya. Sareng aranjeunna ngalaman masalah kusabab NUMA. Ku alatan éta, urang nyoba mareuman eta dina cara kirang invasif ti reboot, tapi ati-ati pikeun pariksa yen eta geus ditumpurkeun. Kusabab, sakumaha pangalaman nempokeun, éta alus urang nganonaktipkeun NUMA dina prosés indungna PostgreSQL, tapi teu sakabehna diperlukeun éta bakal jalan. Urang kedah parios sareng ningali yén anjeunna leres-leres pareum.

Aya tulisan anu saé ku Robert Haas. Ieu salah sahiji committers PostgreSQL. Salah sahiji pamekar konci sadaya giblets tingkat low. Sareng upami anjeun nuturkeun tautan tina tulisan ieu, aranjeunna ngajelaskeun sababaraha carita warna-warni ngeunaan kumaha NUMA ngajantenkeun kahirupan jalma susah. Tingali, diajar daptar pariksa administrator sistem ngeunaan naon anu kedah dikonpigurasikeun dina server supados database urang tiasa dianggo saé. Setélan ieu kedah ditulis sareng dipariksa, sabab upami henteu éta moal saé pisan.

Punten dicatet yén ieu manglaku ka sadaya setélan anu bakal kuring bahas. Tapi biasana pangkalan data dikumpulkeun dina modeu master-budak pikeun kasabaran kasalahan. Tong hilap ngadamel setélan ieu dina budak sabab hiji dinten anjeun bakal kacilakaan sareng anjeun bakal ngalih ka budak sareng éta bakal janten master.

Dina kaayaan darurat, nalika sagalana pisan goréng, telepon anjeun terus hurung jeung boss anjeun datang ngajalankeun kalawan iteuk badag, anjeun moal boga waktu pikeun mikir ngeunaan mariksa. Jeung hasilna bisa jadi rada mawa musibah.

Titik salajengna nyaéta halaman ageung. Kaca-kaca anu ageung hese diuji nyalira, sareng teu aya gunana pikeun ngalakukeunana, sanaos aya tolok ukur anu tiasa ngalakukeun ieu. Éta gampang pikeun Google.

Naon gunana? Anjeun gaduh server teu pisan mahal jeung loba RAM, Contona, leuwih ti 30 GB. Anjeun teu make kaca badag. Ieu ngandung harti yén anjeun pasti gaduh overhead dina hal pamakean memori. Jeung overhead ieu tebih ti paling pikaresepeun.

Kunaon éta? Janten naon anu lumangsung? Sistem operasi allocates memori dina lembar leutik. Ieu jadi merenah, éta kumaha kajadian sajarahna. Sareng upami urang langkung rinci, OS kedah narjamahkeun alamat virtual kana alamat fisik. Sareng prosés ieu sanés pangbasajanna, ku kituna OS nyéépkeun hasil tina operasi ieu dina Tarjamahan Lookaside Buffer (TLB).

Sareng saprak TLB mangrupikeun cache, sadaya masalah anu aya dina cache timbul dina kaayaan ieu. Anu mimiti, upami anjeun gaduh seueur RAM sareng sadayana dialokasikeun dina sakumpulan leutik, teras panyangga ieu janten ageung pisan. Sareng upami cache ageung, teras milarian langkung laun. Overhead séhat sareng éta nyalira nyéépkeun rohangan, nyaéta RAM dikonsumsi ku anu teu leres. Waktos ayeuna.

Dua - beuki cache tumuwuh dina kaayaan kitu, leuwih gampang éta nu bakal boga cache misses. Sareng efisiensi cache ieu gancang turun nalika ukuranana ningkat. Ku alatan éta, sistem operasi datang nepi ka pendekatan basajan. Parantos lami dianggo dina Linux. Éta muncul dina FreeBSD teu lami pisan. Tapi urang ngobrol ngeunaan Linux. Ieu kaca badag.

Sarta di dieu eta kudu dicatet yén kaca badag, salaku hiji gagasan, mimitina kadorong ku komunitas nu kaasup Oracle na IBM, i.e. pabrik database niatna ngira yén ieu bakal mangpaat pikeun database ogé.

Sareng kumaha ieu tiasa janten babaturan sareng PostgreSQL? Anu mimiti, halaman ageung kedah diaktipkeun dina kernel Linux.

Bréh, aranjeunna kedah sacara eksplisit dieusian ku parameter sysctl - sabaraha aya. Angka di dieu téh ti sababaraha server heubeul. Anjeun tiasa ngitung sabaraha seueur panyangga anu anjeun gaduh supados halaman ageung tiasa pas di dinya.

Tur upami sakabéh server anjeun dedicated ka PostgreSQL, lajeng titik awal alus a allocate boh 25% tina RAM ka panyangga dibagikeun, atawa 75% lamun yakin yén database anjeun pasti bakal pas dina ieu 75%. Titik mimiti hiji. Sareng mertimbangkeun, upami anjeun gaduh 256 GB RAM, teras, sasuai, anjeun bakal ngagaduhan 64 GB panyangga ageung. Itung kira-kira kalawan sababaraha margin - naon inohong ieu kudu disetel ka.

Sateuacan versi 9.2 (upami teu lepat, saprak versi 8.2), kamungkinan pikeun nyambungkeun PostgreSQL sareng halaman ageung nganggo perpustakaan pihak katilu. Sareng ieu kedah salawasna dilakukeun. Mimiti, anjeun peryogi kernel pikeun tiasa ngalokasikeun halaman anu ageung kalayan leres. Sareng, kadua, supados aplikasi anu tiasa dianggo sareng aranjeunna tiasa dianggo. Éta henteu ngan ukur dianggo ku cara éta. Kusabab PostgreSQL dialokasikeun mémori dina gaya sistem 5, ieu tiasa dilakukeun nganggo libhugetlbfs - ieu mangrupikeun nami lengkep perpustakaan.

Dina 9.3, kinerja PostgreSQL ningkat nalika dianggo sareng mémori sareng metode alokasi mémori sistem 5 ditinggalkeun. Sarerea éta pisan senang, sabab disebutkeun Anjeun nyobian ngajalankeun dua instansi PostgreSQL dina hiji mesin, sarta anjeunna nyebutkeun yen kuring teu boga cukup memori dibagikeun. Sareng anjeunna nyarios yén sysctl kedah dilereskeun. Sareng aya sysctl sapertos anjeun masih kedah reboot, jsb. Sacara umum, sadayana bagja. Tapi alokasi memori mmap peupeus pamakéan kaca badag. Kalolobaan klien kami ngagunakeun panyangga dibagikeun badag. Sarta kami niatna dianjurkeun teu pindah ka 9.3, sabab overhead dinya mimiti diitung dina percentages alus.

Tapi masarakat nengetan masalah ieu sarta dina 9.4 aranjeunna reworked acara ieu kacida alusna. Sareng dina 9.4 parameter muncul dina postgresql.conf dimana anjeun tiasa ngaktipkeun try, atanapi mareuman.

Coba mangrupikeun pilihan anu paling aman. Nalika PostgreSQL dimimitian, nalika allocates memori dibagikeun, éta nyoba grab memori ieu ti kaca badag. Tur upami teu dianggo, mangka gulung deui ka pilihan normal. Sareng upami anjeun gaduh FreeBSD atanapi Solaris, teras anjeun tiasa nyobian, éta aman.

Upami dihurungkeun, teras éta henteu ngamimitian upami henteu tiasa milih tina halaman anu ageung. Di dieu éta geus ngeunaan saha jeung naon nicer. Tapi upami anjeun parantos nyobian, teras parios yén anjeun leres-leres ngagaduhan anu anjeun kedah disorot, sabab aya seueur rohangan pikeun kasalahan. Ayeuna pungsi ieu ngan ukur tiasa dianggo dina Linux.

Hiji catetan leutik deui sateuacan urang langkung jauh. Kaca badag transparan henteu ngeunaan PostgreSQL acan. Anjeunna teu tiasa nganggo aranjeunna normal. Sareng kalayan halaman ageung Transparan pikeun beban kerja sapertos kitu, nalika sapotong mémori anu ageung diperyogikeun, kauntungan ngan ukur aya dina jilid anu ageung pisan. Upami anjeun gaduh terabytes mémori maka ieu tiasa dimaénkeun. Lamun urang ngobrol ngeunaan aplikasi leuwih sapopoé, mun anjeun boga 32, 64, 128, 256 GB memori dina mesin Anjeun, lajeng kaca badag biasa nyaeta Ok, sarta kami ngan nganonaktipkeun Transparan.

Jeung hal panungtungan ngeunaan memori teu langsung patali jeung fruitut, bener bisa ngaruksak hirup anjeun. Kabéh throughput bakal greatly kapangaruhan ku kanyataan yén server ieu terus swapping.

Sareng ieu bakal pikaresepeun pisan dina sababaraha cara. Sareng masalah utami nyaéta kernel modern kalakuanana rada béda ti kernel Linux anu lami. Sarta hal ieu rada pikaresepeun lengkah, sabab lamun urang ngobrol ngeunaan sababaraha jenis karya kalawan swap, eta ditungtungan make datangna untimely OOM-killer. Sareng pembunuh OOM, anu henteu sumping dina waktos anu pas sareng turun PostgreSQL, henteu pikaresepeun. Sadayana bakal terang ngeunaan ieu, nyaéta, dugi ka pangguna terakhir.

Aya naon? Anjeun gaduh jumlah badag RAM aya, sagalana jalan ogé. Tapi pikeun sababaraha alesan server hangs di swap na slows turun kusabab ieu. Ieu bakal sigana nu aya loba memori, tapi ieu kajadian.

Saméméhna, kami disarankan pikeun nyetel vm.swappiness ka nol, nyaéta nganonaktipkeun swap. Saméméhna, éta seemed yén 32 GB RAM na pakait panyangga dibagikeun éta jumlah badag. Tujuan utama swap nyaéta pikeun ngagaduhan tempat pikeun ngalungkeun kerak upami urang murag. Sareng éta henteu deui khususna kaeusi. Teras naon anu anjeun badé lakukeun ku kerak ieu? Ieu mangrupikeun tugas dimana teu jelas pisan naha swap diperyogikeun, khususna ukuran sapertos kitu.

Tapi dina langkung modern, nyaéta versi katilu tina kernel, paripolahna parantos robih. Sareng upami anjeun nyetél swap ka nol, nyaéta mareuman, teras engké atanapi engké, sanaos aya sababaraha RAM anu tinggaleun, pembunuh OOM bakal sumping ka anjeun pikeun maéhan konsumen anu paling intensif. Kusabab anjeunna bakal nganggap yén kalayan beban kerja sapertos kitu urang masih ngagaduhan sakedik deui sareng urang bakal luncat kaluar, nyaéta, sanés pikeun ngiringan prosés sistem, tapi pikeun nangkep hal anu kirang penting. Ieu kurang pentingna bakal konsumen intensif memori dibagikeun, nyaéta postmaster nu. Sareng saatos éta bakal saé upami dasarna henteu kedah dibalikeun deui.

Ku alatan éta, ayeuna standar, sajauh Abdi émut, paling sebaran tempat sabudeureun 6, nyaéta dina titik naon anjeun kudu mimitian nganggo swap gumantung kana sabaraha memori ditinggalkeun. Urang ayeuna nyarankeun setelan vm.swappiness = 1, sabab ieu praktis dipareuman, tapi teu méré épék sarua jeung OOM-killer nu disangka anjog sarta maéhan sakabeh hal.

Naon salajengna? Lamun urang ngobrol ngeunaan kinerja database na laun pindah ka disk, dulur mimiti grab sirah maranéhanana. Kusabab kabeneran yén disk slow sarta memori gancang akrab jeung dulur ti budak leutik. Sareng sadayana terang yén pangkalan data bakal ngagaduhan masalah kinerja disk.

Masalah kinerja PostgreSQL utama pakait sareng checkpoints spikes teu lumangsung alatan disk slow. Ieu paling dipikaresep alatan kanyataan yén mémori jeung rubakpita disk teu saimbang. Sanajan kitu, aranjeunna bisa jadi teu saimbang di tempat béda. PostgreSQL teu ngonpigurasi, OS teu ngonpigurasi, hardware teu ngonpigurasi jeung hardware teu bener. Jeung masalah ieu teu lumangsung ngan lamun sagalana lumangsung sakumaha sakuduna, i.e. boh euweuh beban, atawa setélan jeung hardware dipilih ogé.

Naon éta sareng kumaha rupana? Biasana jalma anu damel sareng PostgreSQL parantos lebet kana masalah ieu langkung ti sakali. Kuring bakal ngajelaskeun. Salaku Cenah mah, PostgreSQL périodik ngajadikeun checkpoints mun dump kaca kotor dina memori dibagikeun ka disk. Upami urang gaduh jumlah mémori anu ageung, maka titik pamariksaan mimiti gaduh dampak anu intensif dina disk, sabab éta ngaleungitkeun halaman ieu sareng fsync. Éta sumping dina panyangga kernel sareng ditulis kana disk nganggo fsync. Sareng upami volume bisnis ieu ageung, maka urang tiasa ningali pangaruh anu teu pikaresepeun, nyaéta panggunaan disk anu ageung.

Di dieu kuring boga dua gambar. Kuring ayeuna bakal ngajelaskeun naon éta. Ieu dua grafik waktos-correlated. Grafik kahiji nyaéta utilization disk. Di dieu éta ngahontal ampir 90% dina waktos ayeuna. Upami anjeun gaduh kagagalan database sareng disk fisik, kalayan panggunaan pangontrol RAID dina 90%, maka ieu mangrupikeun warta anu goréng. Ieu ngandung harti yén saeutik leuwih sarta eta bakal ngahontal 100 sarta I / O bakal eureun.

Upami anjeun gaduh susunan disk, éta mangrupikeun carita anu rada béda. Eta gumantung kana kumaha eta ngonpigurasi, jenis Asép Sunandar Sunarya éta, jsb.

Sareng paralel, grafik tina tampilan postgres internal dikonpigurasi di dieu, anu nyarioskeun kumaha tempat pamariksaan lumangsung. Sareng warna héjo di dieu nunjukkeun sabaraha panyangga, halaman kotor ieu, dina waktos éta dugi ka tempat pamariksaan ieu kanggo sinkronisasi. Sareng ieu mangrupikeun hal utama anu anjeun kedah terang di dieu. Urang nempo yén urang boga loba kaca dieu sarta di sawatara titik urang pencét dewan, nyaeta, urang nulis jeung nulis, didieu sistem disk jelas pisan sibuk. Sareng pamariksaan kami gaduh pangaruh anu kuat dina disk. Ideally, kaayaan kudu kasampak leuwih kawas kieu, ie urang kirang ngarekam di dieu. Sareng urang tiasa ngalereskeunana ku setélan supados tetep sapertos kieu. Nyaéta, daur ulang leutik, tapi dimana waé urang nyerat hiji hal di dieu.

Naon anu kudu dipigawé pikeun nungkulan masalah ieu? Upami anjeun parantos ngeureunkeun IO dina pangkalan data, ieu hartosna yén sadaya pangguna anu sumping pikeun minuhan pamenta na bakal ngantosan.

Upami anjeun ningal tina sudut pandang Linux, upami anjeun nyandak hardware anu saé, ngonpigurasikeunana leres, ngonpigurasikeun PostgreSQL sacara normal ku kituna ngajadikeun checkpoints ieu kirang sering, nyebarkeun aranjeunna dina waktos anu sanés, teras anjeun lebet kana parameter Debian standar. Kanggo sabagéan ageung distribusi Linux, ieu gambar: vm.dirty_ratio=20, vm.dirty_background_ratio=10.

Naon éta hartosna? Hiji sétan flushing mucunghul tina kernel 2.6. Pdglush, gumantung kana anu ngagunakeun mana, anu kalibet dina latar tukang discarding kaca kotor ti panyangga kernel na discarding lamun perlu Piceun kaca kotor euweuh urusan naon, lamun backgrouind discarding teu mantuan.

Iraha latar datang? Nalika 10% tina total RAM anu aya dina server dijajah ku halaman kotor dina panyangga kernel, fungsi nulis-off khusus disebut di latar tukang. Naha éta latar? Salaku parameter, éta tumut kana akun sabaraha kaca nulis kaluar. Sareng, hayu urang nyarios, anjeunna nyerat N halaman. Sarta bari hal ieu ragrag saré. Terus manehna datang deui jeung nyalin sababaraha kaca deui.

Ieu carita basajan pisan. Masalahna di dieu nyaéta sapertos kolam renang, nalika tuang kana hiji pipa, éta ngalir ka pipa anu sanés. Pos pamariksaan kami dugi sareng upami éta ngirim sababaraha halaman anu kotor pikeun dipiceun, maka laun-laun sadayana bakal direngsekeun sacara rapih tina pgflush panyangga kernel.

Lamun kaca kotor ieu terus akumulasi, aranjeunna ngumpulkeun nepi ka 20%, nu satutasna prioritas OS pikeun nulis kaluar sakabeh hal ka disk, sabab kakuatan bakal gagal jeung sagalana bakal goréng pikeun urang. Urang bakal leungit data ieu, contona.

Naon trik? Trik nyaéta yén parameter ieu di dunya modéren nyaéta 20 sareng 10% tina total RAM anu aya dina mesin, aranjeunna leres-leres monstrous dina hal throughput tina sistem disk anu anjeun gaduh.

Bayangkeun anjeun gaduh 128 GB RAM. 12,8 GB sumping dina sistem disk anjeun. Tur euweuh urusan naon cache anjeun gaduh aya, euweuh urusan naon Asép Sunandar Sunarya anjeun gaduh aya, aranjeunna moal lepas nu panjang.

Kituna, kami nyarankeun yén anjeun geuwat nyaluyukeun angka ieu dumasar kana kamampuhan RAID controller Anjeun. Kuring geuwat dijieun rekomendasi dieu pikeun controller nu boga 512 MB cache.

Sagalana dianggap basajan pisan. Anjeun tiasa nempatkeun vm.dirty_background dina bait. Sareng setelan ieu ngabatalkeun dua saméméhna. Boh rasio sacara standar, atanapi anu nganggo bait diaktipkeun, teras anu nganggo bait bakal jalan. Tapi saprak Kami konsultan DBA sarta gawé bareng klien béda, abdi nyobian ngagambar straws sahingga, lamun dina bait, lajeng dina bait. Teu aya anu masihan jaminan yén admin anu saé moal nambihan deui mémori kana server, reboot deui, sareng inohongna bakal tetep sami. Ngan ngitung angka ieu ambéh sagalana fits di dinya kalawan jaminan.

Naon anu lumangsung lamun anjeun teu cocog? Kuring geus ditulis yén sagala flushing geus éféktif dieureunkeun, tapi dina kanyataanana ieu téh inohong ucapan. Sistem operasi ngagaduhan masalah anu ageung - seueur halaman anu kotor, ku kituna IO anu dibangkitkeun ku klien anjeun sacara efektif dieureunkeun, nyaéta aplikasi parantos sumping pikeun ngirim pamundut sql kana pangkalan data, ngantosan. Sakur input / output kana éta mangrupikeun prioritas panghandapna, sabab pangkalan data dijajah ku pos pamariksaan. Jeung iraha manehna bakal rengse eta sagemblengna can écés. Sareng nalika anjeun parantos ngahontal flushing non-background, éta hartosna yén sadaya IO anjeun dijajah ku éta. Sareng dugi ka réngsé, anjeun moal ngalakukeun nanaon.

Aya dua poin anu langkung penting di dieu anu saluareun ruang lingkup laporan ieu. Setélan ieu kedah cocog sareng setélan dina postgresql.conf, nyaéta setélan checkpoints. Jeung sistem disk Anjeun kudu ngonpigurasi adequately. Upami anjeun gaduh cache dina RAID, éta kedah gaduh batré. Jalma meuli RAID kalawan cache alus tanpa batré a. Upami Anjeun gaduh SSDs di RAID, aranjeunna kedah janten server, kedah aya kapasitor. Ieu daptar pariksa lengkep. Link ieu ngandung laporan kuring ngeunaan cara ngonpigurasikeun disk kinerja dina PostgreSQL. Aya sagala checklists ieu aya.

Naon deui anu tiasa ngajantenkeun hirup susah? Ieu dua parameter. Aranjeunna kawilang anyar. Sacara standar, aranjeunna tiasa dilebetkeun kana aplikasi anu béda. Jeung maranéhna bisa nyieun hirup sagampil hésé lamun aranjeunna dihurungkeun salah.

Aya dua hal anu kawilang anyar. Aranjeunna parantos muncul dina inti katilu. Ieu sched_migration_cost dina nanoseconds na sched_autogroup_enabled, nu hiji sacara standar.

Sareng kumaha aranjeunna ngarusak kahirupan anjeun? Naon sched_migration_cost? Dina Linux, penjadwal tiasa mindahkeun prosés tina hiji CPU ka CPU anu sanés. Sareng pikeun PostgreSQL, anu ngalaksanakeun patarosan, migrasi ka CPU anu sanés teu jelas. Tina sudut pandang sistem operasi, nalika anjeun ngalih windows antara openoffice sareng terminal, ieu tiasa saé, tapi pikeun database ieu pisan goréng. Ku alatan éta, kabijakan anu wajar nyaéta nyetél migration_cost kana sababaraha nilai anu ageung, sahenteuna sababaraha rébu nanodetik.

Naon ieu hartosna pikeun scheduler? Bakal dianggap yén salila ieu prosés masih panas. Hartina, lamun boga urus lila-ngajalankeun nu geus ngalakonan hal pikeun lila, scheduler bakal ngartos ieu. Anjeunna bakal nganggap yén dugi ka seep waktos ieu, teu kedah migrasi prosés ieu ka mana waé. Upami dina waktos anu sami prosésna ngalakukeun hiji hal, maka éta moal hijrah ka mana waé, éta bakal dianggo dina CPU anu dialokasikeun ka dinya. Jeung hasilna alus teuing.

Titik kadua nyaéta autogroup. Aya ide anu sae pikeun beban kerja khusus anu henteu aya hubunganana sareng pangkalan data modéren - ieu pikeun ngagolongkeun prosés ku terminal virtual dimana aranjeunna diluncurkeun. Ieu merenah pikeun sababaraha pancén. Dina prakna, PostgreSQL mangrupakeun sistem multi-prosés kalawan prefork nu ngalir ti terminal tunggal. Anjeun gaduh panulis konci, checkpoint, sareng sadaya pamundut klien anjeun bakal dikelompokkeun kana hiji jadwal, per CPU. Sarta maranéhanana baris antosan aya di unison pikeun manéhna bébas, guna ngaganggu silih jeung tetep manéhna nempatan leuwih lila. Ieu mangrupikeun carita anu henteu diperyogikeun upami aya beban sapertos kitu, ku kituna éta kedah dipareuman.

Babaturan kuring Alexey Lesovsky ngalakukeun tés sareng pgbench saderhana, dimana anjeunna ningkatkeun migration_cost ku urutan gedéna sareng mareuman autogroup. Beda dina hardware goréng ampir 10%. Aya diskusi dina milis postgres dimana jalma-jalma masihan hasil parobihan anu sami sareng laju pamundut dipangaruhan 50%. Aya cukup loba carita saperti.

Sarta pamustunganana, ngeunaan kawijakan hemat daya. Anu saé nyaéta Linux ayeuna tiasa dianggo dina laptop. Sarta eta konon bakal ngagunakeun nepi batréna ogé. Tapi ujug-ujug tétéla yén ieu ogé bisa lumangsung dina server.

Sumawona, upami anjeun nyéwa server ti sababaraha hoster, maka hoster anu "alus" henteu paduli yén anjeun gaduh prestasi anu langkung saé. Tugas maranéhanana nyaéta pikeun mastikeun yén beusi maranéhanana dimangpaatkeun salaku éfisién mungkin. Ku alatan éta, sacara standar aranjeunna tiasa ngaktipkeun mode hemat daya laptop dina sistem operasi.

Lamun make barang ieu dina server kalawan database dina beban beurat, lajeng pilihan anjeun acpi_cpufreq + permormance. Malah ku ondemand bakal aya masalah.

Intel_pstate mangrupikeun supir anu rada béda. Tur ayeuna leuwih sering dipake tinimbang dibikeun ka hiji ieu, sabab engké na jalan hadé.

Sareng, sasuai, gubernur ngan ukur kinerja. Ondemand, powersave sareng anu sanésna sanés ngeunaan anjeun.

Hasil tina ngajelaskeun nganalisa PostgreSQL tiasa bénten ku sababaraha ordo gedéna upami anjeun ngaktipkeun powersave, sabab sacara praktis CPU dina pangkalan data anjeun bakal jalan dina cara anu teu kaduga.

Item ieu tiasa kalebet sacara standar. Tingali taliti pikeun ningali upami aranjeunna dihurungkeun sacara standar. Ieu bisa jadi masalah bener badag.

Sarta pamustunganana, kuring hayang ngucapkeun hatur nuhun ka guys ti tim PosgreSQL-Consulting DBA kami, nyaéta Max Boguk jeung Alexey Lesovsky, anu nyieun headway dina urusan ieu unggal poe. Sareng urang nyobian ngalakukeun anu pangsaéna pikeun klien kami supados sadayana tiasa dianggo pikeun aranjeunna. Ieu kawas kalawan parentah kaamanan aviation. Sagalana di dieu ditulis dina getih. Unggal kacang ieu kapanggih dina prosés sababaraha jenis masalah. Kami senang babagi aranjeunna sareng anjeun.

patarosan:

Hatur nuhun! Upami, contona, perusahaan hoyong ngahémat artos sareng nempatkeun database sareng logika aplikasi dina hiji server, atanapi upami perusahaan nuturkeun tren modéren arsitéktur microservice, dimana PostgreSQL dijalankeun dina wadah. Naon trik? Sysctl bakal mangaruhan sakabéh kernel sacara global. Kuring geus teu ngadéngé sysctls keur kumaha bae virtualized ambéh maranéhanana dianggo misah dina wadahna. Aya ngan hiji cgroup sarta aya ngan bagian tina kontrol aya. Kumaha anjeun tiasa hirup sareng ieu? Atanapi upami anjeun hoyong pagelaran, teras jalankeun PostgreSQL dina server hardware anu misah sareng setel?

Kami ngajawab patarosan anjeun ku tilu cara. Upami urang henteu ngawangkong ngeunaan server hardware anu tiasa disetel, sareng sajabana, teras santai, sadayana bakal tiasa dianggo tanpa setélan ieu. Upami anjeun gaduh beban sapertos anu anjeun peryogikeun pikeun ngalakukeun setélan ieu, maka anjeun bakal sumping ka server beusi sateuacanna ti setélan ieu.

Naon masalahna? Upami ieu mangrupikeun mesin virtual, maka paling dipikaresep anjeun bakal ngagaduhan seueur masalah, contona, kanyataan yén dina kalolobaan mesin virtual, latency disk rada teu konsisten. Malah lamun throughput disk téh alus, lajeng hiji gagal I / O urus nu teu greatly mangaruhan throughput rata anu lumangsung dina waktu papariksaan atawa dina waktu nulis WAL, lajeng database bakal sangsara greatly tina ieu. Sareng anjeun bakal perhatikeun ieu sateuacan anjeun ngalaman masalah ieu.

Upami anjeun gaduh NGINX dina server anu sami, anjeun ogé bakal ngagaduhan masalah anu sami. Anjeunna bakal tarung pikeun memori dibagikeun. Sareng anjeun moal kéngingkeun masalah anu dijelaskeun di dieu.

Tapi di sisi anu sanés, sababaraha parameter ieu masih bakal relevan pikeun anjeun. Salaku conto, atur dirty_ratio sareng sysctl supados henteu gélo - dina sagala hal, ieu bakal ngabantosan. Hiji cara atanapi anu sanés, anjeun bakal gaduh interaksi sareng disk. Sarta eta bakal nurutkeun pola salah. Ieu umumna standar pikeun parameter anu kuring nunjukkeun. Sareng dina sagala hal éta langkung saé pikeun ngarobih aranjeunna.

Tapi meureun aya masalah sareng NUMA. VmWare, contona, tiasa dianggo saé sareng NUMA kalayan setélan anu sabalikna. Sarta di dieu anjeun kudu milih - server beusi atawa non-beusi.

Kuring boga patarosan patali Amazon AWS. Aranjeunna gaduh gambar anu tos dikonpigurasikeun. Salah sahijina disebut Amazon RDS. Naha aya setélan khusus pikeun sistem operasina?

Aya setélan aya, tapi aranjeunna setelan béda. Di dieu urang ngonpigurasikeun sistem operasi dina watesan kumaha database bakal ngagunakeun hal ieu. Sareng aya parameter anu nangtukeun dimana urang kedah angkat ayeuna, sapertos ngabentuk. Nyaéta, urang peryogi seueur sumber daya, ayeuna urang bakal tuang aranjeunna. Sanggeus ieu, Amazon RDS tightens sumberdaya ieu, sarta kinerja turun di dinya. Aya carita individu ngeunaan kumaha jalma mimiti ngaganggu masalah ieu. Sok sanajan rada hasil. Tapi ieu teu aya hubunganana sareng setélan OS. Ieu kawas hacking awan. Éta carita béda.

Naha halaman ageung Transparan teu aya pangaruhna dibandingkeun sareng TLB ageung?

Entong masihan. Ieu bisa dipedar ku sababaraha cara. Tapi dina kanyataanana aranjeunna ngan saukur teu masihan. Naon sajarah PostgreSQL? Dina ngamimitian, éta allocates sapotong badag memori dibagikeun. Naha aranjeunna transparan atanapi henteu leres-leres henteu relevan. Kanyataan yén aranjeunna nangtung kaluar dina mimiti ngajelaskeun sagalana. Sareng upami aya seueur mémori sareng anjeun kedah ngawangun deui bagean shared_memory, teras halaman ageung Transparan bakal relevan. Dina PostgreSQL, éta ngan saukur dialokasikeun dina sakumpulan ageung di awal sareng éta, teras teu aya anu khusus kajadian di dinya. Anjeun tiasa, tangtosna, make eta, tapi aya kasempetan meunang hiji korupsi shared_memory lamun eta ulang allocates hal. PostgreSQL henteu terang ngeunaan ieu.

sumber: www.habr.com