კურსის სტუდენტებისთვის მომზადებული სტატიის თარგმანი "ლინუქსის ადმინისტრატორი".

ადრე მე ვისაუბრე იმაზე, თუ როგორ უნდა გამოსცადო და ჩართო Hugepages Linux-ზე.
ეს სტატია სასარგებლო იქნება მხოლოდ იმ შემთხვევაში, თუ თქვენ ნამდვილად გაქვთ ადგილი, რომ გამოიყენოთ Hugepages. მე შევხვდი უამრავ ადამიანს, რომლებიც მოტყუებულნი არიან იმ პერსპექტივით, რომ Hugepages ჯადოსნურად გააუმჯობესებს პროდუქტიულობას. თუმცა, უზარმაზარი პეიჯინგი კომპლექსური თემაა და არასწორად გამოყენების შემთხვევაში შეიძლება დაქვეითდეს შესრულება.

ნაწილი 1: იმის შემოწმება, რომ უზარმაზარი გვერდები ჩართულია Linux-ზე (ორიგინალი აქ)

პრობლემა:
თქვენ უნდა შეამოწმოთ ჩართულია თუ არა HugePages თქვენს სისტემაში.

გამოსავალი:
ეს საკმაოდ მარტივია:

cat /sys/kernel/mm/transparent_hugepage/enabled

თქვენ მიიღებთ ასეთ რამეს:

always [madvise] never

თქვენ ნახავთ ხელმისაწვდომი ვარიანტების ჩამონათვალს (ყოველთვის, შეშლილი, არასდროს), ხოლო ამჟამად აქტიური ვარიანტი ჩასმული იქნება ფრჩხილებში (ნაგულისხმევად შეშლილი).

შეშლილი ნიშნავს რომ transparent hugepages ჩართულია მხოლოდ მეხსიერების ზონებისთვის, რომლებიც ცალსახად ითხოვენ უზარმაზარი გვერდების გამოყენებას madvise (2).

ყოველთვის ნიშნავს რომ transparent hugepages ყოველთვის ჩართულია ყველა პროცესისთვის. ეს ჩვეულებრივ აუმჯობესებს შესრულებას, მაგრამ თუ თქვენ გაქვთ გამოყენების შემთხვევა, როდესაც ბევრი პროცესი მოიხმარს მცირე რაოდენობით მეხსიერებას, მაშინ მეხსიერების მთლიანი დატვირთვა შეიძლება მკვეთრად გაიზარდოს.

არასოდეს ნიშნავს რომ transparent hugepages არ იქნება ჩართული მაშინაც კი, როდესაც მოთხოვნილი იქნება madvise-ის გამოყენებით. მეტის გასაგებად, დაუკავშირდით დოკუმენტაცია Linux-ის ბირთვები.

როგორ შევცვალოთ ნაგულისხმევი მნიშვნელობა

ვარიანტი 1: პირდაპირ შეცვლა sysfs (გადატვირთვის შემდეგ პარამეტრი უბრუნდება ნაგულისხმევ მნიშვნელობას):

echo always >/sys/kernel/mm/transparent_hugepage/enabled
echo madvise >/sys/kernel/mm/transparent_hugepage/enabled
echo never >/sys/kernel/mm/transparent_hugepage/enabled

ვარიანტი 2: შეცვალეთ სისტემის ნაგულისხმევი ბირთვი შეცვლილი კონფიგურაციით ხელახლა შედგენით (ეს ვარიანტი რეკომენდებულია მხოლოდ იმ შემთხვევაში, თუ იყენებთ მორგებულ ბირთვს):

• ყოველთვის ნაგულისხმევად დასაყენებლად გამოიყენეთ:

  CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y
  # Comment out CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y

• madvise ნაგულისხმევად დასაყენებლად გამოიყენეთ:

  CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y
  # Comment out CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y

ნაწილი 2: HugePages-ის უპირატესობები და უარყოფითი მხარეები

ჩვენ შევეცდებით შერჩევით ავხსნათ Hugepages-ის გამოყენების უპირატესობები, უარყოფითი მხარეები და შესაძლო ხარვეზები. ვინაიდან ტექნოლოგიურად რთული და პედანტური სტატია, სავარაუდოდ, რთული გასაგები იქნება იმ ადამიანებისთვის, რომლებიც ცდებიან, რომ Hugepages პანაცეაა, მე შევწირავ სიზუსტეს სიმარტივეს. უბრალოდ უნდა გვახსოვდეს, რომ ბევრი თემა მართლაც რთულია და, შესაბამისად, ძალიან გამარტივებული.

გთხოვთ გაითვალისწინოთ, რომ ჩვენ ვსაუბრობთ 64-ბიტიან x86 სისტემებზე, რომლებიც მუშაობენ Linux-ზე, და რომ მე უბრალოდ ვარაუდობ, რომ სისტემა მხარს უჭერს გამჭვირვალე უზარმაზარი გვერდებს (რადგან მინუსი არ არის უზარმაზარი გვერდების გადაწერა), როგორც ეს ხდება თითქმის ნებისმიერ თანამედროვე Linux-ში. გარემო.

დამატებით ტექნიკურ აღწერას დავდებ ქვემოთ მოცემულ ბმულებზე.

Ვირტუალური მეხსიერება

თუ თქვენ ხართ C++ პროგრამისტი, იცით, რომ მეხსიერებაში არსებულ ობიექტებს აქვთ კონკრეტული მისამართები (მაჩვენებლის მნიშვნელობები).

თუმცა, ეს მისამართები სულაც არ ასახავს მეხსიერებაში არსებულ ფიზიკურ მისამართებს (RAM მისამართები). ისინი წარმოადგენენ მისამართებს ვირტუალურ მეხსიერებაში. პროცესორს აქვს სპეციალური MMU (მეხსიერების მართვის ერთეული) მოდული, რომელიც ეხმარება ბირთვს ვირტუალური მეხსიერების ფიზიკურ მდებარეობაზე გადატანაში.

ამ მიდგომას ბევრი უპირატესობა აქვს, მაგრამ ყველაზე მნიშვნელოვანია:

• შესრულება (სხვადასხვა მიზეზის გამო);
• პროგრამის იზოლაცია, ანუ ვერცერთი პროგრამა ვერ წაიკითხავს სხვა პროგრამის მეხსიერებიდან.

რა არის გვერდები?

ვირტუალური მეხსიერება დაყოფილია გვერდებად. თითოეული ცალკეული გვერდი მიუთითებს კონკრეტულ ფიზიკურ მეხსიერებაზე, მას შეუძლია მიუთითოს RAM-ის არეზე, ან შეიძლება მიუთითოს ფიზიკურ მოწყობილობაზე მინიჭებულ მისამართზე, როგორიცაა ვიდეო ბარათი.

გვერდების უმეტესობა, რომელთანაც თქვენ გაქვთ საქმე, მიუთითებს RAM-ზე ან არის გაცვლილი, რაც ნიშნავს რომ ისინი ინახება თქვენს მყარ დისკზე ან SSD-ზე. ბირთვი მართავს თითოეული გვერდის ფიზიკურ განლაგებას. თუ გაყალბებულ გვერდზე წვდომა ხდება, ბირთვი აჩერებს თემას, რომელიც ცდილობს მეხსიერების წვდომას, კითხულობს გვერდს მყარი დისკიდან/SSD-დან RAM-ში და შემდეგ აგრძელებს ნაკადის შესრულებას.

ეს პროცესი გამჭვირვალეა, რაც იმას ნიშნავს, რომ ის აუცილებლად არ იკითხება პირდაპირ HDD/SSD-დან. ჩვეულებრივი გვერდების ზომაა 4096 ბაიტი. უზარმაზარი გვერდების ზომაა 2 მეგაბაიტი.

თარგმანის ასოციაციური ბუფერი (TLB)

როდესაც პროგრამა წვდება მეხსიერების გვერდზე, პროცესორმა უნდა იცოდეს, რომელი ფიზიკური გვერდიდან წაიკითხოს მონაცემები (ანუ აქვს ვირტუალური მისამართის რუკა).

ბირთვს აქვს მონაცემთა სტრუქტურა (გვერდის ცხრილი), რომელიც შეიცავს ყველა ინფორმაციას გამოყენებული გვერდების შესახებ. ამ მონაცემთა სტრუქტურის გამოყენებით, შეგიძლიათ ვირტუალური მისამართი ფიზიკურ მისამართზე დააფიქსიროთ.

თუმცა, გვერდების ცხრილი საკმაოდ რთული და ნელია, ამიტომ ჩვენ უბრალოდ ვერ გავაანალიზებთ მონაცემთა მთლიან სტრუქტურას ყოველ ჯერზე, როცა პროცესი მეხსიერებას წვდება.

საბედნიეროდ, ჩვენს პროცესორს აქვს TLB, რომელიც ინახავს რუკებს ვირტუალურ და ფიზიკურ მისამართებს შორის. ეს ნიშნავს, რომ მიუხედავად იმისა, რომ ჩვენ გვჭირდება გვერდის ცხრილის გაანალიზება პირველი წვდომის მცდელობისას, ყველა შემდგომი წვდომა გვერდზე შეიძლება დამუშავდეს TLB-ში, რაც საშუალებას იძლევა სწრაფი ფუნქციონირება.

იმის გამო, რომ ის დანერგილია როგორც ფიზიკური მოწყობილობა (რაც მას პირველ რიგში აჩქარებს), მისი ტევადობა შეზღუდულია. ასე რომ, თუ გსურთ მეტი გვერდის წვდომა, TLB ვერ შეძლებს ყველა მათგანის რუკების შენახვას, რაც გამოიწვევს თქვენი პროგრამის გაცილებით ნელ მუშაობას.

ჰაიპეიჯი სამაშველოში მოდის

მაშ, რა შეგვიძლია გავაკეთოთ TLB-ს გადაჭარბების თავიდან ასაცილებლად? (ვვარაუდობთ, რომ პროგრამას ჯერ კიდევ იგივე რაოდენობის მეხსიერება სჭირდება).

სწორედ აქ შემოდის Hugepages. 4096 ბაიტის ნაცვლად, რომელიც მოითხოვს მხოლოდ ერთ TLB ჩანაწერს, ერთი TLB ჩანაწერი ახლა შეიძლება მიუთითებდეს უზარმაზარ 2 მეგაბაიტზე. დავუშვათ, TLB-ს აქვს 512 ჩანაწერი, აქ Hugepages-ის გარეშე შეგვიძლია დავამთხვიოთ:

4096 b⋅512=2 MB

მაშინ როგორ შეგვიძლია შევადაროთ მათ:

2 MB⋅512=1 GB

ამიტომაა Hugepages გასაოცარია. მათ შეუძლიათ გააუმჯობესონ პროდუქტიულობა დიდი ძალისხმევის გარეშე. მაგრამ აქ არის მნიშვნელოვანი უკუჩვენებები.

უზარმაზარი გვერდების გაყალბება

ბირთვი ავტომატურად აკონტროლებს რამდენად ხშირად გამოიყენება მეხსიერების თითოეული გვერდი. თუ არ არის საკმარისი ფიზიკური მეხსიერება (RAM), ბირთვი გადაიტანს ნაკლებად მნიშვნელოვან (ნაკლებად ხშირად გამოყენებულ) გვერდებს მყარ დისკზე, რათა გაათავისუფლოს RAM უფრო მნიშვნელოვანი გვერდებისთვის.
პრინციპში, იგივე ეხება Hugepages-ს. თუმცა, ბირთვს შეუძლია შეცვალოს მხოლოდ მთელი გვერდები და არა ცალკეული ბაიტები.

ვთქვათ, გვაქვს ასეთი პროგრამა:

char* mymemory = malloc(2*1024*1024); // Возьмем это за одну Hugepage!
// Заполним mymemory какими-либо данными
// Сделаем много других вещей,
// которые приведут к подмене страницы mymemory
// ...
// Запросим доступ только к первому байту
putchar(mymemory[0]); 

ამ შემთხვევაში, ბირთვს დასჭირდება შეცვალოს (წაიკითხოს) 2 მეგაბაიტი ინფორმაცია მყარი დისკიდან/SSD მხოლოდ იმისთვის, რომ თქვენ წაიკითხოთ ერთი ბაიტი. რაც შეეხება ჩვეულებრივ გვერდებს, მყარი დისკიდან/SSD-დან მხოლოდ 4096 ბაიტის წაკითხვაა საჭირო.

ამიტომ, თუ უზარმაზარი გვერდი აკრძალულია, მისი წაკითხვა უფრო სწრაფია, თუ თქვენ გჭირდებათ წვდომა მთელ გვერდზე. ეს ნიშნავს, რომ თუ თქვენ ცდილობთ შემთხვევით შეხვიდეთ მეხსიერების სხვადასხვა ნაწილზე და უბრალოდ კითხულობთ რამდენიმე კილობაიტს, უნდა გამოიყენოთ ჩვეულებრივი გვერდები და არ ინერვიულოთ სხვაზე.

მეორეს მხრივ, თუ მეხსიერების დიდ ნაწილზე თანმიმდევრულად წვდომა გჭირდებათ, უზარმაზარი გვერდები გააუმჯობესებს თქვენს შესრულებას. თუმცა, თქვენ თვითონ უნდა შეამოწმოთ იგი (არა აბსტრაქტული პროგრამული უზრუნველყოფით) და ნახოთ რა მუშაობს უფრო სწრაფად.

განაწილება მეხსიერებაში

თუ თქვენ დაწერთ C, თქვენ იცით, რომ შეგიძლიათ მოითხოვოთ თვითნებურად მცირე (ან თითქმის თვითნებურად დიდი) მეხსიერების გროვიდან გამოყენებით malloc(). ვთქვათ, გჭირდებათ 30 ბაიტი მეხსიერება:

char* mymemory = malloc(30);

პროგრამისტს შეიძლება მოეჩვენოს, რომ თქვენ „ითხოვთ“ 30 ბაიტ მეხსიერებას ოპერაციული სისტემიდან და აბრუნებთ მაჩვენებელს ზოგიერთ ვირტუალურ მეხსიერებაში. Მაგრამ სინამდვილეში malloc () უბრალოდ C ფუნქციაა, რომელიც იძახებს ფუნქციის შიგნიდან ბრკ და სბრკ ოპერაციული სისტემიდან მეხსიერების მოთხოვნის ან განთავისუფლების მიზნით.

თუმცა, ყოველი განაწილებისთვის მეტი და მეტი მეხსიერების მოთხოვნა არაეფექტურია; სავარაუდოდ, მეხსიერების ზოგიერთი სეგმენტი უკვე გათავისუფლებულია (free())და ჩვენ შეგვიძლია მისი ხელახლა გამოყენება. malloc() ახორციელებს საკმაოდ რთულ ალგორითმებს განთავისუფლებული მეხსიერების ხელახლა გამოყენებისათვის.

ამავდროულად, შენთვის ყველაფერი შეუმჩნევლად ხდება, რატომ უნდა შეგაწუხო? მაგრამ რადგან გამოწვევა free() არ ნიშნავს ამას მეხსიერება აუცილებლად დაუყოვნებლივ უბრუნდება ოპერაციულ სისტემას.

არსებობს მეხსიერების ფრაგმენტაცია. უკიდურეს შემთხვევაში, არის გროვის სეგმენტები, სადაც გამოიყენება მხოლოდ რამდენიმე ბაიტი, ხოლო მათ შორის ყველაფერი გათავისუფლებულია (free()).

გთხოვთ გაითვალისწინოთ, რომ მეხსიერების ფრაგმენტაცია წარმოუდგენლად რთული თემაა და პროგრამის უმნიშვნელო ცვლილებებმაც კი შეიძლება მნიშვნელოვანი გავლენა იქონიოს. უმეტეს შემთხვევაში, პროგრამები არ გამოიწვევს მეხსიერების მნიშვნელოვან ფრაგმენტაციას, მაგრამ უნდა იცოდეთ, რომ თუ გროვის ზოგიერთ უბანში ფრაგმენტაციის პრობლემაა, უზარმაზარმა გვერდებმა შეიძლება გააუარესოს სიტუაცია.

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

ამ სტატიის წაკითხვის შემდეგ, თქვენ დაადგინეთ, თქვენი პროგრამის რომელ ნაწილს შეუძლია ისარგებლოს უზარმაზარი გვერდების გამოყენებით და რომელი არა. ასე რომ, უზარმაზარი გვერდები საერთოდ უნდა იყოს ჩართული?

საბედნიეროდ შეგიძლიათ გამოიყენოთ madvise()უზარმაზარი პეიჯინგის ჩართვა მეხსიერების მხოლოდ იმ უბნებისთვის, სადაც ის სასარგებლო იქნება.

პირველ რიგში, შეამოწმეთ, რომ უზარმაზარი გვერდები მუშაობს madvise() რეჟიმში გამოყენებით ინსტრუქციები სტატიის დასაწყისში.

შემდეგ გამოიყენეთ madvise()რომ ზუსტად უთხრას ბირთვს სად გამოიყენოს უზარმაზარი გვერდები.

#include <sys/mman.h>
// Аллоцируйте большое количество памяти, которую будете использовать
size_t size = 256*1024*1024;
char* mymemory = malloc(size);
// Просто включите hugepages…
madvise(mymemory, size, MADV_HUGEPAGE);
// … и задайте следующее
madvise(mymemory, size, MADV_HUGEPAGE | MADV_SEQUENTIAL)

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

იხილეთ დოკუმენტაცია (manpage)madviseრომ გაიგოთ მეტი მეხსიერების მართვის შესახებ და madvise(), ამ თემას აქვს წარმოუდგენლად ციცაბო სასწავლო მრუდი. ასე რომ, თუ თქვენ აპირებთ ამაში ნამდვილად კარგი გახდეთ, მოემზადეთ წასაკითხად და ტესტირებისთვის რამდენიმე კვირის განმავლობაში, სანამ რაიმე დადებით შედეგს მოელოდებით.

რა წავიკითხო?

• IBM OpenStack სტატია უზარმაზარ გვერდებზე
• გამჭვირვალე უზარმაზარი გვერდები არაგამჭვირვალე უზარმაზარი გვერდების წინააღმდეგ
• ვიკიპედიის სტატია TLB-ის შესახებ
• Linux-ის ბირთვის დოკუმენტაცია გამჭვირვალე უზარმაზარ გვერდებზე
• StackOverflow: უზარმაზარი გვერდები მიდრეკილია მეხსიერების ფრაგმენტაციისკენ
• Microsoft-ის სტატია ვირტუალური მეხსიერების მართვის შესახებ

გაქვთ შეკითხვა? დაწერეთ კომენტარებში!

წყარო: www.habr.com