സിസ്റ്റത്തിൽ തിരഞ്ഞെടുത്ത സമയ സ്രോതസ്സിന്റെ പ്രകടന സ്വാധീനത്തിന്റെ വിശകലനം

നിലവിൽ ലിനക്സ് കെർണലിൽ ബിപിഎഫ് അടിസ്ഥാനമാക്കിയുള്ള പ്രകടന വിശകലന ടൂളുകൾ വികസിപ്പിച്ചുകൊണ്ടിരിക്കുന്ന ഡിട്രേസിന്റെ ഡെവലപ്പർമാരിൽ ഒരാളായ ബ്രെൻഡൻ ഗ്രെഗ്, CentOS-ൽ നിന്ന് ഉബുണ്ടുവിലേക്ക് Cassandra DBMS മൈഗ്രേറ്റ് ചെയ്യുമ്പോൾ Netflix നേരിട്ട പ്രകടന പ്രശ്നങ്ങൾ വിശകലനം ചെയ്തതിന്റെ അനുഭവം സംഗ്രഹിച്ചു. Xen അടിസ്ഥാനമാക്കിയുള്ള Amazon EC2 ക്ലൗഡ്. മൈഗ്രേഷനുശേഷം, സിപിയു ലോഡ് 30% വർദ്ധിച്ചു, എഴുത്ത് പ്രവർത്തനങ്ങളിലെ കാലതാമസം ഏതാണ്ട് അതേ അളവിൽ വർദ്ധിച്ചു. ഇത് മാറുന്നതുപോലെ, സമയ വിവരങ്ങൾ തീവ്രമായി ആവശ്യപ്പെടുന്ന ആപ്ലിക്കേഷനുകളുടെ പ്രകടനം സിസ്റ്റത്തിൽ തിരഞ്ഞെടുത്ത കൃത്യമായ സമയ ഉറവിടത്തെ ആശ്രയിച്ചിരിക്കുന്നു.

ആദ്യം, പ്രകടനം കുറയുന്നതിന്റെ കാരണം വ്യക്തമല്ല, കൂടാതെ ടോപ്പ്, എക്‌സ്‌നൂപ് യൂട്ടിലിറ്റികൾ ഉപയോഗിച്ച് നിരന്തരം പ്രവർത്തിക്കുന്നതോ ആനുകാലികമായി സമാരംഭിക്കുന്നതോ ആയ റിസോഴ്‌സ്-ഇന്റൻസീവ് സിസ്റ്റം പ്രക്രിയകളുടെ സാധ്യമായ ആഘാതം നിരീക്ഷിക്കുന്നതിലൂടെയാണ് രോഗനിർണയം ആരംഭിച്ചത്. ജാവയിൽ എഴുതിയ കസാന്ദ്ര ഡിബിഎംഎസിൽ വിഭവങ്ങളുടെ ഉപഭോഗം പ്രത്യേകമായി വർദ്ധിച്ചുവെന്ന് എല്ലാം സൂചിപ്പിച്ചു. CentOS, Ubuntu എന്നിവയിൽ സമാന്തരമായി പ്രവർത്തിക്കുന്ന രണ്ട് കസാന്ദ്ര പ്രോസസുകളുടെ പ്രൊഫൈലിംഗ് മെട്രിക്‌സ് താരതമ്യപ്പെടുത്തുമ്പോൾ, ഒരേ ചോദ്യങ്ങൾ പ്രോസസ്സ് ചെയ്യുന്നതിലൂടെ, മൊത്തം സമയത്തിന്റെ 32% ചെലവഴിച്ചത് os::javaTimeMillis(), നിലവിലെ സമയത്തെക്കുറിച്ചുള്ള വിവരങ്ങൾ നേടുന്നതിന് ഉപയോഗിക്കുന്നു. .

ഇതിനുശേഷം, ഒരു പരീക്ഷണം നടത്തി, അതിൽ ലളിതമായ ഒരു ജാവ ആപ്ലിക്കേഷൻ എഴുതപ്പെട്ടു, അത് System.currentTimeMillis() രീതി ഒരു ലൂപ്പിൽ നൂറു ദശലക്ഷം തവണ. ആപ്ലിക്കേഷൻ പ്രവർത്തിപ്പിക്കുമ്പോൾ, സെന്റോസിൽ പൂർത്തിയാക്കാൻ 13 സെക്കൻഡും ഉബുണ്ടുവിൽ ഏകദേശം 68 സെക്കൻഡും എടുത്തു, അതായത്. 5 മടങ്ങ് പതുക്കെ. സമാനമായ ഒരു പ്രോഗ്രാം സിയിൽ എഴുതിയിട്ടുണ്ട്, അത് gettimeofday() ഫംഗ്‌ഷനെ നൂറ് ദശലക്ഷം തവണ വിളിക്കുന്നു, എന്നാൽ എക്‌സിക്യൂട്ട് ചെയ്‌തപ്പോൾ സമാനമായ ഫലങ്ങൾ ലഭിച്ചു.

നിലവിലെ സമയം തിരികെ നൽകുന്ന പ്രവർത്തനമാണ് പ്രശ്നത്തിന്റെ ഉറവിടം എന്ന് വ്യക്തമായതിനാൽ, സിസ്റ്റത്തിലെ കൃത്യമായ സമയത്തിന്റെ വ്യത്യസ്ത ഉറവിടങ്ങൾ തിരഞ്ഞെടുക്കുമ്പോൾ സൂചകങ്ങളിലെ മാറ്റങ്ങളിലേക്ക് ശ്രദ്ധ തിരിഞ്ഞു. “/sys/devices/system/clocksource/clocksource0/current_clocksource” എന്നതിന്റെ ഉള്ളടക്കം അനുസരിച്ച്, ഗസ്റ്റ് സിസ്റ്റത്തിൽ Linux പ്രവർത്തിപ്പിക്കുമ്പോൾ “xen” ടൈമർ സ്ഥിരസ്ഥിതിയായി ഉപയോഗിച്ചു. സമയ സ്രോതസ്സ് "tsc" ആയി മാറ്റിയ ശേഷം, ഉബുണ്ടുവിലെ ടെസ്റ്റ് ആപ്ലിക്കേഷന്റെ എക്സിക്യൂഷൻ സമയം 68 ൽ നിന്ന് 3.3 സെക്കൻഡായി കുറഞ്ഞു, അതായത്. അത് 20 മടങ്ങ് വേഗത്തിലായി. കൂടാതെ, kvm-clock ടൈം സ്രോതസ്സിന്റെ ഒരു പെർഫോമൻസ് ടെസ്റ്റ് നടത്തി, ഇത് 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.337sys0 29.875m0 echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource $ time java TimeBench real 3.370m0s ഉപയോക്താവ് 3.353m0s sys 0.026mXNUMXs

ഒരു TSC ഉറവിടം തിരഞ്ഞെടുക്കുമ്പോൾ സമയം ലഭിക്കുന്നതിന്, RDTSC പ്രൊസസർ നിർദ്ദേശം ഉപയോഗിക്കുന്നു, ഇതിന്റെ നിർവ്വഹണത്തിന് ഒരു സിസ്റ്റം കോൾ ആവശ്യമില്ല (നിർദ്ദേശത്തിന് ഉയർന്ന പ്രത്യേകാവകാശങ്ങൾ ആവശ്യമില്ല കൂടാതെ സിപിയുവിൽ നിർമ്മിച്ച സമയ കൗണ്ടറിൽ നിന്ന് ഒരു മൂല്യം നിർമ്മിക്കുന്നു). ഡിഫോൾട്ടായി, ടിഎസ്‌സി സജീവമാക്കിയിട്ടില്ല, കാരണം പഴയ കാലത്ത് ഈ ഉറവിടം ക്രമാനുഗതമായ ടൈം ഡ്രിഫ്റ്റ് ഒഴിവാക്കിയിരുന്നില്ല, മറ്റ് പ്രോസസ്സറുകളിൽ കൂടുതൽ കൃത്യമായ റീഡിംഗുകൾ നേടുന്നതിന് സോഫ്റ്റ്വെയർ ഉപയോഗിച്ച് ഇത് ക്രമീകരിക്കുന്നു. പ്രോസസർ വികസനത്തിൽ വിദഗ്ധനായ ഒരു എഞ്ചിനീയർ പറയുന്നതനുസരിച്ച്, TSC ഉപയോഗിക്കുമ്പോൾ സമയമാറ്റത്തെക്കുറിച്ചുള്ള ഭയം വളരെക്കാലമായി അസത്യമാണ്, ആധുനിക പ്രോസസ്സറുകളിൽ ഈ ഉറവിടത്തിന് വർഷങ്ങളോളം സ്ഥിരമായ വായനകൾ സൃഷ്ടിക്കാൻ കഴിയും.

നെറ്റ്ഫ്ലിക്സിലെ പ്രൊഡക്ഷൻ സെർവറുകൾ ഒരു ടിഎസ്‌സി ഉറവിടത്തിലേക്ക് മാറ്റുന്നത്, റൈറ്റ് ലേറ്റൻസിയിൽ 43% കുറവുണ്ടാക്കുകയും ഉബുണ്ടു ഉപയോഗിച്ച് ഫലങ്ങൾ നേടുകയും ചെയ്തു, ഇത് "xen" ടൈം സ്രോതസ്സുള്ള CentOS-ൽ പ്രവർത്തിക്കുന്ന കോൺഫിഗറേഷനുകളേക്കാൾ 4 മടങ്ങ് വേഗതയുള്ളതായിരുന്നു. Xen ഹൈപ്പർവൈസറിനെ അടിസ്ഥാനമാക്കി AWS EC2 പരിതസ്ഥിതികളിൽ സ്ഥിരസ്ഥിതി TSC ടൈം സോഴ്‌സ് ഉപയോഗിക്കാൻ ഔദ്യോഗികമായി ശുപാർശ ചെയ്ത ആമസോണിലേക്ക് പഠന ഫലങ്ങൾ കൈമാറി.

അവലംബം: opennet.ru