ការលៃតម្រូវលីនុចដើម្បីកែលម្អការអនុវត្ត PostgreSQL ។ Ilya Kosmodemyansky

ប្រតិចារិកនៃរបាយការណ៍ឆ្នាំ 2015 ដោយ Ilya Kosmodemyansky "ការលៃតម្រូវលីនុចដើម្បីកែលម្អការអនុវត្ត PostgreSQL"

ការបដិសេធ៖ ខ្ញុំកត់សម្គាល់ថារបាយការណ៍នេះចុះកាលបរិច្ឆេទខែវិច្ឆិកា ឆ្នាំ 2015 - ជាង 4 ឆ្នាំបានកន្លងផុតទៅ ហើយពេលវេលាជាច្រើនបានកន្លងផុតទៅ។ កំណែ 9.4 ដែល​បាន​ពិភាក្សា​ក្នុង​របាយការណ៍​គឺ​មិន​ត្រូវ​បាន​គាំទ្រ​ទៀត​ទេ​។ ក្នុងរយៈពេល 4 ឆ្នាំកន្លងមកនេះ PostgreSQL ថ្មីចំនួន 5 ត្រូវបានចេញផ្សាយ ហើយ 15 កំណែនៃខឺណែលលីនុចត្រូវបានចេញផ្សាយ។ ប្រសិនបើអ្នកសរសេរអត្ថបទទាំងនេះឡើងវិញ អ្នកនឹងបញ្ចប់ដោយរបាយការណ៍ផ្សេង។ ប៉ុន្តែនៅទីនេះយើងពិចារណាការលៃតម្រូវលីនុចជាមូលដ្ឋានសម្រាប់ PostgreSQL ដែលនៅតែពាក់ព័ន្ធសព្វថ្ងៃនេះ។

ឈ្មោះរបស់ខ្ញុំគឺ Ilya Kosmodemyansky ។ ខ្ញុំធ្វើការនៅ PostgreSQL-Consulting ។ ហើយឥឡូវនេះខ្ញុំនឹងនិយាយបន្តិចអំពីអ្វីដែលត្រូវធ្វើជាមួយលីនុចទាក់ទងនឹងមូលដ្ឋានទិន្នន័យជាទូទៅនិង PostgreSQL ជាពិសេសពីព្រោះគោលការណ៍គឺស្រដៀងគ្នា។

តើយើងនឹងនិយាយអំពីអ្វី? ប្រសិនបើអ្នកប្រាស្រ័យទាក់ទងជាមួយ PostgreSQL បន្ទាប់មកក្នុងកម្រិតខ្លះ អ្នកត្រូវក្លាយជាអ្នកគ្រប់គ្រង UNIX ។ តើ​វា​មានន័យ​យ៉ាង​ដូចម្តេច? ប្រសិនបើយើងប្រៀបធៀប Oracle និង PostgreSQL នោះនៅក្នុង Oracle អ្នកត្រូវមាន 80% DBA database admin និង 20% Linux admin ។

ជាមួយនឹង PostgreSQL វាមានភាពស្មុគស្មាញបន្តិច។ ជាមួយនឹង PostgreSQL អ្នកត្រូវមានការយល់ដឹងកាន់តែច្បាស់អំពីរបៀបដែលលីនុចដំណើរការ។ ហើយក្នុងពេលជាមួយគ្នានេះ រត់បន្តិចបន្ទាប់ពីក្បាលរថភ្លើង ព្រោះថ្មីៗនេះអ្វីៗត្រូវបានអាប់ដេតយ៉ាងស្អាត។ ហើយខឺណែលថ្មីត្រូវបានបញ្ចេញ ហើយមុខងារថ្មីលេចឡើង ដំណើរការប្រសើរឡើង។ល។

ហេតុអ្វីបានជាយើងនិយាយអំពីលីនុច? មិនមែនដោយសារតែយើងនៅឯសន្និសីទលីនុចពេត្រុសទេ ប៉ុន្តែដោយសារតែនៅក្នុងលក្ខខណ្ឌទំនើបនៃប្រព័ន្ធប្រតិបត្តិការដ៏ត្រឹមត្រូវបំផុតមួយសម្រាប់ការប្រើប្រាស់មូលដ្ឋានទិន្នន័យជាទូទៅ និង PostgreSQL ជាពិសេសគឺលីនុច។ ដោយសារតែ FreeBSD ជាអកុសលកំពុងអភិវឌ្ឍក្នុងទិសដៅចម្លែកណាស់។ ហើយនឹងមានបញ្ហាទាំងការសម្តែង និងជាមួយរឿងជាច្រើនទៀត។ ការអនុវត្តរបស់ PostgreSQL នៅលើ Windows ជាទូទៅគឺជាបញ្ហាធ្ងន់ធ្ងរដាច់ដោយឡែកមួយ ដោយផ្អែកលើការពិតដែលថា Windows មិនមានអង្គចងចាំដែលបានចែករំលែកដូចគ្នាទៅនឹង UNIX ខណៈពេលដែល PostgreSQL ត្រូវបានចងភ្ជាប់ជាមួយនឹងបញ្ហានេះ ព្រោះវាជាប្រព័ន្ធពហុដំណើរការ។

ហើយខ្ញុំគិតថាអ្នកគ្រប់គ្នាមិនសូវចាប់អារម្មណ៍នឹងកម្រនិងអសកម្មដូច Solaris ដូច្នេះតោះទៅ។

ការចែកចាយលីនុចទំនើបមានជម្រើស syctl ជាង 1 អាស្រ័យលើរបៀបដែលអ្នកបង្កើតខឺណែល។ ក្នុងពេលជាមួយគ្នានេះ ប្រសិនបើយើងក្រឡេកមើលគ្រាប់ផ្សេងគ្នា យើងអាចកែសម្រួលអ្វីមួយតាមវិធីជាច្រើន។ មានប៉ារ៉ាម៉ែត្រប្រព័ន្ធឯកសារអំពីរបៀបម៉ោនពួកវា។ ប្រសិនបើអ្នកមានសំណួរអំពីរបៀបចាប់ផ្តើមវា: អ្វីដែលត្រូវបើកនៅក្នុង BIOS របៀបកំណត់ផ្នែករឹង។ល។

នេះគឺជាបរិមាណដ៏ច្រើនដែលអាចត្រូវបានពិភាក្សាក្នុងរយៈពេលជាច្រើនថ្ងៃ ហើយមិនមែននៅក្នុងរបាយការណ៍ខ្លីមួយនោះទេ ប៉ុន្តែឥឡូវនេះខ្ញុំនឹងផ្តោតលើរឿងសំខាន់ៗ របៀបជៀសវាងការតុងរួចដែលត្រូវបានធានាដើម្បីការពារអ្នកពីការប្រើប្រាស់មូលដ្ឋានទិន្នន័យរបស់អ្នកបានយ៉ាងល្អនៅលើលីនុច ប្រសិនបើអ្នក កុំកែពួកគេ។ ហើយក្នុងពេលជាមួយគ្នានេះ ចំណុចសំខាន់មួយគឺថា ប៉ារ៉ាម៉ែត្រលំនាំដើមជាច្រើនមិនត្រូវបានរួមបញ្ចូលនៅក្នុងការកំណត់ដែលត្រឹមត្រូវសម្រាប់មូលដ្ឋានទិន្នន័យនោះទេ។ នោះគឺតាមលំនាំដើម វានឹងដំណើរការមិនល្អ ឬអត់ទាល់តែសោះ។

តើ​គោល​ដៅ​កែ​សម្រួល​បែប​ប្រពៃណី​អ្វី​ខ្លះ​នៅ​ក្នុង​លីនុច? ខ្ញុំគិតថាចាប់តាំងពីអ្នកទាំងអស់កំពុងដោះស្រាយជាមួយការគ្រប់គ្រងលីនុច វាមិនចាំបាច់ពន្យល់ពីអ្វីដែលជាគោលដៅនោះទេ។

អ្នកអាចលៃតម្រូវ៖

• ស៊ីភីយូ។
• ការចងចាំ។
• ឧបករណ៍ផ្ទុក។
• ផ្សេងទៀត។ យើងនឹងនិយាយអំពីរឿងនេះនៅចុងបញ្ចប់សម្រាប់អាហារសម្រន់។ សូម្បីតែឧទាហរណ៍ ប៉ារ៉ាម៉ែត្រដូចជាគោលការណ៍សន្សំសំចៃថាមពលអាចប៉ះពាល់ដល់ដំណើរការក្នុងទម្រង់ដែលមិនអាចទាយទុកជាមុនបាន និងមិនមែនជាវិធីរីករាយបំផុតនោះទេ។

តើអ្វីជាលក្ខណៈពិសេសរបស់ PostgreSQL និងមូលដ្ឋានទិន្នន័យជាទូទៅ? បញ្ហាគឺថា អ្នកមិនអាចកែប្រែគ្រាប់នីមួយៗ ហើយឃើញថាដំណើរការរបស់យើងមានភាពប្រសើរឡើងគួរឱ្យកត់សម្គាល់។

បាទ មានឧបករណ៍បែបនេះ ប៉ុន្តែមូលដ្ឋានទិន្នន័យគឺជារឿងស្មុគស្មាញ។ វាធ្វើអន្តរកម្មជាមួយធនធានទាំងអស់ដែលម៉ាស៊ីនមេមាន ហើយចូលចិត្តធ្វើអន្តរកម្មឱ្យបានពេញលេញបំផុត។ ប្រសិនបើអ្នកក្រឡេកមើលការណែនាំបច្ចុប្បន្នរបស់ Oracle អំពីរបៀបប្រើប្រព័ន្ធប្រតិបត្តិការម៉ាស៊ីន វានឹងដូចជារឿងកំប្លែងអំពីអវកាសយានិកម៉ុងហ្គោលីនោះ - ចិញ្ចឹមឆ្កែ ហើយមិនប៉ះអ្វីទាំងអស់។ ចូរផ្តល់ឱ្យមូលដ្ឋានទិន្នន័យនូវធនធានទាំងអស់ មូលដ្ឋានទិន្នន័យខ្លួនឯងនឹងតម្រៀបអ្វីៗទាំងអស់ចេញ។

ជាគោលការណ៍ ក្នុងកម្រិតខ្លះ ស្ថានភាពគឺដូចគ្នាទៅនឹង PostgreSQL ។ ភាពខុសប្លែកគ្នានោះគឺថា មូលដ្ឋានទិន្នន័យមិនទាន់អាចយកធនធានទាំងអស់សម្រាប់ខ្លួនវានៅឡើយ ពោលគឺនៅកន្លែងណាមួយនៅកម្រិតលីនុច អ្នកត្រូវតម្រៀបវាចេញដោយខ្លួនឯង។

គំនិតចម្បងគឺមិនត្រូវជ្រើសរើសគោលដៅតែមួយ ហើយចាប់ផ្តើមលៃតម្រូវវា ឧទាហរណ៍ អង្គចងចាំ ស៊ីភីយូ ឬអ្វីមួយដូចនោះ ប៉ុន្តែដើម្បីវិភាគបន្ទុកការងារ និងព្យាយាមកែលម្អលំហូរឱ្យបានច្រើនតាមតែអាចធ្វើទៅបានដើម្បីឱ្យបន្ទុកដែលអ្នកសរសេរកម្មវិធីល្អបានបង្កើតវាឡើង។ សម្រាប់ពួកយើង រួមទាំងអ្នកប្រើប្រាស់របស់យើង។

នេះជារូបភាពដើម្បីពន្យល់ថាវាជាអ្វី។ មានសតិបណ្ដោះអាសន្ន Linux OS ហើយមានអង្គចងចាំចែករំលែក ហើយមានសតិបណ្ដោះអាសន្ន PostgreSQL ចែករំលែក។ PostgreSQL មិនដូច Oracle ដំណើរការដោយផ្ទាល់តែតាមរយៈ kernel buffer ពោលគឺ ដើម្បីឱ្យទំព័រមួយពី disk ចូលទៅក្នុង memory រួមរបស់វា វាត្រូវតែឆ្លងកាត់ kernel buffer និង back ស្ថានភាពដូចគ្នា។

ថាសរស់នៅក្រោមប្រព័ន្ធនេះ។ ខ្ញុំបានគូរវាជាថាស។ តាមការពិតអាចមានឧបករណ៍បញ្ជា RAID ។ល។

ហើយការបញ្ចូល-ទិន្នផលនេះតាមមធ្យោបាយមួយ ឬមួយផ្សេងទៀតកើតឡើងតាមរយៈបញ្ហានេះ។

PostgreSQL គឺជាមូលដ្ឋានទិន្នន័យបុរាណ។ មានទំព័រមួយនៅខាងក្នុង។ ហើយការបញ្ចូល និងលទ្ធផលទាំងអស់កើតឡើងដោយប្រើទំព័រ។ យើងកំពុងបង្កើនប្លុកទៅក្នុងការចងចាំជាមួយទំព័រ។ ហើយប្រសិនបើគ្មានអ្វីកើតឡើងទេ យើងគ្រាន់តែអានពួកវា បន្ទាប់មកពួកវាបាត់បន្តិចម្តងៗពីឃ្លាំងសម្ងាត់នេះ ពីសតិបណ្ដោះអាសន្នដែលបានចែករំលែក ហើយបញ្ចប់នៅលើថាសវិញ។

ប្រសិនបើយើងជំនួសអ្វីមួយនៅកន្លែងណាមួយ នោះទំព័រទាំងមូលត្រូវបានសម្គាល់ថាកខ្វក់។ ខ្ញុំបានសម្គាល់ពួកវានៅទីនេះជាពណ៌ខៀវ។ ហើយនេះមានន័យថាទំព័រនេះត្រូវតែធ្វើសមកាលកម្មជាមួយការផ្ទុកប្លុក។ នោះ​គឺ​នៅ​ពេល​ដែល​យើង​ធ្វើ​ឲ្យ​វា​កខ្វក់ យើង​បាន​ចូល​ក្នុង WAL។ ហើយនៅពេលវេលាដ៏អស្ចារ្យមួយ បាតុភូតមួយហៅថា ប៉ុស្តិ៍ត្រួតពិនិត្យបានមកដល់។ ហើយព័ត៌មានត្រូវបានកត់ត្រានៅក្នុងកំណត់ហេតុនេះដែលគាត់បានមកដល់។ ហើយនេះមានន័យថាទំព័រកខ្វក់ទាំងអស់ដែលមាននៅទីនេះនៅពេលនោះនៅក្នុងសតិបណ្ដោះអាសន្នដែលបានចែករំលែកទាំងនេះត្រូវបានធ្វើសមកាលកម្មជាមួយថាសផ្ទុកដោយប្រើ fsync តាមរយៈសតិបណ្ដោះអាសន្នខឺណែល។

ហេតុអ្វីបានជានេះត្រូវបានធ្វើ? ប្រសិនបើយើងបាត់បង់វ៉ុលនោះយើងមិនទទួលបានស្ថានភាពដែលទិន្នន័យទាំងអស់ត្រូវបានបាត់បង់នោះទេ។ ការចងចាំជាប់លាប់ ដែលមនុស្សគ្រប់គ្នាបានប្រាប់យើងអំពី រហូតមកដល់ពេលនេះនៅក្នុងទ្រឹស្ដីមូលដ្ឋានទិន្នន័យ - នេះគឺជាអនាគតដ៏ភ្លឺស្វាង ដែលជាការពិតណាស់ យើងខិតខំ ហើយយើងចូលចិត្តវា ប៉ុន្តែសម្រាប់ពេលនេះ ពួកគេរស់នៅក្នុងរយៈពេលដក 20 ឆ្នាំ។ ហើយជាការពិតណាស់ ទាំងអស់នេះត្រូវតែត្រួតពិនិត្យ។

ហើយ​ភារកិច្ច​នៃ​ការ​បង្កើន​ទិន្នផល​អតិបរមា​គឺ​ត្រូវ​សម្រួល​នៅ​គ្រប់​ដំណាក់កាល​ទាំង​អស់​នេះ ដើម្បី​ឱ្យ​វា​វិល​ទៅ​មុខ​យ៉ាង​លឿន។ អង្គចងចាំដែលបានចែករំលែកគឺជាឃ្លាំងសម្ងាត់ទំព័រ។ នៅក្នុង PostgreSQL យើងបានផ្ញើសំណួរជ្រើសរើស ឬអ្វីមួយ វាបានទាញយកទិន្នន័យនេះពីថាស។ ពួកគេបានបញ្ចប់នៅក្នុង buffers ចែករំលែក។ ដូច្នោះហើយដើម្បីឱ្យដំណើរការនេះកាន់តែប្រសើរឡើងត្រូវតែមានការចងចាំច្រើន។

ដើម្បីឱ្យអ្វីៗទាំងអស់នេះដំណើរការបានល្អ និងឆាប់រហ័ស អ្នកត្រូវកំណត់រចនាសម្ព័ន្ធប្រព័ន្ធប្រតិបត្តិការឱ្យបានត្រឹមត្រូវនៅគ្រប់ដំណាក់កាលទាំងអស់។ ហើយជ្រើសរើសផ្នែករឹងដែលមានតុល្យភាព ព្រោះប្រសិនបើអ្នកមានអតុល្យភាពនៅកន្លែងណាមួយ នោះអ្នកអាចបង្កើតអង្គចងចាំបានច្រើន ប៉ុន្តែវានឹងមិនត្រូវបានផ្តល់សេវាក្នុងល្បឿនគ្រប់គ្រាន់នោះទេ។

ហើយសូមឆ្លងកាត់ចំណុចនីមួយៗទាំងនេះ។

ដើម្បីធ្វើឱ្យទំព័រទាំងនេះធ្វើដំណើរទៅមកបានលឿនជាងមុន អ្នកត្រូវសម្រេចបានដូចខាងក្រោម៖

• ជាដំបូង អ្នកត្រូវធ្វើការឱ្យកាន់តែមានប្រសិទ្ធភាពជាមួយនឹងអង្គចងចាំ។
• ទីពីរ ការផ្លាស់ប្តូរនេះនៅពេលដែលទំព័រពីអង្គចងចាំទៅកាន់ថាសគួរតែមានប្រសិទ្ធភាពជាង។
• ហើយទីបីត្រូវតែមានថាសល្អ។

ប្រសិនបើអ្នកមាន RAM ទំហំ 512 GB នៅក្នុងម៉ាស៊ីនមេ ហើយអ្វីៗទាំងអស់នឹងបញ្ចប់នៅលើដ្រាយវ៍រឹង SATA ដោយគ្មានឃ្លាំងសម្ងាត់ណាមួយ នោះម៉ាស៊ីនមេមូលដ្ឋានទិន្នន័យទាំងមូលប្រែទៅជាមិនត្រឹមតែល្ពៅប៉ុណ្ណោះទេ ប៉ុន្តែល្ពៅដែលមានចំណុចប្រទាក់ SATA ។ អ្នកនឹងរត់ចូលទៅក្នុងវាដោយផ្ទាល់។ ហើយគ្មានអ្វីនឹងជួយសង្គ្រោះអ្នកបានទេ។

ទាក់ទង​នឹង​ចំណុច​ទីមួយ​ដែល​មាន​ការ​ចងចាំ​មាន​ចំណុច​បី​ដែល​អាច​ធ្វើ​ឲ្យ​ជីវិត​ជួប​ការ​លំបាក​ខ្លាំង។

ទីមួយក្នុងចំណោមពួកគេគឺ NUMA ។ NUMA គឺជារបស់ដែលបង្កើតឡើងដើម្បីកែលម្អដំណើរការ។ អាស្រ័យលើបន្ទុកការងារ អ្វីៗផ្សេងៗអាចត្រូវបានធ្វើឱ្យប្រសើរ។ ហើយនៅក្នុងទម្រង់បច្ចុប្បន្នថ្មីរបស់វា វាមិនល្អខ្លាំងណាស់សម្រាប់កម្មវិធីដូចជា មូលដ្ឋានទិន្នន័យដែលប្រើសតិបណ្ដោះអាសន្ននៃឃ្លាំងសម្ងាត់ទំព័រ។

នៅ​ក្នុង​ការ​សង្ខេប។ តើ​អ្នក​អាច​ដឹង​ថា​មាន​អ្វី​ខុស​ជាមួយ NUMA ដោយ​របៀប​ណា? អ្នក​មាន​ការ​គោះ​មិន​សប្បាយ​ចិត្ត ស្រាប់តែ CPU ខ្លះ​លើស​ទម្ងន់។ ក្នុងពេលជាមួយគ្នានេះអ្នកវិភាគសំណួរនៅក្នុង PostgreSQL ហើយឃើញថាមិនមានអ្វីស្រដៀងគ្នានៅទីនោះទេ។ សំណួរទាំងនេះមិនគួរមាន CPU ខ្លាំងពេកទេ។ អ្នកអាចចាប់វាបានរយៈពេលយូរ។ វាកាន់តែងាយស្រួលប្រើការណែនាំត្រឹមត្រូវតាំងពីដំបូងអំពីរបៀបកំណត់ NUMA សម្រាប់ PostgreSQL ។

តើមានអ្វីកើតឡើង? NUMA តំណាងឱ្យការចូលប្រើអង្គចងចាំមិនឯកសណ្ឋាន។ តើ​មាន​ចំណុច​អ្វី? អ្នកមានស៊ីភីយូ នៅក្បែរវាមានអង្គចងចាំមូលដ្ឋានរបស់វា។ ហើយអង្គចងចាំនេះអាចទាញអង្គចងចាំពីស៊ីភីយូផ្សេងទៀត។

ប្រសិនបើអ្នករត់ numactl --hardwareបន្ទាប់មកអ្នកនឹងទទួលបានសន្លឹកធំបែបនេះ។ ក្នុងចំណោមរបស់ផ្សេងទៀតនឹងមានវាលឆ្ងាយ។ វានឹងមានលេខ - 10-20 អ្វីមួយដូចនោះ។ លេខទាំងនេះគឺគ្មានអ្វីលើសពីចំនួន hops ដើម្បីយកអង្គចងចាំពីចម្ងាយនេះ ហើយប្រើវាក្នុងមូលដ្ឋាន។ ជាគោលការណ៍គំនិតល្អ។ នេះបង្កើនល្បឿនដំណើរការបានល្អនៅក្រោមជួរនៃបន្ទុកការងារ។

ឥឡូវស្រមៃថាអ្នកមានស៊ីភីយូមួយដំបូងព្យាយាមប្រើអង្គចងចាំមូលដ្ឋានរបស់វា បន្ទាប់មកព្យាយាមទាញអង្គចងចាំផ្សេងទៀតតាមរយៈការតភ្ជាប់អន្តរសម្រាប់អ្វីមួយ។ ហើយស៊ីភីយូនេះទទួលបានឃ្លាំងសម្ងាត់ទំព័រ PostgreSQL ទាំងមូលរបស់អ្នក - នោះហើយជាវា ជីហ្គាបៃមួយចំនួន។ អ្នកតែងតែជួបករណីដ៏អាក្រក់បំផុត ពីព្រោះនៅលើ CPU ជាធម្មតាមានអង្គចងចាំតិចតួចនៅក្នុងម៉ូឌុលនោះ។ ហើយអង្គចងចាំទាំងអស់ដែលត្រូវបានផ្តល់សេវាឆ្លងកាត់ការភ្ជាប់គ្នាទាំងនេះ។ វាប្រែចេញយឺតនិងសោកសៅ។ ហើយប្រព័ន្ធដំណើរការរបស់អ្នកដែលផ្តល់សេវាថ្នាំងនេះត្រូវបានផ្ទុកលើសទម្ងន់ឥតឈប់ឈរ។ ហើយពេលវេលាចូលប្រើអង្គចងចាំនេះគឺមិនល្អ យឺត។ នេះជាស្ថានភាពដែលអ្នកមិនចង់បាន ប្រសិនបើអ្នកកំពុងប្រើវាសម្រាប់មូលដ្ឋានទិន្នន័យ។

ដូច្នេះ ជម្រើសត្រឹមត្រូវជាងសម្រាប់មូលដ្ឋានទិន្នន័យគឺសម្រាប់ប្រព័ន្ធប្រតិបត្តិការលីនុច មិនដឹងថាមានអ្វីកើតឡើងនៅទីនោះទាល់តែសោះ។ ដើម្បីឱ្យវាចូលប្រើអង្គចងចាំដូចដែលវាធ្វើ។

ហេតុអ្វីបានជា​អញ្ចឹង? វាហាក់ដូចជាថាវាគួរតែជាមធ្យោបាយផ្សេងទៀត។ វាកើតឡើងសម្រាប់ហេតុផលសាមញ្ញមួយ: យើងត្រូវការអង្គចងចាំច្រើនសម្រាប់ឃ្លាំងសម្ងាត់ទំព័រ - ដប់, រាប់រយជីហ្គាបៃ។

ហើយប្រសិនបើយើងបែងចែកទាំងអស់នេះ ហើយទុកក្នុងឃ្លាំងសម្ងាត់ទិន្នន័យរបស់យើងនៅទីនោះ នោះផលចំណេញពីការប្រើប្រាស់ឃ្លាំងសម្ងាត់នឹងមានច្រើនជាងការទទួលបានពីការចូលប្រើអង្គចងចាំដ៏ពិបាកបែបនេះ។ ដូច្នេះហើយ យើងនឹងទទួលបានអត្ថប្រយោជន៍ដែលមិនអាចប្រៀបផ្ទឹមបានបើប្រៀបធៀបទៅនឹងការពិតដែលថាយើងនឹងចូលប្រើអង្គចងចាំកាន់តែមានប្រសិទ្ធភាពដោយប្រើ NUMA ។

ហេតុដូច្នេះហើយ មានវិធីសាស្រ្តពីរនៅទីនេះ រហូតទាល់តែអនាគតដ៏ភ្លឺស្វាងបានមកដល់ ហើយមូលដ្ឋានទិន្នន័យខ្លួនឯងមិនអាចកំណត់ថាតើស៊ីភីយូមួយណាដែលវាកំពុងដំណើរការ និងកន្លែងដែលវាត្រូវការទាញអ្វីមួយពីនោះ។

ដូច្នេះ វិធីសាស្រ្តត្រឹមត្រូវគឺត្រូវបិទ NUMA ទាំងអស់គ្នាឧទាហរណ៍នៅពេលចាប់ផ្តើមឡើងវិញ។ ក្នុងករណីភាគច្រើន ការឈ្នះគឺមានលំដាប់លំដោយ ដែលសំណួរថាមួយណាល្អជាងមិនកើតឡើងទាល់តែសោះ។

មានជម្រើសមួយផ្សេងទៀត។ យើងប្រើវាញឹកញាប់ជាងឧបករណ៍ទីមួយ ពីព្រោះនៅពេលដែលអតិថិជនមករកយើងសម្រាប់ការគាំទ្រ ការចាប់ផ្ដើមម៉ាស៊ីនមេឡើងវិញគឺជារឿងធំសម្រាប់គាត់។ គាត់មានអាជីវកម្មនៅទីនោះ។ ហើយពួកគេជួបប្រទះបញ្ហាដោយសារតែ NUMA ។ ដូច្នេះហើយ យើងព្យាយាមបិទវាតាមវិធីដែលរាតត្បាតតិចជាងការចាប់ផ្ដើមឡើងវិញ ប៉ុន្តែត្រូវប្រយ័ត្នដើម្បីពិនិត្យមើលថាវាត្រូវបានបិទ។ ដោយសារតែបទពិសោធន៍បង្ហាញ វាជាការល្អដែលយើងបិទ NUMA នៅលើដំណើរការ PostgreSQL មេ ប៉ុន្តែវាមិនចាំបាច់ទាល់តែសោះដែលវានឹងដំណើរការ។ យើង​ត្រូវ​ពិនិត្យ​មើល​ថា​នាង​ពិត​ជា​បាន​បិទ។

មានការប្រកាសដ៏ល្អដោយ Robert Haas ។ នេះគឺជាអ្នកចាត់ចែង PostgreSQL មួយ។ មួយក្នុងចំណោមអ្នកអភិវឌ្ឍន៍សំខាន់ៗនៃ giblets កម្រិតទាបទាំងអស់។ ហើយប្រសិនបើអ្នកធ្វើតាមតំណភ្ជាប់ពីការបង្ហោះនេះ ពួកគេពិពណ៌នាអំពីរឿងរ៉ាវចម្រុះពណ៌ជាច្រើនអំពីរបៀបដែល NUMA បានធ្វើឱ្យជីវិតលំបាកសម្រាប់មនុស្ស។ មើល សិក្សាបញ្ជីត្រួតពិនិត្យអ្នកគ្រប់គ្រងប្រព័ន្ធនៃអ្វីដែលត្រូវកំណត់រចនាសម្ព័ន្ធនៅលើម៉ាស៊ីនមេ ដើម្បីឱ្យមូលដ្ឋានទិន្នន័យរបស់យើងដំណើរការបានល្អ។ ការ​កំណត់​ទាំង​នេះ​ត្រូវ​សរសេរ​ចុះ ហើយ​ពិនិត្យ​មើល ព្រោះ​បើ​មិន​ដូច្នេះ​ទេ វា​នឹង​មិន​ល្អ​ខ្លាំង​ទេ។

សូមចំណាំថានេះអនុវត្តចំពោះការកំណត់ទាំងអស់ដែលខ្ញុំនឹងនិយាយ។ ប៉ុន្តែជាធម្មតា មូលដ្ឋានទិន្នន័យត្រូវបានប្រមូលនៅក្នុងរបៀបមេ - ទាសករសម្រាប់ការអត់ឱនចំពោះកំហុស។ កុំភ្លេចបង្កើតការកំណត់ទាំងនេះនៅលើទាសករ ព្រោះថ្ងៃណាមួយអ្នកនឹងជួបឧបទ្ទវហេតុ ហើយអ្នកនឹងប្តូរទៅជាទាសករ ហើយវានឹងក្លាយជាម្ចាស់។

ក្នុងស្ថានភាពអាសន្ន នៅពេលដែលអ្វីៗអាក្រក់ខ្លាំង ទូរសព្ទរបស់អ្នករោទ៍ឥតឈប់ឈរ ហើយចៅហ្វាយរបស់អ្នករត់មកជាមួយដំបងធំ នោះអ្នកនឹងគ្មានពេលគិតអំពីការត្រួតពិនិត្យនោះទេ។ ហើយលទ្ធផលអាចជាមហន្តរាយណាស់។

ចំណុចបន្ទាប់គឺទំព័រធំ។ ទំព័រដ៏ធំគឺពិបាកក្នុងការសាកល្បងដោយឡែកពីគ្នា ហើយគ្មានចំណុចណាក្នុងការធ្វើដូច្នេះទេ បើទោះបីជាមានស្តង់ដារដែលអាចធ្វើដូចនេះក៏ដោយ។ ពួកគេងាយស្រួល Google ។

តើ​មាន​ចំណុច​អ្វី? អ្នកមានម៉ាស៊ីនមេមិនថ្លៃខ្លាំងដែលមាន RAM ច្រើន ឧទាហរណ៍លើសពី 30 GB។ អ្នកមិនប្រើទំព័រធំទេ។ នេះមានន័យថាអ្នកពិតជាមានការចំណាយលើសនៅក្នុងលក្ខខណ្ឌនៃការប្រើប្រាស់អង្គចងចាំ។ ហើយការលើសនេះគឺនៅឆ្ងាយពីភាពរីករាយបំផុត។

ហេតុអ្វីបានជា​អញ្ចឹង? ដូច្នេះ​តើ​មាន​អ្វី​កើត​ឡើង? ប្រព័ន្ធប្រតិបត្តិការបែងចែកអង្គចងចាំជាបំណែកតូចៗ។ វាងាយស្រួលណាស់ វាជារបៀបដែលវាបានកើតឡើងជាប្រវត្តិសាស្ត្រ។ ហើយប្រសិនបើយើងសិក្សាលម្អិតនោះ OS ត្រូវតែបកប្រែអាសយដ្ឋាននិម្មិតទៅជារូបវន្ត។ ហើយដំណើរការនេះមិនសាមញ្ញបំផុតនោះទេ ដូច្នេះប្រព័ន្ធប្រតិបត្តិការបានរក្សាទុកលទ្ធផលនៃប្រតិបត្តិការនេះនៅក្នុងការបកប្រែ Lookaside Buffer (TLB)។

ហើយចាប់តាំងពី TLB គឺជាឃ្លាំងសម្ងាត់ បញ្ហាទាំងអស់ដែលមាននៅក្នុងឃ្លាំងសម្ងាត់កើតឡើងក្នុងស្ថានភាពនេះ។ ទីមួយ ប្រសិនបើអ្នកមាន RAM ច្រើន ហើយវាត្រូវបានបែងចែកទៅជាបំណែកតូចៗ នោះសតិបណ្ដោះអាសន្ននេះនឹងក្លាយទៅជាធំណាស់។ ហើយប្រសិនបើឃ្លាំងសម្ងាត់មានទំហំធំ នោះការស្វែងរកតាមរយៈវាគឺយឺតជាង។ Overhead គឺមានសុខភាពល្អ ហើយខ្លួនវាត្រូវការទំហំផ្ទុក ពោលគឺ RAM កំពុងត្រូវបានប្រើប្រាស់ដោយអ្វីដែលមិនត្រឹមត្រូវ។ ពេលនេះ។

ពីរ - ឃ្លាំងសម្ងាត់កាន់តែកើនឡើងក្នុងស្ថានភាពបែបនេះ វាទំនងជាថាអ្នកនឹងមានការបាត់ឃ្លាំងសម្ងាត់។ ហើយប្រសិទ្ធភាពនៃឃ្លាំងសម្ងាត់នេះថយចុះយ៉ាងឆាប់រហ័សនៅពេលដែលទំហំរបស់វាកើនឡើង។ ដូច្នេះ ប្រព័ន្ធប្រតិបត្តិការបានមកជាមួយវិធីសាស្រ្តសាមញ្ញមួយ។ វា​ត្រូវ​បាន​ប្រើ​ក្នុង​លីនុច​ជា​យូរ​មក​ហើយ។ វាបានបង្ហាញខ្លួននៅក្នុង FreeBSD មិនយូរប៉ុន្មានទេ។ ប៉ុន្តែយើងកំពុងនិយាយអំពីលីនុច។ ទាំងនេះគឺជាទំព័រដ៏ធំ។

ហើយនៅទីនេះវាគួរតែត្រូវបានកត់សម្គាល់ថាទំព័រដ៏ធំដែលជាគំនិតមួយត្រូវបានជំរុញដោយសហគមន៍ដែលរួមបញ្ចូល Oracle និង IBM ពោលគឺក្រុមហ៊ុនផលិតមូលដ្ឋានទិន្នន័យគិតយ៉ាងខ្លាំងថាវានឹងមានប្រយោជន៍សម្រាប់មូលដ្ឋានទិន្នន័យផងដែរ។

ហើយតើនេះអាចក្លាយជាមិត្តជាមួយ PostgreSQL យ៉ាងដូចម្តេច? ទីមួយ ទំព័រធំៗត្រូវតែបើកនៅក្នុងខឺណែលលីនុច។

ទីពីរ ពួកគេត្រូវតែបញ្ជាក់យ៉ាងច្បាស់ដោយប៉ារ៉ាម៉ែត្រ sysctl - តើមានប៉ុន្មាន។ លេខនៅទីនេះគឺមកពីម៉ាស៊ីនមេចាស់មួយចំនួន។ អ្នក​អាច​គណនា​ថា​តើ​អ្នក​មាន​បណ្ដោះ​អាសន្ន​ដែល​បាន​ចែក​រំលែក​ប៉ុន្មាន​ដើម្បី​ឱ្យ​ទំព័រ​ធំ​អាច​សម​នឹង​ទីនោះ។

ហើយប្រសិនបើម៉ាស៊ីនមេទាំងមូលរបស់អ្នកត្រូវបានឧទ្ទិសដល់ PostgreSQL នោះចំណុចចាប់ផ្តើមដ៏ល្អគឺត្រូវបែងចែក RAM ទាំង 25% ទៅ buffers ដែលបានចែករំលែក ឬ 75% ប្រសិនបើអ្នកប្រាកដថាមូលដ្ឋានទិន្នន័យរបស់អ្នកពិតជាសមនឹង 75% នេះ។ ចំណុចចាប់ផ្តើមទី១។ ហើយពិចារណាប្រសិនបើអ្នកមាន RAM 256 GB នោះអ្នកនឹងមាន 64 GB នៃ buffers ធំ។ គណនាប្រមាណជាមួយរឹមខ្លះ - តើតួលេខនេះគួរកំណត់ទៅជាអ្វី។

មុនពេលកំណែ 9.2 (ប្រសិនបើខ្ញុំមិនច្រឡំទេ ចាប់តាំងពីកំណែ 8.2) វាអាចភ្ជាប់ PostgreSQL ជាមួយនឹងទំព័រដ៏ធំដោយប្រើបណ្ណាល័យភាគីទីបី។ ហើយនេះគួរតែត្រូវបានធ្វើជានិច្ច។ ដំបូង អ្នកត្រូវការខឺណែល ដើម្បីអាចបែងចែកទំព័រដ៏ធំបានត្រឹមត្រូវ។ ហើយទីពីរដើម្បីឱ្យកម្មវិធីដែលធ្វើការជាមួយពួកគេអាចប្រើវាបាន។ វានឹងមិនគ្រាន់តែប្រើវិធីនោះទេ។ ចាប់តាំងពី PostgreSQL បែងចែកអង្គចងចាំក្នុងរចនាប័ទ្មប្រព័ន្ធ 5 នេះអាចត្រូវបានធ្វើដោយប្រើ libhugetlbfs - នេះគឺជាឈ្មោះពេញរបស់បណ្ណាល័យ។

នៅក្នុង 9.3 ការអនុវត្ត PostgreSQL ត្រូវបានធ្វើឱ្យប្រសើរឡើងនៅពេលធ្វើការជាមួយអង្គចងចាំ ហើយប្រព័ន្ធ 5 វិធីសាស្ត្របែងចែកអង្គចងចាំត្រូវបានបោះបង់ចោល។ គ្រប់គ្នាសប្បាយចិត្តខ្លាំងណាស់ ព្រោះបើមិនដូច្នេះទេ អ្នកព្យាយាមដំណើរការកម្មវិធី PostgreSQL ពីរនៅលើម៉ាស៊ីនតែមួយ ហើយគាត់និយាយថាខ្ញុំមិនមានអង្គចងចាំចែករំលែកគ្រប់គ្រាន់ទេ។ ហើយគាត់និយាយថា sysctl ត្រូវតែកែតម្រូវ។ ហើយមាន sysctl បែបនេះដែលអ្នកនៅតែត្រូវចាប់ផ្តើមឡើងវិញ។ល។ ជាទូទៅ អ្នកគ្រប់គ្នាសប្បាយចិត្ត។ ប៉ុន្តែការបែងចែកអង្គចងចាំ mmap បានបំបែកការប្រើប្រាស់ទំព័រដ៏ធំ។ អតិថិជនរបស់យើងភាគច្រើនប្រើ buffers ចែករំលែកធំ។ ហើយយើងបានផ្តល់អនុសាសន៍យ៉ាងមុតមាំមិនឱ្យប្តូរទៅ 9.3 ទេ ពីព្រោះតម្លៃលើសនៅទីនោះបានចាប់ផ្តើមត្រូវបានគណនាជាភាគរយដ៏ល្អ។

ប៉ុន្តែសហគមន៍បានយកចិត្តទុកដាក់ចំពោះបញ្ហានេះ ហើយនៅក្នុង 9.4 ពួកគេបានដំណើរការព្រឹត្តិការណ៍នេះឡើងវិញបានយ៉ាងល្អ។ ហើយនៅក្នុង 9.4 ប៉ារ៉ាម៉ែត្រមួយបានបង្ហាញខ្លួននៅក្នុង postgresql.conf ដែលអ្នកអាចបើកសាកល្បង បើក ឬបិទ។

សាកល្បងគឺជាជម្រើសដែលមានសុវត្ថិភាពបំផុត។ នៅពេលដែល PostgreSQL ចាប់ផ្តើម នៅពេលដែលវាបែងចែកអង្គចងចាំដែលបានចែករំលែក វាព្យាយាមចាប់យកអង្គចងចាំនេះពីទំព័រដ៏ធំ។ ហើយប្រសិនបើវាមិនដំណើរការ នោះវានឹងវិលត្រលប់ទៅជម្រើសធម្មតាវិញ។ ហើយប្រសិនបើអ្នកមាន FreeBSD ឬ Solaris នោះអ្នកអាចសាកល្បងបាន វាតែងតែមានសុវត្ថិភាព។

ប្រសិនបើបើក នោះវាមិនចាប់ផ្តើមទេ ប្រសិនបើវាមិនអាចជ្រើសរើសពីទំព័រធំៗ។ នៅទីនេះវានិយាយអំពីអ្នកណានិងអ្វីដែលល្អជាង។ ប៉ុន្តែ​ប្រសិន​បើ​អ្នក​បាន​ព្យាយាម សូម​ពិនិត្យ​មើល​ថា​អ្នក​ពិត​ជា​មាន​អ្វី​ដែល​អ្នក​ត្រូវ​ការ​គូស​បញ្ជាក់ ព្រោះ​មាន​ចន្លោះ​ច្រើន​សម្រាប់​កំហុស។ បច្ចុប្បន្នមុខងារនេះដំណើរការតែលើលីនុចប៉ុណ្ណោះ។

កំណត់ចំណាំតូចមួយទៀត មុនពេលយើងបន្តទៅមុខទៀត។ ទំព័រដ៏ធំដែលមានតម្លាភាព មិនទាន់និយាយអំពី PostgreSQL នៅឡើយទេ។ គាត់មិនអាចប្រើជាធម្មតាបានទេ។ ហើយជាមួយនឹងទំព័រដ៏ធំដែលមានតម្លាភាពសម្រាប់បន្ទុកការងារបែបនេះ នៅពេលដែលផ្នែកធំនៃអង្គចងចាំដែលបានចែករំលែកត្រូវបានត្រូវការ អត្ថប្រយោជន៍បានមកតែជាមួយនឹងទំហំធំប៉ុណ្ណោះ។ ប្រសិនបើអ្នកមានអង្គចងចាំ terabytes នោះវាអាចនឹងចូលមកលេង។ ប្រសិនបើយើងកំពុងនិយាយអំពីកម្មវិធីប្រចាំថ្ងៃកាន់តែច្រើន នៅពេលដែលអ្នកមានអង្គចងចាំ 32, 64, 128, 256 GB នៅលើម៉ាស៊ីនរបស់អ្នក នោះទំព័រធំៗធម្មតាគឺ Ok ហើយយើងគ្រាន់តែបិទ Transparent ប៉ុណ្ណោះ។

ហើយ​រឿង​ចុងក្រោយ​អំពី​ការ​ចងចាំ​មិន​ទាក់ទង​ផ្ទាល់​នឹង​ផ្លែ​ឈើ​ទេ វា​ពិតជា​អាច​បំផ្លាញ​ជីវិត​អ្នក​បាន​។ ដំណើរការទាំងអស់នឹងរងផលប៉ះពាល់យ៉ាងខ្លាំងដោយការពិតដែលថាម៉ាស៊ីនមេកំពុងផ្លាស់ប្តូរជានិច្ច។

ហើយនេះនឹងជាការមិនសប្បាយចិត្តខ្លាំងណាស់នៅក្នុងវិធីមួយចំនួន។ ហើយបញ្ហាចម្បងគឺថា ខឺណែលទំនើបមានឥរិយាបទខុសគ្នាបន្តិចពីខឺណែលលីនុចចាស់។ ហើយរឿងនេះពិតជាមិនសប្បាយចិត្តក្នុងការបោះជំហានទៅមុខ ពីព្រោះនៅពេលដែលយើងនិយាយអំពីប្រភេទនៃការងារមួយចំនួនជាមួយ swap វាបញ្ចប់ដោយការមកដល់នៃឃាតករ OOM ដោយមិនទាន់ពេលវេលា។ ហើយឃាតករ OOM ដែលមិនបានមកដល់ទាន់ពេល និងទម្លាក់ PostgreSQL គឺមិនសប្បាយចិត្តទេ។ អ្នករាល់គ្នានឹងដឹងអំពីរឿងនេះ ពោលគឺរហូតដល់អ្នកប្រើប្រាស់ចុងក្រោយ។

តើ​មាន​រឿង​អ្វី​កើតឡើង? អ្នកមាន RAM ច្រើននៅទីនោះ អ្វីៗដំណើរការបានល្អ។ ប៉ុន្តែសម្រាប់ហេតុផលមួយចំនួន ម៉ាស៊ីនមេព្យួរក្នុងការផ្លាស់ប្តូរ ហើយថយចុះដោយសារតែបញ្ហានេះ។ វាហាក់ដូចជាមានការចងចាំច្រើន ប៉ុន្តែរឿងនេះកើតឡើង។

ពីមុន យើងបានណែនាំឱ្យកំណត់ vm.swappiness ទៅសូន្យ ពោលគឺបិទការ swap ។ កាលពីមុនវាហាក់ដូចជាថា 32 GB នៃ RAM និង buffers ដែលត្រូវគ្នាគឺជាចំនួនដ៏ធំ។ គោល​បំណង​សំខាន់​នៃ​ការ​ដោះដូរ​គឺ​ដើម្បី​មាន​កន្លែង​សម្រាប់​បោះ​សំបក​ចោល​ប្រសិន​បើ​យើង​ធ្លាក់​ចេញ។ ហើយវាមិនត្រូវបានបំពេញជាពិសេសទៀតទេ។ ហើយបន្ទាប់មកតើអ្នកនឹងធ្វើអ្វីជាមួយសំបកនេះ? នេះគឺជាកិច្ចការដែលវាមិនច្បាស់ថាហេតុអ្វីបានជាត្រូវការការផ្លាស់ប្តូរ ជាពិសេសទំហំបែបនេះ។

ប៉ុន្តែនៅក្នុងសម័យទំនើបបន្ថែមទៀត ពោលគឺកំណែទីបីនៃខឺណែល ឥរិយាបថបានផ្លាស់ប្តូរ។ ហើយប្រសិនបើអ្នកកំណត់ swap ទៅសូន្យ ពោលគឺបិទវា នោះមិនយូរមិនឆាប់ បើទោះបីជានៅសល់ RAM ខ្លះក៏ដោយ ឃាតករ OOM នឹងមករកអ្នកដើម្បីសម្លាប់អ្នកប្រើប្រាស់ដែលពឹងផ្អែកខ្លាំងបំផុត។ ដោយសារតែគាត់នឹងពិចារណាថា ជាមួយនឹងបន្ទុកការងារបែបនេះ យើងនៅមានសល់បន្តិចបន្តួច ហើយយើងនឹងលោតចេញ ពោលគឺមិនមែនដើម្បីទម្លាក់កំហុសលើដំណើរការប្រព័ន្ធនោះទេ ប៉ុន្តែត្រូវកំណត់អ្វីដែលមិនសូវសំខាន់។ អ្នកដែលមិនសូវសំខាន់នេះនឹងក្លាយជាអ្នកប្រើប្រាស់ដែលពឹងផ្អែកខ្លាំងនៃការចងចាំរួម ពោលគឺមេប្រៃសណីយ៍។ ហើយបន្ទាប់ពីនោះវានឹងល្អប្រសិនបើមូលដ្ឋានមិនចាំបាច់ត្រូវបានស្តារឡើងវិញទេ។

ដូច្នេះហើយ ឥឡូវនេះ លំនាំដើម តាមខ្ញុំចាំ ការចែកចាយភាគច្រើនគឺនៅកន្លែងណាមួយនៅជុំវិញ 6 ពោលគឺនៅត្រង់ចំណុចណាដែលអ្នកគួរចាប់ផ្តើមប្រើ swap អាស្រ័យលើចំនួនអង្គចងចាំដែលនៅសល់។ ឥឡូវនេះ យើងសូមណែនាំឱ្យកំណត់ vm.swappiness = 1 ពីព្រោះវាបិទវា ប៉ុន្តែមិនផ្តល់ផលប៉ះពាល់ដូចទៅនឹង OOM-killer ដែលបានមកដល់ដោយមិនបានរំពឹងទុក និងសម្លាប់អ្វីៗទាំងអស់។

មាន​អ្វី​បន្ទាប់? នៅពេលយើងនិយាយអំពីដំណើរការនៃមូលដ្ឋានទិន្នន័យ ហើយបណ្តើរឆ្ពោះទៅរកថាស មនុស្សគ្រប់គ្នាចាប់ផ្តើមចាប់ក្បាលរបស់ពួកគេ។ ដោយសារតែការពិតដែលថាថាសយឺតហើយការចងចាំលឿនគឺស្គាល់គ្រប់គ្នាតាំងពីកុមារភាព។ ហើយអ្នករាល់គ្នាដឹងថាមូលដ្ឋានទិន្នន័យនឹងមានបញ្ហាដំណើរការថាស។

បញ្ហាដំណើរការ PostgreSQL ចម្បងដែលទាក់ទងនឹងការបង្កើនចំណុចត្រួតពិនិត្យមិនកើតឡើងទេព្រោះថាសយឺត។ នេះទំនងជាដោយសារតែអង្គចងចាំ និងកម្រិតបញ្ជូនថាសមិនមានតុល្យភាព។ ទោះយ៉ាងណាក៏ដោយ ពួកគេប្រហែលជាមិនមានតុល្យភាពនៅកន្លែងផ្សេងៗគ្នាទេ។ PostgreSQL មិន​ត្រូវ​បាន​កំណត់​រចនាសម្ព័ន្ធ OS មិន​ត្រូវ​បាន​កំណត់​រចនាសម្ព័ន្ធ Hardware មិន​ត្រូវ​បាន​កំណត់​រចនាសម្ព័ន្ធ ហើយ Hardware មិន​ត្រឹមត្រូវ។ ហើយបញ្ហានេះមិនកើតឡើង លុះត្រាតែអ្វីៗកើតឡើងដូចដែលវាគួរតែ ពោលគឺមិនមានការផ្ទុក ឬការកំណត់ និងផ្នែករឹងត្រូវបានជ្រើសរើសយ៉ាងល្អ។

តើ​វា​ជា​អ្វី ហើយ​មាន​រូបរាង​យ៉ាង​ណា? ជាធម្មតាមនុស្សដែលធ្វើការជាមួយ PostgreSQL បានចូលទៅក្នុងបញ្ហានេះច្រើនជាងម្តង។ ខ្ញុំនឹងពន្យល់។ ដូចដែលខ្ញុំបាននិយាយ PostgreSQL ជាទៀងទាត់ធ្វើការត្រួតពិនិត្យដើម្បីបោះចោលទំព័រកខ្វក់នៅក្នុងអង្គចងចាំដែលបានចែករំលែកទៅថាស។ ប្រសិនបើយើងមានអង្គចងចាំដែលបានចែករំលែកច្រើន នោះចំណុចត្រួតពិនិត្យចាប់ផ្តើមមានផលប៉ះពាល់ខ្លាំងលើថាស ព្រោះវាធ្វើឱ្យទំព័រទាំងនេះបិទដោយ fsync ។ វាមកដល់សតិបណ្ដោះអាសន្នខឺណែល ហើយត្រូវបានសរសេរទៅថាសដោយប្រើ fsync ។ ហើយប្រសិនបើបរិមាណនៃអាជីវកម្មនេះមានទំហំធំ នោះយើងអាចសង្កេតឃើញនូវឥទ្ធិពលមិនល្អមួយ ពោលគឺការប្រើប្រាស់ឌីសយ៉ាងច្រើន។

នៅទីនេះខ្ញុំមានរូបភាពពីរ។ ឥឡូវនេះខ្ញុំនឹងពន្យល់ថាវាជាអ្វី។ ទាំងនេះគឺជាក្រាហ្វដែលទាក់ទងគ្នានឹងពេលវេលា។ ក្រាហ្វទីមួយគឺការប្រើប្រាស់ថាស។ នៅទីនេះវាឈានដល់ជិត 90% នៅពេលនេះ។ ប្រសិនបើអ្នកមានការបរាជ័យនៃមូលដ្ឋានទិន្នន័យជាមួយថាសរាងកាយ ជាមួយនឹងការប្រើប្រាស់ឧបករណ៍បញ្ជា RAID នៅ 90% នោះនេះគឺជាដំណឹងអាក្រក់។ នេះមានន័យថាបន្តិចទៀតវានឹងឈានដល់ 100 ហើយ I/O នឹងឈប់។

ប្រសិនបើអ្នកមានអារេឌីស នោះវាជារឿងខុសគ្នាបន្តិច។ វា​អាស្រ័យ​លើ​របៀប​ដែល​វា​ត្រូវ​បាន​កំណត់​រចនាសម្ព័ន្ធ​ប្រភេទ​នៃ​អារេ។ល។

ហើយស្របគ្នា ក្រាហ្វពីទិដ្ឋភាពក្រោយហ្គ្រេសខាងក្នុងត្រូវបានកំណត់រចនាសម្ព័ន្ធនៅទីនេះ ដែលប្រាប់ពីរបៀបដែលចំណុចត្រួតពិនិត្យកើតឡើង។ ហើយ​ពណ៌​បៃតង​នៅ​ទីនេះ​បង្ហាញ​ពី​ចំនួន​សតិបណ្ដោះ​អាសន្ន ទំព័រ​កខ្វក់​ទាំង​នេះ​នៅ​ពេល​នោះ​បាន​មក​ដល់​ចំណុច​ត្រួតពិនិត្យ​នេះ​ដើម្បី​ធ្វើ​សមកាលកម្ម។ ហើយនេះគឺជារឿងសំខាន់ដែលអ្នកត្រូវដឹងនៅទីនេះ។ យើងឃើញថាយើងមានទំព័រជាច្រើននៅទីនេះ ហើយនៅចំណុចខ្លះយើងបុកក្តារ ពោលគឺយើងសរសេរ និងសរសេរនៅទីនេះ ប្រព័ន្ធថាសគឺច្បាស់ណាស់រវល់ណាស់។ ហើយប៉ុស្តិ៍ត្រួតពិនិត្យរបស់យើងមានឥទ្ធិពលយ៉ាងខ្លាំងទៅលើថាស។ តាមឧត្ដមគតិ ស្ថានភាពគួរតែមើលទៅដូចនេះ ឧ. យើងមិនសូវបានថតនៅទីនេះទេ។ ហើយ​យើង​អាច​ជួសជុល​វា​ជាមួយ​នឹង​ការ​កំណត់​ដើម្បី​ឱ្យ​វា​បន្ត​ដូច​នេះ​។ នោះគឺការកែច្នៃឡើងវិញគឺតូច ប៉ុន្តែកន្លែងណាមួយយើងកំពុងសរសេរអ្វីមួយនៅទីនេះ។

តើត្រូវធ្វើអ្វីដើម្បីជំនះបញ្ហានេះ? ប្រសិនបើអ្នកបានបញ្ឈប់ IO នៅក្រោមមូលដ្ឋានទិន្នន័យ នេះមានន័យថាអ្នកប្រើប្រាស់ទាំងអស់ដែលបានមកបំពេញសំណើរបស់ពួកគេនឹងរង់ចាំ។

ប្រសិនបើអ្នកក្រឡេកមើលពីទិដ្ឋភាពនៃលីនុច ប្រសិនបើអ្នកបានយកផ្នែករឹងល្អ កំណត់រចនាសម្ព័ន្ធវាឱ្យបានត្រឹមត្រូវ កំណត់រចនាសម្ព័ន្ធ PostgreSQL ជាធម្មតា ដូច្នេះវាធ្វើឱ្យចំណុចត្រួតពិនិត្យទាំងនេះមិនសូវញឹកញាប់ រាលដាលពួកវាតាមពេលវេលារវាងគ្នាទៅវិញទៅមក បន្ទាប់មកអ្នកចូលទៅក្នុងប៉ារ៉ាម៉ែត្រ Debian លំនាំដើម។ សម្រាប់ការចែកចាយលីនុចភាគច្រើន នេះជារូបភាព៖ vm.dirty_ratio=20, vm.dirty_background_ratio=10។

តើ​វា​មានន័យ​យ៉ាង​ដូចម្តេច? បិសាចជញ្ជក់ឈាមមួយបានបង្ហាញខ្លួនពីខឺណែល 2.6 ។ Pdglush អាស្រ័យលើអ្នកដែលកំពុងប្រើ ដែលចូលរួមក្នុងការចោលផ្ទៃខាងក្រោយនៃទំព័រកខ្វក់ចេញពីសតិបណ្ដោះអាសន្នខឺណែល ហើយបោះចោលនៅពេលដែលចាំបាច់ត្រូវបោះបង់ទំព័រដែលកខ្វក់ មិនថាមានរឿងអ្វីនោះទេ នៅពេលដែលការបោះចោលទំព័រខាងក្រោយមិនអាចជួយបានទេ។

តើផ្ទៃខាងក្រោយមកដល់នៅពេលណា? នៅពេលដែល 10% នៃ RAM សរុបដែលមាននៅលើម៉ាស៊ីនមេត្រូវបានកាន់កាប់ដោយទំព័រកខ្វក់នៅក្នុងសតិបណ្ដោះអាសន្នខឺណែល មុខងារបិទពិសេសត្រូវបានហៅនៅផ្ទៃខាងក្រោយ។ ហេតុអ្វីបានជាផ្ទៃខាងក្រោយ? ជាប៉ារ៉ាម៉ែត្រ វាត្រូវគិតគូរពីចំនួនទំព័រដែលត្រូវសរសេរចេញ។ ហើយឧបមាថាគាត់សរសេរចេញពីទំព័រ N ។ ហើយមួយសន្ទុះរឿងនេះក៏ដេកលក់។ ហើយបន្ទាប់មកនាងមកម្តងទៀតហើយចម្លងទំព័រមួយចំនួនទៀត។

នេះគឺជារឿងដ៏សាមញ្ញបំផុត។ បញ្ហានៅទីនេះគឺដូចជាអាងហែលទឹក ពេលដែលវាចាក់ចូលទៅក្នុងបំពង់មួយ វាហូរចូលទៅក្នុងមួយទៀត។ ប៉ុស្តិ៍ត្រួតពិនិត្យរបស់យើងបានមកដល់ ហើយប្រសិនបើវាផ្ញើទំព័រកខ្វក់ពីរបីសម្រាប់ការបោះចោល នោះបន្តិចម្តងៗ អ្វីៗទាំងអស់នឹងត្រូវបានដោះស្រាយយ៉ាងស្អាតពីខឺណែលសតិបណ្ដោះអាសន្ន pgflush ។

ប្រសិនបើទំព័រកខ្វក់ទាំងនេះនៅតែបន្តកកកុញ វានឹងកកកុញរហូតដល់ 20% បន្ទាប់មកអាទិភាព OS គឺត្រូវសរសេរអ្វីៗទាំងអស់ទៅថាស ព្រោះថាមពលនឹងបរាជ័យ ហើយអ្វីៗនឹងអាក្រក់សម្រាប់យើង។ ឧទាហរណ៍ យើងនឹងបាត់បង់ទិន្នន័យនេះ។

តើល្បិចអ្វី? ល្បិចគឺថាប៉ារ៉ាម៉ែត្រទាំងនេះនៅក្នុងពិភពសម័យទំនើបគឺ 20 និង 10% នៃ RAM សរុបដែលមាននៅលើម៉ាស៊ីនពួកគេពិតជាអស្ចារ្យណាស់នៅក្នុងលក្ខខណ្ឌនៃដំណើរការនៃប្រព័ន្ធឌីសណាមួយដែលអ្នកមាន។

ស្រមៃថាអ្នកមាន RAM 128 GB ។ 12,8 GB មកដល់ប្រព័ន្ធឌីសរបស់អ្នក។ ហើយ​មិន​ថា​ឃ្លាំង​សម្ងាត់​ណា​ដែល​អ្នក​មាន​នៅ​ទីនោះ មិន​ថា​អារេ​ណា​ដែល​អ្នក​មាន​នៅ​ទីនោះ​ទេ វា​នឹង​មិន​មាន​រយៈពេល​យូរ​នោះ​ទេ​។

ដូច្នេះហើយ យើងសូមណែនាំឱ្យអ្នកកែសម្រួលលេខទាំងនេះភ្លាមៗ ដោយផ្អែកលើសមត្ថភាពរបស់ឧបករណ៍បញ្ជា RAID របស់អ្នក។ ភ្លាមៗខ្ញុំបានផ្តល់អនុសាសន៍នៅទីនេះសម្រាប់ឧបករណ៍បញ្ជាដែលមានឃ្លាំងសម្ងាត់ 512 MB ។

អ្វីគ្រប់យ៉ាងត្រូវបានចាត់ទុកថាសាមញ្ញណាស់។ អ្នកអាចដាក់ vm.dirty_background ជាបៃ។ ហើយការកំណត់ទាំងនេះលុបចោលពីរមុន។ សមាមាត្រទាំងពីរគឺតាមលំនាំដើម ឬអ្នកដែលមានបៃត្រូវបានធ្វើឱ្យសកម្ម បន្ទាប់មកអ្នកដែលមានបៃនឹងដំណើរការ។ ប៉ុន្តែដោយសារខ្ញុំជាអ្នកប្រឹក្សា DBA និងធ្វើការជាមួយអតិថិជនផ្សេងៗគ្នា ខ្ញុំព្យាយាមគូរចំបើង ហើយដូច្នេះប្រសិនបើគិតជាបៃ បន្ទាប់មកគិតជាបៃ។ គ្មាននរណាម្នាក់ផ្តល់ការធានាណាមួយថាអ្នកគ្រប់គ្រងល្អនឹងមិនបន្ថែមអង្គចងចាំបន្ថែមទៅម៉ាស៊ីនមេ ចាប់ផ្ដើមវាឡើងវិញ ហើយតួលេខនឹងនៅដដែល។ គ្រាន់តែគណនាលេខទាំងនេះដើម្បីឱ្យអ្វីគ្រប់យ៉ាងសមនឹងនៅទីនោះជាមួយនឹងការធានា។

តើមានអ្វីកើតឡើងប្រសិនបើអ្នកមិនសម? ខ្ញុំបានសរសេរថា ការហូរចេញណាមួយត្រូវបានបញ្ឈប់យ៉ាងមានប្រសិទ្ធភាព ប៉ុន្តែតាមពិតនេះគឺជាតួលេខនៃការនិយាយ។ ប្រព័ន្ធប្រតិបត្តិការមានបញ្ហាធំ - វាមានទំព័រកខ្វក់ជាច្រើន ដូច្នេះ IO ដែលអតិថិជនរបស់អ្នកបង្កើតត្រូវបានបញ្ឈប់យ៉ាងមានប្រសិទ្ធភាព ពោលគឺកម្មវិធីបានមកដើម្បីផ្ញើសំណួរ sql ទៅមូលដ្ឋានទិន្នន័យ វាកំពុងរង់ចាំ។ រាល់ការបញ្ចូល/ទិន្នផលទៅវាគឺមានអាទិភាពទាបបំផុត ពីព្រោះមូលដ្ឋានទិន្នន័យត្រូវបានកាន់កាប់ដោយចំណុចត្រួតពិនិត្យ។ ហើយនៅពេលណាដែលនាងនឹងបញ្ចប់វាមិនច្បាស់ទាំងស្រុង។ ហើយនៅពេលដែលអ្នកសម្រេចបានការហូរចេញដែលមិនមានផ្ទៃខាងក្រោយ វាមានន័យថា IO របស់អ្នកទាំងអស់ត្រូវបានកាន់កាប់ដោយវា។ ហើយរហូតដល់វាចប់អ្នកនឹងមិនធ្វើអ្វីទាំងអស់។

មានចំណុចសំខាន់ពីរទៀតនៅទីនេះ ដែលហួសពីវិសាលភាពនៃរបាយការណ៍នេះ។ ការកំណត់ទាំងនេះគួរតែត្រូវគ្នានឹងការកំណត់នៅក្នុង postgresql.conf ពោលគឺការកំណត់ចំណុចត្រួតពិនិត្យ។ ហើយប្រព័ន្ធឌីសរបស់អ្នកត្រូវតែត្រូវបានកំណត់រចនាសម្ព័ន្ធឱ្យបានគ្រប់គ្រាន់។ ប្រសិនបើអ្នកមានឃ្លាំងសម្ងាត់នៅលើ RAID នោះវាត្រូវតែមានថ្ម។ មនុស្សទិញ RAID ជាមួយនឹងឃ្លាំងសម្ងាត់ល្អដោយគ្មានថ្ម។ ប្រសិនបើអ្នកមាន SSDs នៅក្នុង RAID នោះពួកវាត្រូវតែជាម៉ាស៊ីនមេ ត្រូវតែមាន capacitors នៅទីនោះ។ នេះគឺជាបញ្ជីពិនិត្យលម្អិត។ តំណភ្ជាប់នេះមានរបាយការណ៍របស់ខ្ញុំអំពីរបៀបកំណត់រចនាសម្ព័ន្ធថាសដំណើរការនៅក្នុង PostgreSQL ។ មានបញ្ជីត្រួតពិនិត្យទាំងអស់នេះនៅទីនោះ។

តើមានអ្វីទៀតដែលអាចធ្វើឱ្យជីវិតលំបាកខ្លាំង? ទាំងនេះគឺជាប៉ារ៉ាម៉ែត្រពីរ។ ពួកគេគឺថ្មីណាស់។ តាមលំនាំដើម ពួកវាអាចត្រូវបានរួមបញ្ចូលក្នុងកម្មវិធីផ្សេងៗ។ ហើយ​ពួកគេ​អាច​ធ្វើ​ឱ្យ​ជីវិត​ជួប​ការ​លំបាក​ប្រសិនបើ​ពួកគេ​បើក​មិន​ត្រឹមត្រូវ។

មានរឿងថ្មីពីរយ៉ាង។ ពួកគេបានបង្ហាញខ្លួននៅក្នុងស្នូលទីបីរួចហើយ។ នេះគឺជា sched_migration_cost គិតជា nanoseconds និង sched_autogroup_enabled ដែលជាលំនាំដើមមួយ។

ហើយតើពួកគេបំផ្លាញជីវិតអ្នកដោយរបៀបណា? តើ sched_migration_cost ជាអ្វី? នៅលើលីនុច កម្មវិធីកំណត់ពេលអាចផ្ទេរដំណើរការពីស៊ីភីយូមួយទៅមួយទៀត។ ហើយសម្រាប់ PostgreSQL ដែលប្រតិបត្តិសំណួរ ការធ្វើចំណាកស្រុកទៅ CPU ផ្សេងទៀតគឺមិនច្បាស់លាស់ទាំងស្រុង។ តាមទស្សនៈនៃប្រព័ន្ធប្រតិបត្តិការ នៅពេលអ្នកប្តូរបង្អួចរវាងការិយាល័យបើកចំហ និងស្ថានីយ វាអាចល្អ ប៉ុន្តែ សម្រាប់មូលដ្ឋានទិន្នន័យ នេះគឺអាក្រក់ណាស់។ ដូច្នេះ គោលការណ៍សមហេតុផលមួយគឺកំណត់ migration_cost ទៅជាតម្លៃធំមួយចំនួន យ៉ាងហោចណាស់ជាច្រើនពាន់ nanoseconds។

តើនេះមានន័យយ៉ាងណាសម្រាប់អ្នករៀបចំកាលវិភាគ? វានឹងត្រូវបានចាត់ទុកថាក្នុងអំឡុងពេលនេះដំណើរការនៅតែក្តៅ។ នោះគឺប្រសិនបើអ្នកមានប្រតិបត្តិការដ៏យូរដែលបាននិងកំពុងធ្វើអ្វីមួយអស់រយៈពេលជាយូរ អ្នករៀបចំកាលវិភាគនឹងយល់ពីរឿងនេះ។ គាត់នឹងសន្មតថារហូតដល់ពេលវេលានេះកន្លងផុតទៅ មិនចាំបាច់ធ្វើចំណាកស្រុកដំណើរការនេះទៅកន្លែងណានោះទេ។ ប្រសិនបើនៅពេលដំណាលគ្នានោះដំណើរការធ្វើអ្វីមួយ នោះវានឹងមិនត្រូវបានធ្វើចំណាកស្រុកទៅណានោះទេ វានឹងដំណើរការដោយស្ងៀមស្ងាត់នៅលើ CPU ដែលត្រូវបានបម្រុងទុកសម្រាប់វា។ ហើយលទ្ធផលគឺល្អឥតខ្ចោះ។

ចំណុចទីពីរគឺ autogroup ។ មានគំនិតល្អសម្រាប់បន្ទុកការងារជាក់លាក់ដែលមិនទាក់ទងទៅនឹងមូលដ្ឋានទិន្នន័យទំនើប - នេះគឺដើម្បីដំណើរការជាក្រុមដោយស្ថានីយនិម្មិតដែលពួកវាត្រូវបានដាក់ឱ្យដំណើរការ។ នេះងាយស្រួលសម្រាប់កិច្ចការមួយចំនួន។ នៅក្នុងការអនុវត្ត PostgreSQL គឺជាប្រព័ន្ធពហុដំណើរការដែលមាន prefork ដែលដំណើរការពីស្ថានីយតែមួយ។ អ្នកមាន lock writer, checkpoint និងរាល់សំណើរបស់អតិថិជនរបស់អ្នកនឹងត្រូវបានដាក់ជាក្រុមទៅក្នុងកម្មវិធីកំណត់ពេលតែមួយ ក្នុងមួយ CPU។ ហើយពួកគេនឹងរង់ចាំនៅទីនោះដោយឯកឯងដើម្បីឱ្យគាត់មានសេរីភាព ដើម្បីជ្រៀតជ្រែកគ្នាទៅវិញទៅមក និងរក្សាឱ្យគាត់កាន់កាប់បានយូរ។ នេះគឺជារឿងដែលមិនចាំបាច់ទាំងស្រុងនៅក្នុងករណីនៃការផ្ទុកបែបនេះហើយដូច្នេះវាត្រូវការបិទ។

សហសេវិករបស់ខ្ញុំ Alexey Lesovsky បានធ្វើតេស្តដោយប្រើ pgbench សាមញ្ញ ដែលគាត់បានបង្កើន migration_cost តាមលំដាប់លំដោយ ហើយបិទ autogroup ។ ភាពខុសគ្នានៃផ្នែករឹងមិនល្អគឺស្ទើរតែ 10%. មានការពិភាក្សានៅលើបញ្ជីសំបុត្ររួមរបស់ Postgres ដែលមនុស្សផ្តល់លទ្ធផលនៃការផ្លាស់ប្តូរស្រដៀងគ្នាទៅនឹងល្បឿនសំណួរ ឥទ្ធិពល 50%. មានរឿងបែបនេះច្រើនណាស់។

ហើយចុងក្រោយអំពីគោលការណ៍សន្សំសំចៃថាមពល។ រឿងល្អគឺថាលីនុចឥឡូវនេះអាចប្រើនៅលើកុំព្យូទ័រយួរដៃបាន។ ហើយ​វា​នឹង​ប្រើ​ថ្ម​បាន​យ៉ាង​ល្អ។ ប៉ុន្តែភ្លាមៗវាប្រែថានេះក៏អាចកើតឡើងនៅលើម៉ាស៊ីនមេផងដែរ។

លើសពីនេះទៅទៀត ប្រសិនបើអ្នកជួលម៉ាស៊ីនមេពី hoster មួយចំនួន នោះ hosters "ល្អ" មិនខ្វល់ថាអ្នកមានដំណើរការប្រសើរជាងនេះទេ។ ភារកិច្ចរបស់ពួកគេគឺដើម្បីធានាថាដែករបស់ពួកគេត្រូវបានប្រើប្រាស់ប្រកបដោយប្រសិទ្ធភាពតាមដែលអាចធ្វើទៅបាន។ ដូច្នេះតាមលំនាំដើម ពួកគេអាចបើករបៀបសន្សំថាមពលកុំព្យូទ័រយួរដៃនៅលើប្រព័ន្ធប្រតិបត្តិការ។

ប្រសិនបើអ្នកប្រើវត្ថុនេះនៅលើម៉ាស៊ីនមេដែលមានមូលដ្ឋានទិន្នន័យនៅក្រោមបន្ទុកធ្ងន់នោះជម្រើសរបស់អ្នកគឺ acpi_cpufreq + permormance ។ សូម្បីតែ ondemand នឹងមានបញ្ហា។

Intel_pstate គឺជាកម្មវិធីបញ្ជាខុសគ្នាបន្តិចបន្តួច។ ហើយឥឡូវនេះ ចំណូលចិត្តត្រូវបានផ្តល់ទៅឱ្យមួយនេះ ព្រោះថានៅពេលក្រោយ និងដំណើរការកាន់តែប្រសើរ។

ហើយ​តាម​នោះ អភិបាល​គ្រាន់​តែ​ជា​ការ​អនុវត្ត​ប៉ុណ្ណោះ។ Ondemand, powersave និងអ្វីៗផ្សេងទៀតមិនមែនអំពីអ្នកទេ។

លទ្ធផលនៃការពន្យល់ពីការវិភាគ PostgreSQL អាចខុសគ្នាតាមលំដាប់លំដោយជាច្រើន ប្រសិនបើអ្នកបើកដំណើរការ powersave ពីព្រោះជាក់ស្តែង CPU នៅក្រោម database របស់អ្នកនឹងដំណើរការតាមរបៀបដែលមិនអាចទាយទុកជាមុនបាន។

ធាតុទាំងនេះអាចត្រូវបានរួមបញ្ចូលតាមលំនាំដើម។ រកមើលដោយប្រុងប្រយ័ត្នដើម្បីមើលថាតើពួកគេបានបើកវាតាមលំនាំដើម។ នេះអាចជាបញ្ហាធំមែនទែន។

ហើយនៅទីបញ្ចប់ ខ្ញុំចង់និយាយអរគុណចំពោះអ្នកមកពីក្រុម PosgreSQL-Consulting DBA របស់យើងគឺ Max Boguk និង Alexey Lesovsky ដែលកំពុងតែឈានមុខក្នុងបញ្ហានេះជារៀងរាល់ថ្ងៃ។ ហើយ​យើង​ព្យាយាម​ធ្វើ​ឱ្យ​អស់​ពី​សមត្ថភាព​សម្រាប់​អតិថិជន​របស់​យើង ដើម្បី​ឱ្យ​វា​ដំណើរការ​សម្រាប់​ពួក​គេ។ វាដូចជាការណែនាំអំពីសុវត្ថិភាពអាកាសចរណ៍។ អ្វីៗនៅទីនេះត្រូវបានសរសេរដោយឈាម។ គ្រាប់ទាំងនេះនីមួយៗត្រូវបានរកឃើញនៅក្នុងដំណើរការនៃប្រភេទនៃបញ្ហាមួយចំនួន។ ខ្ញុំរីករាយក្នុងការចែករំលែកវាជាមួយអ្នក។

សំណួរ៖

សូមអរគុណ! ឧទាហរណ៍ ប្រសិនបើក្រុមហ៊ុនចង់សន្សំប្រាក់ ហើយដាក់មូលដ្ឋានទិន្នន័យ និងតក្កវិជ្ជាកម្មវិធីនៅលើម៉ាស៊ីនមេតែមួយ ឬប្រសិនបើក្រុមហ៊ុនធ្វើតាមនិន្នាការទាន់សម័យនៃស្ថាបត្យកម្មមីក្រូសេវាកម្ម ដែល PostgreSQL ដំណើរការក្នុងកុងតឺន័រ។ តើល្បិចអ្វី? Sysctl នឹងប៉ះពាល់ដល់ខឺណែលទាំងមូលជាសកល។ ខ្ញុំមិនបានលឺថា sysctls ត្រូវបាននិម្មិតដូចម្ដេច ដើម្បីឱ្យពួកវាធ្វើការដាច់ដោយឡែកពីគ្នានៅលើកុងតឺន័រ។ មានតែ cgroup ហើយមានផ្នែកនៃការគ្រប់គ្រងនៅទីនោះ។ តើអ្នកអាចរស់នៅជាមួយនេះដោយរបៀបណា? ឬប្រសិនបើអ្នកចង់ដំណើរការ បន្ទាប់មកដំណើរការ PostgreSQL នៅលើម៉ាស៊ីនមេផ្នែករឹងដាច់ដោយឡែក ហើយកំណត់វា?

យើងបានឆ្លើយសំណួររបស់អ្នកតាមបីវិធី។ ប្រសិនបើយើងមិននិយាយអំពីម៉ាស៊ីនមេផ្នែករឹងដែលអាចលៃតម្រូវបាន។ល។ បន្ទាប់មកសម្រាក អ្វីៗនឹងដំណើរការល្អដោយគ្មានការកំណត់ទាំងនេះ។ ប្រសិនបើអ្នកមានបន្ទុកបែបនេះដែលអ្នកត្រូវការដើម្បីធ្វើការកំណត់ទាំងនេះ នោះអ្នកនឹងមកម៉ាស៊ីនមេដែកលឿនជាងការកំណត់ទាំងនេះ។

មាន​បញ្ហា​អ្វី? ប្រសិនបើនេះជាម៉ាស៊ីននិម្មិត នោះទំនងជាអ្នកនឹងមានបញ្ហាជាច្រើន ជាឧទាហរណ៍ ដោយការពិតដែលថានៅលើម៉ាស៊ីននិម្មិតភាគច្រើន ភាពយឺតនៃថាសគឺមិនស៊ីសង្វាក់គ្នា។ ទោះបីជាការបញ្ចូលឌីសល្អក៏ដោយ ប្រតិបត្តិការ I/O ដែលបរាជ័យ ដែលមិនប៉ះពាល់ដល់ការបញ្ជូនជាមធ្យមដែលបានកើតឡើងនៅពេលត្រួតពិនិត្យ ឬនៅពេលសរសេរទៅ WAL នោះមូលដ្ឋានទិន្នន័យនឹងរងទុក្ខយ៉ាងខ្លាំងពីបញ្ហានេះ។ ហើយ​អ្នក​នឹង​សម្គាល់​ឃើញ​ចំណុច​នេះ​មុន​ពេល​អ្នក​ជួប​បញ្ហា​ទាំងនេះ។

ប្រសិនបើអ្នកមាន NGINX នៅលើម៉ាស៊ីនមេដូចគ្នា អ្នកក៏នឹងមានបញ្ហាដូចគ្នាដែរ។ គាត់នឹងតស៊ូដើម្បីការចងចាំរួម។ ហើយ​អ្នក​នឹង​មិន​ទទួល​បាន​បញ្ហា​ដែល​បាន​ពិពណ៌នា​នៅ​ទីនេះ។

ប៉ុន្តែម្យ៉ាងវិញទៀត ប៉ារ៉ាម៉ែត្រទាំងនេះមួយចំនួននឹងនៅតែពាក់ព័ន្ធជាមួយអ្នក។ ជាឧទាហរណ៍ កំណត់ dirty_ratio ជាមួយ sysctl ដើម្បីកុំឱ្យវាឆ្កួត - ក្នុងករណីណាក៏ដោយ វានឹងជួយ។ វិធីមួយ ឬមធ្យោបាយផ្សេងទៀត អ្នកនឹងមានអន្តរកម្មជាមួយឌីស។ ហើយវានឹងស្របតាមលំនាំខុស។ ជាទូទៅនេះគឺជាលំនាំដើមសម្រាប់ប៉ារ៉ាម៉ែត្រដែលខ្ញុំបានបង្ហាញ។ ហើយក្នុងករណីណាក៏ដោយវាជាការប្រសើរជាងក្នុងការផ្លាស់ប្តូរពួកគេ។

ប៉ុន្តែប្រហែលជាមានបញ្ហាជាមួយ NUMA ។ ជាឧទាហរណ៍ VmWare ដំណើរការល្អជាមួយ NUMA ជាមួយនឹងការកំណត់ផ្ទុយគ្នា។ ហើយនៅទីនេះអ្នកត្រូវជ្រើសរើស - ម៉ាស៊ីនមេដែកឬមិនមែនដែក។

ខ្ញុំមានសំណួរទាក់ទងនឹង Amazon AWS ។ ពួកគេមានរូបភាពដែលបានកំណត់ជាមុន។ មួយក្នុងចំណោមពួកគេត្រូវបានគេហៅថា Amazon RDS ។ តើមានការកំណត់ផ្ទាល់ខ្លួនសម្រាប់ប្រព័ន្ធប្រតិបត្តិការរបស់ពួកគេទេ?

មានការកំណត់នៅទីនោះ ប៉ុន្តែពួកវាជាការកំណត់ផ្សេងគ្នា។ នៅទីនេះយើងកំណត់រចនាសម្ព័ន្ធប្រព័ន្ធប្រតិបត្តិការនៅក្នុងលក្ខខណ្ឌនៃរបៀបដែលមូលដ្ឋានទិន្នន័យនឹងប្រើរឿងនេះ។ ហើយមានប៉ារ៉ាម៉ែត្រដែលកំណត់កន្លែងដែលយើងគួរទៅឥឡូវនេះ ដូចជា រាង។ នោះគឺយើងត្រូវការធនធានច្រើនណាស់ ឥឡូវនេះយើងនឹងស៊ីវាអស់ហើយ។ បន្ទាប់ពីនេះ Amazon RDS រឹតបន្តឹងធនធានទាំងនេះ ហើយដំណើរការធ្លាក់ចុះនៅទីនោះ។ មានរឿងផ្ទាល់ខ្លួនអំពីរបៀបដែលមនុស្សចាប់ផ្តើមរញ៉េរញ៉ៃជាមួយបញ្ហានេះ។ ពេលខ្លះសូម្បីតែជោគជ័យ។ ប៉ុន្តែនេះមិនមានអ្វីដែលត្រូវធ្វើជាមួយការកំណត់ប្រព័ន្ធប្រតិបត្តិការទេ។ វាដូចជាការលួចស្តាប់ពពក។ នោះជារឿងផ្សេង។

ហេតុអ្វីបានជាទំព័រដ៏ធំដែលមានតម្លាភាពគ្មានប្រសិទ្ធភាពបើប្រៀបធៀបទៅនឹង TLB ដ៏ធំ?

កុំ​អោយ។ នេះអាចត្រូវបានពន្យល់តាមវិធីជាច្រើន។ ប៉ុន្តែ​តាម​ពិត​គេ​មិន​ឲ្យ​វា​ទេ។ តើ PostgreSQL មានប្រវត្តិដូចម្តេច? នៅពេលចាប់ផ្តើម វាបែងចែកផ្នែកធំនៃអង្គចងចាំដែលបានចែករំលែក។ ថាតើពួកគេមានតម្លាភាព ឬអត់ គឺមិនពាក់ព័ន្ធទាំងស្រុងនោះទេ។ ការពិតដែលថាពួកគេលេចធ្លោនៅពេលចាប់ផ្តើមពន្យល់អ្វីគ្រប់យ៉ាង។ ហើយប្រសិនបើមានអង្គចងចាំច្រើន ហើយអ្នកត្រូវបង្កើតផ្នែក shared_memory ឡើងវិញ នោះទំព័រដ៏ធំដែលមានតម្លាភាពនឹងពាក់ព័ន្ធ។ នៅក្នុង PostgreSQL វាត្រូវបានបែងចែកយ៉ាងសាមញ្ញក្នុងផ្នែកដ៏ធំមួយនៅពេលចាប់ផ្តើម ហើយនោះហើយជាវា ហើយបន្ទាប់មកគ្មានអ្វីពិសេសកើតឡើងនៅទីនោះទេ។ អ្នក​អាច​ប្រើ​វា​បាន ប៉ុន្តែ​វា​មាន​ឱកាស​ទទួល​បាន​ការ​ខូច​ខាត​នៃ shared_memory នៅ​ពេល​វា​បែងចែក​អ្វី​មួយ​ឡើង​វិញ។ PostgreSQL មិនដឹងអំពីរឿងនេះទេ។

ប្រភព: www.habr.com