පද්ධතිය තුළ තෝරාගත් කාල ප්‍රභවයේ කාර්ය සාධන බලපෑම විශ්ලේෂණය කිරීම

දැනට Linux කර්නලයේ BPF මත පදනම් වූ කාර්ය සාධන විශ්ලේෂණ මෙවලම් සංවර්ධනය කරමින් සිටින DTrace හි සංවර්ධකයෙකු වන Brendan Gregg, CentOS සිට Ubuntu වෙත Cassandra DBMS සංක්‍රමණය කිරීමේදී Netflix හට ඇති වූ කාර්ය සාධන ගැටළු විශ්ලේෂණය කිරීමෙන් ලබාගත් අත්දැකීම් සාරාංශ කළේය. Xen මත පදනම් වූ Amazon EC2 වලාකුළු. සංක්‍රමණයෙන් පසුව, CPU භාරය 30% කින් වැඩි වූ අතර ලිවීමේ මෙහෙයුම් වලදී ප්‍රමාදයන් සමාන ප්‍රමාණයකින් වැඩි විය. පෙනෙන පරිදි, කාල තොරතුරු දැඩි ලෙස ඉල්ලා සිටින යෙදුම්වල ක්‍රියාකාරිත්වය පද්ධතියේ තෝරාගත් නිශ්චිත කාල ප්‍රභවය මත රඳා පවතී.

මුලදී, කාර්ය සාධනය අඩුවීමට හේතුව පැහැදිලි නොවූ අතර රෝග විනිශ්චය ආරම්භ වූයේ ඉහළ සහ execsnoop උපයෝගිතා භාවිතා කරමින් නිරන්තරයෙන් ක්‍රියාත්මක වන හෝ වරින් වර දියත් කරන ලද සම්පත්-දැඩි පද්ධති ක්‍රියාවලීන්හි ඇති විය හැකි බලපෑම නිරීක්ෂණය කිරීමෙනි. නමුත් සෑම දෙයක්ම පෙන්නුම් කළේ ජාවා භාෂාවෙන් ලියා ඇති Cassandra DBMS හි සම්පත් පරිභෝජනය විශේෂයෙන් වැඩි වී ඇති බවයි. CentOS සහ Ubuntu මත සමාන්තරව ක්‍රියාත්මක වන Cassandra ක්‍රියාවලි දෙකක පැතිකඩ ප්‍රමිතික සංසන්දනය කරමින්, එම විමසුම් සැකසීමෙන්, මුළු කාලයෙන් 32% ක් පමණ වැය කර ඇත්තේ os::javaTimeMillis(), වත්මන් කාලය පිළිබඳ තොරතුරු ලබා ගැනීමට භාවිතා කරන බවයි. .

මෙයින් පසු, ලූපයක් තුළ System.currentTimeMillis() ක්‍රමය නමින් සරල ජාවා යෙදුමක් ලියා ඇති අත්හදා බැලීමක් සිදු කරන ලදී. යෙදුම ධාවනය කිරීමෙන් පෙන්නුම් කළේ එය CentOS හි සම්පූර්ණ කිරීමට තත්පර 13 ක් සහ උබුන්ටු මත තත්පර 68 ක් පමණ ගත වූ බවයි. 5 ගුණයකින් මන්දගාමී වේ. එවැනිම වැඩසටහනක් C හි ලියා ඇති අතර එය gettimeofday() ශ්‍රිතය මිලියන සිය වාරයක් ලෙස හැඳින්වේ, නමුත් ක්‍රියාත්මක කළ විට, සමාන ප්‍රතිඵල ලබා ගන්නා ලදී.

ගැටලුවේ මූලාශ්‍රය වත්මන් වේලාව නැවත ලබා දීමේ කාර්යය බව පැහැදිලි වූ හෙයින්, පද්ධතියේ නිශ්චිත වේලාවේ විවිධ ප්‍රභවයන් තෝරාගැනීමේදී දර්ශකවල වෙනස්කම් කෙරෙහි අවධානය යොමු විය. “/sys/devices/system/clocksource/clocksource0/current_clocksource” හි අන්තර්ගතය අනුව විනිශ්චය කිරීම, ආගන්තුක පද්ධතිය තුළ Linux ධාවනය කිරීමේදී “xen” ටයිමරය පෙරනිමියෙන් භාවිතා කරන ලදී. කාල ප්‍රභවය "tsc" ලෙස වෙනස් කිරීමෙන් පසුව, උබුන්ටු හි පරීක්ෂණ යෙදුම ක්‍රියාත්මක කිරීමේ කාලය තත්පර 68 සිට 3.3 දක්වා අඩු විය, i.e. එය 20 ගුණයකින් වේගවත් විය. මීට අමතරව, kvm-clock time මූලාශ්‍රයේ කාර්ය සාධන පරීක්ෂණයක් සිදු කරන ලද අතර, TSC හා සසඳන විට ප්‍රමාදයන් 20% කින් වැඩි වීමක් පෙන්නුම් කළේය. $ cat /sys/devices/system/clocksource/clocksource0/available_clocksource xen tsc hpet acpi_pm $ cat /sys/devices/system/clocksource/clocksource0/current_clocksource xen $ time java TimeBench real 1m8.300s user 0m38.337sys0m29.875 echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource $ time java TimeBench real 0m3.370s user 0m3.353s sys 0m0.026s

TSC මූලාශ්‍රයක් තෝරාගැනීමේදී කාලය ලබා ගැනීම සඳහා, RDTSC ප්‍රොසෙසර උපදෙස් භාවිතා කරනු ලැබේ, එය ක්‍රියාත්මක කිරීම සඳහා පද්ධති ඇමතුමක් අවශ්‍ය නොවේ (උපදෙස් සඳහා උසස් වරප්‍රසාද අවශ්‍ය නොවන අතර CPU තුළ ගොඩනගා ඇති කාල කවුන්ටරයෙන් අගයක් නිපදවයි). පෙරනිමියෙන්, TSC සක්‍රිය නොවේ, මන්ද පැරණි දිනවල මෙම මූලාශ්‍රය ක්‍රමානුකූල කාල ප්ලාවිතය බැහැර නොකළ අතර, අනෙකුත් ප්‍රොසෙසරවල වඩාත් නිවැරදි කියවීම් ලබා ගැනීම සඳහා මෘදුකාංග මඟින් සකස් කරනු ලැබේ. ප්‍රොසෙසර සංවර්ධනය පිළිබඳ විශේෂඥ ඉංජිනේරුවෙකුට අනුව, TSC භාවිතා කරන විට කාල මාරුවීම් පිළිබඳ බිය බොහෝ කලක සිට අසත්‍ය වී ඇති අතර නවීන ප්‍රොසෙසරවල මෙම ප්‍රභවය වසර ගණනාවක් ස්ථාවර කියවීම් නිපදවිය හැකිය.

Netflix හි නිෂ්පාදන සේවාදායකයන් TSC මූලාශ්‍රයකට මාරු කිරීම නිසා ලිවීමේ ප්‍රමාදය 43% කින් අඩු වූ අතර Ubuntu භාවිතයෙන් ප්‍රතිඵල ලබා ගැනීමට හැකි වූ අතර එය “xen” කාල ප්‍රභවයක් සහිත CentOS ධාවනය වන වින්‍යාසයන්ට වඩා 4 ගුණයක් වේගවත් විය. අධ්‍යයනයේ ප්‍රතිඵල Amazon වෙත මාරු කරන ලද අතර, එය Xen හයිපර්වයිසර් මත පදනම් වූ AWS EC2 පරිසරයන්හි පෙරනිමි TSC කාල ප්‍රභවය භාවිතා කිරීම නිල වශයෙන් නිර්දේශ කරන ලදී (Kvm-clock නයිට්‍රෝ හයිපර්වයිසර් මත පදනම් වූ පරිසරයන්හි නිර්දේශිතව පවතී).

මූලාශ්රය: opennet.ru

අදහස් එක් කරන්න