تجزیه و تحلیل تأثیر عملکرد منبع زمانی انتخاب شده در سیستم

برندان گرگ، یکی از توسعه دهندگان DTrace، که در حال حاضر در حال توسعه ابزارهای تجزیه و تحلیل عملکرد مبتنی بر BPF در هسته لینوکس است، تجربیات به دست آمده از تجزیه و تحلیل مشکلات عملکردی را که نتفلیکس هنگام انتقال DBMS کاساندرا از CentOS به اوبونتو با آن مواجه شد، خلاصه کرد. ابر آمازون EC2 مبتنی بر Xen. پس از انتقال، بار CPU 30٪ افزایش یافت و تاخیر در عملیات نوشتن تقریباً به همان میزان افزایش یافت. همانطور که مشخص است، عملکرد برنامه هایی که به شدت اطلاعات زمانی را درخواست می کنند، بسیار به منبع زمانی دقیق انتخاب شده در سیستم بستگی دارد.

در ابتدا، دلیل کاهش عملکرد مشخص نبود و تشخیص با نظارت بر تأثیر احتمالی فرآیندهای سیستمی که دائماً در حال اجرا هستند یا به طور دوره ای راه اندازی می شوند با استفاده از ابزارهای برتر و execsnoop آغاز شد. اما همه چیز نشان می داد که مصرف منابع به طور خاص در DBMS کاساندرا، نوشته شده به زبان جاوا افزایش یافته است. مقایسه معیارهای پروفایل دو فرآیند کاساندرا که به طور موازی روی CentOS و Ubuntu اجرا می‌شوند و همان پرس‌وجوها را پردازش می‌کنند، نشان می‌دهد که حدود 32٪ از کل زمان صرف فراخوانی os::javaTimeMillis() شده است که برای به دست آوردن اطلاعات مربوط به زمان فعلی استفاده می‌شود. .

پس از این، آزمایشی انجام شد که در آن یک برنامه جاوای ساده نوشته شد که متد System.currentTimeMillis() را صد میلیون بار در یک حلقه نامید. اجرای برنامه نشان داد که تکمیل آن در CentOS 13 ثانیه و در اوبونتو حدود 68 ثانیه طول می کشد. 5 برابر کندتر برنامه مشابهی در C نوشته شده بود که تابع gettimeofday() را صد میلیون بار فراخوانی کرد، اما پس از اجرا، نتایج مشابهی به دست آمد.

از آنجایی که مشخص شد منبع مشکل عملکرد بازگرداندن زمان جاری است، توجه به تغییرات در شاخص ها هنگام انتخاب منابع مختلف زمان دقیق در سیستم معطوف شد. با قضاوت بر اساس محتویات «/sys/devices/system/clocksource/clocksource0/current_clocksource»، تایمر «xen» به طور پیش‌فرض هنگام اجرای لینوکس در سیستم مهمان استفاده می‌شود. پس از تغییر منبع زمانی به "tsc"، زمان اجرای برنامه آزمایشی در اوبونتو از 68 به 3.3 ثانیه کاهش یافت. 20 برابر سریعتر شد علاوه بر این، یک تست عملکرد منبع زمانی kvm-clock انجام شد که نشان دهنده افزایش 20 درصدی تاخیر در مقایسه با TSC بود. $ cat /sys/devices/system/clocksource/clocksource0/available_clocksource xen tsc hpet acpi_pm $ cat /sys/devices/system/clocksource/clocksource0/current_clocksource xen $ زمان جاوا TimeBench واقعی 1m8.300s کاربر 0sm38.337s. echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource $ time java TimeBench واقعی 29.875m0s کاربر 0m3.370s sys 0m3.353s

برای به دست آوردن زمان هنگام انتخاب منبع TSC، از دستورالعمل پردازنده RDTSC استفاده می شود که اجرای آن نیازی به فراخوانی سیستم ندارد (دستورالعمل به امتیازات بالا نیاز ندارد و مقداری را از شمارنده زمان تعبیه شده در CPU تولید می کند). به‌طور پیش‌فرض، TSC فعال نمی‌شود، زیرا در قدیم این منبع جابه‌جایی تدریجی زمان را حذف نمی‌کرد، که در پردازنده‌های دیگر توسط نرم‌افزار تنظیم می‌شود تا به قرائت‌های دقیق‌تر دست یابد. به گفته یک مهندس متخصص در توسعه پردازنده، ترس در مورد تغییر زمان در هنگام استفاده از TSC برای مدت طولانی نادرست است و در پردازنده های مدرن این منبع می تواند برای سال ها خوانش های پایدار ایجاد کند.

تغییر سرورهای تولیدی در Netflix به منبع TSC منجر به کاهش 43 درصدی تأخیر نوشتن شد و نتایجی با استفاده از اوبونتو به دست آمد که 4 برابر سریع‌تر از پیکربندی‌هایی بود که CentOS با منبع زمانی «xen» اجرا می‌کردند. نتایج این مطالعه به آمازون منتقل شد، که رسماً استفاده از منبع زمانی پیش‌فرض TSC در محیط‌های AWS EC2 بر اساس هایپروایزر Xen را توصیه کرد (ساعت kvm در محیط‌های مبتنی بر هایپروایزر Nitro توصیه می‌شود).

منبع: opennet.ru