Brendan Gregg, mmoja wa wasanidi wa DTrace, ambaye kwa sasa anatengeneza zana za uchambuzi wa utendakazi kulingana na BPF katika kinu cha Linux, alitoa muhtasari wa uzoefu uliopatikana kutokana na kuchanganua matatizo ya utendaji ambayo Netflix ilikumbana nayo wakati wa kuhamisha Cassandra DBMS kutoka CentOS hadi Ubuntu. wingu la Amazon EC2 kulingana na Xen. Baada ya kuhama, mzigo wa CPU uliongezeka kwa 30% na ucheleweshaji wakati wa shughuli za uandishi uliongezeka kwa takriban kiasi sawa. Kama inavyotokea, utendaji wa programu ambazo zinaomba sana habari ya wakati inategemea chanzo halisi cha wakati kilichochaguliwa kwenye mfumo.
Mwanzoni, sababu ya kupungua kwa utendakazi haikuwa dhahiri na utambuzi ulianza kwa kufuatilia athari zinazowezekana za uendeshaji wa kila mara au uliozinduliwa mara kwa mara michakato ya mfumo unaotumia rasilimali nyingi kwa kutumia huduma za juu na execsnoop. Lakini kila kitu kilionyesha kuwa matumizi ya rasilimali yameongezeka hasa katika Cassandra DBMS, iliyoandikwa katika Java. Ikilinganisha vipimo vya uwekaji wasifu vya michakato miwili ya Cassandra inayoendeshwa sambamba kwenye CentOS na Ubuntu, ikichakata hoja sawa, ilionyesha kuwa takriban 32% ya muda wote uliotumika kupiga simu os::javaTimeMillis(), ambayo hutumika kupata taarifa kuhusu wakati wa sasa. .
Baada ya hayo, jaribio lilifanyika ambapo programu rahisi ya Java iliandikwa ambayo iitwayo System.currentTimeMillis() mbinu mara milioni mia moja kwenye kitanzi. Kuendesha programu ilionyesha kuwa ilichukua sekunde 13 kukamilisha kwenye CentOS, na kama sekunde 68 kwenye Ubuntu, i.e. Mara 5 polepole. Programu kama hiyo iliandikwa katika C iliyoita kazi ya gettimeofday() mara milioni mia, lakini ilipotekelezwa, matokeo sawa yalipatikana.
Kwa kuwa ikawa wazi kuwa chanzo cha shida ilikuwa kazi ya kurudisha wakati wa sasa, umakini uligeuka kwa mabadiliko katika viashiria wakati wa kuchagua vyanzo tofauti vya wakati halisi kwenye mfumo. Kwa kuzingatia maudhui ya "/sys/devices/system/clocksource/clocksource0/current_clocksource", kipima muda cha "xen" kilitumiwa kwa chaguomsingi wakati wa kuendesha Linux katika mfumo wa wageni. Baada ya kubadilisha chanzo cha muda hadi "tsc", muda wa utekelezaji wa maombi ya mtihani katika Ubuntu ulipungua kutoka sekunde 68 hadi 3.3, i.e. ikawa mara 20 haraka. Zaidi ya hayo, jaribio la utendakazi la chanzo cha saa ya kvm lilifanyika, ambalo lilionyesha kuongezeka kwa ucheleweshaji kwa 20% ikilinganishwa na TSC. $ 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 mtumiaji 0m38.337s 0s 29.875 $s. echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource $ time java TimeBench real 0m3.370s mtumiaji 0m3.353s sys 0m0.026s
Ili kupata muda wakati wa kuchagua chanzo cha TSC, maagizo ya kichakataji cha RDTSC hutumiwa, utekelezaji ambao hauhitaji simu ya mfumo (maagizo hayahitaji marupurupu ya juu na hutoa thamani kutoka kwa counter counter iliyojengwa kwenye CPU). Kwa chaguo-msingi, TSC haijaamilishwa kwa sababu katika siku za zamani chanzo hiki hakikujumuisha utelezi wa polepole wa wakati, ambao katika vichakataji vingine hurekebishwa na programu ili kufikia usomaji sahihi zaidi. Kulingana na mhandisi aliyebobea katika ukuzaji wa processor, hofu juu ya mabadiliko ya wakati unapotumia TSC imekuwa sio kweli na katika wasindikaji wa kisasa chanzo hiki kinaweza kutoa usomaji thabiti kwa miaka.
Kubadilisha seva za uzalishaji kwenye Netflix hadi chanzo cha TSC kulisababisha kupungua kwa kasi ya uandishi kwa 43% na kupata matokeo kwa kutumia Ubuntu ambayo yalikuwa haraka mara 4 kuliko usanidi unaoendesha CentOS yenye chanzo cha wakati cha "xen". Matokeo ya utafiti yalihamishiwa kwa Amazon, ambayo ilipendekeza rasmi kutumia chanzo-msingi cha saa cha TSC katika mazingira ya AWS EC2 kulingana na hypervisor ya Xen (saa ya kvm inasalia kupendekezwa katika mazingira kulingana na hypervisor ya Nitro).
Chanzo: opennet.ru