Pagsusuri ng epekto sa pagganap ng pinagmulan ng oras na napili sa system

Si Brendan Gregg, isa sa mga developer ng DTrace, na kasalukuyang bumubuo ng mga tool sa pagtatasa ng pagganap na nakabatay sa BPF sa kernel ng Linux, ay nagbubuod sa karanasang natamo mula sa pagsusuri sa mga problema sa pagganap na naranasan ng Netflix noong inilipat ang Cassandra DBMS mula sa CentOS patungo sa Ubuntu. ang Amazon EC2 cloud batay sa Xen. Pagkatapos ng paglipat, tumaas ng 30% ang pag-load ng CPU at ang mga pagkaantala sa mga operasyon ng pagsulat ay tumaas ng halos kaparehong halaga. Sa lumalabas, ang pagganap ng mga application na masinsinang humihiling ng impormasyon sa oras ay lubos na nakasalalay sa eksaktong pinagmulan ng oras na napili sa system.

Noong una, hindi halata ang dahilan ng pagbaba ng performance at nagsimula ang diagnosis sa pagsubaybay sa posibleng epekto ng patuloy na pagtakbo o panaka-nakang inilunsad na mga proseso ng system na masinsinang mapagkukunan gamit ang mga top at execsnoop na utility. Ngunit ang lahat ay nagpapahiwatig na ang pagkonsumo ng mapagkukunan ay partikular na tumaas sa Cassandra DBMS, na nakasulat sa Java. Ang paghahambing sa mga sukatan ng profiling ng dalawang proseso ng Cassandra na tumatakbo nang magkatulad sa CentOS at Ubuntu, na nagpoproseso ng parehong mga query, ay nagpakita na humigit-kumulang 32% ng kabuuang oras ang ginugol sa pagtawag sa os::javaTimeMillis(), na ginagamit upang makakuha ng impormasyon tungkol sa kasalukuyang oras .

Pagkatapos nito, isinagawa ang isang eksperimento kung saan isinulat ang isang simpleng Java application na tinatawag na System.currentTimeMillis() na pamamaraan nang isang daang milyong beses sa isang loop. Ang pagpapatakbo ng application ay nagpakita na tumagal ng 13 segundo upang makumpleto sa CentOS, at humigit-kumulang 68 segundo sa Ubuntu, i.e. 5 beses na mas mabagal. Ang isang katulad na programa ay isinulat sa C na tinatawag na gettimeofday() function na isang daang milyong beses, ngunit kapag naisakatuparan, ang mga katulad na resulta ay nakuha.

Dahil naging malinaw na ang pinagmumulan ng problema ay ang pag-andar ng pagbabalik ng kasalukuyang oras, ang atensyon ay bumaling sa mga pagbabago sa mga tagapagpahiwatig kapag pumipili ng iba't ibang mga mapagkukunan ng eksaktong oras sa system. Sa paghusga sa mga nilalaman ng "/sys/devices/system/clocksource/clocksource0/current_clocksource", ang "xen" timer ay ginamit bilang default kapag nagpapatakbo ng Linux sa guest system. Matapos baguhin ang pinagmumulan ng oras sa "tsc", ang oras ng pagpapatupad ng application ng pagsubok sa Ubuntu ay bumaba mula 68 hanggang 3.3 segundo, i.e. ito ay naging 20 beses na mas mabilis. Bilang karagdagan, ang isang pagsubok sa pagganap ng mapagkukunan ng oras ng kvm-clock ay isinagawa, na nagpakita ng pagtaas ng mga pagkaantala ng 20% ​​kumpara sa 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 user 0m38.337s $sy. echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource $ time java TimeBench real 29.875m0s user 0m3.370s sys 0m3.353s

Upang makuha ang oras kapag pumipili ng isang mapagkukunan ng TSC, ginagamit ang pagtuturo ng processor ng RDTSC, ang pagpapatupad nito ay hindi nangangailangan ng isang tawag sa system (ang pagtuturo ay hindi nangangailangan ng mataas na mga pribilehiyo at gumagawa ng isang halaga mula sa counter ng oras na binuo sa CPU). Bilang default, ang TSC ay hindi na-activate dahil noong unang panahon ang source na ito ay hindi nagbukod ng unti-unting pag-anod ng oras, na sa ibang mga processor ay inaayos ng software upang makamit ang mas tumpak na mga pagbabasa. Ayon sa isang inhinyero na nag-specialize sa pag-develop ng processor, ang mga pangamba tungkol sa pagbabago ng oras kapag gumagamit ng TSC ay matagal nang hindi totoo at sa mga modernong processor ang source na ito ay maaaring makagawa ng mga matatag na pagbabasa sa loob ng maraming taon.

Ang paglipat ng mga production server sa Netflix sa isang TSC source ay nagresulta sa 43% na pagbawas sa write latency at nakamit ang mga resulta gamit ang Ubuntu na 4 na beses na mas mabilis kaysa sa mga configuration na nagpapatakbo ng CentOS na may "xen" na pinagmulan ng oras. Ang mga resulta ng pag-aaral ay inilipat sa Amazon, na opisyal na inirerekomenda gamit ang default na TSC time source sa AWS EC2 environment batay sa Xen hypervisor (kvm-clock ay nananatiling inirerekomenda sa mga environment batay sa Nitro hypervisor).

Pinagmulan: opennet.ru

Magdagdag ng komento