ወደ PostgreSQL ውስጣዊ ስታቲስቲክስ በጥልቀት ይግቡ። አሌክሲ ሌሶቭስኪ

የ2015 ዘገባ በአሌሲ ሌሶቭስኪ የተገለበጠ "ወደ PostgreSQL ውስጣዊ ስታቲስቲክስ ጥልቅ ዘልቆ መግባት"

የሪፖርቱ ደራሲ የኃላፊነት ማስተባበያ፡- ይህ ዘገባ በኖቬምበር 2015 የተፃፈ መሆኑን አስተውያለሁ - ከ 4 ዓመታት በላይ አልፈዋል እና ብዙ ጊዜ አልፏል. በሪፖርቱ ውስጥ የተወያየው ስሪት 9.4 ከአሁን በኋላ አይደገፍም። ባለፉት 4 ዓመታት ውስጥ፣ ብዙ ፈጠራዎች፣ ማሻሻያዎች እና ስታቲስቲክስን በተመለከተ ለውጦች የታዩባቸው 5 አዳዲስ የተለቀቁት እና አንዳንድ ቁሶች ጊዜ ያለፈባቸው እና ተዛማጅነት የሌላቸው ናቸው። ስገመግመው አንባቢን እንዳላሳስት እነዚህን ቦታዎች ምልክት ለማድረግ ሞከርኩ። እነዚህን ቦታዎች እንደገና አልጻፍኩም, በጣም ብዙ ናቸው, እና በዚህ ምክንያት, ፍጹም የተለየ ዘገባ ይወጣል.

የ PostgreSQL DBMS ትልቅ ዘዴ ነው፣ እና ይህ ዘዴ ብዙ ንዑስ ስርዓቶችን ያቀፈ ነው ፣ የተቀናጀ ስራው በቀጥታ የ DBMS አፈፃፀም ላይ ተጽዕኖ ያሳድራል። በሚሠራበት ጊዜ ስለ አካላት አሠራር ስታቲስቲክስ እና መረጃ ይሰበሰባል ፣ ይህም የ PostgreSQL ውጤታማነትን ለመገምገም እና አፈፃፀሙን ለማሻሻል እርምጃዎችን እንዲወስዱ ያስችልዎታል። ሆኖም፣ ብዙ እነዚህ መረጃዎች አሉ እና ይልቁንም ቀለል ባለ መልኩ ቀርቧል። ይህንን መረጃ ማስተናገድ እና መተርጎም አንዳንድ ጊዜ ሙሉ በሙሉ ቀላል ያልሆነ ተግባር ነው፣ እና የመሳሪያዎች እና መገልገያዎች "zoo" የላቀ DBA እንኳን በቀላሉ ግራ ሊያጋባ ይችላል።

እንደምን አረፈድክ ስሜ አሌክሲ እባላለሁ። ኢሊያ እንደተናገረው፣ ስለ PostgreSQL ስታቲስቲክስ እናገራለሁ።

PostgreSQL የእንቅስቃሴ ስታቲስቲክስ። PostgreSQL ሁለት ስታቲስቲክስ አለው። የተግባር ስታቲስቲክስ፣ እሱም ይብራራል። እና ስለ ውሂብ ስርጭት የጊዜ ሰሌዳ አኃዛዊ መረጃ። በተለይ ስለ PostgreSQL እንቅስቃሴ ስታቲስቲክስ እናገራለሁ፣ ይህም አፈጻጸምን እንድንገምት እና እንደምንም እንድናሻሽለው ያስችለናል።

የተለያዩ ችግሮችን ለመፍታት ስታቲስቲክስን በብቃት እንዴት መጠቀም እንዳለቦት እነግርዎታለሁ ።

በሪፖርቱ ውስጥ ምን አይሆንም? በሪፖርቱ ውስጥ, የጊዜ ሰሌዳውን ስታቲስቲክስ አልነካም, ምክንያቱም. ይህ መረጃ በመረጃ ቋቱ ውስጥ እንዴት እንደሚከማች እና የጥያቄ ዕቅድ አውጪው የዚህን ውሂብ ጥራት እና አሃዛዊ ባህሪያት እንዴት እንደሚረዳ ለተለየ ዘገባ የተለየ ርዕስ ነው።

እና ምንም የመሳሪያ ግምገማዎች አይኖሩም, አንዱን ምርት ከሌላው ጋር አላወዳድርም. ምንም ማስታወቂያ አይኖርም. ይህንን እንተወው።

ስታቲስቲክስን መጠቀም ጠቃሚ መሆኑን ላሳይዎት እፈልጋለሁ. አስፈላጊ ነው. ያለ ፍርሃት ተጠቀሙበት። እኛ የምንፈልገው ግልጽ SQL እና የ SQL መሰረታዊ እውቀት ነው።

እና ችግሮችን ለመፍታት የትኛውን ስታቲስቲክስ ለመምረጥ እንነጋገራለን.

PostgreSQL ን ከተመለከትን እና ሂደቶቹን ለማየት በስርዓተ ክወናው ላይ ትዕዛዝ ካስኬድ, "ጥቁር ሳጥን" እናያለን. አንድ ነገር የሚያደርጉ አንዳንድ ሂደቶችን እናያለን፣ እና በስም እዚያ ምን እንደሚሰሩ፣ ምን እየሰሩ እንደሆነ መገመት እንችላለን። ግን ፣ በእውነቱ ፣ ይህ ጥቁር ሳጥን ነው ፣ ወደ ውስጥ ማየት አንችልም።

የሲፒዩ ጭነትን መመልከት እንችላለን topበአንዳንድ የስርዓት መገልገያዎች የማህደረ ትውስታ አጠቃቀምን ማየት እንችላለን ነገርግን በ PostgreSQL ውስጥ ማየት አንችልም። ለዚህም ሌሎች መሳሪያዎች ያስፈልጉናል.

እና በመቀጠል ፣ ጊዜው የት እንደጠፋ እነግርዎታለሁ። PostgreSQLን በእንደዚህ ዓይነት እቅድ ውስጥ የምንወክለው ከሆነ ጊዜው የት እንደሚጠፋ መልስ መስጠት ይቻላል. እነዚህ ሁለት ነገሮች ናቸው፡ ከመተግበሪያዎች የሚመጡ የደንበኛ ጥያቄዎችን ማስተናገድ እና PostgreSQL ስራውን እንዲቀጥል የሚያከናውናቸው የጀርባ ተግባራት ናቸው።

ከላይ በግራ ጥግ መመልከት ከጀመርን የደንበኛ ጥያቄዎች እንዴት እንደሚስተናገዱ ማየት እንችላለን። ጥያቄው ከማመልከቻው የመጣ ሲሆን ለተጨማሪ ስራ የደንበኛ ክፍለ ጊዜ ይከፈታል. ጥያቄው ወደ መርሐግብር አውጪው ተላልፏል. እቅድ አውጪው የመጠይቅ እቅድ ይገነባል። ለመፈጸም ተጨማሪ ይልካል. ከሠንጠረዦች እና ኢንዴክሶች ጋር የተቆራኘ አንድ ዓይነት የማገጃ I/O ውሂብ አለ። አስፈላጊው መረጃ ከዲስኮች ወደ ማህደረ ትውስታ የሚነበበው ልዩ ቦታ "የተጋሩ ቋቶች" ነው. የጥያቄ ውጤቶቹ፣ ማሻሻያዎች ከሆኑ፣ ይሰርዛሉ፣ በWAL ውስጥ ባለው የግብይት መዝገብ ውስጥ ተመዝግበው ይገኛሉ። አንዳንድ የስታቲስቲክስ መረጃዎች ወደ ሎግ ወይም ስታቲስቲክስ ሰብሳቢ ውስጥ ይገባሉ። እና የጥያቄው ውጤት ለደንበኛው ይመለሳል. ከዚያ በኋላ ደንበኛው ሁሉንም ነገር በአዲስ ጥያቄ መድገም ይችላል.

ከበስተጀርባ ስራዎች እና ከበስተጀርባ ሂደቶች ጋር ምን አለን? የመረጃ ቋቱ በመደበኛነት እንዲሠራ እና እንዲሠራ የሚያደርጉ ብዙ ሂደቶች አሉን። እነዚህ ሂደቶች በሪፖርቱ ውስጥም ይሸፈናሉ፡ እነዚህ አውቶቫክዩም, ቼክ ጠቋሚ, ከማባዛት ጋር የተያያዙ ሂደቶች, የጀርባ ጸሐፊ ናቸው. ስዘግብ እያንዳንዳቸውን እዳስሳለሁ።

በስታቲስቲክስ ላይ ምን ችግሮች አሉ?

• ብዙ መረጃ። PostgreSQL 9.4 የስታቲስቲክስ መረጃን ለመመልከት 109 መለኪያዎችን ይሰጣል። ሆኖም የመረጃ ቋቱ ብዙ ሠንጠረዦችን ፣ ንድፎችን ፣ የውሂብ ጎታዎችን የሚያከማች ከሆነ እነዚህ ሁሉ መለኪያዎች በተዛማጅ ሠንጠረዦች ፣ የውሂብ ጎታዎች ብዛት ማባዛት አለባቸው። ማለትም የበለጠ መረጃ አለ። እና በውስጡ መስጠም በጣም ቀላል ነው.
• የሚቀጥለው ችግር ስታቲስቲክስ በቆጣሪዎች ይወከላል. እነዚህን ስታቲስቲክስ ከተመለከትን, በየጊዜው እየጨመረ የሚሄድ ቆጣሪዎችን እንመለከታለን. እና ስታቲስቲክስ እንደገና ከተጀመረ በኋላ ብዙ ጊዜ ካለፈ, በቢሊዮኖች የሚቆጠሩ እሴቶችን እናያለን. እና ምንም አይነግሩንም።
• ታሪክ የለም። አንድ ዓይነት ውድቀት ካጋጠመዎት ከ 15-30 ደቂቃዎች በፊት የሆነ ነገር ወድቋል, ስታቲስቲክስን መጠቀም እና ከ15-30 ደቂቃዎች በፊት የሆነውን ማየት አይችሉም. ይህ ችግር ነው።
• በ PostgreSQL ውስጥ አብሮ የተሰራ መሳሪያ አለመኖሩ ችግር ነው። የከርነል ገንቢዎች ምንም አይነት አገልግሎት አይሰጡም። እንደዚህ አይነት ነገር የላቸውም። በመረጃ ቋቱ ውስጥ ስታቲስቲክስን ብቻ ይሰጣሉ። ይጠቀሙበት፣ ጥያቄ ያቅርቡለት፣ የፈለጉትን ያድርጉ፣ ከዚያ ያድርጉት።
• በ PostgreSQL ውስጥ የተሰራ መሳሪያ ስለሌለ ይህ ሌላ ችግር ይፈጥራል። ብዙ የሶስተኛ ወገን መሳሪያዎች። ብዙ ወይም ያነሰ ቀጥተኛ እጆች ያለው እያንዳንዱ ኩባንያ የራሱን ፕሮግራም ለመጻፍ እየሞከረ ነው. እናም በዚህ ምክንያት ማህበረሰቡ ከስታቲስቲክስ ጋር ለመስራት ሊጠቀሙባቸው የሚችሉ ብዙ መሳሪያዎች አሉት. እና በአንዳንድ መሳሪያዎች አንዳንድ ባህሪያት አሉ, በሌሎች መሳሪያዎች ውስጥ ሌሎች ባህሪያት የሉም, ወይም አንዳንድ አዲስ ባህሪያት አሉ. እና እርስ በርስ የሚደጋገፉ እና የተለያዩ ተግባራት ያላቸው ሁለት, ሶስት ወይም አራት መሳሪያዎችን መጠቀም የሚያስፈልግበት ሁኔታ ይፈጠራል. ይህ በጣም ደስ የማይል ነው.

ከዚህ ምን ይከተላል? በፕሮግራሞች ላይ ላለመደገፍ ስታቲስቲክስን በቀጥታ መውሰድ መቻል አስፈላጊ ነው ፣ ወይም እነዚህን ፕሮግራሞች በሆነ መንገድ እራስዎ ያሻሽሉ፡ የእርስዎን ጥቅም ለማግኘት አንዳንድ ተግባራትን ያክሉ።

እና የ SQL መሰረታዊ እውቀት ያስፈልግዎታል። አንዳንድ መረጃዎችን ከስታቲስቲክስ ለማግኘት፣ የ SQL መጠይቆችን ማድረግ ያስፈልግዎታል፣ ማለትም እንዴት እንደሚመረጡ፣ መቀላቀል እንደሚደረግ ማወቅ ያስፈልግዎታል።

ስታቲስቲክስ ብዙ ነገሮችን ይነግሩናል። እነሱ ወደ ምድቦች ሊከፋፈሉ ይችላሉ.

• የመጀመሪያው ምድብ በመረጃ ቋቱ ውስጥ የተከናወኑ ክስተቶች ናቸው. ይህ አንዳንድ ክስተት በመረጃ ቋቱ ውስጥ ሲከሰት ነው፡ መጠይቅ፣ የጠረጴዛ መዳረሻ፣ አውቶቫክዩም (autovacuum) ይፈጽማል፣ ከዚያ እነዚህ ሁሉ ክስተቶች ናቸው። ከእነዚህ ክስተቶች ጋር የሚዛመዱ ቆጣሪዎች ጨምረዋል። እና እነዚህን ክስተቶች መከታተል እንችላለን.
• ሁለተኛው ምድብ እንደ ጠረጴዛዎች, የውሂብ ጎታዎች ያሉ የነገሮች ባህሪያት ናቸው. ንብረቶች አሏቸው። ይህ የጠረጴዛዎች መጠን ነው. የሰንጠረዦችን እድገት, የኢንዴክሶችን እድገት መከታተል እንችላለን. በተለዋዋጭነት ለውጦችን ማየት እንችላለን።
• እና ሶስተኛው ምድብ በዝግጅቱ ላይ የሚጠፋው ጊዜ ነው. ጥያቄ ክስተት ነው። የራሱ የሆነ የቆይታ ጊዜ መለኪያ አለው. እዚህ ተጀምሯል፣ እዚህ አበቃ። መከታተል እንችላለን። ከዲስክ ላይ እገዳን ለማንበብ ወይም ለመጻፍ ጊዜ. እነዚህ ነገሮችም ክትትል ይደረግባቸዋል።

የስታቲስቲክስ ምንጮች እንደሚከተለው ቀርበዋል.

• በጋራ ማህደረ ትውስታ (የተጋራ ማቋረጫ) ውስጥ የማይለዋወጥ ውሂብን እዚያ ለማስቀመጥ ክፍል አለ ፣ እንዲሁም አንዳንድ ክስተቶች ሲከሰቱ በየጊዜው የሚጨመሩ ወይም በመረጃ ቋቱ አሠራር ውስጥ አንዳንድ ጊዜ የሚነሱ ቆጣሪዎች አሉ።
• እነዚህ ሁሉ ቆጣሪዎች ለተጠቃሚው አይገኙም እና ለአስተዳዳሪው እንኳን አይገኙም. እነዚህ ዝቅተኛ ደረጃ ያላቸው ነገሮች ናቸው. እነሱን ለማግኘት፣ PostgreSQL በ SQL ተግባራት መልክ በይነገጽ ያቀርባል። እነዚህን ተግባራት በመጠቀም የተመረጡ ምርጫዎችን ማድረግ እና አንዳንድ ዓይነት መለኪያ (ወይም የመለኪያዎች ስብስብ) ማግኘት እንችላለን።
• ነገር ግን, እነዚህን ተግባራት ለመጠቀም ሁልጊዜ ምቹ አይደለም, ስለዚህ ተግባራት ለእይታዎች (እይታዎች) መሰረት ናቸው. እነዚህ በአንድ የተወሰነ ንዑስ ስርዓት ላይ ወይም በመረጃ ቋቱ ውስጥ ባሉ አንዳንድ የክስተቶች ስብስብ ላይ ስታቲስቲክስን የሚያቀርቡ ምናባዊ ሠንጠረዦች ናቸው።
• እነዚህ አብሮገነብ እይታዎች (እይታዎች) ከስታቲስቲክስ ጋር ለመስራት ዋናው የተጠቃሚ በይነገጽ ናቸው። ያለምንም ተጨማሪ ቅንጅቶች በነባሪነት ይገኛሉ, ወዲያውኑ ሊጠቀሙባቸው, ሊመለከቱት, ከዚያ መረጃ መውሰድ ይችላሉ. እና መዋጮዎችም አሉ። መዋጮዎች ኦፊሴላዊ ናቸው። የ postgresql-contrib ጥቅልን መጫን ይችላሉ (ለምሳሌ ፣ postgresql94-contrib) ፣ አስፈላጊውን ሞጁል በማዋቀሩ ውስጥ ይጫኑ ፣ ለእሱ መለኪያዎችን ይግለጹ ፣ PostgreSQL እንደገና ያስጀምሩ እና እሱን መጠቀም ይችላሉ። (ማስታወሻ. በስርጭቱ ላይ በመመስረት፣ በቅርብ ጊዜ የአስተዋጽኦ ስሪቶች ጥቅሉ የዋናው ጥቅል አካል ነው።).
• እና ኦፊሴላዊ ያልሆኑ አስተያየቶች አሉ። ከመደበኛው PostgreSQL ስርጭት ጋር አይቀርቡም። እንደ ቤተ-መጽሐፍት መጠቅለል ወይም መጫን አለባቸው። የዚህ ኦፊሴላዊ ያልሆነ አስተዋፅዖ ገንቢ ባመጣው ላይ በመመስረት አማራጮች በጣም የተለያዩ ሊሆኑ ይችላሉ።

ይህ ስላይድ ሁሉንም እይታዎች (እይታዎች) እና በPostgreSQL 9.4 ውስጥ የሚገኙትን አንዳንድ ተግባራት ያሳያል። እንደምናየው, በጣም ብዙ ናቸው. እና ለመጀመሪያ ጊዜ ካጋጠመዎት ግራ መጋባት በጣም ቀላል ነው።

ሆኖም ግን, የቀደመውን ምስል ከወሰድን Как тратится время на PostgreSQL እና ከዚህ ዝርዝር ጋር ተኳሃኝ, ይህንን ስዕል እናገኛለን. እያንዳንዱ እይታ (እይታዎች)፣ ወይም እያንዳንዱ ተግባር፣ PostgreSQL ስናሄድ ተገቢውን ስታቲስቲክስ ለማግኘት ለአንድ ወይም ለሌላ ዓላማ ልንጠቀምበት እንችላለን። እና ስለ ንዑስ ስርዓቱ አሠራር አንዳንድ መረጃዎችን ቀድሞውኑ ማግኘት እንችላለን።

በመጀመሪያ የምንመለከተው ነገር ነው። pg_stat_database. እንደምናየው, ይህ ውክልና ነው. ብዙ መረጃዎችን ይዟል። በጣም የተለያየ መረጃ. እና በመረጃ ቋቱ ውስጥ ስላለን ነገር በጣም ጠቃሚ እውቀትን ይሰጣል።

ከዚያ ምን መውሰድ እንችላለን? በጣም ቀላል በሆኑ ነገሮች እንጀምር.

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

እኛ ልንመለከተው የምንችለው የመጀመሪያው ነገር መሸጎጫ መቶኛ ነው። መሸጎጫ መቶኛ ጠቃሚ ልኬት ነው። ከተጋሩ ቋቶች መሸጎጫ ምን ያህል ውሂብ እንደሚወሰድ እና ከዲስክ ምን ያህል እንደተነበበ ለመገመት ያስችልዎታል።

እንደሆነ ግልጽ ነው። ብዙ መሸጎጫ ባገኘን ቁጥር የተሻለ ይሆናል።. ይህንን መለኪያ እንደ መቶኛ እንገመግማለን። እና፣ ለምሳሌ፣ የእነዚህ መሸጎጫ መሸጎጫዎች ከ90% በላይ መቶኛ ካለን ይህ ጥሩ ነው። ከ90% በታች ከቀነሰ የመረጃውን ትኩስ ጭንቅላት በማህደረ ትውስታ ውስጥ ለማቆየት በቂ ማህደረ ትውስታ የለንም። እና ይህን ውሂብ ለመጠቀም, PostgreSQL ዲስኩን ለመድረስ ይገደዳል እና ይህ መረጃ ከማህደረ ትውስታ ከተነበበ የበለጠ ቀርፋፋ ነው. እና ማህደረ ትውስታን ስለማሳደግ ማሰብ አለብዎት-የጋራ ማቋረጫዎችን ይጨምሩ ወይም የብረት ማህደረ ትውስታን (ራም) ይጨምሩ።

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 በጣም ቀላል ነው። እና ይህን ውሂብ ለራሳችን ማየት እንችላለን.

እና የመነሻ ዋጋዎች እዚህ አሉ። የተፈፀመውን እና የመመለሻዎችን ጥምርታ እንመለከታለን። ኮሚትስ የግብይቱን የተሳካ ማረጋገጫ ነው። Rollbacks ወደ ኋላ መመለስ ነው፣ ማለትም ግብይቱ አንዳንድ ስራዎችን ሰርቷል፣ የውሂብ ጎታውን አጣርቷል፣ የሆነ ነገር ግምት ውስጥ ያስገባ፣ እና ከዚያ ውድቀት ተፈጠረ፣ እና የግብይቱ ውጤቶች ተጥለዋል። ማለትም ያለማቋረጥ እየጨመረ የሚሄደው የመመለሻ ብዛት መጥፎ ነው። እና በሆነ መንገድ እነሱን ማስወገድ አለብዎት እና ይህ እንዳይሆን ኮዱን ያርትዑ።

ግጭቶች ከመባዛት ጋር የተያያዙ ናቸው። እና እነሱም መወገድ አለባቸው. በቅጂው ላይ የሚፈጸሙ አንዳንድ ጥያቄዎች ካሉዎት እና ግጭቶች ከተነሱ ታዲያ እነዚህን ግጭቶች መተንተን እና ምን እንደሚፈጠር ማየት ያስፈልግዎታል። ዝርዝሮች በምዝግብ ማስታወሻዎች ውስጥ ይገኛሉ. እና የመተግበሪያ ጥያቄዎች ያለ ስህተቶች እንዲሰሩ ግጭቶችን ይፍቱ።

መዘጋት እንዲሁ መጥፎ ሁኔታ ነው። ጥያቄዎች ለሀብት ሲወዳደሩ አንድ ጥያቄ አንዱን ሃብት አግኝቶ መቆለፊያውን ወሰደ፣ ሁለተኛው ጥያቄ ሁለተኛውን ሃብት አግኝቶ መቆለፊያውንም ወሰደ፣ ከዚያም ሁለቱም ጥያቄዎች አንዳቸው የሌላውን ሃብት አግኝተው ጎረቤቱ መቆለፊያውን እስኪለቅ ድረስ መጠበቅ ዘጋባቸው። ይህ ደግሞ ችግር ያለበት ሁኔታ ነው. አፕሊኬሽኖችን እንደገና በመፃፍ እና የንብረቶች መዳረሻን ተከታታይነት ባለው መልኩ ማስተካከል አለባቸው. እና መቆለፊያዎ በየጊዜው እየጨመረ መሆኑን ካዩ, በምዝግብ ማስታወሻዎች ውስጥ ያሉትን ዝርዝሮች መመልከት, የተከሰቱትን ሁኔታዎች መተንተን እና ችግሩ ምን እንደሆነ ማየት ያስፈልግዎታል.

ጊዜያዊ ፋይሎች (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 በፍተሻ_ጊዜ ከተያዘው በጣም ትልቅ ነው፣ ከዚያ ይሄ መጥፎ ነው። ለምን መጥፎ? ይህ ማለት PostgreSQL ውሂብን ወደ ዲስክ ለመፃፍ በሚያስፈልግበት ጊዜ የማያቋርጥ ውጥረት ውስጥ ነው. የፍተሻ ነጥብ በጊዜ ማብቂያ ብዙም አስጨናቂ ነው እና በውስጣዊ መርሃ ግብሩ መሰረት ይፈጸማል እና በጊዜ ሂደት የተዘረጋ ነው። PostgreSQL በሥራ ላይ ለአፍታ የማቆም እና የዲስክ ንዑስ ስርዓቱን ላለማሳሳት ችሎታ አለው። ይህ ለ PostgreSQL ጠቃሚ ነው። እና በፍተሻ ነጥብ ወቅት የሚፈጸሙ ጥያቄዎች የዲስክ ንዑስ ስርዓት ስራ ስለሚበዛበት ጭንቀት አይታይባቸውም።

እና የፍተሻ ነጥቡን ለማስተካከል ሶስት መለኪያዎች አሉ-

• сheckpoint_segments.

• сheckpoint_timeout.

• сheckpoint_competion_target.

የመቆጣጠሪያ ነጥቦችን አሠራር እንዲቆጣጠሩ ያስችሉዎታል. እኔ ግን በእነርሱ ላይ አላተኩርም። የእነሱ ተጽእኖ የተለየ ጉዳይ ነው.

ማስጠንቀቂያ በሪፖርቱ ውስጥ የተመለከተው ስሪት 9.4 ከአሁን በኋላ አግባብነት የለውም። በዘመናዊ የ PostgreSQL ስሪቶች ውስጥ, መለኪያው checkpoint_segments በመለኪያዎች ተተካ min_wal_size и max_wal_size.

የሚቀጥለው ንዑስ ስርዓት የበስተጀርባ ጸሐፊ ነው - background writer. ምን እያደረገ ነው? ማለቂያ በሌለው ዑደት ውስጥ ያለማቋረጥ ይሰራል። ገጾቹን ወደ የተጋሩ ቋቶች ይፈትሻል እና ያገኛቸውን ቆሻሻ ገፆች በዲስክ ላይ ያጥባል። በዚህ መንገድ የፍተሻ ጠቋሚው በፍተሻ ጊዜ አነስተኛ ስራ እንዲሰራ ይረዳል.

ሌላ ምን ያስፈልገዋል? መረጃን ለማስተናገድ በድንገት (በብዛት እና ወዲያውኑ) ከተፈለገ በጋራ ቋቶች ውስጥ የንጹህ ገጾችን አስፈላጊነት ያቀርባል። ጥያቄው ንጹህ ገጾችን ሲያስፈልግ እና ቀድሞውኑ በጋራ ቋት ውስጥ ሲሆኑ አንድ ሁኔታ ተከሰተ እንበል። ፖስትግሬስ backend እሱ ብቻ ወስዶ ይጠቀምባቸዋል, እሱ ራሱ ምንም ነገር ማጽዳት የለበትም. ነገር ግን በድንገት እንደዚህ አይነት ገፆች ከሌሉ የኋለኛው ክፍል ቆም ብሎ ወደ ዲስክ ለማፍሰስ እና ለፍላጎቱ ለመውሰድ ገጾችን መፈለግ ይጀምራል - ይህም በአሁኑ ጊዜ የአፈፃፀም ጥያቄ ጊዜ ላይ አሉታዊ ተጽዕኖ ያሳድራል። መለኪያ እንዳለዎት ካዩ maxwritten_clean ትልቅ, ይህ ማለት የጀርባው ጸሐፊ ስራውን እየሰራ አይደለም እና መለኪያዎችን መጨመር ያስፈልግዎታል bgwriter_lru_maxpagesበአንድ ዑደት ውስጥ ብዙ ስራዎችን እንዲሰራ, ተጨማሪ ገጾችን ያጽዱ.

እና ሌላ በጣም ጠቃሚ አመላካች ነው buffers_backend_fsync. የኋላ ጀርባዎች fsync አያደርጉትም ምክንያቱም ቀርፋፋ ነው። የ IO ቁልል ፍተሻ ጠቋሚውን ወደላይ ያልፋሉ። የፍተሻ ጠቋሚው የራሱ ወረፋ አለው, በየጊዜው fsyncን ያስኬዳል እና ገጾችን በማህደረ ትውስታ ውስጥ በዲስክ ላይ ካሉ ፋይሎች ጋር ያመሳስላል. የፍተሻ ጠቋሚው ትልቅ እና የተሞላ ከሆነ፣ የጀርባው አካል በራሱ fsync ለማድረግ ይገደዳል እና ይህ የጀርባውን ፍጥነት ይቀንሳል።, ማለትም ደንበኛው ከሚችለው በላይ ዘግይቶ ምላሽ ይቀበላል. ይህ ዋጋ ከዜሮ የሚበልጥ መሆኑን ካዩ, ይህ ቀድሞውኑ ችግር ነው እና ለጀርባ ጸሐፊ ቅንጅቶች ትኩረት መስጠት እና የዲስክ ንዑስ ስርዓትን አፈፃፀም መገምገም ያስፈልግዎታል ።

ማስጠንቀቂያ _የሚከተለው ጽሁፍ ከማባዛት ጋር የተያያዙትን እስታቲስቲካዊ እይታዎች ይገልፃል። አብዛኛዎቹ የእይታ እና የተግባር ስሞች በፖስትግሬስ 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 እና የማባዛት መዘግየትን በባይት እና በሰከንዶች መገመት እንችላለን። ለዚህ ደግሞ ከዚህ እይታ (እይታዎች) እሴቱን እንጠቀማለን።

ማስታወሻ: ከpg_xlog_ቦታ ይልቅdiff() ተግባር፣ የመቀነስ ኦፕሬተሩን መጠቀም እና አንዱን ቦታ ከሌላው መቀነስ ይችላሉ። ምቹ።

በሰከንዶች ውስጥ ባለው መዘግየት ፣ አንድ አፍታ አለ። በጌታው ላይ ምንም አይነት እንቅስቃሴ ከሌለ ግብይቱ ከ 15 ደቂቃ በፊት ነበር እና ምንም አይነት እንቅስቃሴ የለም, እና ይህንን ግልባጭ በቅጅው ላይ ከተመለከትን, የ 15 ደቂቃዎች መዘግየት እናያለን. ይህ ማስታወስ ተገቢ ነው. እና ይህን መዘግየት ሲመለከቱ ወደ ድንጋጤ ሊመራ ይችላል።

pg_stat_all_tables ሌላው ጠቃሚ እይታ ነው። በጠረጴዛዎች ላይ ስታቲስቲክስን ያሳያል. በመረጃ ቋቱ ውስጥ ጠረጴዛዎች ሲኖሩን, ከእሱ ጋር አንዳንድ እንቅስቃሴዎች, አንዳንድ ድርጊቶች, ይህንን መረጃ ከዚህ እይታ ማግኘት እንችላለን.

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 - በሠንጠረዡ ውስጥ ረድፎችን የማዘመን አሠራር. እንደ እውነቱ ከሆነ ማዘመን ሁለት ኦፕሬሽኖች (ወይም እንዲያውም የበለጠ) ነው። ይህ አዲስ የረድፍ ሥሪት በማስገባት የድሮውን የረድፍ ሥሪት ጊዜ ያለፈበት መሆኑን እያሳየ ነው። በኋላ፣ አውቶቫክዩም መጥቶ እነዚህን ጊዜ ያለፈባቸውን የመስመሮቹ ስሪቶች ያጸዳል፣ ይህንን ቦታ ለእንደገና ጥቅም ላይ ሊውል እንደሚችል ምልክት ያድርጉበት።

በተጨማሪም ማዘመን ሠንጠረዥን ማዘመን ብቻ አይደለም። አሁንም የመረጃ ጠቋሚ ማሻሻያ ነው። በጠረጴዛው ላይ ብዙ ኢንዴክሶች ካሉዎት፣ከዝማኔ ጋር፣በጥያቄው ውስጥ የተዘመኑት መስኮች የሚሳተፉባቸው ሁሉም ኢንዴክሶችም መዘመን አለባቸው። እነዚህ ኢንዴክሶች ማጽዳት የሚያስፈልጋቸው ጊዜ ያለፈባቸው የረድፍ ስሪቶችም ይኖራቸዋል።

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% ቀርተናል። ማሻሻያ ማድረግ ሲፈልጉ፣ ምናልባት በተመሳሳይ ገጽ ላይ ይከሰታል፣ እና አዲሱ የረድፉ ስሪት በተመሳሳይ ገጽ ላይ ይጣጣማል። እና ትኩስ_ዝማኔ ይከናወናል። ይህ በጠረጴዛዎች ላይ ለመጻፍ ቀላል ያደርገዋል.

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 ውስጥ ማየት የምንችለው በአሁኑ ጊዜ ስንት ቫክዩም እንዳለን ነው። ይሁን እንጂ በእንቅስቃሴ ላይ ምን ያህል ጠረጴዛዎች በወረፋው ውስጥ እንዳሉ ለመረዳት በጣም አስቸጋሪ ነው.

ማስታወሻ: ከድህረ ገጽ 10 ጀምሮ የቫኩም ቫክዩም የመከታተል ሁኔታ በጣም ተሻሽሏል - የpg_stat_progress እይታ ታይቷልቫክዩም, ይህም የራስ-ቫኩም ክትትልን ጉዳይ በእጅጉ ያቃልላል.

ይህን ቀለል ያለ ጥያቄ መጠቀም እንችላለን። እና ቫክዩም መቼ መደረግ እንዳለበት ማየት እንችላለን. ግን ቫክዩም እንዴት እና መቼ መጀመር አለበት? እነዚህ ቀደም ብዬ የተናገርኳቸው የሕብረቁምፊዎች የድሮ ስሪቶች ናቸው። ዝማኔ ተከስቷል፣ አዲሱ የረድፉ ስሪት ገብቷል። ጊዜው ያለፈበት የሕብረቁምፊው ስሪት ታይቷል። ጠረጴዛ pg_stat_user_tables እንደዚህ ያለ መለኪያ አለ n_dead_tup. የ "ሙታን" ረድፎችን ቁጥር ያሳያል. እና የሞቱ ረድፎች ቁጥር ከተወሰነ ገደብ በላይ እንደ ሆነ፣ አውቶቫክዩም ወደ ጠረጴዛው ይመጣል።

እና ይህ ገደብ እንዴት ይሰላል? ይህ በሠንጠረዡ ውስጥ ካሉት የረድፎች ጠቅላላ ቁጥር በጣም የተወሰነ መቶኛ ነው። መለኪያ አለ autovacuum_vacuum_scale_factor. መቶኛን ይገልጻል። እንበል 10% + ተጨማሪ የ 50 መስመሮች መነሻ ገደብ አለ። እና ምን ይሆናል? በሠንጠረዡ ውስጥ ካሉት ሁሉም ረድፎች ከ "10% + 50" የበለጠ የሞቱ ረድፎች ሲኖሩን, ጠረጴዛውን በራስ-ሰር ላይ እናስቀምጠዋለን.

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 በተናጠል ሊመደብ ይችላል. እና, በዚህ መሠረት, ጣራው ዓለም አቀፋዊ አይሆንም, ግን ለጠረጴዛው ግለሰብ ነው. ስለዚህ, ለማስላት, እዚያ ዘዴዎችን እና ዘዴዎችን መጠቀም ያስፈልግዎታል. እና ፍላጎት ካሎት የአቪቶ ባልደረቦቻችንን ልምድ ማየት ይችላሉ (በስላይድ ላይ ያለው አገናኝ ልክ ያልሆነ እና በጽሁፉ ውስጥ ተዘምኗል)።

ብለው ጽፈዋል munin ተሰኪእነዚህን ነገሮች ግምት ውስጥ ያስገባል. በሁለት አንሶላዎች ላይ የእግር ልብስ አለ. ግን እሱ በትክክል ያገናዘበ እና በጣም ውጤታማ በሆነ መንገድ ለጠረጴዛዎች ብዙ ባዶ ቦታ የት እንደሚፈለግ ለመገምገም ይፈቅድልናል ፣ ትንሽ በሌለበት።

በዚህ ጉዳይ ላይ ምን እናድርግ? ረጅም ወረፋ ካለን እና አውቶቫክዩም መቋቋም ካልቻለ የቫኩም ሰራተኞችን ቁጥር መጨመር ወይም በቀላሉ ቫክዩም የበለጠ ጠበኛ ማድረግ እንችላለንቀደም ብሎ እንዲነቃነቅ, ጠረጴዛውን በትናንሽ ቁርጥራጮች ያስኬዳል. እና ስለዚህ ወረፋው ይቀንሳል. - እዚህ ያለው ዋናው ነገር በዲስኮች ላይ ያለውን ጭነት መከታተል ነው, ምክንያቱም. የቫኩም ነገር ነፃ አይደለም፣ ምንም እንኳን የኤስኤስዲ/ኤንቪኤምኤ መሳሪያዎች መምጣት ጋር ተያይዞ ችግሩ ብዙም ትኩረት የማይሰጥ ሆኗል።

pg_stat_all_indexes በመረጃ ጠቋሚዎች ላይ ያለ ስታቲስቲክስ ነው። ትልቅ አይደለችም። እና ስለ ኢንዴክሶች አጠቃቀም መረጃን ከእሱ ማግኘት እንችላለን. እና ለምሳሌ, የትኛዎቹ ኢንዴክሶች ተጨማሪ እንዳለን መወሰን እንችላለን.

አስቀድሜ እንዳልኩት ፣ ዝማኔ ሠንጠረዦችን ማዘመን ብቻ ሳይሆን ኢንዴክሶችንም ማዘመን ነው። በዚህ መሠረት, በጠረጴዛው ላይ ብዙ ኢንዴክሶች ካሉን, በሠንጠረዡ ውስጥ ያሉትን ረድፎች ሲያዘምኑ, የተጠቆሙት መስኮች ኢንዴክሶችም መዘመን አለባቸው, እና ምንም ኢንዴክስ የሌሉባቸው ጥቅም ላይ ያልዋሉ ኢንዴክሶች ካሉን እንደ ባላስት ከእኛ ጋር ይሰቅላሉ። እና እነሱን ማስወገድ ያስፈልግዎታል. ለዚህ መስክ ያስፈልገናል 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. ይህ የመገልገያው አናሎግ ነው። 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)';

እና ከላይ እንዳልኩት እነዚህ ሁለት ግዛቶች በግብይት ውስጥ ስራ ፈት እና በግብይት ውስጥ ስራ ፈት (የተቋረጠ) መጥፎ ናቸው። ምንድን ነው? ይህ አፕሊኬሽኑ ግብይት ከፈተ፣ አንዳንድ ድርጊቶችን ሲፈጽም እና ስራውን ሲሰራ ነው። ግብይቱ ክፍት እንደሆነ ይቆያል። ተንጠልጥሏል ፣ ምንም ነገር አይከሰትም ፣ ግንኙነቱን ይወስዳል ፣ በተቀየሩ ረድፎች ላይ ይቆልፋል እና በPorges የዝውውር ሞተር ሥነ ሕንፃ ምክንያት አሁንም የሌሎች ጠረጴዛዎች እብጠት ሊጨምር ይችላል። እና እንደዚህ አይነት ግብይቶችም መተኮስ አለባቸው, ምክንያቱም በአጠቃላይ ጎጂ ናቸው, በማንኛውም ሁኔታ.

በውሂብ ጎታህ ውስጥ ከ5-10-20 በላይ እንዳሎት ካየህ መጨነቅ እና ከእነሱ ጋር የሆነ ነገር ማድረግ መጀመር አለብህ።

እዚህ ደግሞ ለስሌቱ ጊዜ እንጠቀማለን clock_timestamp(). ግብይቶችን እንተኩሳለን, አፕሊኬሽኑን እናሻሽላለን.

ከላይ እንደተናገርኩት መቆለፊያዎች ሁለት ወይም ከዚያ በላይ ግብይቶች ለአንድ ወይም ለቡድን ሀብቶች ሲወዳደሩ ነው. ለዚህም ሜዳ አለን። waiting ከቦሊያን ዋጋ ጋር true ወይም false.

እውነት ነው - ይህ ማለት ሂደቱ እየጠበቀ ነው, አንድ ነገር መደረግ አለበት. አንድ ሂደት ሲጠበቅ, ከዚያም ሂደቱን የጀመረው ደንበኛም እየጠበቀ ነው. በአሳሹ ውስጥ ያለው ደንበኛ ተቀምጦ ይጠብቃል።

ማስጠንቀቂያ _ከፖስትግሬስ 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 ሪፖርቶችን ለመገንባት ያገለግላል. በቀን አንድ ጊዜ ስታቲስቲክስን እንደገና እናስጀምራለን. እናከማቻል። በሚቀጥለው ጊዜ ስታቲስቲክስን ዳግም ከማስጀመርዎ በፊት፣ ሪፖርት እንገነባለን። የሪፖርቱ ማገናኛ እነሆ። ሊመለከቱት ይችላሉ.

ምን እየሰራን ነው? የሁሉም ጥያቄዎች አጠቃላይ ስታቲስቲክስን እናሰላለን። ከዚያ፣ ለእያንዳንዱ ጥያቄ፣ ለዚህ ​​አጠቃላይ ስታቲስቲክስ ግላዊ አስተዋጾ እንቆጥራለን።

እና ምን ማየት እንችላለን? የአንድ የተወሰነ አይነት የሁሉም ጥያቄዎች አጠቃላይ የአፈፃፀም ጊዜ ከሌሎች ጥያቄዎች ዳራ አንጻር ማየት እንችላለን። ከአጠቃላይ ምስል ጋር በተገናኘ የሲፒዩ እና የአይ/ኦ አጠቃቀምን መመልከት እንችላለን። እና እነዚህን ጥያቄዎች ለማመቻቸት። በዚህ ሪፖርት ላይ ተመስርተን ከፍተኛ መጠይቆችን እየገነባን ነው እና ምን ማመቻቸት እንዳለብን አስቀድሞ ለማሰብ ምግብ እያገኘን ነው።

ከመጋረጃ ጀርባ ምን አለን? አሁንም ያላሰብኳቸው ጥቂት ማቅረቢያዎች አሉ፣ ምክንያቱም ጊዜ ውስን ነው።

አሉ pgstattuple ከመደበኛ መዋጮ ጥቅል ተጨማሪ ሞጁል ነው። እንዲገመግሙ ያስችልዎታል bloat ጠረጴዛዎች, የሚባሉት. የጠረጴዛ ቁርጥራጭ. እና መቆራረጡ ትልቅ ከሆነ, ማስወገድ ያስፈልግዎታል, የተለያዩ መሳሪያዎችን ይጠቀሙ. እና ተግባር pgstattuple ለረጅም ጊዜ ይሰራል. እና ብዙ ጠረጴዛዎች, ረዘም ያለ ጊዜ ይሰራል.

የሚቀጥለው አስተዋፅዖ ነው። pg_buffercache. የተጋሩ ማቋረጫዎችን ለመፈተሽ ይፈቅድልዎታል-ምን ያህል የተጠናከረ እና ለየትኞቹ የጠረጴዛዎች ቋት ገጾች ጥቅም ላይ ይውላሉ። እና ወደ የተጋሩ ቋቶች እንዲመለከቱ እና እዚያ ምን እየተፈጠረ እንዳለ እንዲገመግሙ ይፈቅድልዎታል።

የሚቀጥለው ሞጁል ነው። pgfincore. በስርዓት ጥሪ አማካኝነት ዝቅተኛ ደረጃ የጠረጴዛ ስራዎችን እንዲያከናውኑ ይፈቅድልዎታል mincore(), ማለትም ሰንጠረዡን ወደ የጋራ ቋቶች እንዲጭኑት ወይም እንዲጭኑት ይፈቅድልዎታል. እና ከሌሎች ነገሮች በተጨማሪ የስርዓተ ክወናውን የገጽ መሸጎጫ ለመፈተሽ ያስችላል, ማለትም, ሰንጠረዡ በገጹ መሸጎጫ ውስጥ, በጋራ መያዣዎች ውስጥ ምን ያህል እንደሚይዝ እና በቀላሉ በጠረጴዛው ላይ ያለውን ጭነት እንዲገመግሙ ያስችልዎታል.

የሚቀጥለው ሞጁል ነው። pg_stat_kcache. የስርዓት ጥሪንም ይጠቀማል getrusage(). እና ጥያቄው ከመፈጸሙ በፊት እና በኋላ ያስፈጽማል. እና በተገኘው ስታቲስቲክስ ውስጥ, ጥያቄያችን በዲስክ I / O ላይ ምን ያህል እንደሚያጠፋ ለመገመት ያስችለናል, ማለትም, ከፋይል ስርዓቱ ጋር የሚሰሩ ስራዎች እና የአቀነባባሪውን አጠቃቀም እንመለከታለን. ሆኖም ሞጁሉ ወጣት ነው (khe-khe) እና ለስራው ቀደም ሲል የጠቀስኳቸውን PostgreSQL 9.4 እና pg_stat_statements ያስፈልገዋል።

• ስታቲስቲክስን የመጠቀም ችሎታ ጠቃሚ ነው. የሶስተኛ ወገን ሶፍትዌር አያስፈልግዎትም። ማየት፣ ማየት፣ የሆነ ነገር ማድረግ፣ ማከናወን ትችላለህ።

• ስታቲስቲክስን መጠቀም ቀላል ነው፣ ግልጽ SQL ነው። ጥያቄ ሰብስበህ፣ አጠናቅረህ፣ ላከህ፣ ተመለከትከው።

• ስታቲስቲክስ ጥያቄዎችን ለመመለስ ይረዳል። ጥያቄዎች ካሉዎት ወደ ስታቲስቲክስ ይመለሳሉ - ይመልከቱ, መደምደሚያ ይሳሉ, ውጤቱን ይተንትኑ.

• እና ሙከራ። ብዙ ጥያቄዎች፣ ብዙ ውሂብ። አንዳንድ ነባር ጥያቄዎችን ሁልጊዜ ማመቻቸት ይችላሉ። ከዋናው የበለጠ የሚስማማዎትን የጥያቄውን የእራስዎን እትም መስራት እና መጠቀም ይችላሉ።

ማጣቀሻዎች

በጽሁፉ ውስጥ የተገኙ ትክክለኛ አገናኞች፣ በየትኞቹ ላይ ተመስርተው በሪፖርቱ ውስጥ ነበሩ።

ደራሲ የበለጠ ጻፍ
https://dataegret.com/news-blog (ኢንጂነር)

የስታቲስቲክስ ሰብሳቢው
https://www.postgresql.org/docs/current/monitoring-stats.html

የስርዓት አስተዳደር ተግባራት
https://www.postgresql.org/docs/current/functions-admin.html

የአስተዋጽኦ ሞጁሎች
https://www.postgresql.org/docs/current/pgstatstatements.html
https://www.postgresql.org/docs/current/pgstattuple.html
https://www.postgresql.org/docs/current/pgbuffercache.html
https://github.com/klando/pgfincore
https://github.com/dalibo/pg_stat_kcache

የ SQL መገልገያዎች እና sql ኮድ ምሳሌዎች
https://github.com/dataegret/pg-utils

ስለ ትኩረትዎ ሁላችሁንም አመሰግናለሁ!

ምንጭ: hab.com