ਸਿਸਟਮ ਵਿੱਚ ਚੁਣੇ ਗਏ ਸਮੇਂ ਦੇ ਸਰੋਤ ਦੇ ਪ੍ਰਦਰਸ਼ਨ ਪ੍ਰਭਾਵ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ

ਬ੍ਰੈਂਡਨ ਗ੍ਰੇਗ, DTrace ਦੇ ਡਿਵੈਲਪਰਾਂ ਵਿੱਚੋਂ ਇੱਕ, ਜੋ ਵਰਤਮਾਨ ਵਿੱਚ ਲੀਨਕਸ ਕਰਨਲ ਵਿੱਚ BPF- ਅਧਾਰਤ ਪ੍ਰਦਰਸ਼ਨ ਵਿਸ਼ਲੇਸ਼ਣ ਟੂਲ ਵਿਕਸਿਤ ਕਰ ਰਿਹਾ ਹੈ, ਨੇ Cassandra DBMS ਨੂੰ CentOS ਤੋਂ Ubuntu ਵਿੱਚ ਮਾਈਗਰੇਟ ਕਰਨ ਵੇਲੇ Netflix ਨੂੰ ਆਈਆਂ ਕਾਰਗੁਜ਼ਾਰੀ ਸਮੱਸਿਆਵਾਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨ ਤੋਂ ਪ੍ਰਾਪਤ ਅਨੁਭਵ ਦਾ ਸਾਰ ਦਿੱਤਾ। Xen 'ਤੇ ਆਧਾਰਿਤ ਐਮਾਜ਼ਾਨ EC2 ਕਲਾਊਡ। ਮਾਈਗ੍ਰੇਸ਼ਨ ਤੋਂ ਬਾਅਦ, CPU ਲੋਡ ਵਿੱਚ 30% ਦਾ ਵਾਧਾ ਹੋਇਆ ਹੈ ਅਤੇ ਰਾਈਟ ਓਪਰੇਸ਼ਨ ਦੌਰਾਨ ਦੇਰੀ ਲਗਭਗ ਉਸੇ ਮਾਤਰਾ ਵਿੱਚ ਵਧ ਗਈ ਹੈ। ਜਿਵੇਂ ਕਿ ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ, ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਜੋ ਸਮੇਂ ਦੀ ਜਾਣਕਾਰੀ ਦੀ ਤੀਬਰਤਾ ਨਾਲ ਬੇਨਤੀ ਕਰਦੇ ਹਨ, ਸਿਸਟਮ ਵਿੱਚ ਚੁਣੇ ਗਏ ਸਹੀ ਸਮੇਂ ਦੇ ਸਰੋਤ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ।

ਪਹਿਲਾਂ, ਕਾਰਗੁਜ਼ਾਰੀ ਵਿੱਚ ਕਮੀ ਦਾ ਕਾਰਨ ਸਪੱਸ਼ਟ ਨਹੀਂ ਸੀ ਅਤੇ ਨਿਦਾਨ ਸਿਖਰ ਅਤੇ ਐਕਸਕਸਨੂਪ ਉਪਯੋਗਤਾਵਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਨਿਰੰਤਰ ਚੱਲ ਰਹੇ ਜਾਂ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਲਾਂਚ ਕੀਤੇ ਸਰੋਤ-ਅਨੁਭਵ ਸਿਸਟਮ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੇ ਸੰਭਾਵੀ ਪ੍ਰਭਾਵ ਦੀ ਨਿਗਰਾਨੀ ਨਾਲ ਸ਼ੁਰੂ ਹੋਇਆ ਸੀ। ਪਰ ਹਰ ਚੀਜ਼ ਨੇ ਸੰਕੇਤ ਦਿੱਤਾ ਕਿ ਜਾਵਾ ਵਿੱਚ ਲਿਖੇ ਕੈਸੈਂਡਰਾ ਡੀਬੀਐਮਐਸ ਵਿੱਚ ਸਰੋਤਾਂ ਦੀ ਖਪਤ ਖਾਸ ਤੌਰ 'ਤੇ ਵਧੀ ਹੈ। CentOS ਅਤੇ Ubuntu 'ਤੇ ਸਮਾਨਾਂਤਰ ਚੱਲ ਰਹੀਆਂ ਦੋ ਕੈਸੈਂਡਰਾ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੀ ਪ੍ਰੋਫਾਈਲਿੰਗ ਮੈਟ੍ਰਿਕਸ ਦੀ ਤੁਲਨਾ ਕਰਦੇ ਹੋਏ, ਉਸੇ ਸਵਾਲਾਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਦੇ ਹੋਏ, ਦਿਖਾਇਆ ਗਿਆ ਹੈ ਕਿ ਕੁੱਲ ਸਮੇਂ ਦਾ ਲਗਭਗ 32% os::javaTimeMillis(), ਜੋ ਮੌਜੂਦਾ ਸਮੇਂ ਬਾਰੇ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਕਾਲ ਕਰਨ ਵਿੱਚ ਖਰਚਿਆ ਗਿਆ ਸੀ। .

ਇਸ ਤੋਂ ਬਾਅਦ, ਇੱਕ ਪ੍ਰਯੋਗ ਕੀਤਾ ਗਿਆ ਜਿਸ ਵਿੱਚ ਇੱਕ ਸਧਾਰਨ ਜਾਵਾ ਐਪਲੀਕੇਸ਼ਨ ਲਿਖੀ ਗਈ ਸੀ ਜਿਸਨੂੰ ਇੱਕ ਲੂਪ ਵਿੱਚ ਇੱਕ ਸੌ ਮਿਲੀਅਨ ਵਾਰ System.currentTimeMillis() ਵਿਧੀ ਕਿਹਾ ਜਾਂਦਾ ਹੈ। ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਚਲਾਉਣਾ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਇਸ ਨੂੰ CentOS 'ਤੇ ਪੂਰਾ ਕਰਨ ਲਈ 13 ਸਕਿੰਟ ਲੱਗ ਗਏ, ਅਤੇ ਉਬੰਟੂ 'ਤੇ ਲਗਭਗ 68 ਸਕਿੰਟ, ਯਾਨੀ. 5 ਗੁਣਾ ਹੌਲੀ. ਇੱਕ ਸਮਾਨ ਪ੍ਰੋਗਰਾਮ C ਵਿੱਚ ਲਿਖਿਆ ਗਿਆ ਸੀ ਜਿਸਨੂੰ gettimeofday() ਫੰਕਸ਼ਨ ਨੂੰ ਸੌ ਮਿਲੀਅਨ ਵਾਰ ਕਿਹਾ ਗਿਆ ਸੀ, ਪਰ ਜਦੋਂ ਚਲਾਇਆ ਗਿਆ, ਤਾਂ ਸਮਾਨ ਨਤੀਜੇ ਪ੍ਰਾਪਤ ਹੋਏ।

ਕਿਉਂਕਿ ਇਹ ਸਪੱਸ਼ਟ ਹੋ ਗਿਆ ਹੈ ਕਿ ਸਮੱਸਿਆ ਦਾ ਸਰੋਤ ਮੌਜੂਦਾ ਸਮੇਂ ਨੂੰ ਵਾਪਸ ਕਰਨ ਦਾ ਕੰਮ ਸੀ, ਸਿਸਟਮ ਵਿੱਚ ਸਹੀ ਸਮੇਂ ਦੇ ਵੱਖ-ਵੱਖ ਸਰੋਤਾਂ ਦੀ ਚੋਣ ਕਰਦੇ ਸਮੇਂ ਸੂਚਕਾਂ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਵੱਲ ਧਿਆਨ ਦਿੱਤਾ ਗਿਆ। “/sys/devices/system/clocksource/clocksource0/current_clocksource” ਦੇ ਅੰਸ਼ਾਂ ਦੁਆਰਾ ਨਿਰਣਾ ਕਰਦੇ ਹੋਏ, ਗੈਸਟ ਸਿਸਟਮ ਵਿੱਚ ਲੀਨਕਸ ਚਲਾਉਣ ਵੇਲੇ “xen” ਟਾਈਮਰ ਮੂਲ ਰੂਪ ਵਿੱਚ ਵਰਤਿਆ ਜਾਂਦਾ ਸੀ। ਸਮਾਂ ਸਰੋਤ ਨੂੰ "tsc" ਵਿੱਚ ਬਦਲਣ ਤੋਂ ਬਾਅਦ, Ubuntu ਵਿੱਚ ਟੈਸਟ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਸਮਾਂ 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.337s. echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource $time java TimeBench ਅਸਲੀ 29.875m0s ਉਪਭੋਗਤਾ 0m3.370s sys 0m3.353s

ਇੱਕ TSC ਸਰੋਤ ਦੀ ਚੋਣ ਕਰਨ ਵੇਲੇ ਸਮਾਂ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ, RDTSC ਪ੍ਰੋਸੈਸਰ ਹਦਾਇਤ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਜਿਸ ਦੇ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਲਈ ਸਿਸਟਮ ਕਾਲ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ ਹੈ (ਹਿਦਾਇਤਾਂ ਨੂੰ ਉੱਚੇ ਅਧਿਕਾਰਾਂ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ ਹੈ ਅਤੇ CPU ਵਿੱਚ ਬਣੇ ਟਾਈਮ ਕਾਊਂਟਰ ਤੋਂ ਇੱਕ ਮੁੱਲ ਪੈਦਾ ਕਰਦਾ ਹੈ)। ਮੂਲ ਰੂਪ ਵਿੱਚ, TSC ਕਿਰਿਆਸ਼ੀਲ ਨਹੀਂ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਪੁਰਾਣੇ ਦਿਨਾਂ ਵਿੱਚ ਇਹ ਸਰੋਤ ਹੌਲੀ-ਹੌਲੀ ਸਮੇਂ ਦੇ ਵਹਾਅ ਨੂੰ ਬਾਹਰ ਨਹੀਂ ਰੱਖਦਾ ਸੀ, ਜਿਸ ਨੂੰ ਹੋਰ ਪ੍ਰੋਸੈਸਰਾਂ ਵਿੱਚ ਵਧੇਰੇ ਸਹੀ ਰੀਡਿੰਗ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਸੌਫਟਵੇਅਰ ਦੁਆਰਾ ਐਡਜਸਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਪ੍ਰੋਸੈਸਰ ਦੇ ਵਿਕਾਸ ਵਿੱਚ ਮੁਹਾਰਤ ਰੱਖਣ ਵਾਲੇ ਇੱਕ ਇੰਜੀਨੀਅਰ ਦੇ ਅਨੁਸਾਰ, ਟੀਐਸਸੀ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ ਸਮੇਂ ਦੀ ਤਬਦੀਲੀ ਬਾਰੇ ਡਰ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਗਲਤ ਹੈ ਅਤੇ ਆਧੁਨਿਕ ਪ੍ਰੋਸੈਸਰਾਂ ਵਿੱਚ ਇਹ ਸਰੋਤ ਸਾਲਾਂ ਲਈ ਸਥਿਰ ਰੀਡਿੰਗ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ।

Netflix 'ਤੇ ਉਤਪਾਦਨ ਸਰਵਰਾਂ ਨੂੰ ਇੱਕ TSC ਸਰੋਤ ਵਿੱਚ ਬਦਲਣ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਲਿਖਣ ਦੀ ਲੇਟੈਂਸੀ ਵਿੱਚ 43% ਦੀ ਕਮੀ ਆਈ ਹੈ ਅਤੇ ਉਬੰਟੂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਨਤੀਜੇ ਪ੍ਰਾਪਤ ਹੋਏ ਹਨ ਜੋ ਕਿ "xen" ਸਮਾਂ ਸਰੋਤ ਨਾਲ CentOS ਨੂੰ ਚਲਾਉਣ ਵਾਲੀਆਂ ਸੰਰਚਨਾਵਾਂ ਨਾਲੋਂ 4 ਗੁਣਾ ਤੇਜ਼ ਸਨ। ਅਧਿਐਨ ਦੇ ਨਤੀਜੇ ਐਮਾਜ਼ਾਨ ਨੂੰ ਟ੍ਰਾਂਸਫਰ ਕੀਤੇ ਗਏ ਸਨ, ਜਿਸ ਨੇ ਅਧਿਕਾਰਤ ਤੌਰ 'ਤੇ Xen ਹਾਈਪਰਵਾਈਜ਼ਰ ਦੇ ਆਧਾਰ 'ਤੇ AWS EC2 ਵਾਤਾਵਰਣਾਂ ਵਿੱਚ ਡਿਫਾਲਟ TSC ਸਮਾਂ ਸਰੋਤ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਸਿਫ਼ਾਰਸ਼ ਕੀਤੀ ਸੀ (Kvm-ਘੜੀ ਨਾਈਟਰੋ ਹਾਈਪਰਵਾਈਜ਼ਰ 'ਤੇ ਆਧਾਰਿਤ ਵਾਤਾਵਰਨ ਵਿੱਚ ਸਿਫ਼ਾਰਿਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ)।

ਸਰੋਤ: opennet.ru