సిస్టమ్‌లో ఎంచుకున్న సమయ మూలం యొక్క పనితీరు ప్రభావం యొక్క విశ్లేషణ

ప్రస్తుతం Linux కెర్నల్‌లో BPF-ఆధారిత పనితీరు విశ్లేషణ సాధనాలను అభివృద్ధి చేస్తున్న DTrace యొక్క డెవలపర్‌లలో ఒకరైన బ్రెండన్ గ్రెగ్, CentOS నుండి Ubuntuకి Cassandra DBMSని తరలించినప్పుడు Netflix ఎదుర్కొన్న పనితీరు సమస్యలను విశ్లేషించడం ద్వారా పొందిన అనుభవాన్ని సంగ్రహించారు. Xen ఆధారంగా అమెజాన్ EC2 క్లౌడ్. వలస తర్వాత, CPU లోడ్ 30% పెరిగింది మరియు వ్రాత కార్యకలాపాల సమయంలో ఆలస్యం అదే మొత్తంలో పెరిగింది. ఇది ముగిసినట్లుగా, సమయ సమాచారాన్ని తీవ్రంగా అభ్యర్థించే అప్లికేషన్‌ల పనితీరు సిస్టమ్‌లో ఎంచుకున్న ఖచ్చితమైన సమయ మూలంపై ఆధారపడి ఉంటుంది.

మొదట, పనితీరు తగ్గడానికి కారణం స్పష్టంగా లేదు మరియు టాప్ మరియు ఎగ్జిక్యూటివ్ యుటిలిటీలను ఉపయోగించి నిరంతరం నడుస్తున్న లేదా క్రమానుగతంగా ప్రారంభించబడిన రిసోర్స్-ఇంటెన్సివ్ సిస్టమ్ ప్రాసెస్‌ల యొక్క సాధ్యమైన ప్రభావాన్ని పర్యవేక్షించడంతో రోగ నిర్ధారణ ప్రారంభమైంది. కానీ జావాలో వ్రాసిన కాసాండ్రా 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 సెకన్లకు తగ్గింది, అనగా. అది 20 రెట్లు వేగంగా మారింది. అదనంగా, kvm-క్లాక్ టైమ్ సోర్స్ యొక్క పనితీరు పరీక్ష నిర్వహించబడింది, ఇది 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 యూజర్ 0m38.337s0m29.875 echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource $ time java TimeBench real 0m3.370s యూజర్ 0m3.353s sys 0m0.026s

TSC మూలాన్ని ఎంచుకున్నప్పుడు సమయాన్ని పొందేందుకు, RDTSC ప్రాసెసర్ సూచన ఉపయోగించబడుతుంది, దీని అమలుకు సిస్టమ్ కాల్ అవసరం లేదు (సూచనకు అధిక అధికారాలు అవసరం లేదు మరియు CPUలో నిర్మించిన టైమ్ కౌంటర్ నుండి విలువను ఉత్పత్తి చేస్తుంది). డిఫాల్ట్‌గా, TSC యాక్టివేట్ చేయబడదు ఎందుకంటే పాత రోజుల్లో ఈ మూలం క్రమక్రమంగా టైమ్ డ్రిఫ్ట్‌ను మినహాయించలేదు, ఇతర ప్రాసెసర్‌లలో మరింత ఖచ్చితమైన రీడింగ్‌లను సాధించడానికి సాఫ్ట్‌వేర్ ద్వారా సర్దుబాటు చేయబడుతుంది. ప్రాసెసర్ డెవలప్‌మెంట్‌లో ప్రత్యేకత కలిగిన ఇంజనీర్ ప్రకారం, TSCని ఉపయోగిస్తున్నప్పుడు సమయం మారుతుందనే భయాలు చాలా కాలంగా అవాస్తవంగా ఉన్నాయి మరియు ఆధునిక ప్రాసెసర్‌లలో ఈ మూలం సంవత్సరాలుగా స్థిరమైన రీడింగ్‌లను ఉత్పత్తి చేయగలదు.

నెట్‌ఫ్లిక్స్‌లోని ప్రొడక్షన్ సర్వర్‌లను TSC మూలానికి మార్చడం వలన వ్రాత జాప్యం 43% తగ్గింది మరియు ఉబుంటును ఉపయోగించి ఫలితాలు సాధించాయి, ఇది “xen” సమయ మూలంతో CentOS నడుస్తున్న కాన్ఫిగరేషన్‌ల కంటే 4 రెట్లు వేగంగా ఉంది. అధ్యయనం యొక్క ఫలితాలు అమెజాన్‌కు బదిలీ చేయబడ్డాయి, ఇది Xen హైపర్‌వైజర్ ఆధారంగా AWS EC2 పరిసరాలలో డిఫాల్ట్ TSC సమయ మూలాన్ని ఉపయోగించాలని అధికారికంగా సిఫార్సు చేసింది (Nitro హైపర్‌వైజర్ ఆధారంగా వాతావరణంలో kvm-గడియారం సిఫార్సు చేయబడింది).

మూలం: opennet.ru