সিস্টেমে নির্বাচিত সময়ের উৎসের কার্যক্ষমতার প্রভাবের বিশ্লেষণ

ব্রেন্ডন গ্রেগ, DTrace-এর একজন ডেভেলপার, যিনি বর্তমানে Linux কার্নেলে BPF-ভিত্তিক পারফরম্যান্স অ্যানালাইসিস টুল ডেভেলপ করছেন, Cassandra DBMS-কে CentOS থেকে Ubuntu-এ স্থানান্তরিত করার সময় Netflix যে পারফরম্যান্স সমস্যার সম্মুখীন হয়েছিল তা বিশ্লেষণ করে অর্জিত অভিজ্ঞতার সংক্ষিপ্ত বিবরণ দিয়েছেন। Xen-এর উপর ভিত্তি করে অ্যামাজন EC2 ক্লাউড। মাইগ্রেশনের পরে, CPU লোড 30% বৃদ্ধি পেয়েছে এবং লেখার ক্রিয়াকলাপের সময় বিলম্ব প্রায় একই পরিমাণ বৃদ্ধি পেয়েছে। এটি দেখা যাচ্ছে, যে অ্যাপ্লিকেশনগুলির কার্যকারিতা নিবিড়ভাবে সময়ের তথ্যের জন্য অনুরোধ করে তা সিস্টেমে নির্বাচিত সঠিক সময়ের উত্সের উপর নির্ভর করে।

প্রথমে, কর্মক্ষমতা হ্রাসের কারণটি সুস্পষ্ট ছিল না এবং নির্ণয়টি শীর্ষ এবং এক্সিক্সনূপ ইউটিলিটিগুলি ব্যবহার করে ক্রমাগত চলমান বা পর্যায়ক্রমে চালু হওয়া সংস্থান-নিবিড় সিস্টেম প্রক্রিয়াগুলির সম্ভাব্য প্রভাব নিরীক্ষণের মাধ্যমে শুরু হয়েছিল। তবে সবকিছুই ইঙ্গিত দেয় যে জাভাতে লেখা ক্যাসান্দ্রা ডিবিএমএসে বিশেষভাবে সম্পদের ব্যবহার বেড়েছে। সেন্টোস এবং উবুন্টুতে সমান্তরালভাবে চলমান দুটি ক্যাসান্ড্রা প্রক্রিয়াগুলির প্রোফাইলিং মেট্রিক্সের তুলনা করে, একই প্রশ্নগুলি প্রক্রিয়া করে, দেখায় যে মোট সময়ের প্রায় 32% os::javaTimeMillis(), যা বর্তমান সময় সম্পর্কে তথ্য পেতে ব্যবহৃত হয় কল করার জন্য ব্যয় করা হয়েছে। .

এর পরে, একটি পরীক্ষা চালানো হয়েছিল যেখানে একটি সাধারণ জাভা অ্যাপ্লিকেশন লেখা হয়েছিল যাকে বলা হয় System.currentTimeMillis() পদ্ধতিটি লুপে একশ মিলিয়ন বার। অ্যাপ্লিকেশনটি চালানো দেখায় যে এটি CentOS-এ সম্পূর্ণ হতে 13 সেকেন্ড এবং উবুন্টুতে প্রায় 68 সেকেন্ড সময় নেয়, অর্থাৎ 5 গুণ ধীর। সি-তে একটি অনুরূপ প্রোগ্রাম লেখা হয়েছিল যা gettimeofday() ফাংশনকে একশ মিলিয়ন বার বলে, কিন্তু যখন কার্যকর করা হয়, তখন একই রকম ফলাফল পাওয়া যায়।

যেহেতু এটি স্পষ্ট হয়ে গেছে যে সমস্যার উত্সটি বর্তমান সময় ফেরত দেওয়ার কাজ ছিল, সিস্টেমে সঠিক সময়ের বিভিন্ন উত্স নির্বাচন করার সময় সূচকগুলির পরিবর্তনের দিকে মনোযোগ দেওয়া হয়েছিল। “/sys/devices/system/clocksource/clocksource0/current_clocksource”-এর বিষয়বস্তু বিচার করে, গেস্ট সিস্টেমে Linux চালানোর সময় ডিফল্টরূপে “xen” টাইমার ব্যবহার করা হত। সময় উৎসকে "tsc" এ পরিবর্তন করার পর, উবুন্টুতে পরীক্ষার আবেদনের কার্যকর করার সময় 68 থেকে 3.3 সেকেন্ডে কমে যায়, অর্থাৎ এটি 20 গুণ দ্রুত হয়ে উঠেছে। অতিরিক্তভাবে, কেভিএম-ঘড়ির সময় উৎসের একটি কর্মক্ষমতা পরীক্ষা করা হয়েছিল, যা টিএসসির তুলনায় বিলম্বে 20% বৃদ্ধি দেখায়। $ 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 ব্যবহারকারী 0s38.337m0. echo tsc > /sys/devices/system/clocksource/clocksource29.875/current_clocksource $ time java TimeBench বাস্তব 0m0s ব্যবহারকারী 3.370m0s sys 3.353m0s

একটি TSC উত্স নির্বাচন করার সময় সময় পেতে, RDTSC প্রসেসর নির্দেশনা ব্যবহার করা হয়, যার বাস্তবায়নের জন্য একটি সিস্টেম কলের প্রয়োজন হয় না (নির্দেশের জন্য উন্নত সুবিধার প্রয়োজন হয় না এবং CPU-তে নির্মিত টাইম কাউন্টার থেকে একটি মান তৈরি করে)। ডিফল্টরূপে, টিএসসি সক্রিয় করা হয় না কারণ পুরানো দিনে এই উত্সটি ধীরে ধীরে সময়ের প্রবাহকে বাদ দেয়নি, যা অন্যান্য প্রসেসরগুলিতে আরও সঠিক রিডিং অর্জনের জন্য সফ্টওয়্যার দ্বারা সামঞ্জস্য করা হয়। প্রসেসর ডেভেলপমেন্টে বিশেষজ্ঞ একজন প্রকৌশলীর মতে, টিএসসি ব্যবহার করার সময় সময় পরিবর্তনের ভয় দীর্ঘদিন ধরে অসত্য ছিল এবং আধুনিক প্রসেসরে এই উত্স বছরের পর বছর ধরে স্থিতিশীল রিডিং তৈরি করতে পারে।

Netflix-এ প্রোডাকশন সার্ভারগুলিকে একটি TSC উৎসে স্যুইচ করার ফলে লেখার লেটেন্সি 43% হ্রাস পেয়েছে এবং উবুন্টু ব্যবহার করে ফলাফল অর্জন করেছে যা "xen" সময় উত্স সহ CentOS-এর কনফিগারেশনের চেয়ে 4 গুণ দ্রুততর। অধ্যয়নের ফলাফলগুলি আমাজনে স্থানান্তরিত করা হয়েছিল, যা আনুষ্ঠানিকভাবে Xen হাইপারভাইজারের উপর ভিত্তি করে AWS EC2 পরিবেশে ডিফল্ট TSC সময় উৎস ব্যবহার করার সুপারিশ করেছিল (নাইট্রো হাইপারভাইজারের উপর ভিত্তি করে পরিবেশে kvm-ঘড়ি সুপারিশ করা হয়)।

উত্স: opennet.ru