સિસ્ટમમાં પસંદ કરેલ સમય સ્ત્રોતની કામગીરીની અસરનું વિશ્લેષણ

બ્રેન્ડન ગ્રેગ, DTraceના વિકાસકર્તાઓમાંના એક, જેઓ હાલમાં Linux કર્નલમાં BPF-આધારિત પ્રદર્શન વિશ્લેષણ સાધનો વિકસાવી રહ્યા છે, Cassandra DBMS ને CentOS થી Ubuntu માં સ્થાનાંતરિત કરતી વખતે Netflix ને જે કામગીરી સમસ્યાઓનો સામનો કરવો પડ્યો તેનું વિશ્લેષણ કરવાથી પ્રાપ્ત થયેલા અનુભવનો સારાંશ આપ્યો. Xen પર આધારિત Amazon EC2 ક્લાઉડ. સ્થળાંતર પછી, CPU લોડ 30% વધ્યો અને લેખન કામગીરી દરમિયાન વિલંબ લગભગ સમાન રકમથી વધ્યો. જેમ જેમ તે તારણ આપે છે તેમ, એપ્લિકેશનોનું પ્રદર્શન જે સમયની માહિતીની સઘન વિનંતી કરે છે તે સિસ્ટમમાં પસંદ કરેલ ચોક્કસ સમય સ્ત્રોત પર આધારિત છે.

શરૂઆતમાં, પ્રદર્શનમાં ઘટાડો થવાનું કારણ સ્પષ્ટ નહોતું અને નિદાનની શરૂઆત ટોચ અને એક્ઝેક્સનૂપ ઉપયોગિતાઓનો ઉપયોગ કરીને સતત ચાલતી અથવા સમયાંતરે શરૂ કરાયેલ સંસાધન-સઘન સિસ્ટમ પ્રક્રિયાઓની સંભવિત અસર પર દેખરેખ સાથે થઈ હતી. પરંતુ બધું જ સૂચવે છે કે જાવામાં લખેલા કેસાન્ડ્રા ડીબીએમએસમાં સંસાધનનો વપરાશ ખાસ કરીને વધ્યો છે. 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 વાસ્તવિક 1m8.300s વપરાશકર્તા 0m38.337. echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource $time java TimeBench વાસ્તવિક 29.875m0s વપરાશકર્તા 0m3.370s sys 0m3.353s

TSC સ્ત્રોત પસંદ કરતી વખતે સમય મેળવવા માટે, RDTSC પ્રોસેસર સૂચનાનો ઉપયોગ કરવામાં આવે છે, જેના અમલીકરણ માટે સિસ્ટમ કૉલની જરૂર નથી (સૂચનાને એલિવેટેડ વિશેષાધિકારોની જરૂર નથી અને CPU માં બનેલા સમય કાઉન્ટરમાંથી મૂલ્ય ઉત્પન્ન કરે છે). ડિફૉલ્ટ રૂપે, TSC સક્રિય થતું નથી કારણ કે જૂના દિવસોમાં આ સ્ત્રોત ક્રમિક સમયના પ્રવાહને બાકાત રાખતો ન હતો, જે અન્ય પ્રોસેસરોમાં વધુ સચોટ વાંચન પ્રાપ્ત કરવા માટે સોફ્ટવેર દ્વારા એડજસ્ટ કરવામાં આવે છે. પ્રોસેસર ડેવલપમેન્ટમાં નિષ્ણાત એન્જિનિયરના જણાવ્યા અનુસાર, TSC નો ઉપયોગ કરતી વખતે સમય બદલાવાની આશંકા લાંબા સમયથી અસત્ય છે અને આધુનિક પ્રોસેસરોમાં આ સ્ત્રોત વર્ષો સુધી સ્થિર રીડિંગ ઉત્પન્ન કરી શકે છે.

નેટફ્લિક્સ પર પ્રોડક્શન સર્વર્સને TSC સ્ત્રોત પર સ્વિચ કરવાને પરિણામે લેખન વિલંબમાં 43% ઘટાડો થયો અને ઉબુન્ટુનો ઉપયોગ કરીને પરિણામો પ્રાપ્ત કર્યા જે "xen" સમય સ્ત્રોત સાથે CentOS ચલાવતા રૂપરેખાંકનો કરતાં 4 ગણા ઝડપી હતા. અભ્યાસના પરિણામો એમેઝોન પર સ્થાનાંતરિત કરવામાં આવ્યા હતા, જેણે Xen હાઇપરવાઇઝર પર આધારિત AWS EC2 વાતાવરણમાં ડિફોલ્ટ TSC સમય સ્ત્રોતનો ઉપયોગ કરવાની સત્તાવાર રીતે ભલામણ કરી હતી (નાઇટ્રો હાઇપરવાઇઝર પર આધારિત વાતાવરણમાં kvm-ઘડિયાળની ભલામણ રહે છે).

સોર્સ: opennet.ru