ჩატვირთვის ეკრანი retry-ციკლი იყო და არა გაჭედვა — გადატვირთვა საჭირო არ ყოფილა

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

Crimson Desert Proton Experimental-ის ქვეშ Ubuntu-ზე ზოგჯერ სამუდამოდ იჭედებოდა შენახვის ჩატვირთვის ეკრანზე. ცნობილი გამოსავალი მანქანის სრული გადატვირთვა იყო. ეს „ზოგჯერ“ ხდებოდა, აშკარა ტრიგერის გარეშე.

გაჭედილია თუ ტრიალებს?

პირველი კითხვა ყველაფერს წყვეტს: პროცესი რაღაცას ელოდება თუ CPU-ს წვავს? D მდგომარეობაში პროცესი ბირთვშია დაბლოკილი, ჩვეულებრივ შეტანა-გამოტანაზე, და მისი მოკვლა შეუძლებელია. R მდგომარეობაში პროცესი მუშაობს და სიგნალით მოკვდება.

ps აჩვენებდა R-ს. ნაკადების მიხედვით — ჩამტვირთის სამი ნაკადი, თითოეული 100 % CPU-ზე, და მათი wchan იყო 0: ტრიალებენ user space-ში და არა ბირთვში დაბლოკილი.

გადამწყვეტი გაზომვა

მაღალი CPU თავისთავად ციკლს არ ამტკიცებს: ნელი ჩატვირთვაც წვავს CPU-ს. ამტკიცებს პროგრესი. /proc/<pid>/io ორჯერ წავიკითხე, ხუთწამიანი ინტერვალით:

სიგნალი	დელტა 5 წამში
read_bytes	0
syscr	+38 468

წამში დაახლოებით 7 700 წაკითხვის სისტემური გამოძახება — და არც ერთი რეალურად წაკითხული ბაიტი. თამაშის ლოგი შეცდომას ასახელებდა: ReadFile ვარდება Windows-ის შეცდომით 6, ERROR_INVALID_HANDLE, და მეორდება უსასრულო ციკლში, backoff-ისა და მცდელობების ლიმიტის გარეშე. ჩატვირთვის ეკრანი არაფერს ელოდა — ის ურტყამდა წაკითხვებს, რომლებიც ვერასოდეს გამოვიდოდა.

გამორიცხულია გაზომვით და არა ვარაუდით

• გაჭედილი დისკის I/O — D-ში პროცესები არ არის, წაკითხულია ნული ბაიტი, ადგილი ბევრია;
• ქსელის ან ღრუბლოვანი შენახვის გაჭედვა — გამავალი კავშირები საერთოდ არ არის;
• მეხსიერების ნაკლებობა — ათეულობით გიგაბაიტი თავისუფალია, swap არ გამოიყენება;
• დაზიანებული შენახვა — ლოგმა აჩვენა შენახვის წარმატებული ჩატვირთვა ციკლის დაწყებამდე; გაუმართაობა დაახლოებით რვა წამის შემდეგ დაიწყო, ასეტების სტრიმინგის დროს;
• GPU-ს გაჭედვა — GPU-ს დატვირთვა ჩატვირთვის ეკრანის ანიმაცია იყო და მყისიერად დაეცა, როგორც კი პროცესი გაქრა.

გამოსწორება

რადგან პროცესი R-ში იყო, სიგნალი საკმარისი აღმოჩნდა:

pkill -TERM -f CrimsonDesert.exe

ის SIGTERM-ით სუფთად დასრულდა. GPU-ს დატვირთვა 99 %-დან 2 %-მდე დაეცა. გადატვირთვა ყოველთვის ზედმეტი იყო.

რა იწვევს არავალიდურ ჰენდლს, ჯერ უცნობია — დიდი ალბათობით, რბოლა თამაშის ასეტების სტრიმინგში ან Proton-ის ექსპერიმენტულ ვერსიაში. შემდეგ ჯერზე PROTON_LOG=1 ჩართული მექნება, რომ ტრასამ ფაილი დაასახელოს.

დასკვნები

• R თუ D წყვეტს, საერთოდ საჭიროა თუ არა გადატვირთვა. მოტრიალე პროცესი გაჭედილი არ არის.
• მაღალი CPU + გაჩერებული I/O მთვლელები = retry-ციკლი. გაზომეთ დელტა რამდენიმე წამში, სანამ უროს მისწვდებით.
• ჰიპოთეზები ციფრებით გამორიცხეთ. ყოველი „იქნებ დისკია / ქსელია / GPU-ა“ ერთი ბრძანებით უარიყო.
• იგივე ანაბეჭდი ყველგან გვხვდება: init-კონტეინერი, რომელიც წარუმატებელ mount-ს იმეორებს, sidecar, რომელიც მკვდარ ენდპოინტს იმეორებს, CI-ის ნაბიჯი, რომელიც 404-ს იმეორებს.