PostgreSQLን ለማስተካከል የኢንዱስትሪ አቀራረብ፡ ከመረጃ ቋቶች ጋር ሙከራዎች። Nikolay Samokhvalov

የኒኮላይ ሳሞክቫሎቭ ዘገባ “PostgreSQL ን ለማስተካከል የኢንዱስትሪ አቀራረብ፡ በመረጃ ቋቶች ላይ ያሉ ሙከራዎች” የሚለውን ዘገባ እንዲያነቡ እመክርዎታለሁ።

Shared_buffers = 25% - ብዙ ነው ወይስ ትንሽ? ወይስ ልክ ነው? ይህ - ይልቁንም ጊዜው ያለፈበት - ምክር በእርስዎ ጉዳይ ላይ ተገቢ መሆኑን እንዴት ያውቃሉ?

የ postgresql.conf መለኪያዎችን "እንደ ትልቅ ሰው" የመምረጥ ጉዳይ ለመቅረብ ጊዜው አሁን ነው. በዓይነ ስውራን "አውቶማቲክስ" እርዳታ ወይም ከጽሁፎች እና ብሎጎች ጊዜ ያለፈበት ምክር አይደለም ነገር ግን በ:

1. በመረጃ ቋቶች ላይ በጥብቅ የተረጋገጡ ሙከራዎች ፣ በራስ ሰር ፣ በብዛት እና በተቻለ መጠን “መዋጋት” በሚቻልበት ሁኔታ ይከናወናሉ ፣
2. የዲቢኤምኤስ እና የስርዓተ ክወና ባህሪያትን በጥልቀት መረዳት።

ናንሲ CLI በመጠቀምhttps://gitlab.com/postgres.ai/nancy), አንድ የተወሰነ ምሳሌ እንመለከታለን - ታዋቂውን የተጋሩ_buffers - በተለያዩ ሁኔታዎች, በተለያዩ ፕሮጀክቶች ውስጥ እና ለመሠረተ ልማት, የውሂብ ጎታ እና ጭነት ተስማሚ መቼት እንዴት እንደሚመርጡ ለማወቅ እንሞክራለን.

ስለ ዳታቤዝ ሙከራዎች እንነጋገራለን. ይህ ከስድስት ወራት በላይ የሚቆይ ታሪክ ነው።

ስለ እኔ ትንሽ። ከ Postgres ጋር ከ14 ዓመታት በላይ ልምድ። በርካታ የማህበራዊ ትስስር ኩባንያዎች ተመስርተዋል። Postgres ነበር እና በሁሉም ቦታ ጥቅም ላይ ይውላል።

እንዲሁም የ RuPostgres ቡድን በ Meetup ላይ፣ በአለም 2ኛ ደረጃ። ቀስ በቀስ ወደ 2 ሰዎች እንቀርባለን. RuPostgres.org.

እና ሃይሎድን ጨምሮ በተለያዩ ኮንፈረንሶች ፒሲዎች እኔ ከጅምሩ ጀምሮ ለዳታቤዝ በተለይም ለፖስትግሬስ ሀላፊነት አለኝ።

እና ባለፉት ጥቂት አመታት የ Postgres የማማከር ልምምዴን 11 የሰዓት ሰቆች ከዚህ ዳግም ጀምሬያለሁ።

እና ይህን ከጥቂት አመታት በፊት ሳደርግ፣ ከ2010 ጀምሮ ምናልባትም ከፖስትግሬስ ጋር ንቁ በሆነ የእጅ ስራ ላይ የተወሰነ እረፍት አግኝቻለሁ። የዲቢኤ የስራ ሂደት ምን ያህል እንደተለወጠ እና ምን ያህል የእጅ ሥራ አሁንም ጥቅም ላይ መዋል እንዳለበት አስገርሞኛል። እና እዚህ የሆነ ችግር እንዳለ ወዲያውኑ አሰብኩ, ሁሉንም ነገር በራስ ሰር ማድረግ አለብኝ.

እና ሁሉም ነገር ሩቅ ስለነበር, አብዛኛዎቹ ደንበኞች በደመና ውስጥ ነበሩ. እና ብዙ አስቀድሞ በራስ ሰር ተሰርቷል፣ ግልጽ ነው። በዚህ ላይ ተጨማሪ። ማለትም፣ ይህ ሁሉ በርካታ መሳሪያዎች ሊኖሩ ይገባል የሚለውን ሀሳብ አስከትሏል፣ ማለትም፣ ብዙ ቁጥር ያላቸው የውሂብ ጎታዎችን ማስተዳደር ይቻል ዘንድ ሁሉንም የ DBA ድርጊቶችን በራስ ሰር የሚሰራ አንድ አይነት መድረክ።

ይህ ሪፖርት የሚከተሉትን አያካትትም

• “የብር ጥይቶች” እና የመሳሰሉት መግለጫዎች - 8 ጂቢ ወይም 25% የተጋሩ_buffers ያዘጋጁ እና ደህና ይሆናሉ። ስለ የተጋሩ_buffers ብዙ ነገር አይኖርም።
• ሃርድኮር "ውስጣዊ"

ምን ይሆናል?

• እኛ የምንተገብራቸው እና የምናዳብረው የማመቻቸት መርሆዎች ይኖራሉ። በመንገዱ ላይ የሚነሱ ሁሉም አይነት ሃሳቦች እና በ Open Source ውስጥ በአብዛኛው የምንፈጥራቸው የተለያዩ መሳሪያዎች ይኖራሉ, ማለትም በክፍት ምንጭ ውስጥ መሰረት እናደርጋለን. በተጨማሪም ፣ ቲኬቶች አሉን ፣ ሁሉም ግንኙነቶች በተግባር ክፍት ምንጭ ናቸው። አሁን የምንሰራውን፣ በሚቀጥለው ልቀት ምን እንደሚሆን፣ ወዘተ ማየት ትችላለህ።
• በተጨማሪም እነዚህን መርሆዎች በመጠቀም አንዳንድ ልምድ ይኖራቸዋል, እነዚህ መሳሪያዎች በበርካታ ኩባንያዎች ውስጥ: ከትንሽ ጅምሮች እስከ ትላልቅ ኩባንያዎች.

ይህ ሁሉ እንዴት እያደገ ነው?

በመጀመሪያ የዲቢኤ ዋና ተግባር የአብነቶችን መፍጠር፣ የመጠባበቂያ ቅጂዎችን ማሰማራት እና የመሳሰሉትን ከማረጋገጥ በተጨማሪ ማነቆዎችን መፈለግ እና አፈፃፀሙን ማሳደግ ነው።

አሁን እንዲህ ተዘጋጅቷል። ክትትልን እንመለከታለን, አንድ ነገር እናያለን, ነገር ግን አንዳንድ ዝርዝሮች ይጎድለናል. የበለጠ በጥንቃቄ መቆፈር እንጀምራለን, ብዙውን ጊዜ በእጃችን, እና በአንድ ወይም በሌላ መንገድ ምን ማድረግ እንዳለብን እንረዳለን.

እና ሁለት አቀራረቦች አሉ. Pg_stat_statements ቀርፋፋ መጠይቆችን ለመለየት ነባሪ መፍትሄ ነው። እና pgBadgerን በመጠቀም የ Postgres ምዝግብ ማስታወሻዎች ትንተና።

እያንዳንዱ አቀራረብ ከባድ ድክመቶች አሉት. በመጀመሪያው አቀራረብ ሁሉንም መመዘኛዎች አውጥተናል. እና ቡድኖቹን ካየን * ከጠረጴዛው ውስጥ አምድ ከ "?" ወይም "$" ከ Postgres 10. ይህ የመረጃ ጠቋሚ ወይም የሴክ ስካን መሆኑን አናውቅም. በመለኪያው ላይ በጣም የተመካ ነው. እምብዛም ያልተገናኘን እሴት እዚያ ከተተኩ፣ የመረጃ ጠቋሚ ቅኝት ይሆናል። የሠንጠረዡን 90% የሚይዘው እሴት ከቀየሩ፣ የፖስትግሬስ ስታቲስቲክስን ስለሚያውቅ የሴኪው ፍተሻ ግልጽ ይሆናል። እና ይሄ ትልቅ የpg_stat_statements ጉድለት ነው፣ ምንም እንኳን አንዳንድ ስራዎች በመካሄድ ላይ ናቸው።

የሎግ ትንተና ትልቁ ጉዳቱ እንደ አንድ ደንብ "log_min_duration_statement = 0" መግዛት አለመቻል ነው። እና ስለዚህ ጉዳይ እንነጋገራለን. በዚህ መሠረት, ሙሉውን ምስል አያዩትም. እና በጣም ፈጣን የሆነ አንዳንድ መጠይቅ ከፍተኛ መጠን ያለው ሃብት ሊፈጅ ይችላል፣ነገር ግን ከመግቢያዎ በታች ስለሆነ አያዩትም።

ዲቢኤዎች የሚያገኟቸውን ችግሮች እንዴት ይፈታሉ?

ለምሳሌ, አንዳንድ ችግር አግኝተናል. ብዙውን ጊዜ ምን ይደረጋል? ገንቢ ከሆንክ አንዳንድ ጊዜ ተመሳሳይ መጠን የሌለው ነገር ታደርጋለህ። DBA ከሆንክ፣ እንግዲህ ዝግጅት አለህ። እና አንድ ብቻ ሊሆን ይችላል. እና ከስድስት ወር በኋላ ነበር. እና እርስዎ ወደ ምርት እንደሚሄዱ ያስባሉ. እና ልምድ ያካበቱ ዲቢኤዎች እንኳን ወደ ምርት፣ ብዜት ይፈትሹ። እና ጊዜያዊ ኢንዴክስ ሲፈጥሩ፣ የሚረዳው መሆኑን ያረጋግጡ፣ ይጥሉት እና ለገንቢዎች በስደት ፋይሎች ውስጥ እንዲያስቀምጡ ያደርጉታል። አሁን እየሆነ ያለው ይህ ዓይነቱ ከንቱ ነገር ነው። እና ይሄ ችግር ነው።

• ውቅሮችን ያስተካክሉ።
• የመረጃ ጠቋሚዎችን ስብስብ ያመቻቹ።
• የ SQL መጠይቁን እራሱ ይቀይሩ (ይህ በጣም አስቸጋሪው መንገድ ነው).
• አቅም ይጨምሩ (በአብዛኛዎቹ ጉዳዮች ቀላሉ መንገድ)።

በእነዚህ ነገሮች ላይ ብዙ ነገር አለ። በፖስትግሬስ ውስጥ ብዙ እጀታዎች አሉ። ለማወቅ ብዙ ነገር አለ። በፖስትግሬስ ውስጥ ብዙ ኢንዴክሶች አሉ፣ ለዚህ ​​ጉባኤ አዘጋጆችም ምስጋና ይድረሳቸው። እና ይሄ ሁሉ መታወቅ አለበት, እና ይህ DBA ያልሆኑ ሰዎች ጥቁር አስማትን እንደሚለማመዱ እንዲሰማቸው የሚያደርግ ነው. ይህ ሁሉ በተለምዶ ለመረዳት ለመጀመር ለ 10 ዓመታት ማጥናት ያስፈልግዎታል.

እናም እኔ ከዚህ ጥቁር አስማት ጋር ተዋጊ ነኝ። ቴክኖሎጂ እንዲኖር ሁሉንም ነገር ማድረግ እፈልጋለሁ, እና በዚህ ሁሉ ውስጥ ምንም ውስጣዊ ስሜት የለም.

የእውነተኛ ህይወት ምሳሌዎች

ይህንን የራሴን ጨምሮ ቢያንስ በሁለት ፕሮጀክቶች ውስጥ ተመልክቻለሁ። ሌላ የብሎግ ልጥፍ ለነባሪ_ስታቲስቲክስ_ዒላማ 1 ዋጋ ጥሩ እንደሆነ ይነግረናል። እሺ፣ በምርት ውስጥ እንሞክረው።

እና እዚህ ጋር, የእኛን መሳሪያ በመጠቀም ከሁለት አመት በኋላ, ዛሬ እየተነጋገርን ባለው የውሂብ ጎታ ላይ በተደረጉ ሙከራዎች እገዛ, ምን እንደነበረ እና ምን እንደ ሆነ ማወዳደር እንችላለን.

እና ለዚህ ሙከራ መፍጠር አለብን. አራት ክፍሎችን ያቀፈ ነው.

• የመጀመሪያው አካባቢ ነው. የሃርድዌር ቁራጭ እንፈልጋለን። እና ወደ አንዳንድ ኩባንያ መጥቼ ውል ስፈርም እንደ ምርት አይነት ሃርድዌር እንዲሰጡኝ እነግራቸዋለሁ። ለእያንዳንዳችሁ ጌቶች፣ እንደዚህ አይነት ሃርድዌር ቢያንስ አንድ ቁራጭ እፈልጋለሁ። ይህ በአማዞን ወይም በ Google ውስጥ ያለ ምናባዊ ማሽን ነው ፣ ወይም በትክክል ተመሳሳይ ሃርድዌር እፈልጋለሁ። ማለትም አካባቢውን እንደገና መፍጠር እፈልጋለሁ. እና በአካባቢ ጽንሰ-ሀሳብ ውስጥ ዋናውን የ Postgres ስሪት እናካትታለን።
• ሁለተኛው ክፍል የጥናታችን ዓላማ ነው። ይህ የመረጃ ቋት ነው። በበርካታ መንገዶች ሊፈጠር ይችላል. እንዴት እንደሆነ አሳይሃለሁ።
• ሦስተኛው ክፍል ጭነቱ ነው. ይህ በጣም አስቸጋሪው ጊዜ ነው።
• አራተኛው ክፍል ደግሞ የምንመረምረው ማለትም ከምን ጋር የምናወዳድረው ነው። በቅንጅቱ ውስጥ አንድ ወይም ከዚያ በላይ መለኪያዎች መለወጥ እንችላለን ወይም ኢንዴክስ መፍጠር እንችላለን እንበል ወዘተ.

ሙከራ እየጀመርን ነው። የpg_stat_ መግለጫዎች እነሆ። በግራ በኩል የሆነው ነገር ነው. በቀኝ በኩል - ምን እንደተከሰተ.

በግራ ነባሪ_ስታቲስቲክስ_ታርጌት = 100 ፣ በቀኝ =1 ይህ እንደረዳን እናያለን። በአጠቃላይ ሁሉም ነገር በ 000% ተሻሽሏል.

ወደ ታች ከተሸብልል ግን ከpgBadger ወይም ከpg_stat_statements የጥያቄ ቡድኖች ይኖራሉ። ሁለት አማራጮች አሉ። አንዳንድ ጥያቄ በ 88% ቀንሷል እናያለን. እና እዚህ የምህንድስና አቀራረብ ይመጣል. ለምን ሰመጠ ብለን ስለምንጠራጠር ውስጣችን የበለጠ መቆፈር እንችላለን። በስታቲስቲክስ ምን እንደተፈጠረ መረዳት ያስፈልግዎታል. በስታቲስቲክስ ውስጥ ብዙ ባልዲዎች ለምን ወደ መጥፎ ውጤቶች ይመራሉ ።

ወይም መቆፈር አንችልም ነገር ግን "ALTER TABLE ... ALTER COLUMN" ያድርጉ እና 100 ባልዲዎችን ወደዚህ አምድ ስታቲስቲክስ ይመልሱ። እና ከዚያ በሌላ ሙከራ ይህ ፕላስተር እንደረዳን ማረጋገጥ እንችላለን። ሁሉም። ይህ ትልቁን ምስል እንድናይ እና በውስጥ ላይ ሳይሆን በመረጃ ላይ የተመሰረተ ውሳኔ እንድናደርግ የሚረዳን የምህንድስና አካሄድ ነው።

ከሌሎች አካባቢዎች ጥቂት ምሳሌዎች። ለብዙ አመታት በፈተና ውስጥ የ CI ሙከራዎች ነበሩ. እና በትክክለኛው አእምሮ ውስጥ ያለ ማንኛውም ፕሮጀክት ያለ አውቶሜትድ ሙከራዎች አይኖርም።

በሌሎች ኢንዱስትሪዎች፡ በአቪዬሽን፣ በአውቶሞቲቭ ኢንዱስትሪ ውስጥ፣ ኤሮዳይናሚክስን ስንፈትሽ፣ ሙከራዎችንም ለማድረግ እድሉን አለን። አንድን ነገር ከሥዕል በቀጥታ ወደ ጠፈር አናስነሳም ወይም ወዲያውኑ መኪና ወደ ትራኩ አንሄድም። ለምሳሌ, የንፋስ ጉድጓድ አለ.

ከሌሎች ኢንዱስትሪዎች ምልከታ መደምደሚያ ላይ መድረስ እንችላለን.

በመጀመሪያ, ልዩ አካባቢ አለን. ወደ ምርት ቅርብ ነው, ግን ቅርብ አይደለም. ዋናው ባህሪው ርካሽ, ሊደገም የሚችል እና በተቻለ መጠን አውቶማቲክ መሆን አለበት. እንዲሁም ዝርዝር ትንተና ለማካሄድ ልዩ መሳሪያዎች ሊኖሩ ይገባል.

ምናልባትም፣ አውሮፕላን አስነሳን እና ስንበር፣ እያንዳንዱ ሚሊሜትር የክንፉን ወለል ለማጥናት በነፋስ መሿለኪያ ውስጥ ካለን ያነሰ እድል ይኖረናል። ተጨማሪ የመመርመሪያ መሳሪያዎች አሉን. በአየር ላይ አውሮፕላን ለማንሳት አቅም የሌላቸውን የበለጠ ከባድ ዕቃዎችን መሸከም እንችላለን። ከ Postgres ጋር ተመሳሳይ። በአንዳንድ አጋጣሚዎች በሙከራ ጊዜ ሙሉ የመጠይቅ ምዝግብ ማስታወሻን ማንቃት እንችላለን። እና ይህንን በምርት ውስጥ ማድረግ አንፈልግም. auto_explainን በመጠቀም ይህንን ለማንቃት እቅድ ልናወጣ እንችላለን።

እና እንዳልኩት፣ ከፍተኛ ደረጃ አውቶሜሽን ማለት ቁልፉን ተጭነን እንደግመዋለን ማለት ነው። ይህ መሆን ያለበት እንደዚህ ነው, ስለዚህ ብዙ ሙከራዎች እንዲኖሩ, በዥረት ላይ ነው.

ናንሲ CLI - “የውሂብ ጎታ ቤተ ሙከራ” መሠረት

እናም ይህን ነገር አደረግን. ማለትም፣ ስለእነዚህ ሃሳቦች የተናገርኩት በሰኔ ወር፣ ከአንድ አመት ገደማ በፊት ነው። እና ቀደም ሲል በክፍት ምንጭ ውስጥ ናንሲ CLI የሚባሉት አሉን። ይህ የመረጃ ቋት ላብራቶሪ ለመገንባት መሰረት ነው.

ናንሲ - በክፍት ምንጭ፣ በ Gitlab ላይ ነው። ሊሉት ይችላሉ, ሊሞክሩት ይችላሉ. በተንሸራታቾች ውስጥ አገናኝ አቅርቤያለሁ. በእሱ ላይ ጠቅ ማድረግ ይችላሉ እና እዚያ ይሆናል እርዳታ በሁሉም ረገድ.

በእርግጥ በልማት ላይ ገና ብዙ አለ። እዚያ ብዙ ሀሳቦች አሉ። ግን ይህ በየቀኑ ማለት ይቻላል የምንጠቀመው ነገር ነው። እና አንድ ሀሳብ ሲኖረን - ለምንድነው 40 መስመሮችን ስንሰርዝ ሁሉም ወደ IO ይወርዳል, ከዚያም አንድ ሙከራ ማድረጋችን እና ምን እንደተፈጠረ ለመረዳት በበለጠ ዝርዝር ሁኔታ ለማየት እና በጉዞ ላይ ለማስተካከል እንሞክራለን. ማለትም አንድ ሙከራ እያደረግን ነው። ለምሳሌ, የሆነ ነገር እናስተካክላለን እና በመጨረሻ ምን እንደሚከሰት እንመለከታለን. እና ይህንን በምርት ውስጥ አናደርግም. የሃሳቡ ፍሬ ነገር ይህ ነው።

ይህ የት ሊሠራ ይችላል? ይህ በአካባቢው ሊሠራ ይችላል, ማለትም በማንኛውም ቦታ ሊያደርጉት ይችላሉ, እንዲያውም በ MacBook ላይ ማስኬድ ይችላሉ. ዶከር እንፈልጋለን፣ እንሂድ። ይኼው ነው. በአንዳንድ ሁኔታዎች በሃርድዌር ላይ ወይም በምናባዊ ማሽን ውስጥ በማንኛውም ቦታ ማሄድ ይችላሉ።

እና በአማዞን ውስጥ በ EC2 ለምሳሌ ፣ በቦታዎች ውስጥ በርቀት የመሮጥ እድሉም አለ። እና ይህ በጣም ጥሩ እድል ነው. ለምሳሌ፣ ትላንትና ከ500 በላይ ሙከራዎችን በ i3 አብነት አድርገናል፣ ከትንሹ ጀምሮ እና በ i3-16-xlarge ያበቃል። እና 500 ሙከራዎች 64 ዶላር አውጥተውልናል። እያንዳንዳቸው 15 ደቂቃዎች ቆዩ. ያም ማለት, ነጠብጣቦች እዚያ ጥቅም ላይ በመዋላቸው, በጣም ርካሽ ነው - የ 70% ቅናሽ, የአማዞን በሰከንድ ክፍያ. ብዙ ማድረግ ትችላለህ። እውነተኛ ምርምር ማድረግ ይችላሉ.

እና ሶስት ዋና ዋና የ Postgres ስሪቶች ይደገፋሉ። አንዳንድ አሮጌዎችን እና አዲሱን 12 ኛ እትም ለመጨረስ በጣም አስቸጋሪ አይደለም.

አንድን ነገር በሦስት መንገዶች መግለፅ እንችላለን። ይህ፡-

• መጣል/ስኩዌር ፋይል።
• ዋናው መንገድ የPGDATA ማውጫን መዝጋት ነው። እንደ አንድ ደንብ, ከመጠባበቂያ አገልጋይ ይወሰዳል. የተለመዱ ሁለትዮሽ መጠባበቂያዎች ካሉዎት, ከዚያ ክሎኖችን ማድረግ ይችላሉ. ደመና ካለህ እንደ Amazon እና Google ያለ የደመና ቢሮ ይህን ያደርግልሃል። ይህ እውነተኛ ምርትን ለማቃለል በጣም አስፈላጊው መንገድ ነው. የምንገለጥበት መንገድ እንደዚህ ነው።
• እና የመጨረሻው ዘዴ በ Postgres ውስጥ አንድ ነገር እንዴት እንደሚሰራ ለመረዳት ሲፈልጉ ለምርምር ተስማሚ ነው. ይህ pgbench ነው. pgbench በመጠቀም ማመንጨት ይችላሉ። አንድ "db-pgbench" አማራጭ ብቻ ነው። ምን ሚዛን ይነግሩታል. እና ሁሉም ነገር እንደተገለጸው በደመና ውስጥ ይፈጠራል.

እና ጭነት:

• ጭነቱን በአንድ SQL ክር ውስጥ ማከናወን እንችላለን. ይህ በጣም ጥንታዊው መንገድ ነው.
• እና ጭነቱን መኮረጅ እንችላለን. እና ከሁሉም በፊት በሚከተለው መንገድ ልንመስለው እንችላለን. ሁሉንም ምዝግብ ማስታወሻዎች መሰብሰብ አለብን. እና ያማል። ለምን እንደሆነ አሳይሃለሁ። እና pgreplay ን በመጠቀም እንጫወታለን፣ እሱም በናንሲ ውስጥ የተገነባ።
• ወይም ሌላ አማራጭ። በተወሰነ ጥረት የምናደርገው የእጅ ሥራ ጭነት ተብሎ የሚጠራው. በጦርነቱ ስርዓት ላይ ያለን ጭነት በመተንተን, ከፍተኛ የጥያቄ ቡድኖችን እናወጣለን. እና pgbench ን በመጠቀም ይህንን ጭነት በቤተ ሙከራ ውስጥ መኮረጅ እንችላለን።

• ወይም አንድ ዓይነት SQL ን ማከናወን አለብን ፣ ማለትም አንድ ዓይነት ፍልሰትን እንፈትሻለን ፣ እዚያ ኢንዴክስ እንፈጥራለን ፣ እዚያ አናላዜን ያስፈጽማሉ። እና ከቫክዩም በፊት እና ከቫኩም በኋላ የሆነውን እንመለከታለን. በአጠቃላይ, ማንኛውም SQL.
• በማዋቀር ውስጥ አንድ ወይም ከዚያ በላይ መለኪያዎችን እንለውጣለን. ለምሳሌ 100 እሴቶችን በአማዞን ውስጥ ለቴራባይት የውሂብ ጎታችን እንድንፈትሽ ልንነግረን እንችላለን። እና በጥቂት ሰዓታት ውስጥ ውጤቱን ያገኛሉ. እንደ ደንቡ የቴራባይት ዳታቤዝ ለማሰማራት ብዙ ሰአታት ይወስዳል። ነገር ግን በእድገት ላይ አንድ ጠጋኝ አለ ፣ ተከታታይ ሊሆኑ የሚችሉ አሉን ፣ ማለትም በተመሳሳይ አገልጋይ ላይ ያለማቋረጥ ተመሳሳይ pgdata መጠቀም እና ማረጋገጥ ይችላሉ። Postgres እንደገና ይጀመራል እና መሸጎጫዎች እንደገና ይጀመራሉ። እና ጭነቱን መንዳት ይችላሉ.

• ከpg ቅጽበተ ፎቶዎች ጀምሮ የተለያዩ ፋይሎችን የያዘ ማውጫ ይመጣልሁኔታ***. እና በጣም የሚያስደስት ነገር pg_stat_statements፣ pg_stat_kcacke አለ። እነዚህ ጥያቄዎችን የሚተነትኑ ሁለት ቅጥያዎች ናቸው። እና pg_stat_bgwriter የpgwriter ስታቲስቲክስን ብቻ ሳይሆን በፍተሻ ነጥብ ላይ እና ደጋፊዎቹ ራሳቸው የቆሸሹ ቋቶችን እንዴት እንደሚያፈናቅሉም ይዟል። እና ማየት ሁሉ አስደሳች ነው። ለምሳሌ የተጋሩ_ማቋቋሚያዎችን ስናዘጋጅ፣ ሁሉም ሰው ምን ያህል እንደተተካ ማየት በጣም አስደሳች ነው።
• የፖስትግሬስ ምዝግብ ማስታወሻዎችም እየደረሱ ነው። ሁለት ምዝግብ ማስታወሻዎች - የዝግጅት ምዝግብ ማስታወሻ እና የመልሶ ማጫወት መዝገብ.
• በአንጻራዊ ሁኔታ አዲስ ባህሪ FlameGraphs ነው።
• እንዲሁም ጭነቱን ለመጫወት pgreplay ወይም pgbench አማራጮችን ከተጠቀሙ ውጤታቸው ቤተኛ ይሆናል። እና መዘግየት እና TPS ያያሉ። እንዴት እንዳዩት መረዳት የሚቻል ይሆናል።
• የስርዓት መረጃ.
• መሰረታዊ ሲፒዩ እና IO ቼኮች። ይህ በአማዞን ውስጥ ለ EC2 ምሳሌ የበለጠ ነው ፣ 100 ተመሳሳይ ምሳሌዎችን በክር ውስጥ ለማስጀመር እና 100 የተለያዩ ሩጫዎችን እዚያ ለማስኬድ ሲፈልጉ 10 ሙከራዎች ይኖርዎታል። እና ቀድሞውኑ በአንድ ሰው እየተጨቆነ ያለው ጉድለት ያለበትን ሁኔታ እንዳያጋጥሙዎት ማረጋገጥ አለብዎት. ሌሎች በዚህ የሃርድዌር ቁራጭ ላይ ንቁ ናቸው እና ትንሽ የቀረህ ሃብት ይኖርሃል። እንደነዚህ ያሉትን ውጤቶች መጣል የተሻለ ነው. እና በ sysbench ከ Alexey Kopytov እርዳታ የሚመጡ ብዙ አጫጭር ቼኮችን እናደርጋለን እና ከሌሎች ጋር ሊመሳሰሉ ይችላሉ, ማለትም ሲፒዩ እንዴት እንደሚሰራ እና IO እንዴት እንደሚሰራ ይገነዘባሉ.

በተለያዩ ኩባንያዎች ምሳሌ ላይ የተመሰረቱ ቴክኒካዊ ችግሮች ምንድ ናቸው?

ምዝግብ ማስታወሻዎችን በመጠቀም እውነተኛውን ጭነት መድገም እንፈልጋለን እንበል. በ Open Source pgreplay ላይ ከተጻፈ በጣም ጥሩ ሀሳብ ነው። እንጠቀማለን. ነገር ግን በጥሩ ሁኔታ እንዲሰራ ሙሉ የጥያቄ ምዝግብ ማስታወሻን ከግቤቶች እና ጊዜ ጋር ማንቃት አለብዎት።

ከቆይታ እና የጊዜ ማህተም ጋር አንዳንድ ውስብስቦች አሉ። ይህንን ወጥ ቤት በሙሉ ባዶ እናደርጋለን። ዋናው ጥያቄ እርስዎ ሊገዙት ይችላሉ ወይስ አይችሉም?

https://gist.github.com/NikolayS/08d9b7b4845371d03e195a8d8df43408

ችግሩ ምናልባት ላይገኝ ይችላል። በመጀመሪያ ደረጃ, ምን ዥረት ወደ ምዝግብ ማስታወሻው ላይ እንደሚጻፍ መረዳት አለብዎት. pg_stat_statements ካልዎት፣ በሰከንድ ምን ያህል ባይት እንደሚፃፍ ለመረዳት ይህንን መጠይቅ መጠቀም ይችላሉ (አገናኙ በስላይድ ውስጥ ይገኛል)።

የጥያቄውን ርዝመት እንመለከታለን. ምንም መመዘኛዎች አለመኖራቸውን ችላ እያልን ነው, ነገር ግን የጥያቄውን ርዝመት እናውቃለን እና በሰከንድ ስንት ጊዜ እንደተፈጸመ እናውቃለን. በዚህ መንገድ በሰከንድ ምን ያህል ባይት በግምት መገመት እንችላለን። ስህተትን በእጥፍ ልንሰራ እንችላለን፣ ግን በእርግጠኝነት በዚህ መንገድ ትዕዛዙን እንረዳለን።

ይህ ጥያቄ በሰከንድ 802 ጊዜ ሲፈጸም ማየት እንችላለን። እና ባይት_በሴኮንድ – 300 ኪባ/ሰ ሲደመር ወይም ሲቀነስ አይተናል። እና እንደ አንድ ደንብ, እንዲህ አይነት ፍሰትን መግዛት እንችላለን.

ግን! እውነታው ግን የተለያዩ የምዝግብ ማስታወሻዎች ስርዓቶች አሉ. እና የሰዎች ነባሪ አብዛኛውን ጊዜ "syslog" ነው.

እና syslog ካለዎት, እንደዚህ አይነት ምስል ሊኖርዎት ይችላል. pgbench ን እንወስዳለን፣ የጥያቄ ምዝግብ ማስታወሻን እናነቃለን እና ምን እንደተፈጠረ እንመለከታለን።

ሳይገቡ - ይህ በግራ በኩል ያለው አምድ ነው. 161 TPS አግኝተናል። በ syslog - ይህ በኡቡንቱ 000 Amazon ላይ ነው, 16.04 TPS እናገኛለን. እና ወደ ሌሎች ሁለት የመመዝገቢያ ዘዴዎች ከቀየርን, ሁኔታው ​​​​በጣም የተሻለ ነው. ይወርዳል ብለን ጠብቀን ነበር ግን በተመሳሳይ መጠን።

እና በ CentOS 7 ላይ፣ ጆርናልድ በሚሳተፍበት፣ ምዝግብ ማስታወሻዎችን ወደ ሁለትዮሽ ቅርጸት ለቀላል ፍለጋ ወዘተ.፣ ከዚያ እዚያ ቅዠት ነው፣ በ TPS ውስጥ 44 ጊዜ እንጥላለን።

እና ሰዎች የሚኖሩት ይህ ነው። እና ብዙ ጊዜ በኩባንያዎች, በተለይም ትላልቅ, ይህ ለመለወጥ በጣም አስቸጋሪ ነው. ከ syslog ማምለጥ ከቻላችሁ እባኮትን ከሱ ራቁ።

• IOPSን ይገምግሙ እና ፍሰት ይፃፉ።
• የምዝግብ ማስታወሻ ስርዓትዎን ያረጋግጡ።
• የታቀደው ጭነት ከመጠን በላይ ትልቅ ከሆነ, ናሙናዎችን ያስቡ.

pg_stat_statements አሉን። እንዳልኩት እዚያ መሆን አለበት። እናም እያንዳንዱን የጥያቄ ቡድን በልዩ መንገድ በፋይል ወስደን መግለፅ እንችላለን። እና ከዚያ በ pgbench ውስጥ በጣም ምቹ የሆነ ባህሪን መጠቀም እንችላለን - ይህ የ “-f” አማራጭን በመጠቀም ብዙ ፋይሎችን የማስገባት ችሎታ ነው።

ብዙ "-f" ይረዳል. እና እያንዳንዱ ፋይል ምን ድርሻ ሊኖረው እንደሚገባ በመጨረሻ በ "@" እገዛ መንገር ይችላሉ። ይህ ማለት በ 10% ከሚሆኑት ጉዳዮች እና ይህንን በ 20% ውስጥ ያድርጉት ማለት እንችላለን. ይህ ደግሞ በምርት ላይ ወደምናየው ነገር ያቀርበናል።

በምርት ውስጥ ያለንን እንዴት እንረዳለን? ምን ድርሻ እና እንዴት? ይህ ትንሽ ወደ ጎን ነው. አንድ ተጨማሪ ምርት አለን postgres-ቼክ. እንዲሁም በክፍት ምንጭ ውስጥ መሠረት። እና አሁን በንቃት እያዳበርነው ነው።

የተወለደው በተለያየ ምክንያት ነው. ክትትል በቂ ስላልሆነ። ይኸውም መጥተህ መሰረቱን ተመልከት፣ ያሉትን ችግሮች ተመልከት። እና፣ እንደ አንድ ደንብ፣ የጤና_ቼክ ታደርጋለህ። ልምድ ያለው DBA ከሆንክ የጤና_ቼክ ታደርጋለህ። እኛ ኢንዴክሶች አጠቃቀም ተመልክተናል, ወዘተ. OKmeter ካለዎት, ከዚያም በጣም ጥሩ. ይህ ለ Postgres ጥሩ ክትትል ነው። OKmeter.io - እባክዎን ይጫኑት, ሁሉም ነገር እዚያ በደንብ ተከናውኗል. ተከፍሏል።

ከሌለህ ብዙውን ጊዜ ብዙ የለህም ማለት ነው። በክትትል ውስጥ፣ አብዛኛውን ጊዜ ሲፒዩ፣ IO፣ እና ከዚያ ከተያዙ ቦታዎች ጋር አለ፣ እና ያ ብቻ ነው። እና ተጨማሪ እንፈልጋለን. አውቶቫክዩም እንዴት እንደሚሰራ, የፍተሻ ነጥቡ እንዴት እንደሚሰራ, io ውስጥ የፍተሻ ነጥቡን ከ bgwriter እና ከጀርባው ወዘተ መለየት አለብን.

ችግሩ አንድ ትልቅ ኩባንያ ሲረዱ አንድ ነገር በፍጥነት መተግበር አይችሉም. OKmeter በፍጥነት መግዛት አይችሉም. ምናልባት በስድስት ወራት ውስጥ ይገዙ ይሆናል. አንዳንድ ጥቅሎችን በፍጥነት ማድረስ አይችሉም።

እና ምንም ነገር መጫን የማይፈልግ ልዩ መሳሪያ ያስፈልገናል የሚል ሀሳብ አመጣን, ማለትም በምርት ላይ ምንም ነገር መጫን የለብዎትም. በላፕቶፕህ ላይ ጫን፣ ወይም ከምትሰራበት ቦታ ሆኖ ታዛቢ አገልጋይ ላይ ጫን። እና ብዙ ነገሮችን ይተነትናል-ስርዓተ ክወናው ፣ የፋይል ስርዓቱ እና ፖስትግሬስ ራሱ ፣ በቀጥታ ወደ ምርት ሊሄዱ የሚችሉ አንዳንድ ቀላል ጥያቄዎችን ያዘጋጃል እና ምንም ነገር አይሳካም።

Postgres-checkup ብለነዋል። በሕክምና ረገድ ይህ መደበኛ የጤና ምርመራ ነው። አውቶሞቲቭ-ገጽታ ከሆነ፣ ልክ እንደ ጥገና ነው። እንደ የምርት ስሙ በየስድስት ወሩ ወይም በዓመት በመኪናዎ ላይ ጥገና ያደርጋሉ። ለመሠረትዎ ጥገና ያደርጋሉ? ያም ማለት በየጊዜው ጥልቅ ምርምር ታደርጋለህ? መደረግ አለበት። ምትኬዎችን ካደረጉ, ከዚያም ፍተሻ ያድርጉ, ይህ ያነሰ አስፈላጊ አይደለም.

እና እንደዚህ አይነት መሳሪያ አለን. ከሦስት ወራት በፊት በንቃት ብቅ ማለት ጀመረ. እሱ ገና ወጣት ነው ፣ ግን እዚያ ብዙ አለ።

በጣም “ተጽዕኖ ፈጣሪ” የጥያቄ ቡድኖችን መሰብሰብ - በ Postgres-checkup ውስጥ K003 ሪፖርት ያድርጉ

እና የሪፖርቶች ቡድን K. ሶስት ሪፖርቶች እስካሁን አሉ. እና እንደዚህ ያለ ሪፖርት K003 አለ. በጠቅላላ_ሰዓት የተደረደሩ ከpg_stat_statements ከፍተኛ አለ።

የጥያቄ ቡድኖችን በጠቅላላ_ሰዓት ስንለይ ፣ላይኛው ላይ ስርዓታችንን በብዛት የሚጭን ቡድን እናያለን ፣ማለትም ተጨማሪ ሀብቶችን የሚወስድ። ለምንድነው የጥያቄ ቡድኖችን ስም የምሰጠው? መለኪያዎችን ስለጣልን. እነዚህ ከአሁን በኋላ ጥያቄዎች አይደሉም፣ ነገር ግን የጥያቄዎች ቡድኖች፣ ማለትም እነሱ ረቂቅ ናቸው።

እና ከላይ ወደ ታች ከተመቻቸን ሀብታችንን እናቃለን እና ማሻሻል ያለብንን ጊዜ እናዘገያለን። ይህ ገንዘብን ለመቆጠብ በጣም ጥሩ መንገድ ነው.

ምናልባት ይህ ተጠቃሚዎችን ለመንከባከብ በጣም ጥሩ መንገድ ላይሆን ይችላል ፣ ምክንያቱም እኛ ብርቅዬ ላናይ እንችላለን ፣ ግን አንድ ሰው 15 ሰከንድ የጠበቀ በጣም የሚያበሳጩ ጉዳዮች። በጠቅላላው, እኛ አናያቸውም, እነሱ በጣም ጥቂት ናቸው, ነገር ግን ከሀብቶች ጋር እየተገናኘን ነው.

በዚህ ሠንጠረዥ ውስጥ ምን ሆነ? ሁለት ቅጽበተ-ፎቶዎችን ወስደናል. Postgres_checkup ለእያንዳንዱ ልኬት ዴልታ ይሰጥዎታል፡ ጠቅላላ ጊዜ፣ ጥሪዎች፣ ረድፎች፣ የተጋሩ_blks_read፣ ወዘተ። ያ ነው፣ ዴልታው የተሰላ ነው። በpg_stat_statements ላይ ያለው ትልቁ ችግር ዳግም እንደተጀመረ አለማስታወስ ነው። pg_stat_database የሚያስታውስ ከሆነ pg_stat_statements አያስታውስም። 1 ቁጥር እንዳለ ታያለህ ነገርግን ከየት እንደቆጠርን አናውቅም።

እና እዚህ እናውቃለን, እዚህ ሁለት ቅጽበተ-ፎቶዎች አሉን. በዚህ ጉዳይ ላይ ያለው ዴልታ 56 ሴኮንድ እንደነበረ እናውቃለን. በጣም አጭር ክፍተት. በጠቅላላ_ጊዜ ተደርድሯል። እና ከዚያ መለየት እንችላለን, ማለትም ሁሉንም መለኪያዎች በቆይታ እንከፋፍላለን. እያንዳንዱን መለኪያ በቆይታ ካካፈልን በሴኮንድ የጥሪዎች ብዛት ይኖረናል።

በመቀጠል፣ ጠቅላላ_ጊዜ በሰከንድ የእኔ ተወዳጅ መለኪያ ነው። የሚለካው በሴኮንዶች፣ በሴኮንድ ነው፣ ማለትም ይህን የጥያቄዎች ቡድን በሰከንድ ለማስፈጸም ስንት ሴኮንድ እንደፈጀበት ነው። እዚያ በሰከንድ ከአንድ ሰከንድ በላይ ካየህ ከአንድ በላይ ኮር መስጠት ነበረብህ ማለት ነው። ይህ በጣም ጥሩ መለኪያ ነው. ይህ ጓደኛ, ለምሳሌ, ቢያንስ ሶስት ኮርሞች እንደሚያስፈልገው መረዳት ይችላሉ.

ይህ የእኛ እውቀት ነው, የትም ቦታ አይቼ አላውቅም. እባክዎን ያስተውሉ - ይህ በጣም ቀላል ነገር ነው - በሰከንድ ሰከንድ. አንዳንድ ጊዜ፣ የእርስዎ ሲፒዩ 100%፣ ከዚያም ግማሽ ሰአት በሰከንድ፣ ማለትም፣ እነዚህን ጥያቄዎች ብቻ ለማድረግ ግማሽ ሰአት አሳልፈዋል።

በመቀጠል በሰከንድ ረድፎችን እናያለን. በሰከንድ ስንት ረድፎች እንደተመለሰ እናውቃለን።

እና ከዚያ ደግሞ አንድ አስደሳች ነገር አለ. ስንት የተጋሩ_buffers ከራሱ ከተጋራው_buffers በሴኮንድ እናነባለን። ስኬቶች ቀድሞውኑ ነበሩ, እና ረድፎቹን ከስርዓተ ክወናው መሸጎጫ ወይም ከዲስክ ወስደናል. የመጀመሪያው አማራጭ ፈጣን ነው, ሁለተኛው ደግሞ እንደ ሁኔታው ​​ፈጣን ሊሆን ይችላል ወይም ላይሆን ይችላል.

እና ሁለተኛው የልዩነት መንገድ በዚህ ቡድን ውስጥ ያሉትን የጥያቄዎች ብዛት መከፋፈል ነው። በሁለተኛው አምድ ውስጥ ሁል ጊዜ አንድ መጠይቅ በአንድ መጠይቅ ይከፈላል ። እና ከዚያ አስደሳች ነው - በዚህ ጥያቄ ውስጥ ስንት ሚሊሰከንዶች ነበሩ። ይህ መጠይቅ በአማካይ እንዴት እንደሚሠራ እናውቃለን። ለእያንዳንዱ ጥያቄ 101 ሚሊሰከንድ ያስፈልጋል። ይህ ልንገነዘበው የሚገባን ባህላዊ መለኪያ ነው።

እያንዳንዱ መጠይቅ በአማካይ ስንት ረድፎች ተመልሷል? ይህ ቡድን 8 ሲመለስ እናያለን። በአማካይ ምን ያህል ከመሸጎጫው ተወስዶ ተነቧል። ሁሉም ነገር በጥሩ ሁኔታ እንደተሸጎጠ እናያለን። ለመጀመሪያው ቡድን ጠንካራ ምቶች።

እና በእያንዳንዱ መስመር ውስጥ ያለው አራተኛው ንዑስ ሕብረቁምፊ ከጠቅላላው ምን ያህል መቶኛ ነው። ጥሪዎች አሉን። 1 እንበል።እናም ይህ ቡድን የሚያበረክተውን አስተዋጽኦ መረዳት እንችላለን። በዚህ ሁኔታ ውስጥ የመጀመሪያው ቡድን ከ 000% ያነሰ አስተዋፅኦ እንዳለው እናያለን. ማለትም፡ በጣም ቀርፋፋ ከመሆኑ የተነሳ በአጠቃላይ ምስል ላይ እንዳናየው ነው። እና ሁለተኛው ቡድን በጥሪዎች ላይ 000% ነው. ያም ማለት ከሁሉም ጥሪዎች 0,01% ሁለተኛው ቡድን ናቸው.

ጠቅላላ_ጊዜ እንዲሁ አስደሳች ነው። በመጀመሪያው የጥያቄዎች ቡድን ላይ ከጠቅላላ የስራ ሰዓታችን 14% አሳልፈናል። እና ለሁለተኛው - 11%, ወዘተ.

ወደ ዝርዝር ጉዳዮች አልገባም ፣ ግን እዚያ ውስጥ ረቂቅ ነገሮች አሉ። ስህተትን ከላይ እናሳያለን፣ ምክንያቱም ስናወዳድር፣ ቅጽበተ-ፎቶዎች ሊንሳፈፉ ይችላሉ፣ ማለትም፣ አንዳንድ ጥያቄዎች ሊወድቁ እና በሁለተኛው ውስጥ ሊገኙ አይችሉም፣ አንዳንድ አዳዲሶች ግን ሊታዩ ይችላሉ። እና እዚያ ስህተቱን እናሰላለን. 0 ካየህ ያ ጥሩ ነው። ምንም ስህተቶች የሉም. የስህተት መጠኑ እስከ 20% ከሆነ፣ ምንም ችግር የለውም።

ከዚያም ወደ ርዕሳችን እንመለሳለን. የሥራ ጫና መፍጠር አለብን. ከላይ ወደ ታች ወስደን 80% ወይም 90% እስክንደርስ ድረስ እንሄዳለን. ብዙውን ጊዜ ይህ ከ10-20 ቡድኖች ነው. እና ለ pgbench ፋይሎችን እንሰራለን. እኛ እዚያ በዘፈቀደ እንጠቀማለን. አንዳንድ ጊዜ ይህ, በሚያሳዝን ሁኔታ, አይሰራም. እና በ Postgres 12 ይህን አካሄድ ለመጠቀም ብዙ እድሎች ይኖራሉ።

እና ከዚያ በዚህ መንገድ በጠቅላላ_ጊዜ ከ80-90% እናተርፋለን። ከ "@" በኋላ ምን ማስቀመጥ አለብኝ? ጥሪዎችን እንመለከታለን, ምን ያህል ወለድ እንዳለ እንመለከታለን እና እዚህ ብዙ ወለድ እንዳለን እንረዳለን. ከእነዚህ መቶኛዎች እያንዳንዱን ፋይሎች እንዴት ማመጣጠን እንደሚቻል እንረዳለን። ከዚያ በኋላ pgbench እንጠቀማለን እና ወደ ሥራ እንሄዳለን.

እኛ ደግሞ K001 እና K002 አሉን።

K001 አራት ንኡስ ሕብረቁምፊዎች ያሉት አንድ ትልቅ ሕብረቁምፊ ነው። ይህ የሙሉ ሸክማችን ባህሪ ነው። ሁለተኛውን ዓምድ እና ሁለተኛውን የግርጌ ክፍል ይመልከቱ። በሴኮንድ አንድ ተኩል ሰከንድ ያህል, ማለትም ሁለት ኮርሶች ካሉ, ከዚያም ጥሩ ይሆናል. በግምት 75% አቅም ይኖረዋል። እና እንደዚህ ይሰራል. 10 ኮሮች ካሉን, በአጠቃላይ እንረጋጋለን. በዚህ መንገድ ሀብቶችን መገምገም እንችላለን.

K002 የመጠይቅ ክፍል የምለው ነው፣ ማለትም ምረጥ፣ አስገባ፣ አዘምን፣ ሰርዝ። እና ለማዘመን በተናጠል ምረጥ፣ ምክንያቱም መቆለፊያ ነው።

እና እዚህ SELECT ተራ አንባቢ ነው ብለን መደምደም እንችላለን - ከሁሉም ጥሪዎች 82% ፣ ግን በተመሳሳይ ጊዜ - 74% በጠቅላላ_ሰዓት። ያም ማለት ብዙ ተብለው ይጠራሉ, ግን አነስተኛ ሀብቶችን ይበላሉ.

እና ወደሚለው ጥያቄ እንመለሳለን፡-“እንዴት ትክክለኛዎቹን የተጋሩ_ማቋቋሚያዎች መምረጥ እንችላለን?” አብዛኛው ማመሳከሪያዎች በሃሳቡ ላይ የተመሰረቱ መሆናቸውን አስተውያለሁ - ውጤቱ ምን እንደሚሆን ማለትም ውጤቱ ምን እንደሚሆን እንይ። ብዙውን ጊዜ የሚለካው በ TPS ወይም QPS ነው።

እና በተቻለ መጠን ብዙ ግብይቶችን በሰከንድ ከመኪናው ውስጥ የማስተካከያ መለኪያዎችን በመጠቀም ለማውጣት እንሞክራለን። እዚህ በትክክል 311 በሰከንድ ለመምረጥ ነው።

ነገር ግን ወደ ስራ እና በሙሉ ፍጥነት የሚነዳ ማንም የለም። ይህ ሞኝነት ነው። ከመረጃ ቋቶች ጋር ተመሳሳይ ነው። በሙሉ ፍጥነት ማሽከርከር የለብንም ፣ እና ማንም አያደርገውም። 100% ሲፒዩ ባለው ምርት ውስጥ የሚኖር ማንም የለም። ምንም እንኳን, ምናልባት አንድ ሰው ይኖራል, ግን ይህ ጥሩ አይደለም.

ሀሳቡ ብዙውን ጊዜ የምንነዳው በ 20 በመቶ አቅም ነው ፣ በተለይም ከ 50% ያልበለጠ ነው። እና ከሁሉም በላይ ለተጠቃሚዎቻችን የምላሽ ጊዜን ለማመቻቸት እንሞክራለን። ማለትም፣ በ20% ፍጥነት ዝቅተኛ መዘግየት እንዲኖር፣ ሁኔታዊ በሆነ ሁኔታ የእኛን ቁልፎች ማዞር አለብን። ይህ በሙከራዎቻችን ልንጠቀምበት የምንሞክረው ሀሳብ ነው።

እና በመጨረሻም, ምክሮች:

• የውሂብ ጎታ ቤተ ሙከራን ማድረግዎን እርግጠኛ ይሁኑ.
• ከተቻለ ለተወሰነ ጊዜ እንዲገለጥ በፍላጎት ያድርጉት - ይጫወቱ እና ይጣሉት። ደመናዎች ካሉዎት, ይህ ሳይናገር ይሄዳል, ማለትም ብዙ አቋም ይኑርዎት.
• ጉጉ ሁን። እና የሆነ ነገር ከተሳሳተ, ከዚያም እንዴት እንደሚሠራ በሙከራዎች ይፈትሹ. ናንሲ መሰረቱ እንዴት እንደሚሰራ ለመፈተሽ እራስዎን ለማሰልጠን መጠቀም ይችላሉ።
• እና ዝቅተኛውን የምላሽ ጊዜ ዓላማ ያድርጉ።
• እና የፖስትግሬስ ምንጮችን አትፍሩ። ከምንጮች ጋር ስትሰራ እንግሊዝኛ ማወቅ አለብህ። እዚያ ብዙ አስተያየቶች አሉ, ሁሉም ነገር እዚያ ተብራርቷል.
• እና የመረጃ ቋቱን ጤና በየጊዜው፣ ቢያንስ በየሶስት ወሩ አንድ ጊዜ፣ በእጅ ወይም Postgres-checkup ይመልከቱ።

ጥያቄዎች

በጣም አመግናለሁ! በጣም ደስ የሚል ነገር።

ሁለት ቁራጭ.

አዎ, ሁለት ቁርጥራጮች. እኔ ብቻ በደንብ አልገባኝም። እኔና ናንሲ ስንሠራ አንድ መለኪያ ብቻ ወይም ሙሉ ቡድን ማስተካከል እንችላለን?

የዴልታ ውቅረት መለኪያ አለን። የፈለጉትን ያህል በአንድ ጊዜ ወደዚያ ማዞር ይችላሉ። ነገር ግን ብዙ ነገሮችን በምትቀይርበት ጊዜ የተሳሳተ መደምደሚያ ላይ መድረስ እንደምትችል መረዳት አለብህ.

አዎ. ለምን ጠየቅኩት? ምክንያቱም አንድ መለኪያ ብቻ ሲኖርዎት ሙከራዎችን ማካሄድ ከባድ ነው። አጥብቀውታል፣ እንዴት እንደሚሰራ ይመልከቱ። አወጣሁት። ከዚያ የሚቀጥለውን ይጀምራሉ.

በተመሳሳይ ጊዜ ማጠንጠን ይችላሉ, ግን እንደ ሁኔታው ​​ይወሰናል, በእርግጥ. ግን አንድ ሀሳብ መሞከር የተሻለ ነው. ትናንት አንድ ሀሳብ ነበረን። በጣም ቅርብ የሆነ ሁኔታ ነበረን. ሁለት አወቃቀሮች ነበሩ። እና ለምን ትልቅ ልዩነት እንዳለ ሊገባን አልቻለም። እና ያለማቋረጥ ለመረዳት እና ልዩነቱ ምን እንደሆነ ለማወቅ ዲኮቶሚ መጠቀም ያስፈልግዎታል የሚል ሀሳብ ተነሳ። ወዲያውኑ ግማሹን ግማሹን አንድ አይነት, ከዚያም ሩብ, ወዘተ ማድረግ ይችላሉ ሁሉም ነገር ተለዋዋጭ ነው.

እና አንድ ተጨማሪ ጥያቄ አለ. ፕሮጀክቱ ወጣት እና እያደገ ነው. ሰነዱ ቀድሞውኑ ዝግጁ ነው ፣ ዝርዝር መግለጫ አለ?

እኔ በተለይ ወደ ግቤቶች መግለጫ እዚያ አገናኝ ሠራሁ። እዚያ ነው. ግን ብዙ ነገሮች እስካሁን የሉም። ተመሳሳይ አስተሳሰብ ያላቸውን ሰዎች እየፈለግኩ ነው። እና ስጫወት አገኛቸዋለሁ። ይህ በጣም አሪፍ ነው። አንድ ሰው አስቀድሞ ከእኔ ጋር እየሰራ ነው፣ አንድ ሰው ረድቶ እዚያ የሆነ ነገር አድርጓል። እና በዚህ ርዕስ ላይ ፍላጎት ካሎት, የጎደለውን ነገር አስተያየት ይስጡ.

ላቦራቶሪውን ከገነባን በኋላ ምናልባት አስተያየት ሊኖር ይችላል. እስኪ እናያለን. አመሰግናለሁ!

ሀሎ! ለሪፖርቱ እናመሰግናለን! የአማዞን ድጋፍ እንዳለ አየሁ። ጂኤስፒን ለመደገፍ እቅድ አለ?

ጥሩ ጥያቄ. ማድረግ ጀመርን። እና ገንዘብ መቆጠብ ስለምንፈልግ ለአሁን አሰርነው። ማለትም በ localhost ላይ አሂድን በመጠቀም ድጋፍ አለ። ምሳሌን እራስዎ መፍጠር እና በአገር ውስጥ መሥራት ይችላሉ። በነገራችን ላይ ይህን ነው የምናደርገው። ይህንን የማደርገው በጌትላብ፣ እዚያ በጂኤስፒ ነው። ነገር ግን እንደዚህ አይነት ኦርኬስትራ ማድረግ ፋይዳውን እስካሁን አናይም, ምክንያቱም Google ርካሽ ቦታዎች ስለሌለው. አለ ??? ሁኔታዎች, ግን ገደቦች አሏቸው. በመጀመሪያ ፣ ሁልጊዜ የ 70% ቅናሽ ብቻ አላቸው እና እዚያ ባለው ዋጋ መጫወት አይችሉም። በቦታዎች ላይ፣ የመገረፍ እድልን ለመቀነስ በ5-10% ዋጋን እንጨምረዋለን። ያም ማለት ነጠብጣቦችን ታድናለህ, ነገር ግን በማንኛውም ጊዜ ከእርስዎ ሊወሰዱ ይችላሉ. ሌሎች ከሚያቀርቡት ትንሽ ከፍ ያለ ዋጋ ካቀረቡ በኋላ ይገደላሉ። ጉግል ሙሉ ለሙሉ የተለያዩ ዝርዝሮች አሉት። እና ሌላ በጣም መጥፎ ገደብ አለ - ለ 24 ሰዓታት ብቻ ይኖራሉ. እና አንዳንድ ጊዜ ለ 5 ቀናት ሙከራን ማካሄድ እንፈልጋለን. ግን ይህንን በቦታዎች ውስጥ ማድረግ ይችላሉ ፣ ነጠብጣቦች አንዳንድ ጊዜ ለወራት ይቆያሉ።

ሀሎ! ለሪፖርቱ እናመሰግናለን! ፍተሻን ጠቅሰዋል። የስታቲስቲክስ_መግለጫ ስህተቶችን እንዴት ማስላት ይቻላል?

በጣም ጥሩ ጥያቄ። በጣም በዝርዝር ላሳይህ እችላለሁ። በአጭሩ ፣ የጥያቄ ቡድኖች እንዴት እንደተንሳፈፉ ፣ ምን ያህል እንደወደቁ እና ምን ያህል አዲስ እንደታዩ እንመለከታለን። እና ከዚያ ሁለት መለኪያዎችን እንመለከታለን፡ ጠቅላላ_ሰዓት እና ጥሪዎች፣ ስለዚህ ሁለት ስህተቶች አሉ። እና የተንሳፋፊ ቡድኖችን አስተዋፅኦ እንመለከታለን. ሁለት ንኡስ ቡድኖች አሉ፡ የሄዱት እና የደረሱት። ለአጠቃላዩ ገጽታ የእነርሱ አስተዋፅኦ ምን እንደሆነ እንይ።

በቅጽበተ-ፎቶዎች መካከል ባለው ጊዜ ውስጥ ሁለት ወይም ሶስት ጊዜ ወደዚያ እንደሚዞር አትፈራም?

እንደገና ተመዝግበዋል ወይስ ምን?

ለምሳሌ, ይህ ጥያቄ አንድ ጊዜ አስቀድሞ ተዘጋጅቷል, ከዚያም መጥቷል እና እንደገና ተዘጋጅቷል, ከዚያም እንደገና መጥቷል እና እንደገና ተዘጋጅቷል. እና እዚህ የሆነ ነገር አስልተዋል, እና ሁሉም ነገር የት ነው?

ጥሩ ጥያቄ፣ መመልከት አለብን።

ተመሳሳይ ነገር አደረግሁ። ይበልጥ ቀላል ነበር, በእርግጥ, ብቻዬን ነው ያደረኩት. ነገር ግን የስታቲስቲክስ መግለጫዎችን ዳግም ማቀናበር፣ ዳግም ማስጀመር እና በፎቶው ጊዜ ከተወሰነ ክፍልፋይ ያነሰ መሆኑን ማወቅ ነበረብኝ፣ ይህም አሁንም እዚያ ምን ያህል የስታቲስቲክስ መግለጫዎች ሊከማች እንደሚችል ጣሪያ ላይ አልደረሰም። እና የእኔ ግንዛቤ፣ ምናልባትም፣ ምንም ነገር አልተፈናቀልም ነበር።

አዎ አዎ.

ግን በአስተማማኝ ሁኔታ እንዴት ሌላ ማድረግ እንዳለብኝ አልገባኝም።

እንደ አለመታደል ሆኖ የመጠይቁን ጽሁፍ እዚያ እንደምንጠቀም ወይም በpg_stat_statements መጠየቂያውን በትክክል እንደምንጠቀም እና በእሱ ላይ እንዳተኮርን አላስታውስም። በ queryid ላይ ካተኮርን በቲዎሪ ደረጃ ተመጣጣኝ ነገሮችን እያነጻጸርን ነው።

አይደለም፣ በቅጽበተ-ፎቶዎች መካከል ብዙ ጊዜ አስገድዶ እንደገና መምጣት ይችላል።

በተመሳሳይ መታወቂያ?

አዎን.

ይህንን እናጠናለን። ጥሩ ጥያቄ. ልናጠናው ይገባል። አሁን ግን የምናየው ወይ ተጽፎ 0...

ይህ በእርግጥ ያልተለመደ ጉዳይ ነው፣ነገር ግን stat_statemetns እዚያ ሊፈናቀል እንደሚችል ሳውቅ በጣም ደነገጥኩ።

በPg_stat_statements ውስጥ ብዙ ነገሮች ሊኖሩ ይችላሉ። ትራክ_ዩቲሊቲ = ላይ ካለህ የአንተ ስብስቦችም ክትትል ይደረግባቸዋል የሚለውን እውነታ አጋጥመናል።

አዎን በእርግጥ.

እና ጃቫ ሃይበርኔት ካለህ፣ ይህም በዘፈቀደ ነው፣ ከዚያ የሃሽ ጠረጴዛው እዚያ መገኘት ይጀምራል። እና በጣም የተጫነ መተግበሪያን እንዳጠፉ ከ50-100 ቡድኖችን ያገኛሉ። እና ሁሉም ነገር እዚያ ብዙ ወይም ያነሰ የተረጋጋ ነው. ይህንን ለመዋጋት አንዱ መንገድ pg_stat_statements.max መጨመር ነው።

አዎ, ግን ምን ያህል እንደሆነ ማወቅ ያስፈልግዎታል. እና በሆነ መንገድ እሱን መከታተል ያስፈልገናል. እኔ የማደርገው ይህንኑ ነው። ማለትም pg_stat_statements.max አለኝ። እና በፎቶው ጊዜ 70% እንዳልደረስኩ አያለሁ. እሺ፣ ምንም ነገር አላጠፋንም። እንደገና እናስጀምር። እና እንደገና እንቆጥባለን. የሚቀጥለው ቅጽበታዊ ገጽ እይታ ከ 70 በታች ከሆነ ፣ ምናልባት እርስዎ እንደገና ምንም ነገር አላጠፉም።

አዎ. ነባሪው አሁን 5 ነው። እና ይሄ ለብዙ ሰዎች በቂ ነው።

አብዛኛውን ጊዜ አዎ.

ቪዲዮ

PS በራሴ ስም፣ፖስትግሬስ ሚስጥራዊ መረጃዎችን ከያዘ እና በሙከራ አካባቢ ውስጥ መካተት ካልቻለ፣መጠቀም እንደሚችሉ እጨምራለሁ PostgreSQL Anonymizer. መርሃግብሩ በግምት እንደሚከተለው ነው-

ምንጭ: hab.com