სისტემაში შერჩეული დროის წყაროს შესრულებაზე გავლენის ანალიზი

ბრენდან გრეგმა, DTrace-ის ერთ-ერთმა დეველოპერმა, რომელიც ამჟამად ავითარებს BPF-ზე დაფუძნებულ შესრულების ანალიზის ინსტრუმენტებს Linux-ის ბირთვში, შეაჯამა ეფექტურობის პრობლემების ანალიზის შედეგად მიღებული გამოცდილება, რომელიც Netflix-ს შეექმნა Cassandra DBMS-ის CentOS-დან Ubuntu-ში გადატანისას. Amazon EC2 ღრუბელი, რომელიც დაფუძნებულია Xen-ზე. მიგრაციის შემდეგ, პროცესორის დატვირთვა გაიზარდა 30%-ით, ხოლო ჩაწერის ოპერაციების შეფერხებები გაიზარდა დაახლოებით იგივე რაოდენობით. როგორც ირკვევა, აპლიკაციების შესრულება, რომლებიც ინტენსიურად ითხოვენ დროის ინფორმაციას, ძალიან დამოკიდებულია სისტემაში არჩეულ დროის ზუსტ წყაროზე.

თავდაპირველად, შესრულების შემცირების მიზეზი აშკარა არ იყო და დიაგნოზი დაიწყო მუდმივად გაშვებული ან პერიოდულად დაწყებული რესურსზე ინტენსიური სისტემის პროცესების შესაძლო ზემოქმედების მონიტორინგით, ზედა და execsnoop უტილიტების გამოყენებით. მაგრამ ყველაფერი იმაზე მეტყველებდა, რომ რესურსების მოხმარება გაიზარდა კონკრეტულად Cassandra DBMS-ში, რომელიც დაწერილია ჯავაში. CentOS-სა და Ubuntu-ზე პარალელურად მიმდინარე ორი Cassandra პროცესის პროფილირების მეტრიკის შედარებამ, იგივე მოთხოვნების დამუშავებამ აჩვენა, რომ მთლიანი დროის დაახლოებით 32% დაიხარჯა os::javaTimeMillis(), რომელიც გამოიყენება მიმდინარე დროის შესახებ ინფორმაციის მისაღებად. .

ამის შემდეგ ჩატარდა ექსპერიმენტი, რომელშიც დაიწერა მარტივი Java აპლიკაცია, რომელსაც ციკლში ას მილიონჯერ უწოდეს System.currentTimeMillis() მეთოდი. აპლიკაციის გაშვებამ აჩვენა, რომ CentOS-ზე დასრულებას 13 წამი დასჭირდა, Ubuntu-ზე კი დაახლოებით 68 წამი, ე.ი. 5-ჯერ ნელა. მსგავსი პროგრამა დაიწერა C-ში, რომელსაც ას მილიონჯერ უწოდებდა gettimeofday() ფუნქციას, მაგრამ შესრულებისას მიიღეს მსგავსი შედეგები.

მას შემდეგ, რაც გაირკვა, რომ პრობლემის წყარო იყო მიმდინარე დროის დაბრუნების ფუნქცია, ყურადღება მიექცა ინდიკატორების ცვლილებებს სისტემაში ზუსტი დროის სხვადასხვა წყაროს არჩევისას. თუ ვიმსჯელებთ „/sys/devices/system/clocksource/clocksource0/current_clocksource“-ის შინაარსით, „xen“ ტაიმერი ნაგულისხმევად გამოიყენებოდა სტუმრების სისტემაში Linux-ის გაშვებისას. დროის წყაროს „tsc“-ზე შეცვლის შემდეგ, Ubuntu-ში სატესტო აპლიკაციის შესრულების დრო 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 $ დრო java TimeBench რეალური 1m8.300s მომხმარებლის $0s 38.337sm 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%-ით შემცირება და Ubuntu-ს გამოყენებით მიღწეული შედეგები, რომლებიც 4-ჯერ უფრო სწრაფი იყო, ვიდრე კონფიგურაციები, რომლებიც მუშაობენ CentOS-ზე „xen“ დროის წყაროთი. კვლევის შედეგები გადაეცა Amazon-ს, რომელიც ოფიციალურად რეკომენდაციას უწევს ნაგულისხმევი TSC დროის წყაროს გამოყენებას AWS EC2 გარემოში Xen ჰიპერვიზორის საფუძველზე (kvm-clock რჩება რეკომენდირებული Nitro ჰიპერვიზორის ბაზაზე დაფუძნებულ გარემოში).

წყარო: opennet.ru