ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಆಯ್ಕೆ ಮಾಡಲಾದ ಸಮಯದ ಮೂಲದ ಕಾರ್ಯಕ್ಷಮತೆಯ ಪ್ರಭಾವದ ವಿಶ್ಲೇಷಣೆ

ಪ್ರಸ್ತುತ ಲಿನಕ್ಸ್ ಕರ್ನಲ್‌ನಲ್ಲಿ BPF-ಆಧಾರಿತ ಕಾರ್ಯಕ್ಷಮತೆ ವಿಶ್ಲೇಷಣಾ ಸಾಧನಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತಿರುವ DTrace ನ ಡೆವಲಪರ್‌ಗಳಲ್ಲಿ ಒಬ್ಬರಾದ ಬ್ರೆಂಡನ್ ಗ್ರೆಗ್, CentOS ನಿಂದ Ubuntu ಗೆ Cassandra DBMS ಅನ್ನು ಸ್ಥಳಾಂತರಿಸುವಾಗ Netflix ಎದುರಿಸಿದ ಕಾರ್ಯಕ್ಷಮತೆಯ ಸಮಸ್ಯೆಗಳನ್ನು ವಿಶ್ಲೇಷಿಸುವುದರಿಂದ ಪಡೆದ ಅನುಭವವನ್ನು ಸಂಕ್ಷಿಪ್ತಗೊಳಿಸಿದ್ದಾರೆ. Xen ಆಧಾರಿತ Amazon 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.337sys0 29.875m0 echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource $ ಟೈಮ್ ಜಾವಾ TimeBench real 3.370m0s ಬಳಕೆದಾರ 3.353m0s sys 0.026mXNUMXs

TSC ಮೂಲವನ್ನು ಆಯ್ಕೆಮಾಡುವಾಗ ಸಮಯವನ್ನು ಪಡೆಯಲು, RDTSC ಪ್ರೊಸೆಸರ್ ಸೂಚನೆಯನ್ನು ಬಳಸಲಾಗುತ್ತದೆ, ಅದರ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆಗೆ ಸಿಸ್ಟಮ್ ಕರೆ ಅಗತ್ಯವಿಲ್ಲ (ಸೂಚನೆಗೆ ಉನ್ನತ ಸವಲತ್ತುಗಳ ಅಗತ್ಯವಿಲ್ಲ ಮತ್ತು CPU ನಲ್ಲಿ ನಿರ್ಮಿಸಲಾದ ಸಮಯ ಕೌಂಟರ್‌ನಿಂದ ಮೌಲ್ಯವನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ). ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ, TSC ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಲಾಗಿಲ್ಲ ಏಕೆಂದರೆ ಹಳೆಯ ದಿನಗಳಲ್ಲಿ ಈ ಮೂಲವು ಕ್ರಮೇಣ ಸಮಯದ ಡ್ರಿಫ್ಟ್ ಅನ್ನು ಹೊರತುಪಡಿಸುವುದಿಲ್ಲ, ಇತರ ಪ್ರೊಸೆಸರ್ಗಳಲ್ಲಿ ಹೆಚ್ಚು ನಿಖರವಾದ ವಾಚನಗೋಷ್ಠಿಯನ್ನು ಸಾಧಿಸಲು ಸಾಫ್ಟ್ವೇರ್ನಿಂದ ಸರಿಹೊಂದಿಸಲಾಗುತ್ತದೆ. ಪ್ರೊಸೆಸರ್ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ಪರಿಣತಿ ಹೊಂದಿರುವ ಇಂಜಿನಿಯರ್ ಪ್ರಕಾರ, TSC ಅನ್ನು ಬಳಸುವಾಗ ಸಮಯದ ಬದಲಾವಣೆಗಳ ಬಗ್ಗೆ ಭಯವು ಬಹಳ ಹಿಂದಿನಿಂದಲೂ ಸುಳ್ಳು ಮತ್ತು ಆಧುನಿಕ ಸಂಸ್ಕಾರಕಗಳಲ್ಲಿ ಈ ಮೂಲವು ವರ್ಷಗಳವರೆಗೆ ಸ್ಥಿರವಾದ ವಾಚನಗೋಷ್ಠಿಯನ್ನು ಉಂಟುಮಾಡಬಹುದು.

ನೆಟ್‌ಫ್ಲಿಕ್ಸ್‌ನಲ್ಲಿನ ಪ್ರೊಡಕ್ಷನ್ ಸರ್ವರ್‌ಗಳನ್ನು TSC ಮೂಲಕ್ಕೆ ಬದಲಾಯಿಸುವುದರಿಂದ ಬರೆಯುವ ಲೇಟೆನ್ಸಿಯಲ್ಲಿ 43% ಕಡಿತವಾಯಿತು ಮತ್ತು ಉಬುಂಟು ಬಳಸಿಕೊಂಡು ಫಲಿತಾಂಶಗಳನ್ನು ಸಾಧಿಸಿತು, ಅದು "xen" ಸಮಯದ ಮೂಲದೊಂದಿಗೆ CentOS ಅನ್ನು ಚಾಲನೆ ಮಾಡುವ ಸಂರಚನೆಗಳಿಗಿಂತ 4 ಪಟ್ಟು ವೇಗವಾಗಿರುತ್ತದೆ. ಅಧ್ಯಯನದ ಫಲಿತಾಂಶಗಳನ್ನು ಅಮೆಜಾನ್‌ಗೆ ವರ್ಗಾಯಿಸಲಾಯಿತು, ಇದು Xen ಹೈಪರ್‌ವೈಸರ್‌ನ ಆಧಾರದ ಮೇಲೆ AWS EC2 ಪರಿಸರದಲ್ಲಿ ಡೀಫಾಲ್ಟ್ TSC ಸಮಯದ ಮೂಲವನ್ನು ಬಳಸಲು ಅಧಿಕೃತವಾಗಿ ಶಿಫಾರಸು ಮಾಡಿದೆ (ನೈಟ್ರೋ ಹೈಪರ್‌ವೈಸರ್ ಆಧಾರಿತ ಪರಿಸರದಲ್ಲಿ kvm-ಗಡಿಯಾರವನ್ನು ಶಿಫಾರಸು ಮಾಡಲಾಗಿದೆ).

ಮೂಲ: opennet.ru