🥇ចូលជ្រៅទៅក្នុងស្ថិតិផ្ទៃក្នុង PostgreSQL ។ Alexey Lesovsky

ប្រតិចារិកនៃរបាយការណ៍ឆ្នាំ 2015 ដោយ Alexey Lesovsky "ជ្រមុជទឹកចូលទៅក្នុងស្ថិតិផ្ទៃក្នុង PostgreSQL"

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

PostgreSQL DBMS គឺជាយន្តការដ៏ធំមួយ ហើយយន្តការនេះមានប្រព័ន្ធរងជាច្រើន ដែលជាការងារសម្របសម្រួលដែលជះឥទ្ធិពលដោយផ្ទាល់ដល់ដំណើរការរបស់ DBMS ។ ក្នុងអំឡុងពេលប្រតិបត្តិការ ស្ថិតិ និងព័ត៌មានអំពីប្រតិបត្តិការនៃសមាសធាតុត្រូវបានប្រមូល ដែលអនុញ្ញាតឱ្យអ្នកវាយតម្លៃប្រសិទ្ធភាពនៃ PostgreSQL និងចាត់វិធានការដើម្បីកែលម្អការអនុវត្ត។ ទោះយ៉ាងណាក៏ដោយ មានព័ត៌មាននេះច្រើន ហើយវាត្រូវបានបង្ហាញជាទម្រង់សាមញ្ញជាង។ ការដំណើរការព័ត៌មាននេះ និងការបកស្រាយវាជួនកាលជាកិច្ចការដែលមិនសំខាន់ទាំងស្រុង ហើយ "សួនសត្វ" នៃឧបករណ៍ និងឧបករណ៍ប្រើប្រាស់អាចច្រឡំយ៉ាងងាយស្រួលសូម្បីតែ DBA កម្រិតខ្ពស់ក៏ដោយ។

អរុណសួស្តី ខ្ញុំឈ្មោះ អាឡិច។ ដូចដែល Ilya បាននិយាយខ្ញុំនឹងនិយាយអំពីស្ថិតិ PostgreSQL ។

ស្ថិតិសកម្មភាព PostgreSQL ។ PostgreSQL មានស្ថិតិពីរ។ ស្ថិតិសកម្មភាព ដែលនឹងត្រូវបានពិភាក្សា។ និងស្ថិតិអ្នកកំណត់ពេលអំពីការចែកចាយទិន្នន័យ។ ខ្ញុំនឹងនិយាយជាពិសេសអំពីស្ថិតិសកម្មភាព PostgreSQL ដែលអនុញ្ញាតឱ្យយើងវិនិច្ឆ័យការអនុវត្ត និងកែលម្អវាដោយដូចម្ដេច។

ខ្ញុំនឹងប្រាប់អ្នកពីរបៀបប្រើប្រាស់ស្ថិតិប្រកបដោយប្រសិទ្ធភាព ដើម្បីដោះស្រាយបញ្ហាផ្សេងៗដែលអ្នកមាន ឬអាចមាន។

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

ហើយនឹងមិនមានការពិនិត្យឧបករណ៍ទេ ខ្ញុំនឹងមិនប្រៀបធៀបផលិតផលមួយជាមួយផលិតផលមួយផ្សេងទៀតទេ។ នឹងមិនមានការផ្សាយពាណិជ្ជកម្មទេ។ ចូរទម្លាក់នេះចុះ។

ខ្ញុំចង់បង្ហាញអ្នកថាការប្រើស្ថិតិមានប្រយោជន៍។ វាគឺជាការចាំបាច់។ ប្រើវាដោយមិនភ័យខ្លាច។ អ្វីដែលយើងត្រូវការគឺ SQL ធម្មតា និងចំណេះដឹងជាមូលដ្ឋាននៃ SQL ។

ហើយយើងនឹងនិយាយអំពីស្ថិតិមួយណាដែលត្រូវជ្រើសរើសដើម្បីដោះស្រាយបញ្ហា។

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

យើងអាចពិនិត្យមើលការផ្ទុកស៊ីភីយូ topយើងអាចមើលឃើញការប្រើប្រាស់អង្គចងចាំដោយឧបករណ៍ប្រើប្រាស់ប្រព័ន្ធមួយចំនួន ប៉ុន្តែយើងនឹងមិនអាចមើលខាងក្នុង PostgreSQL បានទេ។ សម្រាប់បញ្ហានេះយើងត្រូវការឧបករណ៍ផ្សេងទៀត។

ហើយបន្តទៅមុខទៀត ខ្ញុំនឹងប្រាប់អ្នកពីកន្លែងដែលពេលវេលាត្រូវចំណាយ។ ប្រសិនបើយើងតំណាងឱ្យ PostgreSQL ក្នុងទម្រង់នៃគ្រោងការណ៍បែបនេះ នោះវានឹងអាចឆ្លើយបានថា តើពេលវេលាត្រូវចំណាយនៅឯណា។ ទាំងនេះគឺជារឿងពីរ៖ វាគឺជាដំណើរការនៃសំណើរបស់អតិថិជនពីកម្មវិធី និងកិច្ចការផ្ទៃខាងក្រោយដែល PostgreSQL អនុវត្តដើម្បីឱ្យវាដំណើរការ។

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

តើយើងមានអ្វីខ្លះជាមួយនឹងកិច្ចការផ្ទៃខាងក្រោយ និងដំណើរការផ្ទៃខាងក្រោយ? យើងមានដំណើរការជាច្រើនដែលរក្សាមូលដ្ឋានទិន្នន័យឱ្យដំណើរការក្នុងរបៀបប្រតិបត្តិការធម្មតា។ ដំណើរការទាំងនេះក៏នឹងត្រូវបានគ្របដណ្តប់នៅក្នុងរបាយការណ៍ផងដែរ៖ ទាំងនេះគឺជា autovacuum, checkpointer, processes related to replication, background writer. ខ្ញុំនឹងប៉ះលើពួកគេម្នាក់ៗដូចដែលខ្ញុំរាយការណ៍។

តើស្ថិតិមានបញ្ហាអ្វីខ្លះ?

ព័ត៌មានជាច្រើន។ PostgreSQL 9.4 ផ្តល់ 109 ម៉ែត្រសម្រាប់ការមើលទិន្នន័យស្ថិតិ។ ទោះយ៉ាងណាក៏ដោយ ប្រសិនបើឃ្លាំងទិន្នន័យផ្ទុកតារាងជាច្រើន គ្រោងការណ៍ មូលដ្ឋានទិន្នន័យ នោះម៉ែត្រទាំងអស់នេះនឹងត្រូវគុណនឹងចំនួនតារាង មូលដ្ឋានទិន្នន័យដែលត្រូវគ្នា។ នោះគឺមានព័ត៌មានបន្ថែម។ ហើយវាងាយស្រួលណាស់ក្នុងការលង់ទឹក។
បញ្ហាបន្ទាប់គឺថាស្ថិតិត្រូវបានតំណាងដោយបញ្ជរ។ ប្រសិនបើយើងក្រឡេកមើលស្ថិតិទាំងនេះ យើងនឹងឃើញការកើនឡើងជាបន្តបន្ទាប់។ ហើយប្រសិនបើពេលវេលាជាច្រើនបានកន្លងផុតទៅចាប់តាំងពីស្ថិតិត្រូវបានកំណត់ឡើងវិញ នោះយើងនឹងឃើញតម្លៃរាប់ពាន់លាន។ ហើយពួកគេមិនប្រាប់យើងអ្វីទាំងអស់។
មិនមានប្រវត្តិទេ។ ប្រសិនបើអ្នកមានប្រភេទនៃការបរាជ័យអ្វីមួយបានធ្លាក់ចុះ 15-30 នាទីមុន អ្នកនឹងមិនអាចប្រើស្ថិតិនិងឃើញអ្វីដែលបានកើតឡើងកាលពី 15-30 នាទីមុន។ នេះជាបញ្ហា។
កង្វះឧបករណ៍ដែលបានបង្កើតឡើងនៅក្នុង PostgreSQL គឺជាបញ្ហាមួយ។ អ្នកអភិវឌ្ឍន៍ខឺណែលមិនផ្តល់ឧបករណ៍ប្រើប្រាស់ណាមួយឡើយ។ ពួកគេមិនមានអ្វីដូចនោះទេ។ ពួកគេគ្រាន់តែផ្តល់ស្ថិតិនៅក្នុងមូលដ្ឋានទិន្នន័យ។ ប្រើវា ធ្វើសំណើទៅវា អ្វីដែលអ្នកចង់បាន បន្ទាប់មកធ្វើវា។
ដោយសារតែមិនមានឧបករណ៍ដែលបានបង្កើតឡើងនៅក្នុង PostgreSQL នេះបណ្តាលឱ្យមានបញ្ហាមួយផ្សេងទៀត។ ឧបករណ៍ភាគីទីបីជាច្រើន។ គ្រប់ក្រុមហ៊ុនដែលមានដៃផ្ទាល់ច្រើន ឬតិច កំពុងព្យាយាមសរសេរកម្មវិធីផ្ទាល់ខ្លួន។ ហើយជាលទ្ធផល សហគមន៍មានឧបករណ៍ជាច្រើនដែលអ្នកអាចប្រើដើម្បីធ្វើការជាមួយស្ថិតិ។ ហើយនៅក្នុងឧបករណ៍មួយចំនួនមានលក្ខណៈពិសេសមួយចំនួននៅក្នុងឧបករណ៍ផ្សេងទៀតមិនមានលក្ខណៈពិសេសផ្សេងទៀតឬមានលក្ខណៈពិសេសថ្មីមួយចំនួន។ ហើយស្ថានភាពមួយកើតឡើងដែលអ្នកត្រូវប្រើឧបករណ៍ពីរ បី ឬបួន ដែលត្រួតលើគ្នា និងមានមុខងារខុសៗគ្នា។ នេះជាការរំខានខ្លាំងណាស់។

តើមានអ្វីបន្តពីនេះ? វាជាការសំខាន់ដើម្បីអាចយកស្ថិតិដោយផ្ទាល់ ដើម្បីកុំឱ្យពឹងផ្អែកលើកម្មវិធី ឬកែលម្អកម្មវិធីទាំងនេះដោយខ្លួនឯង៖ បន្ថែមមុខងារមួយចំនួនដើម្បីទទួលបានអត្ថប្រយោជន៍របស់អ្នក។

ហើយអ្នកត្រូវការចំណេះដឹងជាមូលដ្ឋាននៃ SQL ។ ដើម្បីទទួលបានទិន្នន័យមួយចំនួនពីស្ថិតិ អ្នកត្រូវបង្កើតសំណួរ SQL ពោលគឺអ្នកត្រូវដឹងពីរបៀបជ្រើសរើស ចូលរួម។

ស្ថិតិប្រាប់យើងនូវរឿងជាច្រើន។ ពួកគេអាចត្រូវបានបែងចែកជាប្រភេទ។

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

ប្រភពនៃស្ថិតិត្រូវបានបង្ហាញដូចខាងក្រោម:

នៅក្នុងអង្គចងចាំដែលបានចែករំលែក (shared buffers) មានផ្នែកមួយសម្រាប់ដាក់ទិន្នន័យឋិតិវន្តនៅទីនោះ ក៏មានរាប់ទាំងនោះដែលត្រូវបានបង្កើនជាបន្តបន្ទាប់នៅពេលដែលព្រឹត្តិការណ៍ជាក់លាក់កើតឡើង ឬពេលខ្លះកើតឡើងនៅក្នុងប្រតិបត្តិការនៃមូលដ្ឋានទិន្នន័យ។
បញ្ជរទាំងអស់នេះមិនមានសម្រាប់អ្នកប្រើប្រាស់ទេ ហើយក៏មិនមានសម្រាប់អ្នកគ្រប់គ្រងដែរ។ ទាំងនេះគឺជាវត្ថុកម្រិតទាប។ ដើម្បីចូលប្រើពួកវា PostgreSQL ផ្តល់នូវចំណុចប្រទាក់ក្នុងទម្រង់នៃមុខងារ SQL ។ យើងអាចធ្វើការជ្រើសរើសដោយប្រើមុខងារទាំងនេះ ហើយទទួលបានប្រភេទម៉ែត្រមួយចំនួន (ឬសំណុំម៉ែត្រ)។
ទោះយ៉ាងណាក៏ដោយ វាមិនតែងតែងាយស្រួលប្រើមុខងារទាំងនេះទេ ដូច្នេះមុខងារគឺជាមូលដ្ឋានសម្រាប់ទិដ្ឋភាព (VIEWs)។ ទាំងនេះគឺជាតារាងនិម្មិតដែលផ្តល់ស្ថិតិនៅលើប្រព័ន្ធរងជាក់លាក់មួយ ឬនៅលើសំណុំនៃព្រឹត្តិការណ៍មួយចំនួននៅក្នុងមូលដ្ឋានទិន្នន័យ។
ទិដ្ឋភាពដែលភ្ជាប់មកជាមួយ (VIEWs) ទាំងនេះគឺជាចំណុចប្រទាក់អ្នកប្រើសំខាន់សម្រាប់ធ្វើការជាមួយស្ថិតិ។ ពួកវាអាចប្រើបានតាមលំនាំដើមដោយគ្មានការកំណត់បន្ថែម អ្នកអាចប្រើវាភ្លាមៗ មើល យកព័ត៌មានពីទីនោះ។ ហើយក៏មានការរួមចំណែកផងដែរ។ ការចូលរួមចំណែកជាផ្លូវការ។ អ្នកអាចដំឡើងកញ្ចប់ postgresql-contrib (ឧទាហរណ៍ postgresql94-contrib) ផ្ទុកម៉ូឌុលចាំបាច់ក្នុងការកំណត់រចនាសម្ព័ន្ធ បញ្ជាក់ប៉ារ៉ាម៉ែត្រសម្រាប់វា ចាប់ផ្ដើម PostgreSQL ហើយអ្នកអាចប្រើវាបាន។ (ចំណាំ។ អាស្រ័យលើការចែកចាយ នៅក្នុងកំណែថ្មីៗនៃការរួមចំណែក កញ្ចប់គឺជាផ្នែកមួយនៃកញ្ចប់ចម្បង).
ហើយមានការរួមចំណែកក្រៅផ្លូវការ។ ពួកគេមិនត្រូវបានផ្គត់ផ្គង់ជាមួយនឹងការចែកចាយ PostgreSQL ស្តង់ដារទេ។ ពួកគេត្រូវតែចងក្រង ឬដំឡើងជាបណ្ណាល័យ។ ជម្រើសអាចមានភាពខុសគ្នាខ្លាំង អាស្រ័យលើអ្វីដែលអ្នកអភិវឌ្ឍន៍នៃការរួមចំណែកក្រៅផ្លូវការនេះបានបង្កើតឡើង។

ស្លាយនេះបង្ហាញពីទិដ្ឋភាពទាំងអស់នោះ (VIEWs) និងមុខងារមួយចំនួនដែលមាននៅក្នុង PostgreSQL 9.4។ ដូចដែលយើងឃើញមានពួកគេជាច្រើន។ ហើយវាងាយស្រួលណាស់ក្នុងការយល់ច្រលំ ប្រសិនបើអ្នកជួបប្រទះវាជាលើកដំបូង។

ទោះយ៉ាងណាក៏ដោយប្រសិនបើយើងយករូបភាពមុន។ Как тратится время на PostgreSQL ហើយត្រូវគ្នាជាមួយបញ្ជីនេះ យើងទទួលបានរូបភាពនេះ។ ទិដ្ឋភាពនីមួយៗ (VIEWs) ឬមុខងារនីមួយៗ យើងអាចប្រើសម្រាប់គោលបំណងមួយ ឬមួយផ្សេងទៀត ដើម្បីទទួលបានស្ថិតិសមស្របនៅពេលដែលយើងមាន PostgreSQL កំពុងដំណើរការ។ ហើយយើងអាចទទួលបានព័ត៌មានមួយចំនួនរួចហើយអំពីប្រតិបត្តិការនៃប្រព័ន្ធរង។

រឿងដំបូងដែលយើងនឹងមើលគឺ pg_stat_database. ដូចដែលយើងអាចមើលឃើញនេះគឺជាតំណាង។ វាមានព័ត៌មានជាច្រើន។ ព័ត៌មានចម្រុះបំផុត។ ហើយវាផ្តល់នូវចំណេះដឹងដ៏មានប្រយោជន៍នៃអ្វីដែលយើងកំពុងកើតឡើងក្នុងមូលដ្ឋានទិន្នន័យ។

តើយើងអាចយកអ្វីពីទីនោះ? ចូរចាប់ផ្តើមជាមួយនឹងអ្វីដែលសាមញ្ញបំផុត។

select
sum(blks_hit)*100/sum(blks_hit+blks_read) as hit_ratio
from pg_stat_database;

រឿងដំបូងដែលយើងអាចមើលបានគឺភាគរយនៃឃ្លាំងសម្ងាត់។ ភាគរយនៃឃ្លាំងសម្ងាត់គឺជាម៉ែត្រដ៏មានប្រយោជន៍។ វាអនុញ្ញាតឱ្យអ្នកប៉ាន់ស្មានថាតើទិន្នន័យប៉ុន្មានត្រូវបានយកចេញពីឃ្លាំងផ្ទុកទិន្នន័យដែលបានចែករំលែក និងចំនួនប៉ុន្មានត្រូវបានអានពីថាស។

វាច្បាស់ណាស់នោះ។ ឃ្លាំងសម្ងាត់កាន់តែច្រើនដែលយើងមាន នោះកាន់តែប្រសើរ. យើងវាយតម្លៃម៉ែត្រនេះជាភាគរយ។ ហើយជាឧទាហរណ៍ ប្រសិនបើយើងមានភាគរយនៃឃ្លាំងសម្ងាត់ទាំងនេះច្រើនជាង 90% នោះជាការល្អ។ ប្រសិនបើវាធ្លាក់ចុះក្រោម 90% នោះយើងមិនមានអង្គចងចាំគ្រប់គ្រាន់ដើម្បីរក្សាក្បាលក្តៅនៃទិន្នន័យនៅក្នុងអង្គចងចាំនោះទេ។ ហើយដើម្បីប្រើទិន្នន័យនេះ PostgreSQL ត្រូវបានបង្ខំឱ្យចូលប្រើថាស ហើយនេះគឺយឺតជាងប្រសិនបើទិន្នន័យត្រូវបានអានពីអង្គចងចាំ។ ហើយអ្នកត្រូវគិតអំពីការបង្កើនអង្គចងចាំ៖ បង្កើនសតិបណ្ដោះអាសន្នដែលបានចែករំលែក ឬបង្កើនអង្គចងចាំដែក (RAM)។

select
datname,
(xact_commit*100)/(xact_commit+xact_rollback) as c_ratio,
deadlocks, conflicts,
temp_file, pg_size_pretty(temp_bytes) as temp_size
from pg_stat_database;

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

យើងអាចប្រើសំណើនេះ។ SQL នេះគឺសាមញ្ញណាស់។ ហើយយើងអាចមើលឃើញទិន្នន័យនេះសម្រាប់ខ្លួនយើង។

ហើយនេះគឺជាតម្លៃកម្រិត។ យើងក្រឡេកមើលសមាមាត្រនៃការសន្យា និងការវិលត្រឡប់មកវិញ។ Commits គឺជាការបញ្ជាក់ជោគជ័យនៃប្រតិបត្តិការ។ Rollbacks គឺជា rollback ពោលគឺ ប្រតិបត្តិការបានធ្វើការងារមួយចំនួន ធ្វើឱ្យមូលដ្ឋានទិន្នន័យមានភាពតឹងតែង ពិចារណាអ្វីមួយ ហើយបន្ទាប់មកការបរាជ័យបានកើតឡើង ហើយលទ្ធផលនៃប្រតិបត្តិការត្រូវបានលុបចោល។ i.e. ចំនួន rollbacks កើនឡើងឥតឈប់ឈរគឺអាក្រក់។ ហើយអ្នកគួរជៀសវាងវាដោយរបៀបណា ហើយកែកូដដើម្បីកុំឱ្យរឿងនេះកើតឡើង។

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

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

ឯកសារបណ្តោះអាសន្ន (temp_files) ក៏មិនល្អដែរ។ នៅពេលដែលសំណើរបស់អ្នកប្រើមិនមានអង្គចងចាំគ្រប់គ្រាន់ដើម្បីបំពេញប្រតិបត្តិការទិន្នន័យបណ្តោះអាសន្ន វាបង្កើតឯកសារនៅលើថាស។ ហើយប្រតិបត្តិការទាំងអស់ដែលគាត់អាចអនុវត្តនៅក្នុងសតិបណ្ដោះអាសន្ននៅក្នុងសតិ គាត់ចាប់ផ្តើមអនុវត្តរួចហើយនៅលើថាស។ វាយឺត។ វាបង្កើនពេលវេលាដំណើរការសំណួរ។ ហើយអតិថិជនដែលបានផ្ញើសំណើទៅ PostgreSQL នឹងទទួលបានការឆ្លើយតបបន្តិចក្រោយមក។ ប្រសិនបើប្រតិបត្តិការទាំងអស់នេះត្រូវបានអនុវត្តនៅក្នុងសតិ នោះ Postgres នឹងឆ្លើយតបកាន់តែលឿន ហើយអតិថិជននឹងរង់ចាំតិចជាងមុន។

pg_stat_bgwriter - ទិដ្ឋភាពនេះពិពណ៌នាអំពីប្រតិបត្តិការនៃប្រព័ន្ធរង PostgreSQL ពីរ៖ checkpointer и background writer.

ដើម្បីចាប់ផ្តើមជាមួយ ចូរយើងវិភាគចំណុចត្រួតពិនិត្យ ដែលហៅថា។ checkpoints. តើប៉ុស្តិ៍ត្រួតពិនិត្យមានអ្វីខ្លះ? ចំណុចត្រួតពិនិត្យគឺជាទីតាំងមួយនៅក្នុងកំណត់ហេតុប្រតិបត្តិការដែលបង្ហាញថាការផ្លាស់ប្តូរទិន្នន័យទាំងអស់ដែលបានប្រព្រឹត្តនៅក្នុងកំណត់ហេតុត្រូវបានធ្វើសមកាលកម្មដោយជោគជ័យជាមួយនឹងទិន្នន័យនៅលើថាស។ ដំណើរការនេះ អាស្រ័យលើបន្ទុកការងារ និងការកំណត់អាចមានរយៈពេលវែង ហើយភាគច្រើនមានការធ្វើសមកាលកម្មទំព័រកខ្វក់នៅក្នុងសតិបណ្ដោះអាសន្នដែលបានចែករំលែកជាមួយឯកសារទិន្នន័យនៅលើថាស។ តើវាប្រើសំរាប់ធ្វើអ្វី? ប្រសិនបើ PostgreSQL ចូលប្រើថាសគ្រប់ពេល ហើយយកទិន្នន័យពីទីនោះ ហើយសរសេរទិន្នន័យលើការចូលប្រើនីមួយៗ វានឹងយឺត។ ដូច្នេះ PostgreSQL មានផ្នែកអង្គចងចាំដែលទំហំរបស់វាអាស្រ័យលើប៉ារ៉ាម៉ែត្រនៅក្នុងការកំណត់រចនាសម្ព័ន្ធ។ Postgres បែងចែកទិន្នន័យប្រតិបត្តិការនៅក្នុងអង្គចងចាំនេះសម្រាប់ដំណើរការបន្ថែម ឬសួរសំណួរ។ ក្នុងករណីសំណើផ្លាស់ប្តូរទិន្នន័យ ពួកគេត្រូវបានផ្លាស់ប្តូរ។ ហើយយើងទទួលបានទិន្នន័យពីរកំណែ។ មួយគឺនៅក្នុងសតិ មួយទៀតគឺនៅលើថាស។ ហើយជាទៀងទាត់អ្នកត្រូវធ្វើសមកាលកម្មទិន្នន័យនេះ។ យើងត្រូវការអ្វីដែលត្រូវបានផ្លាស់ប្តូរនៅក្នុងអង្គចងចាំដើម្បីធ្វើសមកាលកម្មទៅថាស។ នេះតម្រូវឱ្យមានប៉ុស្តិ៍ត្រួតពិនិត្យ។

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

មានចំណុចត្រួតពិនិត្យពីរប្រភេទ។ ប៉ុស្តិ៍ត្រួតពិនិត្យមួយត្រូវបានប្រតិបត្តិនៅពេលអស់ពេល។ ប៉ុស្តិ៍ត្រួតពិនិត្យនេះមានប្រយោជន៍និងល្អ - checkpoint_timed. ហើយមានប៉ុស្តិ៍ត្រួតពិនិត្យតាមតម្រូវការ - checkpoint required. ប៉ុស្តិ៍ត្រួតពិនិត្យបែបនេះកើតឡើងនៅពេលដែលយើងមានកំណត់ត្រាទិន្នន័យធំណាស់។ យើងបានកត់ត្រាកំណត់ហេតុប្រតិបត្តិការជាច្រើន។ ហើយ PostgreSQL ជឿជាក់ថាវាត្រូវធ្វើសមកាលកម្មទាំងអស់នេះឱ្យបានលឿនតាមដែលអាចធ្វើទៅបាន បង្កើតប៉ុស្តិ៍ត្រួតពិនិត្យ និងបន្តទៅមុខទៀត។

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

ហើយមានប៉ារ៉ាម៉ែត្រចំនួនបីដើម្បីកែតម្រូវចំណុចត្រួតពិនិត្យ:

сheckpoint_segments.
сheckpoint_timeout.
сheckpoint_competion_target.

ពួកគេអនុញ្ញាតឱ្យអ្នកគ្រប់គ្រងប្រតិបត្តិការនៃចំណុចត្រួតពិនិត្យ។ ប៉ុន្តែខ្ញុំនឹងមិនរស់នៅលើពួកគេទេ។ ឥទ្ធិពលរបស់ពួកគេគឺជាបញ្ហាដាច់ដោយឡែក។

ព្រមាន: កំណែ 9.4 ដែលត្រូវបានពិចារណានៅក្នុងរបាយការណ៍គឺលែងពាក់ព័ន្ធទៀតហើយ។ នៅក្នុងកំណែទំនើបនៃ PostgreSQL ប៉ារ៉ាម៉ែត្រ checkpoint_segments ជំនួសដោយប៉ារ៉ាម៉ែត្រ min_wal_size и max_wal_size.

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

តើគាត់ត្រូវការអ្វីទៀត? វាផ្តល់នូវតម្រូវការសម្រាប់ទំព័រស្អាតនៅក្នុងសតិបណ្ដោះអាសន្នដែលបានចែករំលែក ប្រសិនបើពួកគេត្រូវបានទាមទារភ្លាមៗ (ក្នុងបរិមាណច្រើន និងភ្លាមៗ) ដើម្បីផ្ទុកទិន្នន័យ។ ឧបមាថាស្ថានភាពមួយបានកើតឡើងនៅពេលដែលសំណើទាមទារទំព័រស្អាត ហើយពួកវាស្ថិតនៅក្នុងសតិបណ្ដោះអាសន្នដែលបានចែករំលែករួចហើយ។ Postgres backend គាត់គ្រាន់តែយកវាទៅប្រើ ហើយគាត់មិនចាំបាច់សម្អាតអ្វីដោយខ្លួនឯងទេ។ ប៉ុន្តែប្រសិនបើភ្លាមៗនោះមិនមានទំព័របែបនេះទេ កម្មវិធីខាងក្រោយផ្អាក ហើយចាប់ផ្តើមស្វែងរកទំព័រដើម្បីបញ្ចោញពួកវាទៅក្នុងថាស ហើយយកវាសម្រាប់តម្រូវការផ្ទាល់ខ្លួនរបស់វា ដែលជះឥទ្ធិពលអវិជ្ជមានដល់ពេលវេលានៃសំណើដែលកំពុងដំណើរការបច្ចុប្បន្ន។ ប្រសិនបើអ្នកឃើញថាអ្នកមានប៉ារ៉ាម៉ែត្រ maxwritten_clean ធំ នេះមានន័យថាអ្នកសរសេរផ្ទៃខាងក្រោយមិនធ្វើការងាររបស់វាទេ ហើយអ្នកត្រូវបង្កើនប៉ារ៉ាម៉ែត្រ bgwriter_lru_maxpagesដូច្នេះគាត់អាចធ្វើការងារបានច្រើនក្នុងមួយវដ្ត ជម្រះទំព័របន្ថែមទៀត។

ហើយសូចនាករដ៏មានប្រយោជន៍មួយទៀតគឺ buffers_backend_fsync. ផ្នែកខាងក្រោយមិនធ្វើ fsync ទេព្រោះវាយឺត។ ពួកគេឆ្លងកាត់ fsync ឡើង IO stack checkpointer ។ ឧបករណ៍ពិនិត្យមានជួររបស់វា វាដំណើរការ fsync ជាទៀងទាត់ និងធ្វើសមកាលកម្មទំព័រនៅក្នុងអង្គចងចាំជាមួយឯកសារនៅលើថាស។ ប្រសិនបើជួរ checkpointer ធំ និងពេញ នោះ backend ត្រូវបានបង្ខំឱ្យធ្វើ fsync ខ្លួនវា ហើយវានឹងបន្ថយ backendពោលគឺ អតិថិជននឹងទទួលបានការឆ្លើយតបយឺតជាងវាអាចធ្វើទៅបាន។ ប្រសិនបើអ្នកឃើញថាអ្នកមានតម្លៃនេះធំជាងសូន្យ នោះនេះគឺជាបញ្ហារួចទៅហើយ អ្នកត្រូវយកចិត្តទុកដាក់លើការកំណត់របស់កម្មវិធីសរសេរផ្ទៃខាងក្រោយ និងវាយតម្លៃដំណើរការនៃប្រព័ន្ធរងរបស់ឌីសផងដែរ។

ព្រមាន: _អត្ថបទខាងក្រោមពិពណ៌នាអំពីទិដ្ឋភាពស្ថិតិដែលទាក់ទងនឹងការចម្លង។ ឈ្មោះទិដ្ឋភាព និងមុខងារភាគច្រើនត្រូវបានប្តូរឈ្មោះនៅក្នុង Postgres 10។ ខ្លឹមសារនៃការប្តូរឈ្មោះគឺត្រូវជំនួស xlog នៅលើ wal и location នៅលើ lsn នៅក្នុងមុខងារ/មើលឈ្មោះ។ល។ ឧទាហរណ៍ពិសេស មុខងារ pg_xlog_location_diff() ត្រូវបានប្តូរឈ្មោះទៅជា pg_wal_lsn_diff()._

យើងក៏មានច្រើននៅទីនេះដែរ។ ប៉ុន្តែយើងត្រូវការតែធាតុដែលទាក់ទងនឹងទីតាំងប៉ុណ្ណោះ។

ប្រសិនបើយើងឃើញថាតម្លៃទាំងអស់ស្មើគ្នា នោះជាការល្អ ហើយការចម្លងមិនយឺតយ៉ាវនៅពីក្រោយមេនោះទេ។

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

сколько записано xlog в байтах
$ select
pg_xlog_location_diff(pg_current_xlog_location(),'0/00000000');
лаг репликации в байтах
$ select
client_addr,
pg_xlog_location_diff(pg_current_xlog_location(), replay_location)
from pg_stat_replication;
лаг репликации в секундах
$ select
extract(epoch from now() - pg_last_xact_replay_timestamp());

បើរឿងទាំងនេះខុសគ្នា នោះក៏មានភាពយឺតយ៉ាវខ្លះដែរ។ Lag គឺជាភាពយឺតយ៉ាវនៃការចម្លងពីមេ ពោលគឺទិន្នន័យខុសគ្នារវាងម៉ាស៊ីនមេ។

មានហេតុផលបីយ៉ាងសម្រាប់ការពន្យារពេល៖

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

ហើយនេះគឺជាសំណួរចំនួនបីដែលអនុញ្ញាតឱ្យយើងប្រើស្ថិតិ។ យើងអាចប៉ាន់ស្មានថាតើចំនួនប៉ុន្មានត្រូវបានកត់ត្រានៅក្នុងកំណត់ហេតុប្រតិបត្តិការរបស់យើង។ មានមុខងារបែបនេះ pg_xlog_location_diff ហើយយើងអាចប៉ាន់ស្មានភាពយឺតនៃការចម្លងជាបៃ និងវិនាទី។ យើងក៏ប្រើតម្លៃពីទិដ្ឋភាពនេះ (VIEWs) សម្រាប់រឿងនេះផងដែរ។

ចំណាំ: ជំនួសឱ្យ pg_xlog_locationមុខងារ diff() អ្នកអាចប្រើសញ្ញាប្រមាណវិធីដក និងដកទីតាំងមួយពីទីតាំងមួយទៀត។ មានផាសុខភាព។

ជាមួយនឹងភាពយឺតយ៉ាវ ដែលគិតជាវិនាទី មានពេលមួយ។ ប្រសិនបើមិនមានសកម្មភាពនៅលើមេទេ ប្រតិបត្តិការនៅទីនោះប្រហែល 15 នាទីមុន ហើយមិនមានសកម្មភាពទេ ហើយប្រសិនបើយើងពិនិត្យមើលភាពយឺតយ៉ាវនៅលើការចម្លងនេះ យើងនឹងឃើញភាពយឺតយ៉ាវ 15 នាទី។ នេះគឺមានតម្លៃចងចាំ។ ហើយវាអាចនាំឱ្យមានការស្រឡាំងកាំងនៅពេលដែលអ្នកមើលការយឺតយ៉ាវនេះ។

pg_stat_all_tables គឺជាទិដ្ឋភាពដ៏មានប្រយោជន៍មួយផ្សេងទៀត។ វាបង្ហាញស្ថិតិនៅលើតារាង។ នៅពេលដែលយើងមានតារាងនៅក្នុង database មានសកម្មភាពខ្លះជាមួយវា សកម្មភាពខ្លះយើងអាចទទួលបានព័ត៌មាននេះពីទិដ្ឋភាពនេះ។

select
relname,
pg_size_pretty(pg_relation_size(relname::regclass)) as size,
seq_scan, seq_tup_read,
seq_scan / seq_tup_read as seq_tup_avg
from pg_stat_user_tables
where seq_tup_read > 0 order by 3,4 desc limit 5;

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

ទោះយ៉ាងណាក៏ដោយមានម៉ែត្រទីពីរ - seq_tup_read ។ នេះជាចំនួនជួរដេកដែលបានត្រឡប់មកពីការស្កេនតាមលំដាប់។ ប្រសិនបើចំនួនមធ្យមលើសពី 1, 000, 10, 000 នោះនេះគឺជាសូចនាកររួចហើយដែលអ្នកប្រហែលជាត្រូវបង្កើតលិបិក្រមនៅកន្លែងណាមួយ ដូច្នេះការចូលប្រើគឺតាមលិបិក្រម ឬវាអាចធ្វើទៅបានដើម្បីបង្កើនប្រសិទ្ធភាពសំណួរដែលប្រើការស្កេនតាមលំដាប់លំដោយដូច្នេះ។ នេះមិនកើតឡើងទេ។

ឧទាហរណ៍សាមញ្ញមួយ - ចូរនិយាយថាសំណើមួយដែលមាន OFFSET ធំនិង LIMIT មានតម្លៃវា។ ឧទាហរណ៍ 100 ជួរក្នុងតារាងមួយត្រូវបានស្កេន ហើយបន្ទាប់ពីនោះ 000 ជួរដែលត្រូវការត្រូវបានយក ហើយជួរដែលបានស្កេនពីមុនត្រូវបានបោះចោល។ នេះក៏ជាករណីអាក្រក់ដែរ។ ហើយសំណើបែបនេះត្រូវតែធ្វើឱ្យប្រសើរ។ ហើយនេះគឺជាសំណួរ SQL ដ៏សាមញ្ញមួយដែលអ្នកអាចឃើញវា និងវាយតម្លៃលេខដែលទទួលបាន។

select
relname,
pg_size_pretty(pg_total_relation_size(relname::regclass)) as
full_size,
pg_size_pretty(pg_relation_size(relname::regclass)) as
table_size,
pg_size_pretty(pg_total_relation_size(relname::regclass) -
pg_relation_size(relname::regclass)) as index_size
from pg_stat_user_tables
order by pg_total_relation_size(relname::regclass) desc limit 10;

ទំហំតារាងក៏អាចទទួលបានដោយប្រើតារាងនេះ និងប្រើប្រាស់មុខងារបន្ថែម pg_total_relation_size(), pg_relation_size().

ជាទូទៅមានពាក្យបញ្ជាមេតា dt и diដែលអ្នកអាចប្រើក្នុង PSQL និងមើលទំហំតារាង និងលិបិក្រមផងដែរ។

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

សរសេរសកម្មភាព។ តើកំណត់ត្រាគឺជាអ្វី? តោះមើលប្រតិបត្តិការ UPDATE - ប្រតិបត្តិការធ្វើបច្ចុប្បន្នភាពជួរក្នុងតារាង។ តាមពិតការធ្វើបច្ចុប្បន្នភាពគឺជាប្រតិបត្តិការពីរ (ឬសូម្បីតែច្រើន) ។ វាកំពុងបញ្ចូលកំណែជួរដេកថ្មី និងសម្គាល់កំណែជួរដេកចាស់ថាលែងប្រើហើយ។ ក្រោយមក autovacuum នឹងមក ហើយសម្អាតបន្ទាត់ដែលលែងប្រើទាំងនេះ ហើយសម្គាល់កន្លែងនេះថាមានសម្រាប់ប្រើឡើងវិញ។

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

select
s.relname,
pg_size_pretty(pg_relation_size(relid)),
coalesce(n_tup_ins,0) + 2 * coalesce(n_tup_upd,0) -
coalesce(n_tup_hot_upd,0) + coalesce(n_tup_del,0) AS total_writes,
(coalesce(n_tup_hot_upd,0)::float * 100 / (case when n_tup_upd > 0
then n_tup_upd else 1 end)::float)::numeric(10,2) AS hot_rate,
(select v[1] FROM regexp_matches(reloptions::text,E'fillfactor=(\d+)') as
r(v) limit 1) AS fillfactor
from pg_stat_all_tables s
join pg_class c ON c.oid=relid
order by total_writes desc limit 50;

ហើយដោយសារតែការរចនារបស់វា UPDATE គឺជាប្រតិបត្តិការទម្ងន់ធ្ងន់។ ប៉ុន្តែពួកគេអាចត្រូវបានធ្វើឱ្យកាន់តែងាយស្រួល។ បរិភោគ hot updates. ពួកគេបានបង្ហាញខ្លួននៅក្នុង PostgreSQL កំណែ 8.3 ។ ហើយនេះជាអ្វី? នេះគឺជាការអាប់ដេតទម្ងន់ស្រាលដែលមិនបណ្តាលឱ្យលិបិក្រមត្រូវបានបង្កើតឡើងវិញ។ នោះគឺយើងធ្វើបច្ចុប្បន្នភាពកំណត់ត្រា ប៉ុន្តែមានតែកំណត់ត្រានៅក្នុងទំព័រ (ដែលជាកម្មសិទ្ធិរបស់តារាង) ប៉ុណ្ណោះដែលត្រូវបានធ្វើបច្ចុប្បន្នភាព ហើយសន្ទស្សន៍នៅតែចង្អុលទៅកំណត់ត្រាដដែលនៅក្នុងទំព័រ។ មានតក្កវិជ្ជាគួរឱ្យចាប់អារម្មណ៍បន្តិចនៃការងារនេះ នៅពេលដែលការខ្វះចន្លោះមក នោះវាមានច្រវាក់ទាំងនេះ hot ស្ថាបនាឡើងវិញ ហើយអ្វីៗបន្តដំណើរការដោយមិនធ្វើបច្ចុប្បន្នភាពសន្ទស្សន៍ ហើយអ្វីៗកើតឡើងដោយខ្ជះខ្ជាយធនធានតិច។

ហើយនៅពេលដែលអ្នកមាន n_tup_hot_upd ធំ វាល្អណាស់។ នេះមានន័យថាការអាប់ដេតទម្ងន់ស្រាលអាចគ្រប់គ្រងបាន ហើយនេះមានតម្លៃថោកសម្រាប់យើងទាក់ទងនឹងធនធាន ហើយអ្វីៗគឺល្អ។

ALTER TABLE table_name SET (fillfactor = 70);

វិធីបង្កើនបរិមាណ hot updateអូ? យើងអាចប្រើ fillfactor. វាកំណត់ទំហំនៃទំហំទំនេរដែលបានបម្រុងទុកនៅពេលបំពេញទំព័រក្នុងតារាងដោយប្រើ INSERTs ។ នៅពេលដែលសិលាចារឹកចូលទៅកាន់តារាង ពួកគេបំពេញទំព័រទាំងស្រុង កុំទុកចន្លោះទទេនៅក្នុងនោះ។ បន្ទាប់មកទំព័រថ្មីមួយត្រូវបានបន្លិច។ ទិន្នន័យត្រូវបានបំពេញម្តងទៀត។ ហើយនេះគឺជាឥរិយាបទលំនាំដើម fillfactor = 100% ។

យើងអាចកំណត់កត្តាបំពេញដល់ 70% ។ នោះគឺជាមួយនឹងការបញ្ចូល ទំព័រថ្មីត្រូវបានបែងចែក ប៉ុន្តែមានតែ 70% នៃទំព័រប៉ុណ្ណោះដែលត្រូវបានបំពេញ។ ហើយយើងនៅសល់ 30% នៅក្នុងទុនបម្រុង។ នៅពេលដែលអ្នកត្រូវធ្វើបច្ចុប្បន្នភាព វានឹងកើតឡើងនៅលើទំព័រតែមួយ ហើយកំណែថ្មីនៃជួរដេកនឹងសមនៅលើទំព័រដូចគ្នា។ ហើយ hot_update នឹងត្រូវធ្វើ។ នេះធ្វើឱ្យវាកាន់តែងាយស្រួលក្នុងការសរសេរនៅលើតុ។

select c.relname,
current_setting('autovacuum_vacuum_threshold') as av_base_thresh,
current_setting('autovacuum_vacuum_scale_factor') as av_scale_factor,
(current_setting('autovacuum_vacuum_threshold')::int +
(current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples))
as av_thresh,
s.n_dead_tup
from pg_stat_user_tables s join pg_class c ON s.relname = c.relname
where s.n_dead_tup > (current_setting('autovacuum_vacuum_threshold')::int
+ (current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples));

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

ចំណាំ: _ចាប់តាំងពី Postgres 10 មក ស្ថានភាពជាមួយនឹងការតាមដានការបូមធូលីបានប្រសើរឡើងច្រើន - ទិដ្ឋភាព pg_stat_progress បានបង្ហាញខ្លួនvacuum ដែលជួយសម្រួលបញ្ហានៃការត្រួតពិនិត្យ autovacuum យ៉ាងខ្លាំង។

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

ហើយកម្រិតនេះត្រូវគណនាដោយរបៀបណា? នេះគឺជាភាគរយជាក់លាក់នៃចំនួនជួរដេកសរុបនៅក្នុងតារាង។ មានប៉ារ៉ាម៉ែត្រ autovacuum_vacuum_scale_factor. វាកំណត់ភាគរយ។ ចូរនិយាយថា 10% + មានកម្រិតមូលដ្ឋានបន្ថែមនៃ 50 បន្ទាត់។ ហើយមានអ្វីកើតឡើង? នៅពេលដែលយើងមានជួរដេកស្លាប់ច្រើនជាង "10% + 50" នៃជួរទាំងអស់នៅក្នុងតារាង យើងដាក់តារាងនៅលើ autovacuum ។

select c.relname,
current_setting('autovacuum_vacuum_threshold') as av_base_thresh,
current_setting('autovacuum_vacuum_scale_factor') as av_scale_factor,
(current_setting('autovacuum_vacuum_threshold')::int +
(current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples))
as av_thresh,
s.n_dead_tup
from pg_stat_user_tables s join pg_class c ON s.relname = c.relname
where s.n_dead_tup > (current_setting('autovacuum_vacuum_threshold')::int
+ (current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples));

ទោះយ៉ាងណាក៏ដោយមានចំណុចមួយ។ កម្រិតមូលដ្ឋានសម្រាប់ប៉ារ៉ាម៉ែត្រ av_base_thresh и av_scale_factor អាចត្រូវបានចាត់តាំងជាលក្ខណៈបុគ្គល។ ហើយតាមនោះ កម្រិតចាប់ផ្ដើមនឹងមិនមែនជាសកលទេ ប៉ុន្តែជាបុគ្គលសម្រាប់តារាង។ ដូច្នេះដើម្បីគណនានៅទីនោះអ្នកត្រូវប្រើល្បិចនិងល្បិច។ ហើយប្រសិនបើអ្នកចាប់អារម្មណ៍ អ្នកអាចមើលបទពិសោធន៍របស់សហសេវិករបស់យើងពី Avito (តំណភ្ជាប់នៅលើស្លាយគឺមិនត្រឹមត្រូវ ហើយត្រូវបានធ្វើបច្ចុប្បន្នភាពនៅក្នុងអត្ថបទ)។

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

តើយើងអាចធ្វើអ្វីបានអំពីវា? ប្រសិនបើយើងមានជួរវែង ហើយម៉ាស៊ីនបូមធូលីមិនអាចដោះស្រាយបានទេ នោះយើងអាចបង្កើនចំនួនអ្នកធ្វើការបូមធូលី ឬគ្រាន់តែធ្វើឱ្យម៉ាស៊ីនបូមធូលីកាន់តែឈ្លានពាន។ដូច្នេះវាកេះមុន ដំណើរការតារាងជាបំណែកតូចៗ។ ហើយដូច្នេះជួរនឹងថយចុះ។ - រឿងសំខាន់នៅទីនេះគឺដើម្បីត្រួតពិនិត្យការផ្ទុកនៅលើថាស, ដោយសារតែ។ រឿងខ្វះចន្លោះគឺមិនគិតថ្លៃទេ ទោះបីជាជាមួយនឹងការមកដល់នៃឧបករណ៍ SSD / NVMe ក៏ដោយ ក៏បញ្ហាកាន់តែគួរឱ្យកត់សម្គាល់។

pg_stat_all_indexes គឺជាស្ថិតិនៅលើលិបិក្រម។ នាងមិនធំទេ។ ហើយយើងអាចទទួលបានព័ត៌មានអំពីការប្រើប្រាស់លិបិក្រមពីវា។ ហើយជាឧទាហរណ៍ យើងអាចកំណត់ថាតើសន្ទស្សន៍ណាមួយដែលយើងមានបន្ថែម។

ដូចដែលខ្ញុំបាននិយាយរួចមកហើយថា update គឺមិនត្រឹមតែធ្វើបច្ចុប្បន្នភាពតារាងប៉ុណ្ណោះទេ វាក៏កំពុងធ្វើបច្ចុប្បន្នភាពលិបិក្រមផងដែរ។ ដូច្នោះហើយ ប្រសិនបើយើងមានលិបិក្រមច្រើននៅលើតារាង នោះនៅពេលធ្វើបច្ចុប្បន្នភាពជួរដេកក្នុងតារាង លិបិក្រមនៃវាលដែលបានធ្វើលិបិក្រមក៏ចាំបាច់ត្រូវធ្វើបច្ចុប្បន្នភាពផងដែរ ហើយ ប្រសិនបើយើងមានលិបិក្រមដែលមិនបានប្រើដែលមិនមានការស្កេនលិបិក្រម នោះពួកគេព្យួរជាមួយយើងដូចជា ballast។ ហើយអ្នកត្រូវកម្ចាត់ពួកគេ។ សម្រាប់បញ្ហានេះយើងត្រូវការវាលមួយ។ idx_scan. យើងគ្រាន់តែមើលចំនួននៃការស្កេនសន្ទស្សន៍។ ប្រសិនបើសន្ទស្សន៍មានការស្កេនសូន្យក្នុងរយៈពេលវែងនៃការផ្ទុកស្ថិតិ (យ៉ាងហោចណាស់ 2-3 សប្តាហ៍) នោះទំនងជាទាំងនេះគឺជាសន្ទស្សន៍មិនល្អ យើងត្រូវកម្ចាត់ពួកវា។

ចំណាំ: នៅពេលស្វែងរកលិបិក្រមដែលមិនប្រើនៅក្នុងករណីនៃការស្ទ្រីមការចម្លងនៃចង្កោម អ្នកត្រូវពិនិត្យមើលថ្នាំងទាំងអស់នៃចង្កោម ព្រោះ ស្ថិតិមិនមែនជាសកលទេ ហើយប្រសិនបើលិបិក្រមមិនត្រូវបានប្រើនៅលើមេ នោះវាអាចប្រើនៅលើការចម្លង (ប្រសិនបើមានបន្ទុក)។

តំណភ្ជាប់ពីរ៖

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

http://www.databasesoup.com/2014/05/new-finding-unused-indexes-query.html

ទាំងនេះគឺជាឧទាហរណ៍សំណួរកម្រិតខ្ពស់បន្ថែមទៀតសម្រាប់របៀបរកមើលលិបិក្រមដែលមិនប្រើ។

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

តើមានអ្វីទៀតដែលគួរត្រូវបានសង្ខេបដោយសន្ទស្សន៍?

លិបិក្រមដែលមិនប្រើគឺអាក្រក់។
ពួកគេយកកន្លែងទំនេរ។
ពន្យឺតប្រតិបត្តិការអាប់ដេត។
ការងារបន្ថែមសម្រាប់ម៉ាស៊ីនបូមធូលី។

ប្រសិនបើយើងលុបលិបិក្រមដែលមិនប្រើ នោះយើងនឹងធ្វើឱ្យមូលដ្ឋានទិន្នន័យកាន់តែប្រសើរឡើងប៉ុណ្ណោះ។

ទិដ្ឋភាពបន្ទាប់គឺ pg_stat_activity. នេះគឺជា analogue នៃឧបករណ៍ប្រើប្រាស់ psមានតែនៅក្នុង PostgreSQL ប៉ុណ្ណោះ។ ប្រសិនបើ ps'អូម អ្នកមើលដំណើរការនៅក្នុងប្រព័ន្ធប្រតិបត្តិការ បន្ទាប់មក pg_stat_activity នឹងបង្ហាញអ្នកពីសកម្មភាពនៅខាងក្នុង PostgreSQL ។

តើយើងអាចយកអ្វីពីទីនោះ?

select
count(*)*100/(select current_setting('max_connections')::int)
from pg_stat_activity;

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

select
client_addr, usename, datname, count(*)
from pg_stat_activity group by 1,2,3 order by 4 desc;

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

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

select
client_addr, usename, datname,
clock_timestamp() - xact_start as xact_age,
clock_timestamp() - query_start as query_age,
query
from pg_stat_activity order by xact_start, query_start;

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

select * from pg_stat_activity where state in
('idle in transaction', 'idle in transaction (aborted)';

ប្រតិបត្តិការមិនល្អគឺនៅទំនេរក្នុងប្រតិបត្តិការ និងនៅទំនេរក្នុងប្រតិបត្តិការ (បោះបង់) ប្រតិបត្តិការ។

តើវាមានន័យយ៉ាងដូចម្តេច? ប្រតិបត្តិការមានរដ្ឋច្រើន។ ហើយរដ្ឋមួយក្នុងចំណោមរដ្ឋទាំងនេះអាចទទួលយកនៅពេលណាក៏បាន។ មានវាលដើម្បីកំណត់រដ្ឋ state នៅក្នុងទិដ្ឋភាពនេះ។ ហើយយើងប្រើវាដើម្បីកំណត់រដ្ឋ។

select * from pg_stat_activity where state in
('idle in transaction', 'idle in transaction (aborted)';

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

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

នៅទីនេះយើងក៏ប្រើសម្រាប់ពេលវេលាគណនាផងដែរ។ clock_timestamp(). យើងបាញ់ប្រតិបត្តិការ យើងបង្កើនប្រសិទ្ធភាពកម្មវិធី។

ដូចដែលខ្ញុំបាននិយាយខាងលើ ការចាក់សោគឺជាពេលដែលប្រតិបត្តិការពីរ ឬច្រើនប្រកួតប្រជែងសម្រាប់ធនធានមួយ ឬក្រុមមួយ។ សម្រាប់នេះយើងមានវាលមួយ។ waiting ជាមួយនឹងតម្លៃប៊ូលីន true ឬ false.

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

ព្រមាន: _ចាប់ផ្តើមពី Postgres 9.6 វាល waiting ដកចេញ និងជំនួសដោយវាលព័ត៌មានពីរបន្ថែមទៀត wait_event_type и wait_event._

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

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

https://github.com/lesovsky/uber-scripts/blob/master/postgresql/sql/c4_06_show_locked_queries.sql

https://github.com/lesovsky/uber-scripts/blob/master/postgresql/sql/show_locked_queries_95.sql

https://github.com/lesovsky/uber-scripts/blob/master/postgresql/sql/show_locked_queries_96.sql

http://big-elephants.com/2013-09/exploring-query-locks-in-postgres/

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

ហើយតំណភ្ជាប់ទីមួយគឺជាអត្ថបទស្នើសុំដោយខ្លួនឯង។ វាវែងណាស់។

ហើយតំណភ្ជាប់ទីពីរគឺជាអត្ថបទស្តីពីសោ។ វាមានប្រយោជន៍ក្នុងការអានវាគួរឱ្យចាប់អារម្មណ៍ណាស់។

ដូច្នេះតើយើងឃើញអ្វី? យើងឃើញសំណើពីរ។ ប្រតិបត្តិការជាមួយ ALTER TABLE គឺជាប្រតិបត្តិការទប់ស្កាត់។ វាបានចាប់ផ្តើម ប៉ុន្តែមិនបានបញ្ចប់ ហើយកម្មវិធីដែលបានបង្ហោះប្រតិបត្តិការនេះកំពុងធ្វើអ្វីៗផ្សេងទៀតនៅកន្លែងណាមួយ។ ហើយសំណើទីពីរគឺការធ្វើបច្ចុប្បន្នភាព។ វារង់ចាំសម្រាប់តារាងផ្លាស់ប្តូរដើម្បីបញ្ចប់មុនពេលបន្តការងាររបស់វា។

នេះជារបៀបដែលយើងអាចដឹងថាអ្នកណាចាក់សោអ្នកណា អ្នកណាកាន់អ្នកណា ហើយយើងអាចដោះស្រាយបញ្ហានេះតទៅទៀត។

ម៉ូឌុលបន្ទាប់គឺ pg_stat_statements. ដូចដែលខ្ញុំបាននិយាយ វាជាម៉ូឌុល។ ដើម្បីប្រើវា អ្នកត្រូវផ្ទុកបណ្ណាល័យរបស់វាក្នុងការកំណត់រចនាសម្ព័ន្ធ ចាប់ផ្ដើម PostgreSQL ឡើងវិញ ដំឡើងម៉ូឌុល (ជាមួយពាក្យបញ្ជាមួយ) ហើយបន្ទាប់មកយើងនឹងមានទិដ្ឋភាពថ្មី។

Cреднее время запроса в милисекундах
$ select (sum(total_time) / sum(calls))::numeric(6,3)
from pg_stat_statements;

Самые активно пишущие (в shared_buffers) запросы
$ select query, shared_blks_dirtied
from pg_stat_statements
where shared_blks_dirtied > 0 order by 2 desc;

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

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

ហើយយើងគ្រាន់តែអាចមើលស្ថិតិផ្សេងគ្នាសម្រាប់សំណើទាំងនេះ។

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

Мы pg_stat_statements ប្រើដើម្បីបង្កើតរបាយការណ៍។ យើងកំណត់ស្ថិតិឡើងវិញម្តងក្នុងមួយថ្ងៃ។ ចូរយើងប្រមូលវា។ មុននឹងកំណត់ស្ថិតិឡើងវិញនៅពេលក្រោយ យើងបង្កើតរបាយការណ៍មួយ។ នេះគឺជាតំណភ្ជាប់ទៅកាន់របាយការណ៍។ អ្នកអាចមើលវាបាន។

ពួកយើងកំពុងធ្វើអ្វីហ្នឹង? យើងគណនាស្ថិតិរួមសម្រាប់សំណួរទាំងអស់។ បន្ទាប់មក សម្រាប់សំណួរនីមួយៗ យើងរាប់ការរួមចំណែកនីមួយៗរបស់វាចំពោះស្ថិតិរួមនេះ។

ហើយតើយើងអាចឃើញអ្វីខ្លះ? យើងអាចមើលឃើញពេលវេលាប្រតិបត្តិសរុបនៃសំណើទាំងអស់នៃប្រភេទជាក់លាក់មួយប្រឆាំងនឹងផ្ទៃខាងក្រោយនៃសំណើផ្សេងទៀតទាំងអស់។ យើងអាចពិនិត្យមើលការប្រើប្រាស់ CPU និង I/O ទាក់ទងនឹងរូបភាពរួម។ ហើយដើម្បីបង្កើនប្រសិទ្ធភាពសំណើទាំងនេះរួចហើយ។ យើងកំពុងបង្កើតសំណួរកំពូលដោយផ្អែកលើរបាយការណ៍នេះ ហើយកំពុងទទួលបានអាហាររួចហើយសម្រាប់ការគិតលើអ្វីដែលត្រូវបង្កើនប្រសិទ្ធភាព។

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

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

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

ម៉ូឌុលបន្ទាប់គឺ pgfincore. វាអនុញ្ញាតឱ្យអ្នកធ្វើប្រតិបត្តិការតារាងកម្រិតទាបតាមរយៈការហៅតាមប្រព័ន្ធ mincore()ពោលគឺវាអនុញ្ញាតឱ្យអ្នកផ្ទុកតារាងទៅក្នុងសតិបណ្ដោះអាសន្នដែលបានចែករំលែក ឬដកវាចេញ។ ហើយវាអនុញ្ញាតឱ្យ ពិនិត្យមើលឃ្លាំងសម្ងាត់ទំព័រនៃប្រព័ន្ធប្រតិបត្តិការ នោះគឺថាតើតារាងកាន់កាប់ប៉ុន្មាននៅក្នុងឃ្លាំងសម្ងាត់ទំព័រ នៅក្នុងសតិបណ្ដោះអាសន្នដែលបានចែករំលែក ហើយគ្រាន់តែអនុញ្ញាតឱ្យអ្នកវាយតម្លៃបន្ទុកនៅលើតុ។

ម៉ូឌុលបន្ទាប់គឺ pg_stat_kcache. វាក៏ប្រើការហៅតាមប្រព័ន្ធផងដែរ។ getrusage(). ហើយវាប្រតិបត្តិវាមុន និងក្រោយការស្នើសុំត្រូវបានប្រតិបត្តិ។ ហើយនៅក្នុងស្ថិតិដែលទទួលបានវាអនុញ្ញាតឱ្យយើងប៉ាន់ប្រមាណថាតើសំណើរបស់យើងចំណាយប៉ុន្មាននៅលើថាស I / O ពោលគឺប្រតិបត្តិការជាមួយប្រព័ន្ធឯកសារនិងមើលការប្រើប្រាស់ខួរក្បាល។ ទោះយ៉ាងណាក៏ដោយ ម៉ូឌុលនេះនៅក្មេង (khe-khe) ហើយសម្រាប់ការងាររបស់វា វាទាមទារ PostgreSQL 9.4 និង pg_stat_statements ដែលខ្ញុំបានលើកឡើងពីមុន។

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