ការសំយោគជាវិធីសាស្រ្តមួយដើម្បីកែលម្អការអនុវត្ត PostgreSQL

សេចក្តីផ្តើមទស្សនវិជ្ជា

ដូច​អ្នក​ដឹង​ហើយ​ថា មាន​តែ​វិធី​ពីរ​យ៉ាង​សម្រាប់​ការ​ដោះ​ស្រាយ​បញ្ហា៖

1. វិធីសាស្រ្តនៃការវិភាគ ឬវិធីសាស្រ្តនៃការកាត់ ឬពីទូទៅទៅជាក់លាក់។
2. វិធីសាស្រ្តនៃការសំយោគ ឬវិធីសាស្រ្តនៃការបញ្ចូល ឬពីពិសេសទៅទូទៅ។

ដើម្បីដោះស្រាយបញ្ហា "ធ្វើអោយប្រសើរឡើងនូវដំណើរការមូលដ្ឋានទិន្នន័យ" វាអាចមើលទៅដូចនេះ។

Анализ - យើងវិភាគបញ្ហាទៅជាផ្នែកដាច់ដោយឡែក ហើយដោយការដោះស្រាយវា យើងព្យាយាមកែលម្អដំណើរការនៃមូលដ្ឋានទិន្នន័យទាំងមូល។

នៅក្នុងការអនុវត្ត ការវិភាគមើលទៅដូចនេះ៖

• បញ្ហាកើតឡើង (ឧប្បត្តិហេតុនៃការអនុវត្ត)
• ការប្រមូលព័ត៌មានស្ថិតិអំពីស្ថានភាពនៃមូលដ្ឋានទិន្នន័យ
• កំពុងរកមើលការស្ទះ
• យើងដោះស្រាយបញ្ហាពីការស្ទះ

ការរារាំងមូលដ្ឋានទិន្នន័យ - ហេដ្ឋារចនាសម្ព័ន្ធ (CPU, Memory, Disks, Network, OS), ការកំណត់ (postgresql.conf), សំណួរ៖

ហេដ្ឋារចនាសម្ព័ន្ធ៖ លទ្ធភាពនៃឥទ្ធិពល និងការផ្លាស់ប្តូរសម្រាប់វិស្វករគឺស្ទើរតែសូន្យ។

ការកំណត់មូលដ្ឋានទិន្នន័យ៖ លទ្ធភាពសម្រាប់ការផ្លាស់ប្តូរគឺធំជាងករណីមុនបន្តិច ប៉ុន្តែជាក្បួនពួកគេនៅតែមានការលំបាក ជាពិសេសនៅក្នុងពពក។

សំណើ ទៅមូលដ្ឋានទិន្នន័យ៖ មានតែបន្ទប់សម្រាប់ធ្វើសមយុទ្ធ.

សំយោគ - យើងធ្វើឱ្យប្រសើរឡើងនូវការអនុវត្តនៃផ្នែកនីមួយៗ ដោយរំពឹងថាការអនុវត្តមូលដ្ឋានទិន្នន័យនឹងប្រសើរឡើងជាលទ្ធផល។

ការណែនាំអំពីទំនុកច្រៀង ឬហេតុអ្វីបានជាទាំងអស់នេះចាំបាច់

តើអ្វីជាដំណើរការសម្រាប់ដោះស្រាយឧប្បត្តិហេតុនៃការអនុវត្ត ប្រសិនបើដំណើរការមូលដ្ឋានទិន្នន័យមិនត្រូវបានត្រួតពិនិត្យ៖

អតិថិជន - "អ្វីគ្រប់យ៉ាងគឺមិនល្អជាមួយយើង វាចំណាយពេលយូរពេក ធ្វើអ្វីដែលល្អសម្រាប់យើង"
វិស្វករ - តើវាអាក្រក់ប៉ុណ្ណា?
អតិថិជន - "នោះហើយជារបៀបដែលវាឥឡូវនេះ (មួយម៉ោងមុនកាលពីម្សិលមិញវាជាពេលវេលាចុងក្រោយ) យឺត"
វិស្វករ - "តើវាល្អនៅពេលណា?"
អតិថិជន - "មួយសប្តាហ៍ (ពីរសប្តាហ៍) មុនវាមិនអាក្រក់ទេ។ “(សំណាងណាស់)
អតិថិជន - "ខ្ញុំមិនចាំថាពេលណាវាល្អទេ ប៉ុន្តែឥឡូវនេះវាអាក្រក់" (ចម្លើយធម្មតា)

លទ្ធផលគឺជារូបភាពបុរាណ៖

តើត្រូវស្តីបន្ទោសអ្នកណា ហើយត្រូវធ្វើអ្វី?

ផ្នែកដំបូងនៃសំណួរគឺងាយស្រួលបំផុតក្នុងការឆ្លើយ - វិស្វករ DBA តែងតែត្រូវស្តីបន្ទោស។

ផ្នែកទីពីរក៏មិនពិបាកឆ្លើយដែរ - អ្នកត្រូវអនុវត្តប្រព័ន្ធត្រួតពិនិត្យដំណើរការមូលដ្ឋានទិន្នន័យ។

សំណួរទីមួយកើតឡើង - អ្វីដែលត្រូវតាមដាន?

ផ្លូវទី 1. យើងនឹងតាមដានអ្វីៗទាំងអស់។

ការផ្ទុកស៊ីភីយូ ចំនួនប្រតិបត្តិការអាន/សរសេរថាស ទំហំនៃអង្គចងចាំដែលបានបែងចែក និងមេហ្គាតុនផ្សេងទៀតនៃបញ្ជរផ្សេងៗគ្នា ដែលប្រព័ន្ធត្រួតពិនិត្យការងារច្រើន ឬតិចអាចផ្តល់ឱ្យ។

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

វិធីទី 2. ត្រួតពិនិត្យតែអ្វីដែលចាំបាច់ ហើយអ្វីដែលមិនចាំបាច់ មិនចាំបាច់ត្រួតពិនិត្យទេ។

អ្នកអាចតាមដាន ខុសគ្នាបន្តិចបន្តួច មានតែអង្គភាព និងព្រឹត្តិការណ៍ប៉ុណ្ណោះ៖

• តើវិស្វករ DBA ណាអាចមានឥទ្ធិពល
• ដែលវាមានក្បួនដោះស្រាយនៃសកម្មភាពនៅពេលដែលព្រឹត្តិការណ៍កើតឡើង ឬអង្គភាពផ្លាស់ប្តូរ។

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

ប៉ុន្តែ​ដើម្បី​កែលម្អ​សំណួរ​ធ្ងន់ៗ​ដែល​ប៉ះពាល់​ដល់​ដំណើរការ​មូលដ្ឋាន​ទិន្នន័យ​ទាំងមូល អ្នក​ត្រូវតែ​ស្វែងរក​វា​ជាមុនសិន។

ដូច្នេះសំណួរពីរដែលទាក់ទងគ្នាកើតឡើង៖

• សំណើ​ណា​មួយ​ត្រូវ​បាន​ចាត់​ទុក​ថា​ពិបាក
• របៀបស្វែងរកសំណួរពិបាក។

ជាក់ស្តែង សំណួរធ្ងន់គឺជាសំណួរដែលប្រើធនធាន OS ជាច្រើនដើម្បីទទួលបានលទ្ធផល។

ចូរបន្តទៅសំណួរទីពីរ - របៀបស្វែងរកហើយបន្ទាប់មកតាមដានសំណួរធ្ងន់ៗ?

តើ PostgreSQL មានសមត្ថភាពត្រួតពិនិត្យសំណួរអ្វីខ្លះ?

បើប្រៀបធៀបទៅនឹង Oracle មានលទ្ធភាពតិចតួច ប៉ុន្តែនៅតែមានអ្វីមួយដែលអាចធ្វើបាន។

PG_STAT_STATEMENTS

ដើម្បីស្វែងរក និងតាមដានសំណួរធ្ងន់ៗនៅក្នុង PostgreSQL ផ្នែកបន្ថែមស្តង់ដារ pg_stat_statements ត្រូវបានបម្រុងទុក។

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

តម្រង់ជួរជួរឈរ pg_stat_statements សម្រាប់បង្កើតប្រព័ន្ធត្រួតពិនិត្យ៖

• សំណួរ កូដ hash ខាងក្នុងត្រូវបានគណនាពីមែកធាងញែករបស់ប្រតិបត្តិករ
• ពេលវេលាអតិបរមា ពេលវេលាអតិបរមាដែលចំណាយលើសេចក្តីថ្លែងការណ៍មួយគិតជាមិល្លីវិនាទី

តាមរយៈការប្រមូល និងប្រើប្រាស់ស្ថិតិនៅលើជួរឈរទាំងពីរនេះ អ្នកអាចបង្កើតប្រព័ន្ធត្រួតពិនិត្យមួយ។

របៀបដែល pg_stat_statements ត្រូវបានប្រើដើម្បីតាមដានការអនុវត្ត PostgreSQL

ដើម្បីតាមដានការអនុវត្តសំណួរប្រើ៖
នៅលើផ្នែកមូលដ្ឋានទិន្នន័យគោលដៅ - ទិដ្ឋភាព pg_stat_statements
ពីចំហៀង ម៉ាស៊ីនបម្រើ និងមូលដ្ឋានទិន្នន័យត្រួតពិនិត្យ - សំណុំនៃស្គ្រីប bash និងតារាងសេវាកម្ម។

ដំណាក់កាលទី 1 - ការប្រមូលទិន្នន័យស្ថិតិ

នៅលើម៉ាស៊ីនត្រួតពិនិត្យ cron ស្គ្រីបមួយត្រូវបានចាប់ផ្តើមជាទៀងទាត់ដែលចម្លងមាតិកានៃទិដ្ឋភាព pg_stat_statements ពីមូលដ្ឋានទិន្នន័យគោលដៅទៅតារាង pg_stat_history នៅក្នុងមូលដ្ឋានទិន្នន័យត្រួតពិនិត្យ។

វាបង្កើតប្រវត្តិនៃការប្រតិបត្តិសំណួរនីមួយៗ ដែលអាចត្រូវបានប្រើដើម្បីបង្កើតរបាយការណ៍ប្រតិបត្តិការ និងកំណត់រចនាសម្ព័ន្ធម៉ែត្រ។

ដំណាក់កាលទី 2 - ការដំឡើងរង្វាស់នៃការអនុវត្ត

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

លទ្ធផល - ការចាប់ផ្តើមនៃការត្រួតពិនិត្យការអនុវត្ត

1. ស្គ្រីបត្រួតពិនិត្យ នៅពេលដំណើរការ ពិនិត្យមើលការវាស់វែងការអនុវត្តដែលបានកំណត់រចនាសម្ព័ន្ធដោយប្រៀបធៀបតម្លៃអតិបរមារបស់ម៉ែត្រជាមួយនឹងតម្លៃពីទិដ្ឋភាព pg_stat_statements នៅក្នុងមូលដ្ឋានទិន្នន័យគោលដៅ។
2. ប្រសិនបើតម្លៃនៅក្នុងមូលដ្ឋានទិន្នន័យគោលដៅលើសពីតម្លៃម៉ែត្រ ការព្រមានត្រូវបានបង្កើត (ឧប្បត្តិហេតុនៅក្នុងប្រព័ន្ធសំបុត្រ)

ជម្រើសបន្ថែម ១

ប្រវត្តិផែនការសំណួរ

ដើម្បីជួយដោះស្រាយឧប្បត្តិហេតុនៃការអនុវត្តនៅពេលក្រោយ វាជាការល្អក្នុងការមានប្រវត្តិនៃការផ្លាស់ប្តូរផែនការប្រតិបត្តិសំណួរ។

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

ជម្រើសបន្ថែម ១

ដំណើរការកែលម្អការអនុវត្តជាបន្តបន្ទាប់

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

ដើម្បីធ្វើដូច្នេះ អ្នកត្រូវបញ្ចូលការវាស់វែងការអនុវត្តបន្ថែម៖

• ក្នុងប៉ុន្មានថ្ងៃថ្មីៗនេះ
• សម្រាប់រយៈពេលមូលដ្ឋាន

ស្គ្រីបជ្រើសរើសសំណួរពីទិដ្ឋភាព pg_stat_statements នៅក្នុងមូលដ្ឋានទិន្នន័យគោលដៅ ហើយប្រៀបធៀបតម្លៃ max_time ជាមួយនឹងតម្លៃ max_time ជាមធ្យម ក្នុងករណីទីមួយសម្រាប់ថ្ងៃចុងក្រោយ ឬសម្រាប់រយៈពេលដែលបានជ្រើសរើស (បន្ទាត់មូលដ្ឋាន) ក្នុងករណីទីពីរ។

ដូច្នេះ ក្នុងករណីមានការថយចុះនៃការអនុវត្តសម្រាប់សំណើណាមួយ ការព្រមាននឹងត្រូវបានបង្កើតដោយស្វ័យប្រវត្តិ ដោយគ្មានការវិភាគដោយដៃនៃរបាយការណ៍។

តើ​ការ​សំយោគ​ត្រូវ​ធ្វើ​អ្វី​ជាមួយ​វា?

នៅក្នុងវិធីសាស្រ្តដែលបានពិពណ៌នា ដូចដែលវិធីសាស្ត្រសំយោគបានណែនាំ ដោយការកែលម្អផ្នែកនីមួយៗនៃប្រព័ន្ធ យើងធ្វើអោយប្រព័ន្ធទាំងមូលកាន់តែប្រសើរឡើង។

• សំណួរត្រូវបានប្រតិបត្តិដោយមូលដ្ឋានទិន្នន័យ - អរូបី
• សំណើដែលបានកែប្រែ - ការប្រឆាំងជំទាស់
• ការផ្លាស់ប្តូរស្ថានភាពនៃប្រព័ន្ធ - ការសំយោគ

ការអភិវឌ្ឍប្រព័ន្ធ

• ផ្នែកបន្ថែមនៃស្ថិតិដែលប្រមូលបានដោយបន្ថែមប្រវត្តិសម្រាប់ទិដ្ឋភាពប្រព័ន្ធ pg_stat_activity
• ពង្រីកស្ថិតិដែលប្រមូលបានដោយបន្ថែមប្រវត្តិសម្រាប់ស្ថិតិនៃតារាងបុគ្គលដែលចូលរួមក្នុងសំណួរ
• ការរួមបញ្ចូលជាមួយប្រព័ន្ធត្រួតពិនិត្យពពក AWS
• ហើយ​អ្នក​អាច​មក​រក​អ្វី​មួយ...

ប្រភព: www.habr.com