កំហុសធម្មតានៅក្នុងកម្មវិធីដែលនាំឱ្យហើមពោះនៅក្នុង postgresql ។ Andrey Salnikov

ខ្ញុំស្នើឱ្យអ្នកអានប្រតិចារិកនៃរបាយការណ៍ពីដើមឆ្នាំ 2016 ដោយ Andrey Salnikov "កំហុសធម្មតានៅក្នុងកម្មវិធីដែលនាំឱ្យហើមពោះនៅក្នុង postgresql"

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

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

ហេតុអ្វីបានជាមានកំហុស? ពួកគេត្រូវបានធ្វើដោយហេតុផលពីរយ៉ាង៖ ដោយចៃដន្យ ប្រហែលជាវានឹងដំណើរការហើយដោយសារតែភាពល្ងង់ខ្លៅនៃយន្តការមួយចំនួនដែលកើតឡើងនៅកម្រិតរវាងមូលដ្ឋានទិន្នន័យ និងកម្មវិធី ក៏ដូចជានៅក្នុងមូលដ្ឋានទិន្នន័យខ្លួនឯងផងដែរ។

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

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

ទិន្នន័យដំបូងនៃចាន: វាតូចណាស់ 2 MB ។ ពេលវេលាឆ្លើយតបសម្រាប់មូលដ្ឋានទិន្នន័យ និងជាពិសេសសម្រាប់សញ្ញាក៏ល្អណាស់។ និងបន្ទុកដ៏ល្អមួយ - ប្រតិបត្តិការ 2 ក្នុងមួយវិនាទីយោងទៅតាមចាន។

ហើយតាមរយៈរបាយការណ៍នេះ ខ្ញុំនឹងបង្ហាញអ្នកនូវក្រាហ្វ ដើម្បីអោយអ្នកយល់ច្បាស់អំពីអ្វីដែលកំពុងកើតឡើង។ វាតែងតែមានស្លាយ 2 ជាមួយក្រាហ្វ។ ស្លាយទីមួយគឺជាអ្វីដែលកើតឡើងជាទូទៅនៅលើម៉ាស៊ីនមេ។

ហើយក្នុងស្ថានភាពនេះ យើងឃើញថាយើងពិតជាមានសញ្ញាតូចមួយ។ សន្ទស្សន៍គឺតូចនៅ 2 MB ។ នេះគឺជាក្រាហ្វដំបូងនៅខាងឆ្វេង។

ពេលវេលាឆ្លើយតបជាមធ្យមនៅលើម៉ាស៊ីនមេក៏មានស្ថេរភាព និងខ្លីផងដែរ។ នេះគឺជាក្រាហ្វខាងស្តាំ។

ក្រាហ្វខាងឆ្វេងខាងក្រោមបង្ហាញពីប្រតិបត្តិការដ៏វែងបំផុត។ យើងឃើញថាប្រតិបត្តិការត្រូវបានបញ្ចប់យ៉ាងឆាប់រហ័ស។ ហើយ autovacuum មិនដំណើរការនៅទីនេះនៅឡើយទេ ព្រោះវាជាការសាកល្បងចាប់ផ្តើម។ វានឹងបន្តដំណើរការ ហើយនឹងមានប្រយោជន៍សម្រាប់យើង។

ស្លាយទីពីរនឹងតែងតែឧទ្ទិសដល់ចានដែលកំពុងធ្វើតេស្ត។ ក្នុងស្ថានភាពនេះ យើងធ្វើបច្ចុប្បន្នភាពសមតុល្យគណនីរបស់អតិថិជនជានិច្ច។ ហើយយើងឃើញថាពេលវេលាឆ្លើយតបជាមធ្យមសម្រាប់ប្រតិបត្តិការអាប់ដេតគឺល្អណាស់ តិចជាងមួយមិល្លីវិនាទី។ យើងឃើញថាធនធានដំណើរការ (នេះគឺជាក្រាហ្វខាងស្តាំខាងលើ) ក៏ត្រូវបានប្រើប្រាស់ស្មើៗគ្នា និងតូចផងដែរ។

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

ហើយឥឡូវនេះយើងមានសោកនាដកម្មមួយ។ សម្រាប់ហេតុផលមួយចំនួនមានប្រតិបត្តិការភ្លេចយូរ។ ហេតុផលជាធម្មតាទាំងអស់គឺ banal:

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

តើរឿងបែបនេះនាំទៅដល់ណា?

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

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

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

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

យើងត្រូវតែមានជីវិតឡើងវិញ។ យើង​ចូល​ទៅ​អ៊ីនធឺណិត​ហើយ​រក​ឃើញ​ថា​ប្រតិបត្តិការ​យូរ​នាំ​ឱ្យ​មាន​បញ្ហា។ យើងស្វែងរក និងសម្លាប់ប្រតិបត្តិការនេះ។ ហើយ​អ្វី​ៗ​ក៏​ក្លាយ​ជា​រឿង​ធម្មតា​សម្រាប់​យើង។ អ្វីគ្រប់យ៉ាងដំណើរការដូចដែលវាគួរតែ។

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

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

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

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

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

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

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

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

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

តើមានអ្វីកើតឡើងក្នុងពេលមានគ្រោះថ្នាក់? តើ​ដំណើរ​ការ​នេះ​កើត​ឡើង​នៅ​ទី​នោះ​ដោយ​របៀប​ណា?

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

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

តាមពិតយើងត្រូវការខ្សែពណ៌បៃតងដើម្បីដំណើរការ។ ប៉ុន្តែក្នុងអំឡុងពេលមានបញ្ហាបែបនេះវាប្រែថាភាគរយនៃបន្ទាត់ពណ៌បៃតងគឺទាបបំផុតនៅទូទាំងតារាងទាំងមូល។

ហើយនៅពេលដែលយើងប្រតិបត្តិសំណួរ មូលដ្ឋានទិន្នន័យត្រូវឆ្លងកាត់បន្ទាត់ទាំងអស់៖ ទាំងក្រហម និងបៃតង ដើម្បីស្វែងរកបន្ទាត់ដែលចង់បាន។ ហើយឥទ្ធិពលនៃការហើមតារាងជាមួយនឹងទិន្នន័យដែលគ្មានប្រយោជន៍ត្រូវបានគេហៅថា "bloat" ដែលស៊ីទំហំថាសរបស់យើងផងដែរ។ ចាំថាវាមាន 2 MB វាក្លាយជា 300 MB? ឥឡូវនេះប្តូរមេកាបៃទៅជាជីហ្គាបៃហើយអ្នកនឹងបាត់បង់ធនធានថាសទាំងអស់របស់អ្នកយ៉ាងឆាប់រហ័ស។

តើ​មាន​ផល​វិបាក​អ្វី​ខ្លះ​សម្រាប់​យើង?

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

ចំពោះគោលបំណងនេះមានវដ្តជាក់លាក់នៃការងារដែលត្រូវបានអនុវត្ត។

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

នៅពេលដែលអ្នកបានរកឃើញតារាងទាំងនេះ អ្នកត្រូវបង្ហាប់ពួកវា។ មានឧបករណ៍សម្រាប់រឿងនេះរួចហើយ។ នៅក្នុងក្រុមហ៊ុនរបស់យើងយើងប្រើឧបករណ៍បី។ ទីមួយគឺ VACUUM FULL ដែលមានស្រាប់។ គាត់ជាមនុស្សឃោរឃៅ ឃោរឃៅ និងគ្មានមេត្តា ប៉ុន្តែពេលខ្លះគាត់មានប្រយោជន៍ខ្លាំងណាស់។ Pg_repack и pgcompacttable - ទាំងនេះគឺជាឧបករណ៍ប្រើប្រាស់ភាគីទីបីសម្រាប់ការបង្ហាប់តារាង។ ហើយពួកគេព្យាបាលមូលដ្ឋានទិន្នន័យដោយប្រុងប្រយ័ត្នជាង។

ពួកវាត្រូវបានប្រើអាស្រ័យលើអ្វីដែលកាន់តែងាយស្រួលសម្រាប់អ្នក។ ប៉ុន្តែខ្ញុំនឹងប្រាប់អ្នកអំពីរឿងនេះនៅចុងបញ្ចប់។ រឿងចំបងគឺថាមានឧបករណ៍បី។ មានច្រើនសម្រាប់ជ្រើសរើស។

បន្ទាប់​ពី​យើង​បាន​កែ​គ្រប់​យ៉ាង​ហើយ​ធ្វើ​ឱ្យ​ប្រាកដ​ថា​គ្រប់​យ៉ាង​ល្អ​ហើយ យើង​ត្រូវ​ដឹង​ពី​វិធី​ការពារ​ស្ថានភាព​នេះ​ទៅ​ថ្ងៃ​អនាគត៖

• វាអាចត្រូវបានរារាំងយ៉ាងងាយស្រួល។ អ្នកត្រូវតាមដានរយៈពេលនៃវគ្គនៅលើ Master server។ ជាពិសេសវគ្គដែលមានគ្រោះថ្នាក់នៅទំនេរក្នុងស្ថានភាពប្រតិបត្តិការ. ទាំងនេះគឺជាអ្នកដែលទើបតែបើកប្រតិបត្តិការ ធ្វើអ្វីមួយ ហើយចាកចេញ ឬគ្រាន់តែព្យួរ បាត់លេខកូដ។
• ហើយសម្រាប់អ្នក ក្នុងនាមជាអ្នកអភិវឌ្ឍន៍ វាមានសារៈសំខាន់ណាស់ក្នុងការធ្វើតេស្តកូដរបស់អ្នកនៅពេលដែលស្ថានភាពទាំងនេះកើតឡើង។ វាមិនពិបាកធ្វើទេ។ នេះនឹងជាការត្រួតពិនិត្យដ៏មានប្រយោជន៍។ អ្នកនឹងជៀសវាងបញ្ហា "កូនក្មេង" មួយចំនួនធំដែលទាក់ទងនឹងប្រតិបត្តិការយូរ។

នៅក្នុងក្រាហ្វទាំងនេះ ខ្ញុំចង់បង្ហាញអ្នកពីរបៀបដែលសញ្ញា និងឥរិយាបថនៃមូលដ្ឋានទិន្នន័យបានផ្លាស់ប្តូរ បន្ទាប់ពីខ្ញុំបានឆ្លងកាត់សញ្ញាជាមួយ VACUUM FULL ក្នុងករណីនេះ។ នេះមិនមែនជាផលិតកម្មសម្រាប់ខ្ញុំទេ។

ទំហំតារាងភ្លាមៗបានត្រលប់ទៅស្ថានភាពប្រតិបត្តិការធម្មតារបស់វាវិញនៃទំហំពីរមេហ្គាបៃ។ នេះមិនប៉ះពាល់ដល់ពេលវេលាឆ្លើយតបជាមធ្យមសម្រាប់ម៉ាស៊ីនមេទេ។

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

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

រឿងទីពីរ ដែលយើងចែកចាយបន្ទុក និងបង្កើនប្រសិទ្ធភាពធនធានម៉ាស៊ីនមេ

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

ហើយ​តើ​ស្ថានភាព​នេះ​មាន​លក្ខណៈ​បែប​ណា? ជាពិសេសនៅលើក្រាហ្វទាំងនេះ ខ្ញុំក៏បានបន្ថែមរយៈពេលនៃប្រតិបត្តិការពីការចម្លងសម្រាប់រយៈពេលប្រតិបត្តិការ។ ក្រាហ្វផ្សេងទៀតទាំងអស់សំដៅលើម៉ាស៊ីនមេមេ។

មកដល់ពេលនេះ ក្រុមប្រឹក្សារបាយការណ៍របស់ខ្ញុំបានរីកចម្រើន។ មានពួកគេច្រើនជាងនេះ។ យើងឃើញថាពេលវេលាឆ្លើយតបរបស់ម៉ាស៊ីនមេជាមធ្យមមានស្ថេរភាព។ យើងឃើញថានៅលើការចម្លងយើងមានប្រតិបត្តិការរយៈពេលវែងដែលដំណើរការរយៈពេល 2 ម៉ោង។ យើងឃើញប្រតិបត្តិការស្ងាត់របស់ autovacuum ដែលដំណើរការបន្ទាត់ស្លាប់។ ហើយអ្វីៗគឺល្អជាមួយយើង។

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

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

យើងទៅអ៊ីនធឺណិត ហើយចាប់ផ្តើមអានថាហេតុអ្វីបានជារឿងនេះកើតឡើង។ ហើយយើងរកដំណោះស្រាយ។

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

យើង​ចង់​ឲ្យ​អ្វីៗ​ល្អ​ឥត​ខ្ចោះ។ យើងឡើងបន្ថែមទៀត។ ហើយយើងបានរកឃើញការកំណត់ត្រជាក់នៅលើអ៊ីនធឺណិត - hot_standby_feedback ។ តោះបើកវា។ Hot_standby_feedback អនុញ្ញាតឱ្យយើងទប់ autovacuum នៅលើ Master ។ ដូច្នេះ យើង​កម្ចាត់​ជម្លោះ​ចម្លង​ទាំងស្រុង។ ហើយអ្វីៗដំណើរការល្អសម្រាប់យើងជាមួយនឹងរបាយការណ៍។

ហើយតើមានអ្វីកើតឡើងជាមួយម៉ាស៊ីនមេ Master នៅពេលនេះ? ហើយ​យើង​មាន​បញ្ហា​ទាំងស្រុង​ជាមួយ​នឹង Master server។ ឥឡូវនេះយើងកំពុងមើលក្រាហ្វនៅពេលដែលខ្ញុំបានបើកការកំណត់ទាំងពីរនេះ។ ហើយយើងឃើញថាវគ្គនៅលើការចម្លងរបស់យើងដូចម្ដេចបានចាប់ផ្តើមមានឥទ្ធិពលលើស្ថានភាពនៅលើម៉ាស៊ីនមេ។ នាងមានឥទ្ធិពលដោយសារតែនាងបានផ្អាក autovacuum ដែលជម្រះបន្ទាត់ដែលស្លាប់។ ទំហំតុរបស់យើងបានកើនឡើងយ៉ាងខ្លាំងម្តងទៀត។ ពេលវេលាដំណើរការសំណួរជាមធ្យមនៅទូទាំងមូលដ្ឋានទិន្នន័យទាំងមូលក៏បានកើនឡើងខ្ពស់ផងដែរ។ autovacuums រឹតបន្តឹងបន្តិច។

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

តើ​វា​នឹង​ទៅ​ជា​យ៉ាង​ណា​ប្រសិន​បើ​យើង​មិន​ដឹង​ថា​ខ្ញុំ​បាន​និយាយ​ពី​មុន?

• យើងចាប់ផ្តើមស្វែងរកបញ្ហា។ ប្រសិនបើ​យើង​ជួប​បញ្ហា​ក្នុង​ផ្នែក​ដំបូង យើង​ដឹង​ថា​នេះ​អាច​មក​ពី​ប្រតិបត្តិការ​យូរ​ហើយ​ទៅ​កាន់ Master។ យើងមានបញ្ហាជាមួយមេ។ សាច់ក្រកគាត់។ វាឡើងកំដៅ ការផ្ទុកជាមធ្យមរបស់វាគឺប្រហែលមួយរយ។
• សំណើ​មាន​ការ​យឺត ប៉ុន្តែ​យើង​មិន​ឃើញ​ប្រតិបត្តិការ​ដែល​មាន​រយៈពេល​យូរ​នៅ​ទីនោះ​ទេ។ ហើយ​យើង​មិន​យល់​ថា​មាន​បញ្ហា​អ្វី​ទេ។ យើងមិនយល់កន្លែងដែលត្រូវរកមើល។
• យើងពិនិត្យមើលឧបករណ៍ម៉ាស៊ីនមេ។ ប្រហែលជាការវាយឆ្មក់របស់យើងបានធ្លាក់។ ប្រហែលជាអង្គចងចាំរបស់យើងត្រូវបានដុតចោល។ បាទ អ្វីៗអាចកើតឡើង។ ប៉ុន្តែទេ ម៉ាស៊ីនមេគឺថ្មី អ្វីគ្រប់យ៉ាងដំណើរការល្អ។
• គ្រប់គ្នាកំពុងដំណើរការ៖ អ្នកគ្រប់គ្រង អ្នកអភិវឌ្ឍន៍ និងនាយក។ គ្មានអ្វីជួយទេ។
• ហើយ​នៅ​ពេល​ណា​មួយ អ្វីៗ​ក៏​ចាប់​ផ្តើម​កែ​ខ្លួន​ភ្លាម។

នៅពេលនេះ សំណើលើការចម្លងរបស់យើងត្រូវបានដំណើរការ ហើយចាកចេញ។ យើងបានទទួលរបាយការណ៍។ អាជីវកម្មនៅតែរីករាយ។ ដូចដែលអ្នកអាចឃើញសញ្ញារបស់យើងបានរីកចម្រើនម្តងទៀតហើយនឹងមិនថយចុះទេ។ នៅលើក្រាហ្វជាមួយវគ្គ ខ្ញុំបានទុកបំណែកនៃប្រតិបត្តិការដ៏វែងនេះពីការចម្លងមួយ ដើម្បីឱ្យអ្នកអាចប៉ាន់ស្មានថាតើវាត្រូវការរយៈពេលប៉ុន្មានរហូតដល់ស្ថានភាពមានស្ថេរភាព។

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

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

ក្នុងករណីណាក៏ដោយ យើងទទួលបានលទ្ធផលដកថយ ដូចករណីទីមួយ ដោយមួយដងកន្លះទៅពីរដង និងពេលខ្លះទៀត។

យើង​ហាក់​ដូច​ជា​បាន​ធ្វើ​អ្វី​គ្រប់​យ៉ាង​ត្រឹម​ត្រូវ។ ចែកចាយបន្ទុក។ ឧបករណ៍មិនទំនេរទេ។ យើង​បាន​បែងចែក​សំណើ​ទៅ​តាម​គំនិត​របស់​យើង ប៉ុន្តែ​នៅ​តែ​មាន​អ្វី​គ្រប់​យ៉ាង​បាន​ប្រែ​ទៅ​ជា​អាក្រក់។

• មិនបើក hot_standby_feedback? បាទ/ចាស វាមិនត្រូវបានណែនាំអោយបើកវាដោយគ្មានហេតុផលខ្លាំងពិសេសនោះទេ។ ដោយសារតែការបង្វិលនេះប៉ះពាល់ដោយផ្ទាល់ទៅលើម៉ាស៊ីនមេ Master និងផ្អាកប្រតិបត្តិការនៃម៉ាស៊ីនបូមធូលីនៅទីនោះ។ តាមរយៈការបើកវានៅលើការចម្លងមួយចំនួន ហើយភ្លេចអំពីវា អ្នកអាចសម្លាប់ Master និងទទួលបានបញ្ហាធំជាមួយកម្មវិធី។
• បង្កើន max_standby_streaming_delay? បាទ សម្រាប់របាយការណ៍នេះជាការពិត។ ប្រសិនបើអ្នកមានរបាយការណ៍រយៈពេល XNUMX ម៉ោង ហើយអ្នកមិនចង់ឱ្យវាគាំងដោយសារតែជម្លោះនៃការចម្លងទេនោះ គ្រាន់តែបង្កើនការពន្យារពេល។ របាយការណ៍រយៈពេលវែងមិនតម្រូវឱ្យមានទិន្នន័យដែលបានមកដល់ក្នុងមូលដ្ឋានទិន្នន័យឥឡូវនេះទេ។ ប្រសិនបើអ្នកមានវារយៈពេលបីម៉ោង នោះអ្នកកំពុងដំណើរការវាសម្រាប់រយៈពេលទិន្នន័យចាស់មួយចំនួន។ ហើយសម្រាប់អ្នក មិនថាមានការពន្យាពេលបីម៉ោង ឬការពន្យាពេល XNUMX ម៉ោង នឹងមិនមានភាពខុសប្លែកគ្នានោះទេ ប៉ុន្តែអ្នកនឹងទទួលបានរបាយការណ៍ជាប់លាប់ ហើយនឹងមិនមានបញ្ហាជាមួយនឹងការធ្លាក់ចុះនោះទេ។
• តាមធម្មជាតិ អ្នកត្រូវគ្រប់គ្រងវគ្គវែងៗលើការចម្លង ជាពិសេសប្រសិនបើអ្នកសម្រេចចិត្តបើក hot_standby_feedback លើការចម្លង។ ព្រោះអ្វីៗអាចកើតឡើង។ យើងបានផ្តល់ការចម្លងនេះទៅឱ្យអ្នកអភិវឌ្ឍន៍ដើម្បីឱ្យគាត់អាចសាកល្បងសំណើ។ គាត់បានសរសេរសំណើឆ្កួតមួយ។ គាត់​បើក​វា ហើយ​ចេញ​ទៅ​ផឹក​តែ ហើយ​យើង​ក៏​ទទួល​ចៅហ្វាយ​ដែល​បាន​បង្កើត។ ឬប្រហែលជាយើងដាក់កម្មវិធីខុសនៅទីនោះ។ ស្ថានភាពគឺខុសគ្នា។ វគ្គនៅលើការចម្លងត្រូវតែត្រូវបានត្រួតពិនិត្យដោយប្រុងប្រយ័ត្នដូចនៅលើ Master ដែរ។
• ហើយប្រសិនបើអ្នកមានសំណួរលឿននិងវែងលើការចម្លងនោះក្នុងករណីនេះវាជាការប្រសើរក្នុងការបែងចែកពួកវាដើម្បីចែកចាយបន្ទុក។ នេះគឺជាតំណភ្ជាប់ទៅកាន់ streaming_delay ។ សម្រាប់​អ្នក​ដែល​មាន​ល្បឿន​លឿន សូម​មាន​ការ​ចម្លង​មួយ​ជាមួយ​នឹង​ការ​ពន្យារ​ពេល​ចម្លង​តូច។ សម្រាប់​សំណើ​រាយការណ៍​ដែល​មាន​រយៈពេល​យូរ សូម​មាន​ការ​ចម្លង​ដែល​អាច​យឺតយ៉ាវ​ត្រឹម 6 ម៉ោង ឬ​ក្នុង​មួយ​ថ្ងៃ។ នេះគឺជាស្ថានភាពធម្មតាទាំងស្រុង។

យើងលុបបំបាត់ផលវិបាកតាមរបៀបដូចគ្នា៖

• យើងរកឃើញតារាងហើមពោះ។
• ហើយយើងបង្ហាប់វាជាមួយនឹងឧបករណ៍ងាយស្រួលបំផុតដែលសាកសមនឹងយើង។

រឿងទីពីរបញ្ចប់នៅទីនេះ។ ចូរយើងបន្តទៅរឿងទីបី។

ក៏ជារឿងធម្មតាផងដែរសម្រាប់ពួកយើងដែលយើងធ្វើចំណាកស្រុក។

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

នេះ​ជា​ការ​ធ្វើ​ចំណាក​ស្រុក​ជាមួយ​នឹង​បច្ចុប្បន្នភាព​ដែល​បង្ហាញ​នៅ​ចំពោះ​មុខ​អ្នក។ ដោយសារទាំងនេះជាប្រតិបត្តិការគណនីរបស់ខ្ញុំ ចាននោះមានទំហំ 15 GB។ ហើយចាប់តាំងពីយើងធ្វើបច្ចុប្បន្នភាពគ្រប់បន្ទាត់ យើងបានបង្កើនទំហំតារាងពីរដងជាមួយនឹងការអាប់ដេត ព្រោះយើងសរសេរឡើងវិញគ្រប់បន្ទាត់។

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

យើងធ្វើចំណាកស្រុក ហើយមានបញ្ហាម្តងទៀត។

ការធ្វើចំណាកស្រុកបានជោគជ័យ ប៉ុន្តែ៖

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

ហើយនេះគឺជាការហើមពោះម្តងទៀត ដែលបំផ្លាញជីវិតរបស់យើងម្តងទៀត។

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

ហើយប្រសិនបើយើងងាកទៅរកតារាងជាមួយគណនី យើងនឹងឃើញថាពេលវេលាស្នើសុំជាមធ្យមបានកើនឡើងទ្វេដងសម្រាប់តារាងនេះ។ ការផ្ទុកនៅលើខួរក្បាលនិងចំនួនបន្ទាត់ដែលបានតម្រៀបចេញនៅក្នុងអង្គចងចាំបានកើនឡើងលើសពី 7,5 ប៉ុន្តែទាបជាង។ ហើយវាលោត 2 ដងនៅក្នុងករណីនៃដំណើរការ 1,5 ដងក្នុងករណីប្រតិបត្តិការប្លុក ពោលគឺយើងទទួលបានការថយចុះនៅក្នុងដំណើរការម៉ាស៊ីនមេ។ ហើយជាលទ្ធផល - ការរិចរិលនៃការអនុវត្តកម្មវិធីរបស់យើង។ ក្នុងពេលជាមួយគ្នានេះ ចំនួននៃការហៅទូរសព្ទនៅតែមានប្រមាណនៅកម្រិតដូចគ្នា។

ហើយរឿងសំខាន់នៅទីនេះគឺត្រូវយល់ពីរបៀបធ្វើចំណាកស្រុកឱ្យបានត្រឹមត្រូវ។ ហើយពួកគេត្រូវធ្វើ។ យើងធ្វើចំណាកស្រុកទាំងនេះជាប់លាប់។

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

ហើយក្នុងពេលជាមួយគ្នានេះយើងនឹងមិនហើមពោះទេហើយនឹងមិនរងទុក្ខក្នុងលក្ខខណ្ឌនៃការសម្តែង។

នេះជាកន្លែងដែលរឿងទីបីបញ្ចប់។

https://github.com/dataegret/pg-utils/blob/master/sql/table_bloat.sql

https://github.com/dataegret/pg-utils/blob/master/sql/table_bloat_approx.sql

ហើយឥឡូវនេះព័ត៌មានលម្អិតបន្តិចអំពីឧបករណ៍ដែលខ្ញុំបានលើកឡើងនៅក្នុងរឿងដំបូងបំផុត។

មុននឹងស្វែងរក bloat អ្នកត្រូវតែដំឡើងកម្មវិធីបន្ថែម pgstattuple.

ដូច្នេះ​ដើម្បី​កុំ​ឲ្យ​អ្នក​មាន​សំណួរ យើង​បាន​សរសេរ​សំណួរ​ទាំង​នេះ​រួច​ហើយ​នៅ​ក្នុង​ការងារ​របស់​យើង។ អ្នកអាចប្រើពួកវាបាន។ មានសំណើពីរនៅទីនេះ។

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

យើង​បាន​រក​ឃើញ​របៀប​កំណត់​តារាង​ដែល​ហើម​ដោយ​ទិន្នន័យ​គ្មាន​ប្រយោជន៍។

ឥឡូវនេះអំពីវិធីដោះស្រាយបញ្ហាហើមពោះ៖

• ប្រសិនបើយើងមានថេប្លេតតូច និងថាសល្អ នោះមានន័យថានៅលើថេប្លេតរហូតដល់មួយជីហ្គាបៃ វាពិតជាអាចទៅរួចក្នុងការប្រើប្រាស់ VACUUM FULL។ គាត់នឹងយកសោផ្តាច់មុខពីអ្នកនៅលើតុរយៈពេលពីរបីវិនាទី ហើយមិនអីទេ ប៉ុន្តែគាត់នឹងធ្វើអ្វីៗគ្រប់យ៉ាងយ៉ាងរហ័ស និងឃោរឃៅ។ តើ VACUUM FULL ធ្វើអ្វី? វាត្រូវការសោផ្តាច់មុខនៅលើតុ ហើយសរសេរឡើងវិញនូវជួរបន្តផ្ទាល់ពីតារាងចាស់ទៅក្នុងតារាងថ្មី។ ហើយនៅទីបញ្ចប់គាត់បានជំនួសពួកគេ។ វាលុបឯកសារចាស់ ហើយជំនួសឯកសារចាស់ជាមួយថ្មី។ ប៉ុន្តែសម្រាប់រយៈពេលនៃការងាររបស់វាវាត្រូវការសោផ្តាច់មុខនៅលើតុ។ នេះមានន័យថាអ្នកមិនអាចធ្វើអ្វីជាមួយតារាងនេះបានទេ៖ មិនសរសេរទៅវា ឬអានវា ឬកែប្រែវាទេ។ ហើយ VACUUM FULL ទាមទារទំហំថាសបន្ថែមដើម្បីសរសេរទិន្នន័យ។
• ឧបករណ៍បន្ទាប់ pg_repack. តាមគោលការណ៍របស់វា វាស្រដៀងទៅនឹង VACUUM FULL ព្រោះវាក៏សរសេរទិន្នន័យឡើងវិញពីឯកសារចាស់ទៅថ្មី ហើយជំនួសវានៅក្នុងតារាង។ ប៉ុន្តែនៅពេលជាមួយគ្នានេះ វាមិនយកសោផ្តាច់មុខនៅលើតុនៅដើមដំបូងនៃការងាររបស់វាទេ ប៉ុន្តែយកវាតែនៅពេលវាមានទិន្នន័យរួចរាល់ហើយ ដើម្បីជំនួសឯកសារ។ តម្រូវការធនធានថាសរបស់វាគឺស្រដៀងទៅនឹង VACUUM FULL ។ អ្នក​ត្រូវ​ការ​ទំហំ​ថាស​បន្ថែម ហើយ​ពេល​ខ្លះ​វា​សំខាន់​ណាស់​ប្រសិន​បើ​អ្នក​មាន​តារាង terabyte។ ហើយ​វា​ពិតជា​ឃ្លាន​ខ្លាំង​ណាស់ ព្រោះ​វា​ដំណើរការ​យ៉ាង​សកម្ម​ជាមួយ I/O ។
• ឧបករណ៍ប្រើប្រាស់ទីបីគឺ pgcompacttable. វាកាន់តែមានការប្រយ័ត្នប្រយែងចំពោះធនធាន ព្រោះវាដំណើរការទៅតាមគោលការណ៍ខុសគ្នាបន្តិចបន្តួច។ គំនិតចម្បងនៃ pgcompacttable គឺថាវាផ្លាស់ទីជួរដេកបន្តផ្ទាល់ទាំងអស់ទៅដើមតារាងដោយប្រើការអាប់ដេតក្នុងតារាង។ ហើយបន្ទាប់មកវាដំណើរការកន្លែងទំនេរនៅលើតុនេះ ពីព្រោះយើងដឹងថាយើងមានជួរបន្តផ្ទាល់នៅដើមដំបូង និងជួរស្លាប់នៅចុងបញ្ចប់។ ហើយម៉ាស៊ីនបូមធូលីខ្លួនវាកាត់កន្ទុយនេះ ពោលគឺវាមិនត្រូវការទំហំថាសបន្ថែមច្រើនទេ។ ហើយក្នុងពេលជាមួយគ្នានេះវានៅតែអាចច្របាច់ក្នុងលក្ខខណ្ឌនៃធនធាន។

អ្វីគ្រប់យ៉ាងជាមួយឧបករណ៍។

ប្រសិនបើអ្នករកឃើញប្រធានបទហើមពោះគួរឱ្យចាប់អារម្មណ៍ទាក់ទងនឹងការស្វែងរកបន្ថែមទៀតនៅខាងក្នុង នេះគឺជាតំណភ្ជាប់ដែលមានប្រយោជន៍មួយចំនួន៖

• https://www.slideshare.net/alexius2Mb/where-is-the-space-postgres - នេះជារបាយការណ៍ពីសហសេវិករបស់ខ្ញុំ។ វាជាទូទៅអំពីកន្លែងដែលលំហរបស់ Postgres ទៅក្នុងអំឡុងពេលការងារ និងជីវិតរបស់វា។ ហើយមានផ្នែកបច្ចេកទេសដ៏ធំ និងលម្អិតសម្រាប់អ្នកគ្រប់គ្រងមូលដ្ឋានទិន្នន័យអំពីការហើមពោះ។
• https://github.com/dataegret/pg-utils - នេះគឺជាតំណភ្ជាប់ទៅកាន់ឃ្លាំងរបស់យើង ដែលជាកន្លែងដែលយើងរក្សាទុកបណ្តុំនៃស្គ្រីបដែលមានប្រយោជន៍សម្រាប់ពិនិត្យមើលស្ថានភាពនៃមូលដ្ឋានទិន្នន័យ។ នៅទីនោះអ្នកអាចស្វែងរកស្គ្រីបដើម្បីស្វែងរកការហើមពោះ។
• ទីបី и ទីបួន តំណភ្ជាប់ទៅឧបករណ៍ដែលនឹងជួយអ្នកកាត់បន្ថយសញ្ញា។
• http://blog.dataegret.com/2Mb018/03/postgresql-bloatbusters.html - នេះជាការប្រកាសពីមិត្តរួមការងាររបស់ខ្ញុំ។ នៅទីនោះគាត់បានវិភាគយ៉ាងយកចិត្តទុកដាក់ និងបច្ចេកទេសយ៉ាងលម្អិតក្នុងកម្រិតមួយជិតស្និទ្ធនឹងអ្នកគ្រប់គ្រង។

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

សំណួរ

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

ក្នុងករណីនេះ នេះជាភារកិច្ចសម្រាប់អ្នកគ្រប់គ្រងក្រុមហ៊ុនរបស់អ្នក មិនចាំបាច់សម្រាប់ DBA ទេ។

ខ្ញុំជាអ្នកគ្រប់គ្រង។

PostgreSQL មានទិដ្ឋភាពមួយហៅថា pg_stat_activity ដែលបង្ហាញសំណួរ dangling ។ ហើយអ្នកអាចមើលឃើញរយៈពេលដែលវាព្យួរនៅទីនោះ។

តើខ្ញុំត្រូវចូលមើលរៀងរាល់ 5 នាទីទេ?

ដំឡើង cron និងពិនិត្យ។ ប្រសិនបើអ្នកមានសំណើរយៈពេលវែង សូមសរសេរសំបុត្រមួយ ហើយនោះហើយជាវា។ នោះគឺអ្នកមិនចាំបាច់មើលដោយភ្នែករបស់អ្នកទេ វាអាចដំណើរការដោយស្វ័យប្រវត្តិ អ្នកនឹងទទួលបានសំបុត្រមួយ អ្នកប្រតិកម្មនឹងវា។ ឬអ្នកអាចបាញ់ដោយស្វ័យប្រវត្តិ។

តើ​មាន​ហេតុ​ផល​ជាក់​លាក់​ណា​មួយ​ដែល​ធ្វើ​ឱ្យ​មាន​រឿង​នេះ​កើត​ឡើង​ទេ?

ខ្ញុំបានរាយបញ្ជីមួយចំនួន។ ឧទាហរណ៍ដ៏ស្មុគស្មាញផ្សេងទៀត។ ហើយ​អាច​មាន​ការ​សន្ទនា​ជា​យូរ​មក​ហើយ។

អរគុណសម្រាប់របាយការណ៍! ខ្ញុំចង់បញ្ជាក់អំពីឧបករណ៍ប្រើប្រាស់ pg_repack ។ ប្រសិនបើនាងមិនធ្វើសោផ្តាច់មុខទេនោះ ...

នាងធ្វើសោផ្តាច់មុខ។

... បន្ទាប់មកខ្ញុំអាចបាត់បង់ទិន្នន័យ។ តើ​ពាក្យ​សុំ​របស់​ខ្ញុំ​មិន​ត្រូវ​បាន​ថត​អ្វី​មួយ​ក្នុង​អំឡុង​ពេល​នេះ?

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

នោះគឺគាត់ពិតជាធ្វើវានៅទីបញ្ចប់?

នៅទីបញ្ចប់ គាត់យកសោផ្តាច់មុខដើម្បីប្តូរឯកសារទាំងនេះ។

តើវានឹងលឿនជាង VACUUM FULL ទេ?

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

សួស្តី! អ្នកបាននិយាយអំពីប្រតិបត្តិការម៉ាស៊ីនបូមធូលីរថយន្ត។ មានក្រាហ្វមួយដែលមានកោសិកាថតក្រហម លឿង និងបៃតង។ នោះគឺពណ៌លឿង - គាត់បានសម្គាល់ពួកវាថាបានលុប។ ហើយ​ជា​លទ្ធផល​អ្វី​ដែល​ថ្មី​អាច​ត្រូវ​បាន​សរសេរ​ទៅ​ក្នុង​ពួក​គេ?

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

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

ទេ ក្នុងករណីណាក៏ដោយ បន្ទាត់ទាំងមូលត្រូវបានធ្វើបច្ចុប្បន្នភាពនៅទីនោះ។ Postgres មានម៉ូដែលផ្ទុកទិន្នន័យពីរ។ វាជ្រើសរើសពីប្រភេទទិន្នន័យ។ មាន​ទិន្នន័យ​ដែល​ត្រូវ​បាន​រក្សា​ទុក​ដោយ​ផ្ទាល់​នៅ​ក្នុង​តារាង ហើយ​ក៏​មាន​ទិន្នន័យ tos ។ ទាំងនេះគឺជាទិន្នន័យដ៏ច្រើន៖ អត្ថបទ, json ។ ពួកវាត្រូវបានរក្សាទុកក្នុងចានដាច់ដោយឡែក។ ហើយយោងទៅតាមថេប្លេតទាំងនេះរឿងដូចគ្នាជាមួយនឹងការហើមពោះកើតឡើងពោលគឺអ្វីគ្រប់យ៉ាងគឺដូចគ្នា។ ពួកវាត្រូវបានរាយដោយឡែកពីគ្នា។

អរគុណសម្រាប់របាយការណ៍! តើ​វា​អាច​ទទួល​យក​បាន​ក្នុង​ការ​ប្រើ​សំណួរ​អស់​ពេល​នៃ​សេចក្តីថ្លែងការណ៍​ដើម្បី​កំណត់​រយៈពេល​ឬ?

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

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

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

នោះគឺវាបិទភ្លាមៗបន្ទាប់ពីការអាប់ដេត?

វាអាស្រ័យលើការកំណត់។ ខ្ញុំបានដាក់ឈ្មោះការកំណត់មួយ។ នេះគឺជាការប្តេជ្ញាចិត្តដោយស្វ័យប្រវត្តិ។ វាជារឿងធម្មតាណាស់។ ប្រសិនបើវាត្រូវបានបើក នោះប្រតិបត្តិការបានបើក និងបិទ។ លុះត្រាតែអ្នកបាននិយាយយ៉ាងច្បាស់ថា "ចាប់ផ្តើមប្រតិបត្តិការ" និង "ប្រតិបត្តិការបញ្ចប់" ប៉ុន្តែគ្រាន់តែចាប់ផ្តើមសំណើទៅក្នុងវគ្គ។

សួស្តី! អរគុណសម្រាប់របាយការណ៍! ចូរស្រមៃថាយើងមានមូលដ្ឋានទិន្នន័យដែលហើមនិងហើមហើយបន្ទាប់មកទំហំនៅលើម៉ាស៊ីនមេនឹងអស់។ តើ​មាន​ឧបករណ៍​ដើម្បី​ដោះស្រាយ​ស្ថានភាព​នេះ​ទេ?

ចន្លោះនៅលើម៉ាស៊ីនមេត្រូវតែត្រួតពិនិត្យឱ្យបានត្រឹមត្រូវ។

ឧទាហរណ៍ DBA បានទៅផឹកតែនៅរមណីយដ្ឋាន។ល។

នៅពេលដែលប្រព័ន្ធឯកសារត្រូវបានបង្កើត យ៉ាងហោចណាស់ប្រភេទនៃទំហំបម្រុងទុកមួយចំនួនត្រូវបានបង្កើតឡើងដែលទិន្នន័យមិនត្រូវបានសរសេរ។

ចុះបើវានៅខាងក្រោមសូន្យទាំងស្រុង?

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

តើមានឧបករណ៍ផ្សេងទៀតទេ?

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

អរគុណសម្រាប់របាយការណ៍! ខ្ញុំមានសំណួរពីរ។ ដំបូង អ្នក​បាន​បង្ហាញ​ស្លាយ​ដែល​បង្ហាញ​ថា​នៅ​ពេល​ប្រតិបត្តិការ​ត្រូវ​បាន​ជាប់គាំង ទាំង​ទំហំ​តារាង​និង​ទំហំ​លិបិក្រម​នឹង​កើនឡើង។ ហើយបន្ថែមទៀតនៅលើរបាយការណ៍មានឧបករណ៍ប្រើប្រាស់ជាច្រើនដែលវេចខ្ចប់ថេប្លេត។ ចុះសន្ទស្សន៍?

ពួកគេខ្ចប់ពួកគេផងដែរ។

ប៉ុន្តែការខ្វះចន្លោះមិនប៉ះពាល់ដល់សន្ទស្សន៍ទេ?

ខ្លះធ្វើការជាមួយសន្ទស្សន៍។ ឧទាហរណ៍ pg_rapack, pgcompacttable ។ កន្លែងទំនេរបង្កើតសន្ទស្សន៍ឡើងវិញ និងប៉ះពាល់ដល់ពួកគេ។ ជាមួយនឹង VACUUM FULL គំនិតគឺដើម្បីសរសេរជាន់លើអ្វីគ្រប់យ៉ាង ពោលគឺវាដំណើរការជាមួយមនុស្សគ្រប់គ្នា។

ហើយសំណួរទីពីរ។ ខ្ញុំ​មិន​យល់​ថា​ហេតុ​អ្វី​បាន​ជា​របាយ​ការណ៍​អំពី​ការ​ចម្លង​អាស្រ័យ​លើ​ការ​ចម្លង​ខ្លួន​វា​ច្រើន​ពេក។ វាហាក់ដូចជាខ្ញុំថារបាយការណ៍ត្រូវបានអាន ហើយការចម្លងគឺត្រូវបានសរសេរ។

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

Andrey ខ្ញុំមានសំណួរមួយ។ ក្រាហ្វដ៏អស្ចារ្យទាំងនេះដែលអ្នកបានបង្ហាញក្នុងអំឡុងពេលធ្វើបទបង្ហាញ តើទាំងនេះជាលទ្ធផលនៃការងាររបស់ឧបករណ៍ប្រើប្រាស់មួយចំនួនរបស់អ្នកដែរឬទេ? តើក្រាហ្វត្រូវបានបង្កើតឡើងយ៉ាងដូចម្តេច?

នេះគឺជាសេវាកម្មមួយ។ Okmeter.

តើនេះជាផលិតផលពាណិជ្ជកម្មមែនទេ?

បាទ។ នេះគឺជាផលិតផលពាណិជ្ជកម្ម។

ប្រភព: www.habr.com