Crynhodd Brendan Gregg, un o ddatblygwyr DTrace, sydd ar hyn o bryd yn datblygu offer dadansoddi perfformiad yn seiliedig ar BPF yn y cnewyllyn Linux, y profiad a gafwyd o ddadansoddi'r problemau perfformiad y daeth Netflix ar eu traws wrth fudo'r Cassandra DBMS o CentOS i Ubuntu amgylcheddau sy'n rhedeg ymlaen cwmwl Amazon EC2 yn seiliedig ar Xen. Ar ôl mudo, cynyddodd y llwyth CPU 30% a chynyddodd yr oedi yn ystod gweithrediadau ysgrifennu tua'r un faint. Fel mae'n digwydd, mae perfformiad ceisiadau sy'n gofyn yn ddwys am wybodaeth amser yn dibynnu'n fawr ar yr union ffynhonnell amser a ddewiswyd yn y system.
Ar y dechrau, nid oedd y rheswm dros y gostyngiad mewn perfformiad yn amlwg a dechreuodd y diagnosis trwy fonitro effaith bosibl prosesau system sy'n rhedeg yn gyson neu'n cael eu lansio o bryd i'w gilydd gan ddefnyddio'r cyfleustodau uchaf ac execsnoop. Ond roedd popeth yn nodi bod y defnydd o adnoddau wedi cynyddu'n benodol yn y Cassandra DBMS, a ysgrifennwyd yn Java. Wrth gymharu metrigau proffilio dwy broses Cassandra sy'n rhedeg ochr yn ochr ar CentOS a Ubuntu, gan brosesu'r un ymholiadau, dangoswyd bod tua 32% o gyfanswm yr amser yn cael ei dreulio yn galw os::javaTimeMillis(), a ddefnyddir i gael gwybodaeth am yr amser presennol .
Ar ôl hyn, cynhaliwyd arbrawf lle ysgrifennwyd cymhwysiad Java syml a oedd yn galw'r dull System.currentTimeMillis() gan miliwn o weithiau mewn dolen. Dangosodd rhedeg y cais ei fod wedi cymryd 13 eiliad i'w gwblhau ar CentOS, a thua 68 eiliad ar Ubuntu, h.y. 5 gwaith yn arafach. Ysgrifennwyd rhaglen debyg yn C a oedd yn galw'r swyddogaeth gettimeofday () gan miliwn o weithiau, ond pan gafodd ei gweithredu, cafwyd canlyniadau tebyg.
Ers iddi ddod yn amlwg mai ffynhonnell y broblem oedd swyddogaeth dychwelyd yr amser presennol, trodd sylw at newidiadau mewn dangosyddion wrth ddewis gwahanol ffynonellau o union amser yn y system. A barnu yn ôl cynnwys “/ sys/devices/system/clocksource/clocksource0/current_clocksource”, defnyddiwyd yr amserydd “xen” yn ddiofyn wrth redeg Linux yn y system westai. Ar ôl newid y ffynhonnell amser i "tsc", gostyngodd amser gweithredu'r cais prawf yn Ubuntu o 68 i 3.3 eiliad, h.y. daeth 20 gwaith yn gyflymach. Yn ogystal, cynhaliwyd prawf perfformiad o ffynhonnell amser cloc kvm, a ddangosodd gynnydd mewn oedi o 20% o'i gymharu â TSC. $ cath /sys/devices/system/clocksource/clocksource0/available_clocksource xen tsc hpet acpi_pm $ cat /sys/devices/system/clocksource/clocksource0/current_clocksource xen $ amser java TimeBench real 1m8.300s defnyddiwr 0m38.337s sys 0m29.875. adlais tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource $ amser java TimeBench real 0m3.370s defnyddiwr 0m3.353s sys 0m0.026s
I gael yr amser wrth ddewis ffynhonnell TSC, defnyddir cyfarwyddyd prosesydd RDTSC, nad oes angen galwad system i'w gyflawni (nid oes angen breintiau uchel ar y cyfarwyddyd ac mae'n cynhyrchu gwerth o'r rhifydd amser sydd wedi'i gynnwys yn y CPU). Yn ddiofyn, nid yw TSC yn cael ei actifadu oherwydd yn yr hen ddyddiau nid oedd y ffynhonnell hon yn eithrio drifft amser graddol, sydd mewn proseswyr eraill yn cael ei addasu gan feddalwedd i gyflawni darlleniadau mwy cywir. Yn ôl peiriannydd sy'n arbenigo mewn datblygu proseswyr, mae ofnau am sifftiau amser wrth ddefnyddio TSC wedi bod yn anwir ers amser maith ac mewn proseswyr modern gall y ffynhonnell hon gynhyrchu darlleniadau sefydlog ers blynyddoedd.
Arweiniodd newid gweinyddwyr cynhyrchu yn Netflix i ffynhonnell TSC at ostyngiad o 43% mewn hwyrni ysgrifennu a chyflawnwyd canlyniadau gan ddefnyddio Ubuntu a oedd 4 gwaith yn gyflymach na chyfluniadau sy'n rhedeg CentOS gyda ffynhonnell amser “xen”. Trosglwyddwyd canlyniadau'r astudiaeth i Amazon, a argymhellodd yn swyddogol ddefnyddio'r ffynhonnell amser TSC rhagosodedig mewn amgylcheddau AWS EC2 yn seiliedig ar yr hypervisor Xen (argymhellir olion cloc kvm mewn amgylcheddau sy'n seiliedig ar y Nitro hypervisor).
Ffynhonnell: opennet.ru