የPostgreSQL አፈጻጸምን ለማሻሻል የሊኑክስ ማስተካከያ። ኢሊያ ኮስሞዴሚያንስኪ

የ 2015 ሪፖርት በIlya Kosmodemyansky "ሊኑክስ ማስተካከያ የ PostgreSQL አፈጻጸምን ለማሻሻል"

የኃላፊነት ማስተባበያ፡ ይህ ዘገባ በኖቬምበር 2015 የተጻፈ መሆኑን አስተውያለሁ - ከ 4 ዓመታት በላይ አልፈዋል እና ብዙ ጊዜ አልፏል. በሪፖርቱ ውስጥ የተወያየው ስሪት 9.4 ከአሁን በኋላ አይደገፍም። ባለፉት 4 ዓመታት ውስጥ፣ 5 አዳዲስ የPostgreSQL እና 15 የሊኑክስ ከርነል ስሪቶች ታይተዋል። እነዚህን ቦታዎች እንደገና ከፃፉ, የተለየ ዘገባ ይዘው ይጨርሳሉ. ግን ለPosgreSQL መሰረታዊ የሊኑክስ ማስተካከያ እዚህ አለ፣ እሱም ዛሬም ጠቃሚ ነው።

ስሜ ኢሊያ ኮስሞዴሚያንስኪ እባላለሁ። ለ PostgreSQL-Consulting ኩባንያ እሰራለሁ። እና አሁን በአጠቃላይ ከመረጃ ቋቶች እና ከ PostgreSQL ጋር በተያያዘ ከሊኑክስ ጋር ምን ማድረግ እንዳለብኝ ትንሽ እናገራለሁ ፣ ምክንያቱም መርሆዎች በጣም ተመሳሳይ ናቸው።

ምን ይብራራል? ከPostgreSQL ጋር እየተገናኘህ ከሆነ በተወሰነ ደረጃ የ UNIX አስተዳዳሪ መሆን አለብህ። ምን ማለት ነው? Oracleን እና PostgreSQLን ካነጻጸርን በOracle ውስጥ 80% DBA ዳታቤዝ አስተዳዳሪ እና 20% ሊኑክስ አስተዳዳሪ መሆን አለቦት።

PostgreSQL ትንሽ የበለጠ ከባድ ነው። በ PostgreSQL፣ ሊኑክስ እንዴት እንደሚሰራ የበለጠ የተሻለ ሀሳብ ሊኖርዎት ይገባል። እና በተመሳሳይ ጊዜ, ከሎኮሞቲቭ በኋላ ትንሽ ይሮጡ, ምክንያቱም በቅርብ ጊዜ ሁሉም ነገር በጣም ጥሩ ተሻሽሏል. እና አዲስ ኮርሶች ይወጣሉ, እና አዲስ ተግባራት ይታያሉ, አፈፃፀሙ ይሻሻላል, ወዘተ.

ስለ ሊኑክስ ለምን እየተነጋገርን ነው? እኛ በሊኑክስ ኮንፈረንስ ፒተር ላይ ስለሆንን አይደለም፣ ነገር ግን በዘመናዊ ሁኔታዎች ከዳታቤዝ ጋር በአጠቃላይ እና በተለይም ከ PostgreSQL ጋር ለመስራት በጣም ትክክለኛ ከሆኑት ኦፕሬቲንግ ሲስተሞች አንዱ ሊኑክስ ነው። ምክንያቱም FreeBSD፣ በሚያሳዝን ሁኔታ፣ በጣም በሚያስገርም አቅጣጫ እያደገ ነው። እና በሁለቱም የአፈፃፀም እና ሌሎች በርካታ ነገሮች ላይ ችግሮች ይኖራሉ. በዊንዶውስ ላይ የ PostgreSQL አፈፃፀም በአጠቃላይ የተለየ ከባድ ርዕስ ነው ፣ ይህም ዊንዶውስ እንደ UNIX ያሉ የጋራ ማህደረ ትውስታ ስለሌለው እና PostgreSQL ሁሉም የዚህ ንግድ ነው ፣ ምክንያቱም ባለብዙ ሂደት ስርዓት ነው።

እና እንደ Solaris ያሉ እንግዳ አካላት ለሁሉም ሰው ብዙም ፍላጎት የላቸውም ብዬ አስባለሁ እና እንሂድ።

ዘመናዊ የሊኑክስ ስርጭት ከ1 በላይ የሲክታል አማራጮች አሉት፣ ይህም እንደ ከርነል እንደተገነባ ነው። በተመሳሳይ ጊዜ, የተለያዩ ፍሬዎችን ከተመለከትን, አሁንም የሆነ ነገር ለማስተካከል ብዙ መንገዶች ሊኖሩ ይችላሉ. እንዴት እንደሚሰቀል የፋይል ስርዓት አማራጮች አሉ። እንዴት እንደሚጀመር ጥያቄዎች ካሉዎት: በ BIOS ውስጥ ምን ማንቃት, ሃርድዌርን እንዴት ማዋቀር እንደሚቻል, ወዘተ.

ይህ በጣም ትልቅ መጠን ነው, እሱም ለብዙ ቀናት ሊነገር ይችላል, እና በአንድ አጭር ዘገባ አይደለም, አሁን ግን በአስፈላጊ ነገሮች ላይ አተኩራለሁ, በሊኑክስ ላይ የውሂብ ጎታ በደንብ እንዲሰሩ የማይፈቅዱትን እነዚያን መሰንጠቂያዎች እንዴት ማስወገድ እንደሚቻል. አታስተካክላቸውም.. እና በተመሳሳይ ጊዜ, አንድ አስፈላጊ ነጥብ ብዙ ነባሪ መለኪያዎች ለዳታቤዝ ትክክለኛ ቅንጅቶች ውስጥ አልተካተቱም. ማለትም በነባሪነት መጥፎ ይሰራል ወይም ጨርሶ አይሰራም።

በሊኑክስ ላይ ባህላዊ ማስተካከያ ዒላማዎች ምንድናቸው? እኔ እንደማስበው ሁላችሁም ከሊኑክስ አስተዳደር ጋር ስለተያያዙ፣ ኢላማዎች ምን እንደሆኑ ማብራራት አያስፈልግም።

ማስተካከል ትችላለህ፡-

• ሲፒዩ
• ማህደረ ትውስታ
• ማከማቻ.
• ሌላ. ስለ መክሰስ መጨረሻ ላይ ስለዚህ ጉዳይ እንነጋገራለን. እንኳን፣ ለምሳሌ፣ እንደ ኃይል ቆጣቢ ፖሊሲ ያሉ ቅንብሮች በጣም ባልተጠበቀ እና በጣም ደስ በማይሰኝ መንገድ አፈፃፀሙን ሊነኩ ይችላሉ።

የ PostgreSQL እና የመረጃ ቋቱ በአጠቃላይ ምንድናቸው? ችግሩ የተወሰነውን ለውዝ ማስተካከል አለመቻላችሁ እና አፈፃፀማችን ብዙ መሻሻሉን ማየት ነው።

አዎ, እንደዚህ አይነት መግብሮች አሉ, ግን የውሂብ ጎታ ውስብስብ ነገር ነው. እሷ አገልጋዩ ካለው ሁሉንም ሀብቶች ጋር ትገናኛለች እና ሙሉ በሙሉ መገናኘት ትመርጣለች። የ Oracle አስተናጋጅ ስርዓተ ክወናን እንዴት መጠቀም እንደሚቻል ላይ ያለውን የአሁን መመሪያዎች ከተመለከቱ፣ ልክ እንደ ሞንጎሊያ የጠፈር ተመራማሪ ቀልድ ነው - ውሻውን ይመግቡ እና ምንም ነገር አይንኩ። የውሂብ ጎታውን ሁሉንም ሀብቶች እንስጥ, ዳታቤዙ ራሱ ሁሉንም ነገር ያጠፋል.

በመርህ ደረጃ, በተወሰነ ደረጃ, ሁኔታው ​​በትክክል ከ PostgreSQL ጋር ተመሳሳይ ነው. ልዩነቱ የሚገኘው በመሠረቱ ሁሉንም ሀብቶች ለራሱ መውሰድ አለመቻሉ ነው ፣ ማለትም ፣ በሆነ ቦታ በሊኑክስ ደረጃ ሁሉንም በራስዎ መደርደር ያስፈልግዎታል።

ዋናው ሀሳቡ አንድ ኢላማ መርጦ ማስተካከል መጀመር ሳይሆን ለምሳሌ ሚሞሪ፣ ሲፒዩ ወይም መሰል ነገር ሳይሆን የስራ ጫናውን መተንተን እና በተቻለ መጠን የሂደቱን መጠን ለማሻሻል መሞከር ጥሩ ፕሮግራመሮች የፈጠሩት ጭነት ነው። ተጠቃሚዎቻችንን ጨምሮ እኛ።

ምን እንደሆነ ለማብራራት ስእል እዚህ አለ. የሊኑክስ ኦኤስ ቋት አለ እና የተጋራ ማህደረ ትውስታ አለ እና PostgreSQL የተጋሩ ቋቶች አሉ። PostgreSQL፣ ከኦራክል በተለየ፣ በቀጥታ የሚሠራው በከርነል ቋት በኩል ብቻ ነው፣ ማለትም፣ ከዲስክ ላይ ያለ ገጽ ወደ የጋራ ማህደረ ትውስታው እንዲገባ፣ በከርነል ቋት ውስጥ ማለፍ እና ልክ ተመሳሳይ ሁኔታ መመለስ አለበት።

ዲስኮች በዚህ ስርዓት ውስጥ ይኖራሉ. እንደ ዲስኮች ሳብኩት። እንደ እውነቱ ከሆነ የ RAID መቆጣጠሪያ ወዘተ ሊኖር ይችላል.

እና ይህ ግቤት-ውፅዓት አንድ መንገድ ወይም ሌላ በዚህ ጉዳይ በኩል ይከሰታል.

PostgreSQL ክላሲክ የውሂብ ጎታ ነው። በገጹ ውስጥ ነው። እና ሁሉም የግቤት-ውፅዓት በገጾች እገዛ ይከሰታል. በማህደረ ትውስታ ውስጥ ብሎኮችን በገጾች ከፍ እናደርጋለን። እና ምንም ነገር ካልተከሰተ እኛ እናነባቸዋለን ፣ ከዚያ ቀስ በቀስ ከዚህ መሸጎጫ ፣ ከጋራ ቋቶች ሰምጠው ወደ ዲስክ ይመለሳሉ።

የሆነ ነገር የሆነ ቦታ ከቀየርን ገጻችን በሙሉ እንደ ቆሻሻ ምልክት ተደርጎበታል። እዚህ በሰማያዊ ምልክት አደረግኳቸው። እና ይህ ማለት ይህ ገጽ ከብሎክ ማከማቻ ጋር መመሳሰል አለበት ማለት ነው። ማለትም፣ ቆሻሻ ስናደርግ፣ ዋል ውስጥ ገብተናል። እና ጥሩ በሆነ ጊዜ ላይ፣ የፍተሻ ነጥብ የሚባል ክስተት መጣ። እና ይህ ምዝግብ እሱ የመጣውን መረጃ መዝግቧል. እና ይህ ማለት በዚያን ጊዜ በነዚህ የተጋሩ ቋቶች ውስጥ ያሉት ሁሉም የቆሸሹ ገፆች በከርነል ቋት በኩል fsyncን በመጠቀም ከማከማቻ ዲስክ ጋር ተመሳስለዋል ማለት ነው።

ለምንድን ነው? ቮልቴጅ ከጠፋን, ሁሉም መረጃዎች የጠፉበትን ሁኔታ አላገኘንም. ሁሉም ሰው የነገረን የማያቋርጥ ትውስታ ፣ በመረጃ ቋት ፅንሰ-ሀሳብ ውስጥ እስካሁን ድረስ ነው - ይህ ብሩህ የወደፊት ነው ፣ እኛ በእርግጥ የምንጥርበት እና የምንወደው ፣ ግን እስካሁን ድረስ በ 20 ዓመታት ውስጥ ይኖራሉ ። እና በእርግጥ, ይህ ሁሉ ክትትል ሊደረግበት ይገባል.

እና ከፍተኛውን የውጤት መጠን የማሳደግ ተግባር ሁሉም ወደ ኋላ እና ወደ ፊት በፍጥነት እንዲሄድ እነዚህን ሁሉ ደረጃዎች ማስተካከል ነው። የጋራ ማህደረ ትውስታ በመሠረቱ የገጽ መሸጎጫ ነው። በ PostgreSQL ውስጥ፣ የሆነ ነገር ምረጥ የሚል ጥያቄ ልከናል፣ ይህን መረጃ ያገኘው ከዲስክ ነው። ወደ የጋራ ቋት ውስጥ ገቡ። በዚህ መሠረት, ይህ በተሻለ ሁኔታ እንዲሠራ, ብዙ ማህደረ ትውስታ መኖር አለበት.

ይህ ሁሉ በጥሩ ሁኔታ እና በፍጥነት እንዲሰራ, በሁሉም ደረጃዎች ስርዓተ ክወናውን በትክክል ማዋቀር ያስፈልግዎታል. እና ሚዛናዊ ብረትን ምረጥ, ምክንያቱም በአንዳንድ ቦታዎች ላይ ሚዛን ካለህ, ከዚያም ብዙ ማህደረ ትውስታን ማድረግ ትችላለህ, ነገር ግን በቂ ባልሆነ ፍጥነት ያገለግላል.

እስቲ እነዚህን ነጥቦች እያንዳንዳቸውን እንመርምር።

እነዚህ ገፆች ወደ ኋላ እና ወደ ፊት በፍጥነት እንዲጓዙ የሚከተሉትን ማሳካት አለብዎት።

• በመጀመሪያ, ከማስታወስ ጋር የበለጠ በብቃት መስራት ያስፈልግዎታል.
• በሁለተኛ ደረጃ, ከማህደረ ትውስታ ገጾች ወደ ዲስክ ሲሄዱ ይህ ሽግግር የበለጠ ውጤታማ መሆን አለበት.
• እና, ሦስተኛ, ጥሩ ዲስኮች መኖር አለባቸው.

በአገልጋዩ ውስጥ 512 ጂቢ ራም ካለዎት እና ይህ ሁሉ በ SATA ሃርድ ድራይቭ ላይ ያለ ምንም መሸጎጫ ያበቃል ፣ ከዚያ አጠቃላይ የመረጃ ቋቱ አገልጋይ ወደ ዱባ ብቻ ሳይሆን ከ SATA በይነገጽ ጋር ወደ ዱባ ይቀየራል። በቀጥታ ወደ እሱ ትገባለህ። እና ምንም አያድናችሁም.

ከማስታወስ ጋር የመጀመሪያውን ነጥብ በተመለከተ, ህይወትን በጣም አስቸጋሪ የሚያደርጉ ሶስት ነገሮች አሉ.

የመጀመሪያው NUMA ነው። NUMA አፈጻጸምን ለማሻሻል የተሰራ ነገር ነው። በስራው ጫና ላይ በመመስረት, የተለያዩ ነገሮችን ማመቻቸት ይችላሉ. እና አሁን ባለው አዲስ ቅፅ፣ የገጽ መሸጎጫ የተጋሩ ማቋረጦችን በከፍተኛ ሁኔታ ለሚጠቀሙ እንደ ዳታቤዝ ላሉት መተግበሪያዎች በጣም ጥሩ አይደለም።

በጥቅሉ. በNUMA ላይ የሆነ ችግር እንዳለ እንዴት መረዳት ይቻላል? አንድ ዓይነት ደስ የማይል ማንኳኳት አለብህ፣ በድንገት አንዳንድ ሲፒዩ ከመጠን በላይ ተጭኗል። በተመሳሳይ ጊዜ በ PostgreSQL ውስጥ ጥያቄዎችን ይተነትናል እና እዚያ ምንም ተመሳሳይ ነገር እንደሌለ ይመለከታሉ። እነዚህ ጥያቄዎች ሲፒዩ የተጠናከረ መሆን የለባቸውም። ለረጅም ጊዜ ሊይዙት ይችላሉ. NUMA ለ PostgreSQL እንዴት ማዋቀር እንደሚቻል ከመጀመሪያው ትክክለኛውን ምክር መጠቀም ቀላል ነው።

በእውነቱ ምን እየተካሄደ ነው? NUMA ዩኒፎርም ያልሆነ የማህደረ ትውስታ መዳረሻ ማለት ነው። ነጥቡ ምንድን ነው? ሲፒዩ አለህ፣ ከጎኑ የአካባቢ ማህደረ ትውስታ አለ። እና ይህ የማህደረ ትውስታ ትስስር ከሌሎች ሲፒዩዎች ማህደረ ትውስታን መሳብ ይችላል።

ከሮጡ numactl --hardware, ከዚያ እንደዚህ ያለ ትልቅ ሉህ ያገኛሉ. ከሌሎች ነገሮች በተጨማሪ የርቀት መስክ ይኖራል. ቁጥሮች ይኖራሉ - 10-20 ፣ እንደዚህ ያለ ነገር። እነዚህ ቁጥሮች ይህንን የርቀት ማህደረ ትውስታ ለማንሳት እና በአገር ውስጥ ለመጠቀም ከሆፕስ ቁጥር በቀር ሌላ አይደሉም። በመሠረቱ ጥሩ ሀሳብ. ይህ በበርካታ የስራ ጫናዎች ውስጥ አፈጻጸምን በደንብ ያሻሽላል.

አሁን አንድ ሲፒዩ እንዳለህ አስብ። እና የእርስዎ የ PostgreSQL ገጽ መሸጎጫ ወደዚህ ሲፒዩ ይደርሳል - ያ ነው፣ ስንት ጊጋባይት አለ። ሁልጊዜም በጣም የከፋው ጉዳይ ታገኛለህ ምክንያቱም በአብዛኛው በሲፒዩ ላይ በቀጥታ በዚያ ሞጁል ውስጥ ትንሽ ማህደረ ትውስታ አለ. እና የሚቀርበው ማህደረ ትውስታ ሁሉ በእነዚህ ማገናኛዎች ውስጥ ያልፋል. ቀስ ብሎ እና በሚያሳዝን ሁኔታ ይለወጣል. እና ይህንን መስቀለኛ መንገድ ያለማቋረጥ ከመጠን በላይ የተጫነውን የሚያገለግል ፕሮሰሰር አለዎት። እና የዚህ ማህደረ ትውስታ መዳረሻ ጊዜ መጥፎ ፣ ቀርፋፋ ነው። ይህንን ጉዳይ ለዳታቤዝ እየተጠቀሙ ከሆነ የማይፈልጉት አይነት ሁኔታ ነው።

ስለዚህ ለዳታቤዝ የበለጠ ትክክለኛ አማራጭ የሊኑክስ ኦፕሬቲንግ ሲስተም እዚያ ምን እየተፈጠረ እንዳለ አያውቅም። ስለዚህ ትዝታዋን ስትናገር ትዝታዋን ታቀርባለች።

ለምንድነው? በተቃራኒው መሆን ያለበት ይመስላል. ይህ የሚከሰተው በአንድ ቀላል ምክንያት ነው, ለገጽ መሸጎጫ ብዙ ማህደረ ትውስታ ያስፈልገናል - አስር, በመቶዎች የሚቆጠሩ ጊጋባይት.

እና ይህንን ሁሉ ከመደብን እና ውሂባችንን እዚያ ካስቀመጥን ፣ ከዚያ መሸጎጫውን በመጠቀም የምናገኘው ትርፍ ከእንደዚህ ዓይነቱ ተንኮለኛ ማህደረ ትውስታ ተደራሽነት የበለጠ ትልቅ ይሆናል። እና በዚህ መንገድ NUMA ን በመጠቀም ማህደረ ትውስታን በብቃት ከመድረስ እውነታ ጋር ሲነፃፀር ወደር የለሽ እናተርፋለን።

ስለዚህ, ብሩህ የወደፊት ጊዜ እስኪመጣ ድረስ በአሁኑ ጊዜ ሁለት አቀራረቦች አሉ, እና የውሂብ ጎታው ራሱ በየትኞቹ ሲፒዩዎች ላይ እንደሚሰራ እና የሆነ ነገር ከየት ማውጣት እንዳለበት ማወቅ አይችልም.

ስለዚህ, ትክክለኛው አቀራረብ NUMA ን ሙሉ በሙሉ ማሰናከል ነውለምሳሌ ዳግም ሲነሳ። በአብዛኛዎቹ አጋጣሚዎች, አሸናፊዎቹ እንደዚህ ባሉ ትዕዛዞች ውስጥ ናቸው, ምንም ጥያቄ የለም, የትኛው የተሻለ ነው.

ሌላ አማራጭ አለ. ከመጀመሪያው በበለጠ ብዙ ጊዜ እንጠቀማለን, ምክንያቱም አንድ ደንበኛ ለድጋፍ ወደ እኛ ሲመጣ, ከዚያ ለእሱ አገልጋዩን እንደገና ማስጀመር ሙሉ ነገር ነው. እዚያ ንግድ አለው. እና በNUMA ምክንያት ችግሮች ያጋጥሟቸዋል. ስለዚህ፣ ዳግም ከማስነሳት ባነሰ ወራሪ መንገዶችን ለማሰናከል እንሞክራለን፣ ግን እዚህ ላይ የአካል ጉዳተኛ መሆኑን ለማረጋገጥ ይጠንቀቁ። ምክንያቱም፣ ተሞክሮ እንደሚያሳየው፣ በ PostgreSQL የወላጅ ሂደት ላይ NUMA ን እናሰናክላለን፣ ይህ ጥሩ ነው፣ ነገር ግን ይህ እንዲሰራ በጭራሽ አስፈላጊ አይደለም። እሷ በእርግጥ እንደጠፋች ማረጋገጥ እና ማየት አለብን።

በሮበርት ሃስ ጥሩ ልጥፍ አለ። ይህ ከPostgreSQL ፈጻሚዎች አንዱ ነው። የሁሉንም ዝቅተኛ ደረጃ ጊብሌቶች ቁልፍ ገንቢዎች አንዱ። እና ከዚህ ልኡክ ጽሁፍ አገናኞችን ከተከተሉ፣ NUMA እንዴት ሰዎችን ህይወት አስቸጋሪ እንዳደረገው በርካታ በቀለማት ያሸበረቁ ታሪኮችን ይገልጻል። ተመልከት፣ የመረጃ ቋታችን በደንብ እንዲሰራ የስርዓት አስተዳዳሪውን የፍተሻ ዝርዝር በአገልጋዩ ላይ ምን ማዋቀር እንዳለበት አጥኑ። እነዚህ ቅንብሮች መቅዳት እና መፈተሽ አለባቸው, ምክንያቱም አለበለዚያ በጣም ጥሩ አይሆንም.

ይህ እኔ ስለምናገርባቸው ሁሉም ቅንብሮች ላይ ስለሚተገበር ትኩረትዎን እሰጣለሁ። ግን አብዛኛውን ጊዜ የውሂብ ጎታዎች ለስህተት መቻቻል በጌታ-ባሪያ ሁነታ ይሰበሰባሉ። እነዚህን መቼቶች በባሪያው ላይ ማድረግዎን አይርሱ ምክንያቱም አንድ ቀን አደጋ ይደርስብዎታል እና ወደ ባሪያው ይቀየራሉ እና እሱ ጌታ ይሆናል ።

በድንገተኛ አደጋ ሁሉም ነገር በጣም መጥፎ በሚሆንበት ጊዜ ስልክዎ ያለማቋረጥ ሲደወል እና አለቃዎ በትልቅ ዱላ እየሮጠ ሲመጣ, ለመፈተሽ ለማሰብ ጊዜ አይኖርዎትም. ውጤቱም በጣም አስከፊ ሊሆን ይችላል.

የሚቀጥለው ቅጽበት ግዙፍ ገጾች ነው። ግዙፍ ገጾች በተናጥል ለመፈተሽ አስቸጋሪ ናቸው, እና በዚህ ውስጥ ምንም ፋይዳ የለውም, ምንም እንኳን ይህን ማድረግ የሚችሉ መለኪያዎች ቢኖሩም. በቀላሉ ጉግል (Google) ናቸው።

ምን ዋጋ አለው? ብዙ ራም ያለው፣ ለምሳሌ ከ30 ጂቢ በላይ የሆነ በጣም ውድ ያልሆነ አገልጋይ አለህ። ግዙፍ ገጾችን እየተጠቀምክ አይደለም። ይህ ማለት በእርግጠኝነት የማህደረ ትውስታ አጠቃቀም ላይ ትርፍ አለህ ማለት ነው። እና ይህ የላይኛው ክፍል በጣም ከሚያስደስት በጣም የራቀ ነው።

ለምንድነው? እና ምን እየሆነ ነው? ስርዓተ ክወናው ማህደረ ትውስታን በትናንሽ ቁርጥራጮች ይመድባል. በጣም ምቹ ፣ በታሪክም ። እና ወደ ዝርዝሮች ከገቡ OSው ምናባዊ አድራሻዎችን ወደ አካላዊ መተርጎም አለበት። እና ይህ ሂደት በጣም ቀላሉ አይደለም, ስለዚህ ስርዓተ ክወናው የዚህን ቀዶ ጥገና ውጤት በትርጉም Looksidede Buffer (TLB) ውስጥ ይሸፍናል.

እና TLB መሸጎጫ ስለሆነ, በዚህ ሁኔታ ውስጥ በመሸጎጫው ውስጥ ያሉ ሁሉም ችግሮች ይነሳሉ. በመጀመሪያ ፣ ብዙ ራም ካለዎት እና ሁሉም በትናንሽ ቁርጥራጮች ከተመደበ ይህ ቋት በጣም ትልቅ ይሆናል። እና መሸጎጫው ትልቅ ከሆነ እሱን ለመፈለግ ቀርፋፋ ነው። የላይኛው ጭንቅላት ጤናማ ነው እና በራሱ ቦታ ይወስዳል, ማለትም አንድ ስህተት RAM እየበላ ነው. በዚህ ጊዜ.

ሁለት - በእንደዚህ ዓይነት ሁኔታ ውስጥ ያለው መሸጎጫ እየጨመረ በሄደ ቁጥር መሸጎጫ ማጣት ሊኖርብዎት ይችላል. እና መጠኑ ሲያድግ የዚህ መሸጎጫ ውጤታማነት በፍጥነት ይቀንሳል. ስለዚህ ስርዓተ ክወናዎች ቀላል አቀራረብ ይዘው መጡ. ሊኑክስ ለረጅም ጊዜ ሲጠቀምበት ቆይቷል። ከረጅም ጊዜ በፊት በ FreeBSD ውስጥ ታየ። ግን እየተነጋገርን ያለነው ስለ ሊኑክስ ነው። እነዚህ ግዙፍ ገጾች ናቸው.

እና እዚህ ላይ ግዙፍ ገፆች እንደ ሀሳብ መጀመሪያ ላይ Oracle እና IBM ን ባካተቱ ማህበረሰቦች ተገፍተው እንደነበር ልብ ሊባል ይገባል, ማለትም የውሂብ ጎታ አምራቾች ይህ ለዳታቤዝ ጨምሮ ጠቃሚ ነው ብለው አስበው ነበር.

እና ከ PostgreSQL ጋር ጓደኝነትን እንዴት መፍጠር እንደሚቻል? በመጀመሪያ፣ በሊኑክስ ከርነል ውስጥ ግዙፍ ገጾች መንቃት አለባቸው።

በሁለተኛ ደረጃ, እነሱ በ sysctl መለኪያ - ምን ያህል እንደሆኑ በግልፅ መገለጽ አለባቸው. እዚህ ያሉት ቁጥሮች ከአንዳንድ የድሮ አገልጋይ የመጡ ናቸው። ግዙፍ ገፆች እዚያ እንዲገጣጠሙ ምን ያህል የተጋሩ ቋቶች እንዳሎት በግምት ማስላት ይችላሉ።

እና ሙሉው አገልጋይ ለ PostgreSQL የተወሰነ ከሆነ ጥሩ መነሻ ነጥብ 25% ራም ለጋራ ቋት መስጠት ወይም 75% የውሂብ ጎታዎ በእርግጠኝነት በእነዚህ 75% እንደሚስማማ እርግጠኛ ከሆኑ 256% መስጠት ነው። መጀመሪያ የመነሻ ነጥብ. እና ግምት ውስጥ ያስገቡ ፣ 64 ጊባ ራም ካለዎት ፣ ከዚያ ፣ በዚህ መሠረት ፣ XNUMX ጂቢ የሸርድ ማስቀመጫዎች ይኖርዎታል። ከተወሰነ ኅዳግ ጋር በግምት አስሉ - ይህ አኃዝ ወደ ምን ማቀናበር እንዳለቦት።

ከስሪት 9.2 በፊት (ካልተሳሳትኩ፣ ከስሪት 8.2 ጀምሮ) የሶስተኛ ወገን ቤተ-መጽሐፍትን በመጠቀም ከትላልቅ ገጾች PostgreSQL ጋር ጓደኝነት መመሥረት ይቻል ነበር። እና ይሄ ሁልጊዜ መደረግ አለበት. በመጀመሪያ ግዙፍ ገጾችን በትክክል ለመመደብ ከርነል ያስፈልግዎታል። እና, ሁለተኛ, ከእነሱ ጋር የሚሰራ መተግበሪያ እነሱን መጠቀም እንዲችሉ. እንደዚያ ብቻ ጥቅም ላይ አይውልም. PostgreSQL በስርዓት 5 ስታይል ውስጥ ማህደረ ትውስታን ስለመደበው፣ ይህ በlibhugetlbfs በመጠቀም ሊከናወን ይችላል - ይህ የቤተ-መጽሐፍት ሙሉ ስም ነው።

9.3 የተሻሻለ የ PostgreSQL ማህደረ ትውስታ አፈፃፀም እና ስርዓቱን 5 ማህደረ ትውስታ ምደባ ዘዴን አስወግዶታል። ሁሉም ሰው በጣም ደስተኛ ነበር, ምክንያቱም አለበለዚያ ሁለት PostgreSQL ምሳሌዎችን በተመሳሳይ ማሽን ላይ ለማሄድ ይሞክራሉ, እና በቂ የጋራ ማህደረ ትውስታ የለኝም አለ. እና sysctl ማስተካከል ያስፈልግዎታል ይላል። እና አሁንም እንደገና ማስጀመር የሚያስፈልግዎ እንደዚህ ያለ sysctl አለ ፣ ወዘተ በአጠቃላይ ሁሉም ሰው ተደስቷል። ነገር ግን የኤምኤምፕ ሜሞሪ ምደባ ግዙፍ ገጾችን በመጠቀም ተበላሽቷል። አብዛኛዎቹ ደንበኞቻችን ትልቅ የጋራ ቋት ይጠቀማሉ። እና ወደ 9.3 እንዳንቀይር አጥብቀን እንመክራለን፣ ምክንያቱም ከፍተኛ ወጪ በጥሩ መቶኛ ማስላት ስለጀመረ ነው።

ነገር ግን በሌላ በኩል ህብረተሰቡ ለዚህ ችግር ትኩረት ስቧል እና በ 9.4 ውስጥ ይህንን ክስተት በጥሩ ሁኔታ ደግመውታል. እና በ9.4 ውስጥ፣ ሙከራን ማብራት ወይም ማጥፋት የምትችልበት መለኪያ በpostgresql.conf ታየ።

ይሞክሩት በጣም አስተማማኝ አማራጭ ነው። PostgreSQL ሲጀምር የጋራ ማህደረ ትውስታን ሲመድብ ይህን ማህደረ ትውስታ ከትላልቅ ገፆች ለመንጠቅ ይሞክራል። እና ካልሰራ, ከዚያም ወደ ተለመደው ምርጫ ይመለሳል. እና FreeBSD ወይም Solaris ካለዎት, መሞከር ይችላሉ, ሁልጊዜም ደህና ነው.

ከበራ ከትላልቅ ገፆች መምረጥ ካልቻለ በቀላሉ አይጀምርም። እዚህ ቀድሞውኑ - ለማን እና የበለጠ ቆንጆ የሆነው። ነገር ግን ሙከራ ካደረግክ፣ ለስህተት ብዙ ቦታዎች ስላሉ፣ የሚያስፈልጎት ነገር ጎልቶ እንዳለህ ያረጋግጡ። በአሁኑ ጊዜ ይህ ተግባር በሊኑክስ ላይ ብቻ ይሰራል።

ከመቀጠላችን በፊት አንድ ተጨማሪ ትንሽ ማስታወሻ. ግልፅ ግዙፍ ገፆች ገና ስለ PostgreSQL አይደሉም። በመደበኛነት ሊጠቀምባቸው አይችልም. እና ለእንደዚህ አይነት የስራ ጫና ከTransparent ግዙፍ ገፆች ጋር ትልቅ የጋራ ማህደረ ትውስታ ሲፈልጉ ፕላስዎቹ በጣም ትልቅ በሆነ መጠን ብቻ ይመጣሉ። ቴራባይት የማስታወስ ችሎታ ካለህ ይህ ሚና ሊጫወት ይችላል። ስለ ተጨማሪ የዕለት ተዕለት አፕሊኬሽኖች እየተነጋገርን ከሆነ በማሽኑ ላይ 32, 64, 128, 256 ጂቢ ማህደረ ትውስታ ሲኖርዎት, የተለመዱ ግዙፍ ገፆች እሺ ናቸው, እና ግልጽነትን ብቻ እናጠፋለን.

እና የማስታወስ የመጨረሻው ነገር ከፍራፍሬ ጋር በቀጥታ የተገናኘ አይደለም, ህይወትን በእጅጉ ሊያበላሽ ይችላል. አገልጋዩ ያለማቋረጥ እየተቀያየረ በመምጣቱ ሁሉም የማስተላለፊያ ዘዴዎች በእጅጉ ይጎዳሉ።

እና በአንዳንድ ቦታዎች ላይ በጣም ደስ የማይል ይሆናል. እና ዋናው ችግር በዘመናዊው ኮርነሎች ባህሪው ከድሮው የሊኑክስ ኮርነሎች ትንሽ የተለየ ነው። እና ይህ ነገር ፣ ለመርገጥ በጣም ደስ የማይል ነው ፣ ምክንያቱም ስለ አንዳንድ ስራዎች ከስዋፕ ጋር ስንነጋገር ፣ ጊዜው ያለፈበት የ OOM-ገዳይ መምጣት ያበቃል። እና OOM-ገዳይ፣ በጊዜ ያልመጣ እና PostgreSQLን የጣለው፣ ደስ የማይል ነው። ሁሉም ሰው ስለዚህ ጉዳይ ማለትም እስከ መጨረሻው ተጠቃሚ ድረስ ያውቃል.

ምን እየተደረገ ነው? እዚያ ብዙ መጠን ያለው RAM አለዎት, ሁሉም ነገር በደንብ ይሰራል. ግን በሆነ ምክንያት አገልጋዩ በስዋፕ ውስጥ ይንጠለጠላል እና በዚህ ምክንያት ፍጥነት ይቀንሳል። ብዙ ማህደረ ትውስታ ያለ ይመስላል ፣ ግን ይከሰታል።

ከዚህ ቀደም vm.swappiness ወደ ዜሮ እንዲዋቀር ጠቁመን ነበር፣ ማለትም መለዋወጥን አሰናክል። ከዚህ ቀደም 32 ጂቢ ራም እና ተጓዳኝ የጋራ ማቋቋሚያዎች ከፍተኛ መጠን ያለው ይመስላል። የመቀየሪያው ዋና አላማ ከወደቅንበት ቅርፊት የምንጥልበት ቦታ ማግኘት ነው። እና በጣም ጥሩ አልተሰራም. እና ከዚያ በዚህ ቅርፊት ምን ታደርጋለህ? ለምን መቀያየር እንደሚያስፈልግ ግልጽ በማይሆንበት ጊዜ ይህ ቀድሞውኑ እንደዚህ ያለ ተግባር ነው ፣ በተለይም እንደዚህ ያለ መጠን።

ነገር ግን ይበልጥ ዘመናዊ በሆነው, ማለትም, በሦስተኛው የከርነል ስሪቶች, ባህሪው ተለውጧል. እና ስዋፕን ወደ ዜሮ ካቀናበሩት፣ ማለትም ያጥፉት፣ ፈጥኖም ይሁን ዘግይቶ፣ የተወሰነ RAM ቢቀር እንኳን፣ የ OOM-ገዳይ በጣም ኃይለኛ ሸማቾችን ለመግደል ወደ እርስዎ ይመጣል። ምክንያቱም እንዲህ ባለው የሥራ ጫና አሁንም ትንሽ እንደቀረን እና ዘልለን እንወጣለን ማለትም የስርዓቱን ሂደት አንገድልም, ነገር ግን ትንሽ አስፈላጊ ነገርን እንገድላለን. ይህ ያነሰ አስፈላጊ የጋራ ማህደረ ትውስታ ከባድ ሸማች ይሆናል, ማለትም የፖስታ አስተዳዳሪ. እና ከዚያ በኋላ መሰረቱን ወደነበረበት መመለስ ከሌለው ጥሩ ይሆናል.

ስለዚህ, አሁን ነባሪው, እኔ እስከማስታውሰው ድረስ, አብዛኛዎቹ ስርጭቶች በ 6 አካባቢ ናቸው, ማለትም ምን ያህል ማህደረ ትውስታ እንደቀረው, ስዋፕን መጠቀም ለመጀመር በየትኛው ነጥብ ላይ ነው. አሁን vm.swappiness = 1 ን ማቀናበር እንመክራለን, ምክንያቱም በተግባር ስለሚያጠፋው, ነገር ግን እንደ ያልተጠበቀ የ OOM-ገዳይ መጥቶ ሙሉውን ገድሏል.

ቀጥሎ ምን አለ? ስለ የውሂብ ጎታዎች አፈፃፀም ስንነጋገር እና ቀስ በቀስ, ቀስ በቀስ, እንደ ዲስኮች እንሆናለን, ሁሉም ሰው ጭንቅላታቸውን መሳብ ይጀምራል. ምክንያቱም እውነት ዲስኩ ቀርፋፋ እና ማህደረ ትውስታ ፈጣን ነው ከልጅነት ጀምሮ ለሁሉም ሰው የታወቀ ነው። እና በመረጃ ቋቱ ውስጥ የዲስክ አፈፃፀም ችግሮች እንደሚኖሩ ሁሉም ሰው ያውቃል።

ዋናው የPostgreSQL የአፈጻጸም ችግር በፍተሻ ነጥቦች ስፒሎች ላይ ዲስኩ ቀርፋፋ ስለሆነ አይደለም። ይህ የማስታወሻ እና የዲስክ የመተላለፊያ ይዘት ሚዛናዊ ባለመሆኑ ምክንያት ነው. ይሁን እንጂ በተለያዩ ቦታዎች ላይ ሚዛናዊ ላይሆኑ ይችላሉ. PostgreSQL አልተዋቀረም, OS አልተዋቀረም, ሃርድዌር አልተዋቀረም እና ሃርድዌር ስህተት ነው. እና ይህ ችግር የሚከሰተው ሁሉም ነገር እንደ ሁኔታው ​​የሚሄድ ከሆነ ብቻ አይደለም ፣ ማለትም ፣ ወይም ምንም ጭነት ከሌለ ፣ ወይም ቅንብሮቹ እና ሃርድዌር በጥሩ ሁኔታ የተመረጡ ናቸው።

ምንድን ነው እና ምን ይመስላል? ብዙውን ጊዜ ከPostgreSQL ጋር የሚሰሩ ሰዎች ከአንድ ጊዜ በላይ ወደዚህ ንግድ ገብተዋል። እኔ እገልጻለሁ. እንዳልኩት፣ PostgreSQL በየጊዜው የቆሸሹ ገጾችን በጋራ ማህደረ ትውስታ ወደ ዲስክ ለመጣል የፍተሻ ነጥቦችን ያደርጋል። ብዙ የተጋራ ማህደረ ትውስታ ካለን የፍተሻ ነጥብ በዲስክ ላይ ከፍተኛ ተጽዕኖ ማሳደር ይጀምራል ምክንያቱም fsync እነዚህን ገጾች ይጥላል። በከርነል ቋት ውስጥ ይደርሳል እና fsyncን በመጠቀም ወደ ዲስክ ይጻፋል. እና የዚህ ጉዳይ መጠን ትልቅ ከሆነ ፣ ከዚያ ደስ የማይል ውጤትን ማለትም በጣም ትልቅ የዲስኮች አጠቃቀምን ማየት እንችላለን።

እዚህ ሁለት ስዕሎች አሉኝ. አሁን ምን እንደሆነ እገልጻለሁ. እነዚህ ሁለት ጊዜ ተዛማጅ ግራፎች ናቸው. የመጀመሪያው ግራፍ የዲስክ አጠቃቀም ነው. እዚህ በዚህ ጊዜ ወደ 90% ገደማ ይደርሳል. የውሂብ ጎታ ከአካላዊ ዲስኮች ጋር፣ ከ RAID መቆጣጠሪያ ጋር በ90% ጥቅም ላይ የሚውል ከሆነ፣ ይህ መጥፎ ዜና ነው። ይህ ማለት ትንሽ ተጨማሪ እና 100 ይመጣል እና ግቤት / ውፅዓት ይቆማል ማለት ነው.

የዲስክ ድርድር ካለህ ትንሽ የተለየ ታሪክ አለ ማለት ነው። እዚያም እንዴት እንደሚዋቀር, ምን ዓይነት ድርድር, ወዘተ ይወሰናል.

እና በትይዩ ፣ ከውስጣዊ ፖስትግሬስ እይታ ግራፍ እዚህ ተዋቅሯል ፣ ይህም የፍተሻ ነጥቡ እንዴት እንደሚከሰት ይነግርዎታል። እና እዚህ ያለው አረንጓዴ ቀለም በዚህ ቅጽበት ምን ያህል የቆሸሹ ገፆች ቋት ወደዚህ የፍተሻ ነጥብ እንደደረሱ ያሳያል። እና እዚህ ማወቅ ያለበት ዋናው ነገር ይህ ነው. እዚህ ብዙ ገጾች እንዳሉን እናያለን እና በአንድ ወቅት ወደ ክፍያ እንሮጣለን, ማለትም, ጻፍን እና ጻፍን, እዚህ የዲስክ ስርዓቱ በጣም ስራ የበዛበት ነው. እና የእኛ የፍተሻ ነጥብ በዲስክ ላይ በጣም ጠንካራ ተጽእኖ አለው. በሐሳብ ደረጃ, ሁኔታው ​​ይህን ይመስላል, ማለትም እኛ እዚህ ያነሰ መዝገብ ነበር. እና በዚህ መልኩ እንዲቀጥል በቅንጅቶች ማስተካከል እንችላለን። ያም ማለት እንደገና ጥቅም ላይ ማዋል ትንሽ ነው, ነገር ግን የሆነ ቦታ እዚህ የሆነ ነገር እየጻፍን ነው.

ይህንን ችግር ለማስወገድ ምን መደረግ አለበት? IOን በመረጃ ቋቱ ውስጥ ካቆሙት ይህ ማለት ጥያቄዎቻቸውን ለማስፈጸም የመጡ ሁሉም ተጠቃሚዎች ይጠባበቃሉ ማለት ነው።

ከሊኑክስ እይታ አንጻር ከተመለከቱ ፣ ጥሩ ሃርድዌር ከወሰዱ ፣ በትክክል ካዋቀሩት ፣ እነዚህን የፍተሻ ነጥቦች ብዙ ጊዜ እንዲያሳንስ በመደበኛነት PostgreSQL ን ካዋቀሩ ፣ በመካከላቸው በሰዓቱ ያሰራጩ ፣ ከዚያ ወደ ነባሪ የዴቢያን መለኪያዎች ገቡ። . ለአብዛኛዎቹ የሊኑክስ ስርጭቶች ይህ ምስሉ ነው፡- vm.dirty_ratio=20፣ vm.dirty_background_ratio=10።

ምን ማለት ነው? ከከርነል 2.6 ጀምሮ፣ አንድ ጋኔን የሚያፈስ ታይቷል። Pdglush፣ ማን ምን እንደሚጠቀም ላይ በመመስረት፣ ከበስተጀርባ የቆሸሹ ገጾችን ከከርነል ቋት በመወርወር እና አስፈላጊ በሚሆንበት ጊዜ የቆሸሹ ገጾችን በመወርወር ላይ የተሰማራው ፣ ምንም ቢሆን ፣ የጀርባ መወርወር በማይረዳበት ጊዜ።

ዳራ የሚመጣው መቼ ነው? በአገልጋዩ ላይ ካለው አጠቃላይ ራም 10% የሚሆነው በከርነል ቋት ውስጥ በቆሸሹ ገፆች ሲያዝ ከበስተጀርባ ያለው ልዩ የማጭበርበር ተግባር ይባላል። ለምንድነዉ? ስንት ገፆች ለመፃፍ እንደ መለኪያ ያስፈልጋል። እና፣ እንበል፣ N ገጾችን ይጽፋል። እና ለተወሰነ ጊዜ ይህ ነገር እንቅልፍ ይተኛል. እና ከዚያ ተመልሳ መጥታ አንዳንድ ተጨማሪ ገጾችን ጻፈች።

ይህ በጣም ቀላል ታሪክ ነው። እዚህ ስራው ልክ እንደ ገንዳ ነው, ወደ አንድ ቱቦ ውስጥ ሲፈስ, ወደ ሌላ ሲፈስስ. የእኛ የፍተሻ ጣቢያ መጣ እና ለመጣል ጥቂት የቆሸሹ ገጾችን ከላከ ፣ ከዚያ ቀስ በቀስ ከከርነል ቋት pgflush ይህ ሁሉ ነገር በጥሩ ሁኔታ ይፈታል።

እነዚህ የቆሸሹ ገፆች መከማቸታቸውን ከቀጠሉ እስከ 20% ድረስ ይሰበስባሉ, ከዚያ በኋላ የስርዓተ ክወናው ቅድሚያ የሚሰጠው ሁሉንም ነገር በዲስክ ላይ መፃፍ ነው, ምክንያቱም ኃይሉ ይወጣል, እና ሁሉም ነገር ለእኛ መጥፎ ይሆናል. ይህን ውሂብ እናጣለን, ለምሳሌ.

ዘዴው ምንድን ነው? ዘዴው እነዚህ መለኪያዎች በዘመናዊው ዓለም ውስጥ 20 እና 10% የሚሆኑት በማሽኑ ላይ ካለው ራም ሁሉ ፣ እርስዎ ካሉዎት ከማንኛውም የዲስክ ስርዓት ፍሰት አንፃር በጣም አስፈሪ ናቸው።

128 ጊባ ራም እንዳለህ አስብ። 12,8 ጂቢ ወደ ዲስክዎ ስርዓት ይመጣል. እና ምንም አይነት መሸጎጫ ቢኖራችሁ፣ ምንም አይነት ድርድር ቢኖራችሁ፣ ያን ያህል መቋቋም አይችሉም።

ስለዚህ እነዚህ ቁጥሮች እንደ RAID መቆጣጠሪያዎ አቅም ላይ በመመስረት ወዲያውኑ እንዲስተካከሉ እንመክራለን። ወዲያውኑ 512 ሜባ መሸጎጫ ላለው መቆጣጠሪያ እዚህ ምክር ሰጠሁ።

ሁሉም ነገር በጣም ቀላል እንደሆነ ይቆጠራል. vm.dirty_backgroundን በባይት ውስጥ ማስቀመጥ ትችላለህ። እና እነዚህ ቅንብሮች የቀደሙትን ሁለቱን ይሽራሉ። ወይ ሬሾው በነባሪ ነው፣ ወይም ባይት ያላቸው ነቅተዋል፣ ከዚያ ባይት ያላቸው ይሰራሉ። ግን እኔ የዲቢኤ አማካሪ ስለሆንኩ እና ከተለያዩ ደንበኞች ጋር ስለምሰራ ገለባ ለማስቀመጥ እሞክራለሁ እና ስለዚህ በባይት ከሆነ ከዚያ በባይት። አንድ ጥሩ አስተዳዳሪ በአገልጋዩ ላይ ማህደረ ትውስታን እንደማይጨምር ፣እንደገና እንደማያስነሳው እና አሃዙ ተመሳሳይ እንደሚሆን ማንም ዋስትና አልሰጠም። ሁሉም ነገር ከዋስትና ጋር እንዲስማማ እነዚህን ቁጥሮች ብቻ አስሉ.

ካልገባህ ምን ይከሰታል? ማንኛውንም ማጠብን በብቃት የሚያቆመው ጽፌያለሁ፣ ነገር ግን እንደ እውነቱ ከሆነ እሱ የንግግር ዘይቤ ነው። የስርዓተ ክወናው ትልቅ ችግር አለው - ብዙ የቆሸሹ ገፆች ስላሉት ደንበኞችዎ የሚያመነጩት IO በትክክል ይቆማል፣ ማለትም አፕሊኬሽኑ የ sql ጥያቄን ወደ ዳታቤዝ ለመላክ መጥቷል፣ እየጠበቀ ነው። ለእሱ ማንኛውም I/O ዝቅተኛው ቅድሚያ የሚሰጠው ነው፣ ምክንያቱም መሰረቱ በቼክ ነጥቡ ተይዟል። እና ስትጨርስ ሙሉ በሙሉ ለመረዳት የማይቻል ነው. እና ከበስተጀርባ ያልሆነ፣ ከበስተጀርባ ያልሆነ መታጠብ ሲደርሱ፣ ሁሉም የእርስዎ አይኦ በእሱ ተይዟል ማለት ነው። እና እስኪያልቅ ድረስ ምንም ነገር አታደርግም.

ከዚህ ሪፖርት ወሰን በላይ የሆኑ ሁለት ተጨማሪ ጠቃሚ ነጥቦች አሉ። እነዚህ ቅንብሮች በpostgresql.conf ውስጥ ካሉት ቅንብሮች ማለትም የፍተሻ ነጥቦች ቅንብሮች ጋር መዛመድ አለባቸው። እና የዲስክ ስርዓትዎ በበቂ ሁኔታ መዋቀር አለበት። በ RAID ላይ መሸጎጫ ካለዎት, ከዚያም ባትሪ ሊኖረው ይገባል. ሰዎች RAIDን ያለ ባትሪ በጥሩ መሸጎጫ ይገዛሉ። በRAID ውስጥ ኤስኤስዲ ካለዎት፣ እነሱ አገልጋይ መሆን አለባቸው፣ capacitors መኖር አለባቸው። የተስፋፋው የማረጋገጫ ዝርዝር ይኸውና በዚህ አገናኝ በ PostgreSQL ውስጥ የዲስክ አፈፃፀምን እንዴት ማዋቀር እንደሚቻል የእኔ ዘገባ አለ። ሁሉም የማረጋገጫ ዝርዝሮች እዚያ አሉ።

ሕይወትን በጣም አስቸጋሪ የሚያደርገው ሌላስ ምንድን ነው? እነዚህ ሁለት አማራጮች ናቸው. በአንጻራዊ ሁኔታ አዲስ ናቸው. በነባሪ, በተለያዩ መተግበሪያዎች ውስጥ ሊካተቱ ይችላሉ. እና በተሳሳተ መንገድ ከበሩ ህይወትን ያወሳስባሉ።

ሁለት በአንጻራዊ ሁኔታ አዲስ ቁርጥራጮች አሉ. በሦስተኛው ኮሮች ውስጥ ቀድሞውኑ ታይተዋል. እነዚህ በ nanoseconds ውስጥ sched_migration_cost እና sched_autogroup_enabled ናቸው ይህም በነባሪ አንድ ነው።

እና ህይወትን እንዴት ያበላሻሉ? የሼድ_ፍልሰት_ዋጋ ምንድን ነው? የሊኑክስ መርሐግብር አዘጋጅ ሂደቱን ከአንድ ሲፒዩ ወደ ሌላ ማዛወር ይችላል። እና ለ PostgreSQL፣ መጠይቆችን ለሚፈጽመው፣ ወደ ሌላ ሲፒዩ መሰደድ ለምን እንደሆነ ሙሉ በሙሉ ለመረዳት የማይቻል ነው። ከስርዓተ ክወና እይታ አንጻር መስኮቶችን በተከፈተው ኦፊስ እና ተርሚናል መካከል ሲቀይሩ ይህ ጥሩ ሊሆን ይችላል ነገር ግን ለዳታቤዝ - በጣም መጥፎ ነው. ስለዚህ፣ ምክንያታዊ ፖሊሲ ፍልሰት_ወጪን ወደ አንድ ትልቅ እሴት ቢያንስ ጥቂት ሺ ናኖሴኮንዶች ማዋቀር ነው።

ይህ ለፕሮግራም አውጪው ምን ማለት ነው? በዚህ ጊዜ ውስጥ ይህ ሂደት አሁንም ትኩስ እንደሆነ ይገመታል. ያም ማለት ለረጅም ጊዜ የሆነ ነገር ሲያደርጉ አንድ ዓይነት ረጅም ግብይት ካለዎት የጊዜ ሰሌዳው አውጪው ይህንን ይረዳል. ይህ ጊዜ እስኪያልፍ ድረስ ይህ ሂደት ወደ የትኛውም ቦታ መዘዋወር እንደማያስፈልግ ይገምታል. በተመሳሳይ ጊዜ ሂደቱ አንድ ነገር ካደረገ, ወደ የትኛውም ቦታ አይሰደዱም, በተመደበው ሲፒዩ ላይ በእርጋታ ያበቃል. ውጤቱም በጣም ጥሩ ነው.

ሁለተኛው ነጥብ ራስ-ግሩፕ ነው. ከዘመናዊ የውሂብ ጎታዎች ጋር ላልሆኑ የተወሰኑ የሥራ ጫናዎች ጥሩ ሀሳብ አለ - ይህ በተጀመሩበት ምናባዊ ተርሚናል ሂደቶችን መቧደን ነው። ለአንዳንድ ስራዎች ምቹ ነው. በተግባር፣ PostgreSQL ከአንድ ተርሚናል የሚሰራ ቅድመ ፎርክ ባለብዙ ሂደት ስርዓት ነው። የመቆለፊያ ጸሐፊ፣ የፍተሻ ነጥብ አለህ፣ እና ሁሉም የደንበኛህ ጥያቄዎች በአንድ መርሐግብር አዘጋጅ፣ በአንድ ሲፒዩ ተመድበዋል። እርስ በርሳቸው ለመጠላለፍ እና ብዙ ጊዜ እንዲጠመዱበት, ነፃ ሲወጣ አብረው ይጠብቃሉ. ይህ በእንደዚህ ዓይነት ጭነት ሁኔታ ውስጥ ሙሉ በሙሉ አላስፈላጊ የሆነ ታሪክ ነው እና ስለሆነም ማጥፋት አለበት.

የሥራ ባልደረባዬ አሌክሲ ሌሶቭስኪ በቀላል pgbench ሙከራዎችን አድርጓል፣ በዚያም migration_cost በትልልቅ ትእዛዝ ጨምሯል እና ራስ-ግሩፕን አጠፋ። በመጥፎ ብረት ላይ ያለው ልዩነት ወደ 10% ገደማ ሆኗል.. ሰዎች በጥያቄ ፍጥነት ላይ ተመሳሳይ ለውጦችን የመሳሰሉ ውጤቶችን የሚዘግቡበት በፖስትግሬስ የደብዳቤ መላኪያ ዝርዝር ላይ ውይይት አለ። 50% ተጽዕኖ አሳድሯል. እንደዚህ ያሉ ታሪኮች በጣም ጥቂት ናቸው.

እና በመጨረሻም ስለ ኃይል ቆጣቢ ፖሊሲ. ሊኑክስ አሁን በላፕቶፕ ላይ መጠቀም መቻሉ ጥሩ ነው። እና ባትሪውን በደንብ ያጠፋል ተብሎ ይታሰባል። ግን በድንገት ይህ በአገልጋዩ ላይም ሊከሰት እንደሚችል ተገለጠ።

በተጨማሪም፣ ከአንዳንድ አስተናጋጅ አገልጋዮችን ከተከራዩ፣ “ጥሩ” አስተናጋጆች የተሻለ አፈጻጸም እንዳለዎት ግድ የላቸውም። የእነሱ ተግባር ብረቱ በተቻለ መጠን በብቃት መጠቀሙን ማረጋገጥ ነው. ስለዚህ, በነባሪ, በስርዓተ ክወናው ላይ የሊፕቶፑን የኃይል ቁጠባ ሁነታን ማብራት ይችላሉ.

ይህን በጣም በተጫነ የውሂብ ጎታ አገልጋይ ላይ እየተጠቀምክ ከሆነ፣ ምርጫህ acpi_cpufreq + permormance ነው። ከፍላጎት ጋር እንኳን, ቀድሞውኑ ችግሮች ይኖራሉ.

Intel_pstate ትንሽ የተለየ ሾፌር ነው። እና አሁን ለዚህ ምርጫ ተሰጥቷል, እንደ በኋላ እና የተሻለ እንደሚሰራ.

እናም, በዚህ መሰረት, ገዥው አፈፃፀም ብቻ ነው. Ondemand, powersave እና ሁሉም የቀሩት - ይህ ስለ አንተ አይደለም.

የማብራሪያ ትንተና PostgreSQL ውጤቶቹ powersave ን ካነቁ በብዙ ትእዛዞች ሊለያዩ ይችላሉ፣ ምክንያቱም በተግባር ሙሉ በሙሉ ሊተነበይ በማይችል መልኩ ሲፒዩ በመረጃ ቋቱ ስር መጥፋት ይኖርዎታል።

እነዚህ ነገሮች በነባሪነት ሊነቁ ይችላሉ። በነባሪነት የነቁ መሆናቸውን ለማየት በጥንቃቄ ይመልከቱ። ይህ በእውነት ትልቅ ችግር ሊሆን ይችላል.

እና በመጨረሻ ፣ በየቀኑ በዚህ ንግድ ውስጥ እብጠቶችን የሚሞሉትን ከ PosgreSQL-Consulting DBA ቡድን ማለትም ማክስ ቦጉክ እና አሌክሲ ሌሶቭስኪ ላሉት ወንዶች አመሰግናለሁ ለማለት ፈልጌ ነበር። እና ለደንበኞቻችን, ሁሉም ነገር ለእነሱ እንዲሰራ, ምርጡን ለማድረግ እየሞከርን ነው. ልክ እንደ የአቪዬሽን ደህንነት መመሪያ ነው። እዚህ ሁሉም ነገር በደም ተጽፏል. እያንዳንዳቸው እነዚህ ፍሬዎች በአንድ ዓይነት ችግር ሂደት ውስጥ ይገኛሉ. እነሱን ላካፍላችሁ ደስተኛ ነኝ።

ጥያቄዎች:

አመሰግናለሁ! ለምሳሌ አንድ ኩባንያ ገንዘብ መቆጠብ እና የውሂብ ጎታውን እና የአፕሊኬሽኑን አመክንዮ በተመሳሳይ አገልጋይ ላይ ማስተናገድ ከፈለገ ወይም ኩባንያው PostgreSQL በኮንቴይነር ውስጥ የሚሰራበትን የማይክሮ ሰርቪስ አርክቴክቸር የፋሽን አዝማሚያ የሚከተል ከሆነ። ምን ዋጋ አለው? Sysctl በአለምአቀፍ ደረጃ መላውን ከርነል ይጎዳል። ሲሳይክሎች በመያዣው ላይ ለየብቻ እንዲሰሩ በሆነ መንገድ ቨርቹዋል እንደሆኑ አልሰማሁም። ስብስብ ብቻ ነው ያለው እና የሱ ክፍል ብቻ ቁጥጥር አለው። ከዚህ ጋር እንዴት መኖር ይቻላል? ወይም አፈጻጸም ከፈለጋችሁ PostgreSQLን በተለየ የብረት አገልጋይ ላይ ያሂዱ እና ያስተካክሉት?

ለጥያቄህ በሦስት መንገዶች መልስ ሰጥተነዋል። ስለ ብረት ሰርቨር ወዘተ እየተነጋገርን ካልሆነ ዘና ይበሉ ፣ ያለ እነዚህ ቅንብሮች ሁሉም ነገር በጥሩ ሁኔታ ይሰራል። እንደዚህ አይነት ጭነት ካለዎት እነዚህን መቼቶች ማድረግ ያስፈልግዎታል, ከዚያ ከእነዚህ ቅንብሮች ቀድመው ወደ ብረት አገልጋይ ይመጣሉ.

ችግሩ ምንድን ነው? ይህ ምናባዊ ማሽን ከሆነ ምናልባት ብዙ ችግሮች ሊያጋጥሙዎት ይችላሉ ፣ ለምሳሌ ፣ አብዛኛዎቹ ቨርቹዋል ማሽኖች ወጥነት የሌለው የዲስክ መዘግየት ስላላቸው። ምንም እንኳን የዲስክ ፍሰት ጥሩ ቢሆንም፣ አንድ ያልተሳካ የI/O ግብይት በፍተሻ ቦታ ላይ ወይም በደብዳቤ ለ WAL በተጻፈበት ወቅት የተከሰተውን አማካይ የፍተሻ መጠን በእጅጉ የማይጎዳ ከሆነ የመረጃ ቋቱ ከዚህ በእጅጉ ይጎዳል። እና ወደ እነዚህ ችግሮች ከመሄድዎ በፊት ይህንን ያስተውላሉ።

በተመሳሳዩ አገልጋይ ላይ NGINX ካለዎት, እርስዎም ተመሳሳይ ችግር አለብዎት. ለጋራ ትውስታ ይዋጋል። እና እዚህ የተገለጹትን ችግሮች አይደርሱዎትም.

ግን በሌላ በኩል ፣ ከእነዚህ መለኪያዎች ውስጥ አንዳንዶቹ አሁንም ለእርስዎ ጠቃሚ ይሆናሉ። ለምሳሌ ፣ በ sysctl ፣ በጣም እብድ እንዳይሆን የ dirty_ratio ያዘጋጁ - በማንኛውም ሁኔታ ይህ ይረዳል። አንድ መንገድ ወይም ሌላ ከዲስክ ጋር መስተጋብር ይኖርዎታል. እና ስህተት ይሆናል. ይህ ባጠቃላይ እኔ ያሳየኋቸው የመለኪያዎች ነባሪ ነው። እና በማንኛውም ሁኔታ እነሱን መቀየር የተሻለ ነው.

እና ከNUMA ጋር ችግሮች ሊኖሩ ይችላሉ. VmWare, ለምሳሌ, በትክክል ከ NUMA ጋር በትክክል ከተቃራኒ ቅንብሮች ጋር ይሰራል. እና እዚህ መምረጥ አለብዎት - የብረት አገልጋይ ወይም ብረት ያልሆነ.

ከአማዞን AWS ጋር የተያያዘ ጥያቄ አለኝ። አስቀድመው የተዋቀሩ ምስሎች አሏቸው። ከመካከላቸው አንዱ Amazon RDS ይባላል. ለስርዓተ ክወናቸው ብጁ ቅንጅቶች አሉ?

ቅንጅቶች አሉ, ግን የተለያዩ ቅንብሮች ናቸው. ዳታቤዙ ይህንን ንግድ እንዴት እንደሚጠቀምበት አንፃር ኦፕሬቲንግ ሲስተሙን እናዋቅረዋለን። እና አሁን የት መሄድ እንዳለብን የሚወስኑ መለኪያዎች አሉ, እንደዚህ አይነት ቅርጽ. ያም ማለት ብዙ ሀብቶች እንፈልጋለን, አሁን እንበላለን. ከዚያ በኋላ፣ Amazon RDS እነዚህን ሀብቶች ያጠናክራል፣ እና አፈፃፀሙ እዚያ ይወድቃል። በዚህ ጉዳይ ላይ ሰዎች እንዴት ኬሚስትሪ እንደሚጀምሩ የተለያዩ ታሪኮች አሉ. አንዳንድ ጊዜ በተሳካ ሁኔታ እንኳን። ግን ከስርዓተ ክወና ቅንብሮች ጋር ምንም ግንኙነት የለውም. ልክ እንደ ደመና መጥለፍ ነው። የተለየ ታሪክ ነው።

ለምንድነው ግልፅ ግዙፍ ገፆች ከ Huge TLB ጋር ሲነፃፀሩ ምንም ተጽእኖ አይኖራቸውም?

አትስጡ. ይህ በብዙ መንገዶች ሊገለጽ ይችላል. ግን በእውነቱ እነሱ አይሰጡትም። የ PostgreSQL ታሪክ ምንድነው? ጅምር ላይ፣ ብዙ የጋራ ማህደረ ትውስታን ይመድባል። ግልጽ እነሱ በተመሳሳይ ጊዜ ናቸው ወይም ግልጽ አይደሉም - ምንም አይደለም. በጅማሬ ላይ ጎልተው መውጣታቸው ሁሉንም ነገር ያብራራል. እና ብዙ ማህደረ ትውስታ ካለ እና የተጋራውን_ማህደረ ትውስታ ክፍል እንደገና መገንባት ካስፈለገዎት ግልፅ ግዙፍ ገጾች ተዛማጅ ይሆናሉ። በ PostgreSQL ውስጥ፣ በቀላሉ በጅምር ላይ በትልቅ ቁራጭ ይደምቃል እና ያ ነው፣ እና ከዚያ ምንም ልዩ ነገር እዚያ አይከሰትም። እርግጥ ነው፣ ሊጠቀሙበት ይችላሉ፣ ነገር ግን የሆነን ነገር በድጋሚ ሲመድብ የተጋራ_memory የማግኘት እድል አለ። PostgreSQL ስለዚህ ጉዳይ አያውቅም።

ምንጭ: hab.com