මෙන් බොහෝ තනතුරු, බෙදා හරින ලද සේවාවක ගැටලුවක් තිබේ, අපි මෙම සේවාව ඇල්වින් ලෙස හඳුන්වමු. මේ වතාවේ මම ගැටලුව මා විසින්ම සොයා ගත්තේ නැත, සේවාදායකයා පාර්ශවයේ අය මට දැනුම් දුන්නා.

අපි නුදුරු අනාගතයේ දියත් කිරීමට සැලසුම් කළ ඇල්වින් සමඟ දිගු ප්‍රමාදයන් හේතුවෙන් දිනක් මම අතෘප්තිමත් විද්‍යුත් තැපෑලකින් අවදි වුණෙමි. විශේෂයෙන්, සේවාලාභියා 99 ms කලාපය තුළ 50 වැනි ප්‍රතිශත ප්‍රමාදය අත්විඳ ඇත, එය අපගේ ප්‍රමාද අයවැයට වඩා බෙහෙවින් වැඩි ය. මම සේවාව පුළුල් ලෙස පරීක්‍ෂා කළ නිසා මෙය පුදුමයට කරුණක් විය, විශේෂයෙන් ම පොදු පැමිණිල්ලක් වන ප්‍රමාදය.

මම ඇල්වින්ව පරීක්‍ෂාවට ලක් කිරීමට පෙර, මම තත්පරයකට 40k විමසුම් (QPS) සමඟ බොහෝ අත්හදා බැලීම් සිදු කළෙමි, ඒ සියල්ල 10ms ට වඩා අඩු ප්‍රමාදයක් පෙන්නුම් කරයි. මම ඔවුන්ගේ ප්‍රතිඵලවලට එකඟ නොවන බව ප්‍රකාශ කිරීමට සූදානම් වුණා. නමුත් ලිපිය දෙස නැවත බැලීමෙන්, මම අලුත් දෙයක් දුටුවෙමි: මම ඔවුන් සඳහන් කළ කොන්දේසි හරියටම පරීක්ෂා කර නැත, ඔවුන්ගේ QPS මට වඩා බෙහෙවින් අඩු ය. මම 40k QPS වලින් පරීක්‍ෂා කළා, නමුත් ඒවා 1k ට පමණයි. මම තවත් අත්හදා බැලීමක් ක්‍රියාත්මක කළෙමි, මෙවර අඩු QPS සමඟ, ඔවුන් සනසනු පිණිස පමණි.

මම මේ ගැන බ්ලොග් ලියන නිසා, ඔවුන්ගේ අංක නිවැරදි බව ඔබ දැනටමත් තේරුම් ගෙන ඇති. මම මගේ අතථ්‍ය සේවාලාභියා නැවත නැවතත් පරීක්‍ෂා කළේ එකම ප්‍රතිඵලයක් සමඟිනි: අඩු ඉල්ලීම් සංඛ්‍යාවක් ප්‍රමාදය වැඩි කරනවා පමණක් නොව, 10 ms ට වැඩි ප්‍රමාදයක් සහිත ඉල්ලීම් ගණන වැඩි කරයි. වෙනත් වචන වලින් කිවහොත්, 40k QPS දී තත්පරයට ඉල්ලීම් 50 ක් පමණ 50 ms ඉක්මවන්නේ නම්, 1k QPS වලදී සෑම තත්පරයකම 100 ms ට වැඩි ඉල්ලීම් 50 ක් ඇත. විරුද්ධාභාසය!

සෙවීම පටු කිරීම

බොහෝ සංරචක සහිත බෙදා හරින ලද පද්ධතියක ප්‍රමාද දෝෂයකට මුහුණ දෙන විට, පළමු පියවර වන්නේ සැකකරුවන්ගේ කෙටි ලැයිස්තුවක් නිර්මාණය කිරීමයි. අපි ඇල්වින්ගේ ගෘහ නිර්මාණ ශිල්පය ගැන ටිකක් ගැඹුරට හාරමු:

හොඳ ආරම්භක ලක්ෂ්‍යයක් වන්නේ සම්පුර්ණ කරන ලද I/O සංක්‍රාන්ති ලැයිස්තුවකි (ජාල ඇමතුම්/තැටි සෙවීම් ආදිය). ප්‍රමාදය කොතැනදැයි සොයා බැලීමට උත්සාහ කරමු. සේවාදායකයා සමඟ ඇති පැහැදිලි I/O වලට අමතරව, ඇල්වින් අමතර පියවරක් ගනී: ඔහු දත්ත ගබඩාවට ප්‍රවේශ වේ. කෙසේ වෙතත්, මෙම ගබඩාව ඇල්වින් මෙන් එකම පොකුරේම ක්‍රියාත්මක වේ, එබැවින් එහි ප්‍රමාදය සේවාදායකයාට වඩා අඩු විය යුතුය. එබැවින්, සැකකරුවන්ගේ ලැයිස්තුව:

1. සේවාලාභියාගෙන් ඇල්වින්ට ජාල ඇමතුම.
2. ඇල්වින්ගෙන් දත්ත ගබඩාවට ජාල ඇමතුම.
3. දත්ත ගබඩාවේ තැටියේ සොයන්න.
4. ඇල්වින් වෙත දත්ත ගබඩාවෙන් ජාල ඇමතුම.
5. ඇල්වින්ගෙන් සේවාලාභියෙකුට ජාල ඇමතුම.

අපි කරුණු කිහිපයක් හරස් කිරීමට උත්සාහ කරමු.

දත්ත ගබඩා කිරීම සමඟ කිසිදු සම්බන්ධයක් නැත

මම මුලින්ම කළේ ඇල්වින් ඉල්ලීම් ක්‍රියාවට නංවන්නේ නැති ping-ping සේවාදායකයකට පරිවර්තනය කිරීමයි. එයට ඉල්ලීමක් ලැබුණු විට, එය හිස් ප්‍රතිචාරයක් ලබා දෙයි. ප්‍රමාදය අඩු වුවහොත්, ඇල්වින් හෝ දත්ත ගබඩාව ක්‍රියාත්මක කිරීමේ දෝෂයක් අසාමාන්‍ය දෙයක් නොවේ. පළමු අත්හදා බැලීමේදී අපට පහත ප්‍රස්ථාරය ලැබේ:

ඔබට පෙනෙන පරිදි, ping-ping සේවාදායකය භාවිතා කරන විට කිසිදු දියුණුවක් නොමැත. මෙයින් අදහස් කරන්නේ දත්ත ගබඩාව ප්‍රමාදය වැඩි නොකරන අතර සැකකරුවන්ගේ ලැයිස්තුව අඩකින් කපා ඇති බවයි:

1. සේවාලාභියාගෙන් ඇල්වින්ට ජාල ඇමතුම.
2. ඇල්වින්ගෙන් සේවාලාභියෙකුට ජාල ඇමතුම.

මහා! ලැයිස්තුව ඉක්මනින් හැකිලෙමින් පවතී. මම හිතුවේ හේතුව මම බොහෝ දුරට තේරුම් ගෙන ඇති බවයි.

gRPC

දැන් ඔබට නව ක්‍රීඩකයෙකු හඳුන්වා දීමට කාලයයි. gRPC. මෙය ක්‍රියාවලි සන්නිවේදනය සඳහා Google වෙතින් විවෘත මූලාශ්‍ර පුස්තකාලයකි ආර්පීසී. වුවද gRPC හොඳින් ප්‍රශස්ත කර පුළුල් ලෙස භාවිතා කර ඇත, මෙය මෙම ප්‍රමාණයේ පද්ධතියක එය භාවිතා කරන පළමු අවස්ථාව මෙය වන අතර මගේ ක්‍රියාත්මක කිරීම උපප්‍රශස්ත වනු ඇතැයි මම අපේක්ෂා කළෙමි - අවම වශයෙන් කිවහොත්.

ලබා ගත හැකි gRPC තොගයේ නව ප්‍රශ්නයක් මතු විය: සමහර විට එය මගේ ක්‍රියාත්මක කිරීම හෝ මා විය හැකිය gRPC ප්‍රමාද ගැටලුවක් ඇති කරන්නේද? නව සැකකරුවෙකු ලැයිස්තුවට එකතු කිරීම:

1. සේවාදායකයා පුස්තකාලය අමතයි gRPC
2. පුස්තකාලය gRPC සේවාලාභියාගේ පුස්තකාලයට ජාල ඇමතුමක් ලබා දෙයි gRPC සේවාදායකයේ
3. පුස්තකාලය gRPC ඇල්වින් සම්බන්ධතා (පිං-පොං සේවාදායකයේ ක්‍රියාකාරිත්වයක් නොමැත)

කේතය කෙබඳුදැයි ඔබට අදහසක් ලබා දීමට, මගේ සේවාදායකයා/ඇල්වින් ක්‍රියාත්මක කිරීම සේවාදායක-සේවාදායක ඒවාට වඩා බොහෝ වෙනස් නොවේ අසමමුහුර්ත උදාහරණ.

සටහන: ඉහත ලැයිස්තුව ටිකක් සරල කර ඇති නිසා gRPC ක්‍රියාත්මක කිරීමේ තොගය එකිනෙකට බැඳී ඇති ඔබේම (සැකිල්ල?) නූල් ආකෘතිය භාවිතා කිරීමට හැකි වේ gRPC සහ පරිශීලක ක්රියාත්මක කිරීම. සරල බව සඳහා, අපි මෙම ආකෘතියට ඇලී සිටින්නෙමු.

පැතිකඩ කිරීම සියල්ල නිවැරදි කරනු ඇත

දත්ත ගබඩාව ඉක්මවා ගිය පසු, මම සිතුවේ මම බොහෝ දුරට අවසන් වී ඇති බවයි: “දැන් එය පහසුයි! අපි පැතිකඩ අදාළ කර ප්‍රමාදය සිදුවන්නේ කොතැනදැයි සොයා බලමු. මම නිරවද්‍ය පැතිකඩකරණයේ විශාල රසිකයෙක්, CPU ඉතා වේගවත් වන අතර බොහෝ විට බාධාව නොවේ. බොහෝ ප්‍රමාදයන් සිදුවන්නේ ප්‍රොසෙසරය වෙනත් දෙයක් කිරීමට සැකසීම නැවැත්විය යුතු විටය. නිවැරදි CPU පැතිකඩ කිරීම එය සිදු කරයි: එය සෑම දෙයක්ම නිවැරදිව වාර්තා කරයි සන්දර්භය ස්විචයන් සහ ප්‍රමාදයන් සිදුවන්නේ කොතැනද යන්න පැහැදිලි කරයි.

මම පැතිකඩ හතරක් ගත්තෙමි: ඉහළ QPS (අඩු ප්‍රමාදය) සහ අඩු QPS (ඉහළ ප්‍රමාදය) සහිත ping-pong සේවාදායකයක් සමඟ, සේවාදායක පැත්තෙන් සහ සේවාදායක පැත්තෙන්. ඒ වගේම මම නියැදි ප්‍රොසෙසර් පැතිකඩක් ද ගත්තා. පැතිකඩ සංසන්දනය කිරීමේදී, මම සාමාන්‍යයෙන් අසාමාන්‍ය ඇමතුම් තොගයක් සොයමි. උදාහරණයක් ලෙස, ඉහළ ප්‍රමාදයක් සහිත නරක පැත්තේ තවත් බොහෝ සන්දර්භ ස්විචයන් ඇත (10 වතාවක් හෝ ඊට වැඩි). නමුත් මගේ නඩුවේදී, සන්දර්භය ස්විචයන් සංඛ්යාව ආසන්න වශයෙන් සමාන විය. මගේ භීතියට, එහි සැලකිය යුතු කිසිවක් නොතිබුණි.

අතිරේක නිදොස්කරණය

මම මංමුලා සහගත විය. මට භාවිතා කළ හැකි වෙනත් මෙවලම් මොනවාදැයි මම නොදැන සිටි අතර, මගේ මීළඟ සැලසුම වූයේ ගැටලුව පැහැදිලිව හඳුනා ගැනීමට වඩා විවිධ වෙනස්කම් සමඟ අත්හදා බැලීම් නැවත නැවත කිරීමයි.

එහෙම වුණොත් මොකක්ද

ආරම්භයේ සිටම, නිශ්චිත 50ms ප්‍රමාදය ගැන මම සැලකිලිමත් විය. මෙය ඉතා විශාල කාලයක්. මෙම දෝෂය ඇති කරන්නේ කුමන කොටසද යන්න හරියටම සොයා ගැනීමට හැකි වන තෙක් මම කේතයෙන් කොටස් කපා ගැනීමට තීරණය කළෙමි. එවිට සාර්ථක වූ අත්හදා බැලීමක් පැමිණියේය.

සුපුරුදු පරිදි, ආපසු හැරී බැලීමේදී සෑම දෙයක්ම පැහැදිලිව පෙනෙන්නට තිබුණි. මම සේවාදායකයා ඇල්වින් සිටි යන්ත්‍රයේම තබා - ඉල්ලීමක් යැව්වෙමි localhost. සහ ප්‍රමාදයේ වැඩිවීම නැති වී යයි!

ජාලයේ යමක් වැරදී ඇත.

ජාල ඉංජිනේරු කුසලතා ඉගෙනීම

මම පිළිගත යුතුයි: ජාල තාක්ෂණයන් පිළිබඳ මගේ දැනුම භයානකයි, විශේෂයෙන් මම ඔවුන් සමඟ සෑම දිනකම වැඩ කරන බව සැලකිල්ලට ගනිමින්. නමුත් ජාලය ප්‍රධාන සැකකරු වූ අතර මට එය නිදොස් කරන්නේ කෙසේදැයි ඉගෙන ගැනීමට අවශ්‍ය විය.

වාසනාවකට මෙන්, අන්තර්ජාලය ඉගෙන ගැනීමට කැමති අයට ආදරෙයි. ping සහ tracert වල සංකලනය ජාල ප්‍රවාහන ගැටළු නිදොස් කිරීමට ප්‍රමාණවත් ආරම්භයක් ලෙස පෙනුනි.

පළමුව, මම දියත් කළා PsPing ඇල්වින්ගේ TCP වරායට. මම පෙරනිමි සැකසුම් භාවිතා කළෙමි - විශේෂ කිසිවක් නැත. පිං දහසකට වැඩි ගණනකින්, උනුසුම් වීම සඳහා පළමු එක හැර, කිසිවක් 10 ms නොඉක්මවිය. මෙය 50 වන ප්‍රතිශතයේ 99 ms හි ප්‍රමාදයේ නිරීක්ෂණයට පටහැනි ය: එහිදී, සෑම ඉල්ලීම් 100 කටම, අපි ms 50 ක ප්‍රමාදයක් සහිත එක් ඉල්ලීමක් පමණ දැක ගත යුතුය.

ඊට පස්සේ මම උත්සාහ කළා ලුහුබැඳීම: ඇල්වින් සහ සේවාදායකයා අතර මාර්ගයේ එක් නෝඩ් එකක ගැටලුවක් තිබිය හැක. එහෙත් ට්රේසර් ද හිස් අතින් ආපසු පැමිණියේය.

එබැවින් ප්‍රමාදයට හේතු වූයේ මගේ කේතය, gRPC ක්‍රියාත්මක කිරීම හෝ ජාලය නොවේ. මට මේක කවදාවත් තේරෙන්නේ නැහැ කියලා මම බය වෙන්න පටන් ගත්තා.

දැන් අපි මොන OS එකේද ඉන්නේ

gRPC ලිනක්ස් මත බහුලව භාවිතා වන නමුත් වින්ඩෝස් මත විදේශීය. මම අත්හදා බැලීමක් උත්සාහ කිරීමට තීරණය කළෙමි, එය සාර්ථක විය: මම ලිනක්ස් අථත්‍ය යන්ත්‍රයක් නිර්මාණය කර, ලිනක්ස් සඳහා ඇල්වින් සම්පාදනය කර එය යෙදුවෙමි.

සිදු වූ දේ මෙන්න: දත්ත මූලාශ්‍රය වෙනස් නොවූවත් Linux ping-pong සේවාදායකයට සමාන Windows සත්කාරකයකට සමාන ප්‍රමාදයන් නොතිබුණි. වින්ඩෝස් සඳහා gRPC ක්රියාත්මක කිරීමේදී ගැටළුව ඇති බව පෙනී යයි.

Nagle ගේ ඇල්ගොරිතම

මෙච්චර වෙලා මම හිතුවේ මට කොඩියක් නැතිවෙලා කියලා gRPC. දැන් මට තේරෙනවා ඇත්තටම මොකක්ද කියලා gRPC වින්ඩෝස් ධජය අතුරුදහන්. සියලුම කොඩි කට්ටල සඳහා හොඳින් ක්‍රියා කරනු ඇතැයි මට විශ්වාස වූ අභ්‍යන්තර RPC පුස්තකාලයක් මට හමු විය වින්සොක්. ඊට පස්සේ මම මේ කොඩි ඔක්කොම gRPC එකට එකතු කරලා Windows වල Alvin, patched Windows ping-pong server එකක යෙදෙව්වා!

පාහේ නිමයි: ප්‍රතිගමනය නැවත පැමිණෙන තෙක් මම එකතු කරන ලද කොඩි එකින් එක ඉවත් කිරීමට පටන් ගතිමි. එය අපකීර්තිමත් විය TCP_NODELAY, Nagle ගේ ඇල්ගොරිතම ස්විචය.

Nagle ගේ ඇල්ගොරිතම පැකට් ප්‍රමාණය නිශ්චිත බයිට් සංඛ්‍යාවක් ඉක්මවන තෙක් පණිවිඩ සම්ප්‍රේෂණය ප්‍රමාද කිරීමෙන් ජාලයක් හරහා යවන ලද පැකට් ගණන අඩු කිරීමට උත්සාහ කරයි. මෙය සාමාන්‍ය පරිශීලකයෙකුට ප්‍රසන්න විය හැකි නමුත්, එය තත්‍ය කාලීන සේවාදායකයන් සඳහා විනාශකාරී වේ, මන්ද OS මඟින් සමහර පණිවිඩ ප්‍රමාද කරයි, අඩු QPS හි ප්‍රමාදයක් ඇති කරයි. යූ gRPC මෙම ධජය TCP සොකට් සඳහා ලිනක්ස් ක්‍රියාත්මක කිරීමේදී සකසා ඇත, නමුත් වින්ඩෝස් වල නොවේ. මම මේ නිවැරදි කළා.

නිගමනය

අඩු QPS හි වැඩි ප්‍රමාදය OS ප්‍රශස්තකරණය නිසා ඇති විය. ආපසු හැරී බැලීමේදී, පැතිකඩ කිරීම ප්‍රමාදය හඳුනා නොගත්තේ එය කර්නල් ප්‍රකාරයේදී සිදු කර ඇති නිසා නොවේ පරිශීලක මාදිලිය. ETW ග්‍රහණ හරහා Nagle ගේ ඇල්ගොරිතම නිරීක්ෂණය කළ හැකිදැයි මම නොදනිමි, නමුත් එය සිත්ගන්නා සුළු වනු ඇත.

දේශීය සත්කාරක අත්හදා බැලීම සඳහා, එය සත්‍ය ජාලකරණ කේතය ස්පර්ශ නොකළ අතර Nagle හි ඇල්ගොරිතම ක්‍රියාත්මක නොවීය, එබැවින් සේවාදායකයා localhost හරහා Alvin වෙත ළඟා වූ විට ප්‍රමාද ගැටළු පහව ගියේය.

ඊළඟ වතාවේ තත්පරයකට ඉල්ලීම් ප්‍රමාණය අඩු වන විට ප්‍රමාදයේ වැඩි වීමක් ඔබ දකින විට, Nagle ගේ ඇල්ගොරිතම ඔබේ සැකකරුවන්ගේ ලැයිස්තුවේ තිබිය යුතුය!

මූලාශ්රය: www.habr.com