እንደ ውስጥ አብዛኞቹ ልጥፎች, በተከፋፈለ አገልግሎት ላይ ችግር አለ, ይህን አገልግሎት አልቪን ብለን እንጠራዋለን. በዚህ ጊዜ እኔ ራሴ ችግሩን አላገኘሁም, ከደንበኛው ወገን ያሉት ሰዎች ነገሩኝ.

አንድ ቀን ከአልቪን ጋር ለረጅም ጊዜ በመዘግየቶች ምክንያት ቅር የተሰኘ ኢሜይል ከእንቅልፌ ነቃሁ፣ በቅርብ ጊዜ ውስጥ ለመጀመር አቅደን ነበር። በተለይም፣ ደንበኛው በ99 ሚሴ ክልል ውስጥ 50ኛ ፐርሰንታይል መዘግየት አጋጥሞታል፣ ይህም ከእኛ የዘገየነት በጀት የበለጠ ነው። አገልግሎቱን በስፋት ስፈትሽ ይህ የሚያስደንቅ ነበር፣በተለይም በመዘግየት ላይ፣ይህም የተለመደ ቅሬታ ነው።

አልቪንን ወደ ሙከራ ከማስገባቴ በፊት በሴኮንድ 40k መጠይቆች (QPS) ብዙ ሙከራዎችን ሮጬአለሁ፣ ሁሉም ከ10ሚሴ በታች መዘግየት ያሳያሉ። በውጤታቸው እንዳልስማማሁ ለመግለፅ ተዘጋጅቻለሁ። ነገር ግን ደብዳቤውን ሌላ ስመለከት፣ አዲስ ነገር አስተዋልኩ፡ የጠቀሷቸውን ሁኔታዎች በትክክል አልሞከርኩም፣ የእነሱ QPS ከእኔ በጣም ያነሰ ነበር። በ 40k QPS ሞከርኩ ነገር ግን እነሱ በ 1 ኪ. እኔ ሌላ ሙከራ ሮጥኩ፣ በዚህ ጊዜ ዝቅተኛ QPS፣ እነሱን ለማስደሰት ብቻ።

እኔ ስለዚህ ጉዳይ እየጦመርኩ ስለሆንኩ ምናልባት ቁጥራቸው ትክክል እንደሆነ አስቀድመው ያውቁ ይሆናል። ምናባዊ ደንበኛዬን ደጋግሜ ሞከርኩት፣ በተመሳሳይ ውጤት፡ አነስተኛ ቁጥር ያላቸው ጥያቄዎች መዘግየትን ብቻ ሳይሆን ከ10 ሚሴ በላይ በሆነ መዘግየት የጥያቄዎችን ብዛት ይጨምራል። በሌላ አነጋገር፣ በ40k QPS በሴኮንድ 50 የሚጠጉ ጥያቄዎች ከ50 ሚሴ በላይ ከሆነ፣ በ1k QPS በየሰከንዱ ከ100 ሚሴ በላይ 50 ጥያቄዎች ነበሩ። ፓራዶክስ!

ፍለጋውን በማጥበብ ላይ

ብዙ አካላት ባሉበት በተከፋፈለ ስርዓት ውስጥ የመዘግየት ችግር ሲያጋጥመው የመጀመሪያው እርምጃ የተጠርጣሪዎችን አጭር ዝርዝር መፍጠር ነው. ወደ አልቪን አርክቴክቸር ትንሽ ጠለቅ ብለን እንመልከት፡-

ጥሩ መነሻ ነጥብ የተጠናቀቁ የ I/O ሽግግሮች (የአውታረ መረብ ጥሪዎች/የዲስክ ፍለጋዎች፣ ወዘተ) ዝርዝር ነው። መዘግየቱ የት እንዳለ ለማወቅ እንሞክር። ከደንበኛው ጋር ካለው ግልጽ I/O በተጨማሪ፣ Alvin ተጨማሪ እርምጃ ይወስዳል፡ ወደ ዳታ ማከማቻው ይደርሳል። ነገር ግን፣ ይህ ማከማቻ ከአልቪን ጋር በተመሳሳይ ክላስተር ውስጥ ይሰራል፣ ስለዚህ እዚያ ያለው መዘግየት ከደንበኛው ያነሰ መሆን አለበት። ስለዚህ የተጠርጣሪዎች ዝርዝር፡-

የአውታረ መረብ ጥሪ ከደንበኛ ወደ Alvin.
የአውታረ መረብ ጥሪ ከአልቪን ወደ ዳታ ማከማቻ።
በመረጃ ማከማቻ ውስጥ በዲስክ ላይ ይፈልጉ።
የአውታረ መረብ ጥሪ ከውሂብ መጋዘን ወደ አልቪን.
የአውታረ መረብ ጥሪ ከአልቪን ወደ ደንበኛ።

አንዳንድ ነጥቦችን ለማንሳት እንሞክር።

የውሂብ ማከማቻ ከእሱ ጋር ምንም ግንኙነት የለውም

መጀመሪያ ያደረግኩት አልቪንን ወደ ፒንግ ፒንግ አገልጋይ ወደማያስተናግድ አገልግሎት መለወጥ ነበር። ጥያቄ ሲደርሰው ባዶ ምላሽ ይመልሳል። መዘግየት ከቀነሰ በአልቪን ወይም በመረጃ ማከማቻ አተገባበር ላይ ያለ ስህተት የማይሰማ ነገር አይደለም። በመጀመሪያው ሙከራ ውስጥ የሚከተለውን ግራፍ እናገኛለን:

እንደሚመለከቱት, የፒንግ-ፒንግ አገልጋይ ሲጠቀሙ ምንም መሻሻል የለም. ይህ ማለት የመረጃ ማከማቻው መዘግየትን አይጨምርም ፣ እና የተጠርጣሪዎች ዝርዝር በግማሽ ተቆርጧል።

የአውታረ መረብ ጥሪ ከደንበኛ ወደ Alvin.
የአውታረ መረብ ጥሪ ከአልቪን ወደ ደንበኛ።

በጣም ጥሩ! ዝርዝሩ በፍጥነት እየጠበበ ነው። ምክንያቱን ለማወቅ ከሞላ ጎደል መሰለኝ።

ጂአርፒሲ

ከአዲስ ተጫዋች ጋር ለማስተዋወቅ ጊዜው አሁን ነው፡- ጂአርፒሲ. ይህ በሂደት ላይ ላለ ግንኙነት ከGoogle የመጣ ክፍት ምንጭ ቤተ-መጽሐፍት ነው። ፒ ፒ… ቢሆንም gRPC በጥሩ ሁኔታ የተመቻቸ እና በሰፊው ጥቅም ላይ የዋለ ፣ ይህ በዚህ መጠን ስርዓት ላይ ስጠቀምበት የመጀመሪያዬ ነበር እና የእኔ ትግበራ በጣም ጥሩ ይሆናል ብዬ ጠብቄ ነበር - ቢያንስ።

ለማገኘት አለማስቸገር gRPC ቁልል ውስጥ አዲስ ጥያቄ አስከትሏል: ምናልባት የእኔ አተገባበር ወይም እራሴ ሊሆን ይችላል gRPC የመዘግየት ችግር ይፈጥራል? አዲስ ተጠርጣሪ ወደ ዝርዝሩ መጨመር፡-

ደንበኛው ወደ ቤተ-መጽሐፍት ይደውላል gRPC
ቤተ መጻሕፍት gRPC በደንበኛው ላይ ወደ ቤተ-መጽሐፍት የአውታረ መረብ ጥሪ ያደርጋል gRPC በአገልጋይ ላይ
ቤተ መጻሕፍት gRPC እውቂያዎች አልቪን (በፒንግ-ፖንግ አገልጋይ ውስጥ ምንም ዓይነት አሠራር የለም)

ኮዱ ምን እንደሚመስል ሀሳብ ለመስጠት ደንበኛዬ/አልቪን አተገባበር ከደንበኛ አገልጋይ ብዙም የተለየ አይደለም ምሳሌዎችን አስምር.

ማስታወሻ፡ ከላይ ያለው ዝርዝር ትንሽ ቀለል ያለ ነው ምክንያቱም gRPC የማስፈጸሚያ ቁልል የተጠላለፈበት የራስዎን (አብነት?) ክር ሞዴል ለመጠቀም ያስችላል። gRPC እና የተጠቃሚ ትግበራ. ለቀላልነት, በዚህ ሞዴል ላይ እንጣበቃለን.

መገለጫ ሁሉንም ነገር ያስተካክላል

የመረጃ ማከማቻዎቹን ካቋረጥኩ በኋላ፣ ለመጨረስ የቀረኝ መስሎኝ ነበር፡ “አሁን ቀላል ነው! መገለጫውን እንተገብረው እና መዘግየቱ የት እንደሚከሰት እንወቅ። አይ የትክክለኛነት መገለጫ ትልቅ አድናቂምክንያቱም ሲፒዩዎች በጣም ፈጣን ናቸው እና አብዛኛውን ጊዜ ማነቆዎች አይደሉም። አብዛኛው መዘግየቶች የሚከሰቱት ፕሮሰሰሩ ሌላ ነገር ለመስራት ሂደቱን ማቆም ሲኖርበት ነው። ትክክለኛ የሲፒዩ ፕሮፋይሊንግ እንዲሁ ያደርጋል፡ ሁሉንም ነገር በትክክል ይመዘግባል አውድ መቀየሪያዎች እና መዘግየቶች የት እንደሚገኙ ግልጽ ያደርገዋል.

አራት መገለጫዎችን ወስጃለሁ: በከፍተኛ QPS (ዝቅተኛ መዘግየት) እና በፒንግ-ፖንግ አገልጋይ ዝቅተኛ QPS (ከፍተኛ መዘግየት) በደንበኛው በኩል እና በአገልጋዩ በኩል። እና እንደዚያ ከሆነ፣ እኔም የናሙና ፕሮሰሰር ፕሮፋይል ወሰድኩ። መገለጫዎችን ሳወዳድር፣ ብዙ ጊዜ ያልተለመደ የጥሪ ቁልል ፈልጋለሁ። ለምሳሌ፣ ከከፍተኛ መዘግየት ጋር በመጥፎው በኩል ብዙ ተጨማሪ የአውድ መቀየሪያዎች (10 ጊዜ ወይም ከዚያ በላይ) አሉ። ነገር ግን በእኔ ሁኔታ፣ የአውድ መቀየሪያዎች ብዛት ከሞላ ጎደል ተመሳሳይ ነበር። ለኔ አስፈሪ፣ እዚያ ምንም ጠቃሚ ነገር አልነበረም።

ተጨማሪ ማረም

ተስፋ ቆርጬ ነበር። ምን ሌሎች መሳሪያዎችን መጠቀም እንደምችል አላውቅም ነበር፣ እና ቀጣዩ እቅዴ ችግሩን በግልፅ ከመመርመር ይልቅ በተለያዩ ልዩነቶች የተደረጉ ሙከራዎችን መድገም ነበር።

ቢሆንስ

ከመጀመሪያው ጀምሮ፣ ስለ ልዩ የ50ms መዘግየት አሳስቦት ነበር። ይህ በጣም ትልቅ ጊዜ ነው። የትኛው ክፍል ለዚህ ስህተት መንስኤ እንደሆነ በትክክል እስካውቅ ድረስ ከኮዱ ውስጥ ቁርጥራጮቹን ለመቁረጥ ወሰንኩ ። ከዚያም ውጤታማ የሆነ ሙከራ መጣ.

እንደተለመደው ፣ በቅድመ-እይታ ሁሉም ነገር ግልፅ ይመስላል። ደንበኛው በአልቪን ተመሳሳይ ማሽን ላይ አስቀምጫለሁ - እና ጥያቄ ልኬያለሁ localhost. እና የመዘግየቱ መጨመር ጠፍቷል!

በአውታረ መረቡ ላይ የሆነ ችግር ነበር።

የአውታረ መረብ መሐንዲስ ክህሎቶችን መማር

መቀበል አለብኝ፡ ስለ ኔትወርክ ቴክኖሎጂዎች ያለኝ እውቀት በጣም አስፈሪ ነው፣ በተለይም በየቀኑ አብሬያቸው የምሰራውን እውነታ ግምት ውስጥ በማስገባት። ነገር ግን አውታረ መረቡ ዋነኛው ተጠርጣሪ ነበር, እና እንዴት ማረም እንዳለብኝ መማር ነበረብኝ.

እንደ እድል ሆኖ, በይነመረብ መማር የሚፈልጉትን ይወዳል. የፒንግ እና ትራሰርት ጥምረት የኔትወርክ ትራንስፖርት ችግሮችን ለማረም በቂ ጅምር ይመስላል።

መጀመሪያ ጀመርኩ። PsPing ወደ አልቪን TCP ወደብ. ነባሪ ቅንብሮችን ተጠቀምኩ - ምንም ልዩ ነገር የለም። ከአንድ ሺህ የሚበልጡ ፒንግዎች ከ10 ሚሴ ያልበለጠ፣ ለማሞቅ የመጀመሪያው ካልሆነ በስተቀር። ይህ በ50ኛ ፐርሰንታይል የ99 ms የዘገየ ጭማሪ ጋር ይቃረናል፡ እዛ፣ ለ100 ጥያቄዎች፣ ስለ አንድ ጥያቄ በ50 ms መዘግየት ማየት ነበረብን።

ከዚያም ሞከርኩ። መከታተያበአልቪን እና በደንበኛው መካከል ባለው መንገድ ላይ ካሉት አንጓዎች በአንዱ ላይ ችግር ሊኖር ይችላል። ነገር ግን ዱካው እንዲሁ ባዶ እጁን ተመለሰ።

ስለዚህ መዘግየቱን የፈጠረው የእኔ ኮድ፣ የ gRPC ትግበራ ወይም አውታረ መረብ አልነበረም። ይህንን በፍፁም እንደማልረዳው መጨነቅ ጀመርኩ።

አሁን በምን አይነት ስርዓተ ክወና ላይ ነን

gRPC በሊኑክስ ላይ በስፋት ጥቅም ላይ የዋለ ፣ ግን በዊንዶው ላይ ያልተለመደ። አንድ ሙከራ ለመሞከር ወሰንኩ፣ ይህም ሰርቷል፡ የሊኑክስ ቨርቹዋል ማሽን ፈጠርኩ፣ አልቪንን ለሊኑክስ አሰባስቤ አሰማርኩት።

እና የሆነው ይኸው ነው፡ የሊኑክስ ፒንግ-ፖንግ አገልጋይ እንደ ተመሳሳይ የዊንዶውስ አስተናጋጅ አይነት መዘግየቶች አልነበረውም ምንም እንኳን የመረጃ ምንጩ ከዚህ የተለየ ባይሆንም። ችግሩ ለዊንዶውስ በ gRPC አተገባበር ውስጥ እንዳለ ሆኖ ተገኝቷል።

የናግል አልጎሪዝም

በዚህ ጊዜ ሁሉ ባንዲራ የጠፋኝ መሰለኝ። gRPC. አሁን በትክክል ምን እንደሆነ ገባኝ። gRPC የዊንዶው ባንዲራ ጠፍቷል። ለሁሉም ባንዲራዎች በጥሩ ሁኔታ እንደሚሰራ እርግጠኛ የሆንኩበት የውስጥ RPC ቤተ-መጽሐፍት አገኘሁ ዊንሶክ. ከዚያም እነዚህን ሁሉ ባንዲራዎች ወደ gRPC ጨምሬ አልቪንን በዊንዶው ላይ፣ በተጣበቀ የዊንዶውስ ፒንግ-ፖንግ አገልጋይ ውስጥ አሰማርኳቸው!

በቃ ማለት ይቻላል ተጠናቅቋል፡ ምክንያቱን ለማወቅ እንድችል ተሃድሶው እስኪመለስ ድረስ የተጨመሩትን ባንዲራዎች አንድ በአንድ ማስወገድ ጀመርኩ። ዝነኛ ነበር። TCP_NODELAY፣ የናግል አልጎሪዝም መቀየሪያ።

የናግል አልጎሪዝም የፓኬቱ መጠን ከተወሰነ ባይት በላይ እስኪያልፍ ድረስ የመልእክቶችን ስርጭት በማዘግየት በአውታረ መረብ ላይ የሚላኩ ፓኬቶችን ለመቀነስ ይሞክራል። ይህ ለአማካይ ተጠቃሚ ጥሩ ሊሆን ቢችልም OS አንዳንድ መልዕክቶችን ስለሚዘገይ ዝቅተኛ QPS እንዲዘገይ ስለሚያደርግ ለእውነተኛ ጊዜ አገልጋዮች አጥፊ ነው። ዩ gRPC ይህ ባንዲራ በሊኑክስ ትግበራ ለTCP ሶኬቶች ተቀምጧል፣ ግን በዊንዶውስ ውስጥ የለም። እኔ ይሄ ነኝ ተስተካክሏል.

መደምደሚያ

ዝቅተኛ QPS ላይ ያለው ከፍተኛ መዘግየት የተፈጠረው በስርዓተ ክወና ማመቻቸት ነው። ወደ ኋላ መለስ ብለን ፕሮፋይል ማድረግ መዘግየትን አላገኘም ምክንያቱም ከውስጥ ይልቅ በከርነል ሁነታ የተሰራ ነው። የተጠቃሚ ሁነታ. የናግል አልጎሪዝም በ ETW ቀረጻዎች ይታይ እንደሆነ አላውቅም፣ ግን አስደሳች ነበር።

የአካባቢ አስተናጋጅ ሙከራን በተመለከተ፣ ምናልባት ትክክለኛውን የአውታረ መረብ ኮድ አልነካም እና የናግል አልጎሪዝም አልሰራም ነበር፣ ስለዚህ ደንበኛው በ localhost በኩል አልቪን ሲደርስ የመዘግየት ችግሮች ጠፉ።

በሰከንድ የጥያቄዎች ብዛት ሲቀንስ የቆይታ መጨመር ሲያዩ የናግል አልጎሪዝም በተጠርጣሪዎች ዝርዝርዎ ውስጥ መሆን አለበት!

ምንጭ: hab.com

አንዳንድ ጊዜ ተጨማሪ ያነሰ ነው. ጭነት ሲቀንስ መዘግየት እየጨመረ ይሄዳል