restart გრაფიკები, რომლებიც გვეხმარება, და ისინი, რომლებიც მხოლოდ ხელს უშლის

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

ამიტომ კითხვა "უნდა ვაკეთო თუ არა ღამის restart?" კი არ არის, არამედ "რა მტკიცებულება გვაქვს, რომ restart გვეხმარება და რამდენი მჭირდება?" ეს პოსტი სწორედ იმაზე პასუხს ეძღვნება იმ გრაფიკებით, რაც უკვე გაქვს: რას ანულებს restart ნამდვილად, როგორ განასხვავო გაჟონვა პლატოსგან, რა სიხშირეს უჭერს მხარს მტკიცებულება და როგორ გაუშვა restart, რომ არავინ დაკარგოს სამუშაო. გრაფიკის აგების მექანიკა - cron ხაზი, დავალებების თანმიმდევრობა, დაყოვნებები - დაგეგმილი დავალებები, რომლებიც ღირს-შია.

რას ანულებს restart ნამდვილად#

restart პროცესს აგდებს და ახალს იმავე ფაილებიდან იწყებს. ეს არის მთელი მისი არსი და რასაც ის ასწორებს, პირდაპირ მისგან გამომდინარეობს.

ამ ცხრილის შუა ნაწილში დევს მთელი პატიოსანი სარგებლის უმეტესობა. ბოლოში კი ხალხი restart-ებს მაინც სვამს და სწორედ ამიტომ ხდება ხშირად, რომ გრაფიკი, რომელიც "ცოტათი გვეხმარება", სინამდვილეში ხალხის შეწუხების გარდა არაფერს აკეთებს. თუ შენი ჩივილი ისაა, რომ სერვერი პიკზე ნელია და 04:00-ზე კარგად, 05:00-ზე restart არაფერს ეხება - იმის ნაცვლად წაიკითხე რატომ ეცემა TPS და რა ვქნა.

დაამტკიცე, რომ გჭირდება: წაიკითხე მეხსიერების გრაფიკი#

პანელი მეხსიერებას, CPU-სა და დისკს გეგმის ლიმიტების საწინააღმდეგოდ ხატავს. ეს გრაფიკი კითხვას პირდაპირ პასუხობს, თუ დღეების განმავლობაში უყურებ და არა წუთების.

გადატვირთე სერვერი, შემდეგ ჩაიწერე მეხსიერების მნიშვნელობა ოთხ წერტილში და შეადარე ფორმა:

Server A                        Server Bafter restart   1.9 GB          after restart   1.9 GB+1 hour         2.6 GB          +1 hour         2.4 GB+6 hours        3.1 GB          +24 hours       3.4 GB+24 hours       3.2 GB          +48 hours       4.6 GB+72 hours       3.2 GB          +72 hours       5.8 GB

Server A ივსება და პლატოზე გადის. ეს გაჟონვა არ არის, ეს ქეშია, რომელიც თავის საქმეს აკეთებს, და ღამის restart-ი ღამის შეწუხების გარდა არაფერს გაძლევს. Server B-ს ქვედა ზღვარი ყოველდღე იზრდება და საბოლოოდ ჭერს მიაღწევს; ეს გაჟონვაა და restart კანონიერი დროებითი გამოსავალია, სანამ მიზეზი არ მოიძებნება.

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

Minecraft-ისთვის დაამატე მეორე გაზომვა, რომელიც მეხსიერება არ არის: /mspt Paper-ში აჩვენებს, რამდენხანს გრძელდება tick, და მისი ტრენდი დღეების განმავლობაში გეუბნება, სიმულაცია უარესდება თუ მხოლოდ heap. თუ ის სტაბილურად იზრდება, profile მიზეზს დაახლოებით ათ წუთში იპოვის - spark ანგარიშის კითხვა ამას ფარავს. Node ან Python აპლიკაციისთვის ექვივალენტია resident მეხსიერების ლიმიტთან მიმართებით დაკვირვება, დეტალებით Node.js-ის მეხსიერების ლიმიტები ახსნილი-ში.

სუფთა გაჩერება და kill ერთი და იგივე მოვლენა არ არის#

სწორედ ეს ხდის restart-ებს ან უფასოს ან ძვირს და ის უხილავია, სანამ პირველად არ დაგიჯდება.

• Stop და Restart სერვერს თხოვს გამორთვას. პროცესს შენახვის, ლოგების გამოცლისა და ფაილების დახურვის შანსი ეძლევა. თამაშისთვის, რომლის სამყაროც მეხსიერებაში ცხოვრობს, ეს შენახვა მთელი აზრია.
• Kill არ ითხოვს. პროცესი უბრალოდ ქრება. ყველაფერი, რაც დისკზე არ ჩაწერილა, გაქრა.
• out-of-memory გაჩერება kill-ს უფრო ჰგავს. მეხსიერების ლიმიტზე კონტეინერს kernel აჩერებს და ის სუფთად ბრუნდება და არა swap-ში რჩება, რაც მანქანას ჯანსაღს და სხვა სერვერებს სწრაფს ინარჩუნებს, მაგრამ თამაშის თვალსაზრისით გეგმის გარეშე გაჩერებაა. რაც სამყაროს იმ წამს მეხსიერებაში ჰქონდა, იკარგება.

ეს ბოლო წერტილი ყველაზე ძლიერი არგუმენტია restart გრაფიკის სასარგებლოდ სერვერზე, რომელსაც ნამდვილი გაჟონვა აქვს. საქმე წარმადობაში არ არის; საქმე იმაშია, ვინ ირჩევს მომენტს. restart 05:00-ზე, მის წინ შენახვით, არაფერი ღირს. იგივე სერვერი, რომელიც ჭერს 21:30-ზე აღწევს, ყველას ბოლო შენახვის ინტერვალს ართმევს, Valheim-ის ნაგულისხმევი კი ოცდაათი წუთია.

რამდენად ხშირად და მტკიცებულება თითოეული სიხშირისთვის#

ინტერვალი იმას მიუსადაგე, რასაც გრაფიკი აჩვენებდა და არა იმას, რასაც სხვა სერვერები აკეთებენ.

ზღვარი, რომლის მიმართაც პატიოსანი უნდა იყო: თუ სერვერს გამოსადეგად დარჩენისთვის დღეში ერთხელ მეტჯერ სჭირდება restart, restart გამოსავალი არ არის. ან გეგმაა ძალიან პატარა იმისთვის, რაც მასზე მუშაობს, ან რაღაც გატეხილია. რატომ იტვირთება შენი გეიმ სერვერი განუწყვეტლივ მიზეზებს ერთმანეთისგან ყოფს და პასუხი ხშირად ისაა, რომ მეხსიერების ლიმიტი და დაყენებული heap ერთმანეთს ეჯიბრება.

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

restart ისე, რომ არავინ არაფერი დაკარგოს#

თანმიმდევრობა დროზე მნიშვნელოვანია. restart, რომელიც გაფრთხილების გარეშე boss-ის ბრძოლის დროს მოდის, მეტ კეთილგანწყობას გიჯდება, ვიდრე მეხსიერება, რომელიც აღდგა.

1. გააფრთხილე ორჯერ. თხუთმეტი წუთით და ხუთი წუთით ადრე, თამაშში. გრაფიკი Discord-ში ერთხელ გამოაქვეყნე, რომ ყოველ ღამე სიახლე არ იყოს.
2. შენახვა აიძულე გაჩერებამდე. save-all flush Minecraft-ისთვის, Save RCON-ით Palworld-ისთვის, saveworld 7 Days to Die-სთვის. თამაშები კონსოლის შენახვის ბრძანების გარეშე - Valheim მათ შორის - სუფთა გაჩერებას ეყრდნობა, სწორედ ამიტომ უნდა იყოს restart Stop და არა Kill.
3. backup restart-მდე გააკეთე და არა მისი დროს. მიმდინარე გამორთვის სერვერის backup მხოლოდ მიმდინარე გამორთვის სერვერის backup-ია და ეს არის არქივი, რომელსაც მოეშველები, თუ restart-ის მომენტში რამე გაფუჭდა - backup-ები, რომლებიც მართლა აღდგება გვეუბნება, რა უნდა იყოს მასში.
4. დატოვე შუალედი. სამოცი წამი შენახვასა და გაჩერებას შორის და გაჩერებასა და მომდევნო ნებისმიერ რამეს შორის.
5. აირჩიე მშვიდი საათი და 02:00-დან 03:00-მდე აარიდე თავი, სადაც ზაფხულის დროზე გადასვლა დავალებას ორჯერ ან საერთოდ არ აწარმოებინებს.

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

რას მალავს ღამის restart#

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

• mod-ის ან plugin-ის გაჟონვა. restart-ის შემდეგ დაამატე ერთი ეჭვმიტანილი ერთდროულად და უყურე 24-საათიან ქვედა ზღვარს. მოსაწყენია, ეფექტურია და მოკლე გზა არ არსებობს.
• ობიექტების დაგროვება. item frame-ები, armour stand-ები, minecart-ები და mob farm-ები სამყაროში ინახება და restart-ს გადაურჩება; restart ასუფთავებს დაგდებულ ნივთებს და მათ გარშემო ჩატვირთულ chunk-ებს. მეხსიერებაზე დაბრალებამდე დათვალე ობიექტები.
• chunk loader-ები და ყოველთვის ჩატვირთული უბნები. სერვერი, სადაც ოცი chunk loader შორეულ მექანიზმებს tick-ში ამუშავებს, ამას ყოველ tick-ზე იხდის და არა მხოლოდ სამი დღის შემდეგ.
• ლოგები, რომლებიც დისკს ავსებს. restart დისკს არ ათავისუფლებს. სერვერი, რომელიც კვირას კარგად იქცევა და შემდეგ არა, ხშირად უბრალოდ ადგილი უწყდება - შეამოწმე დისკი იმავე გრაფიკზე, რაზეც მეხსიერება. ლოგები, რომლებიც შესანახად ღირს შენახვის მხარეს ფარავს.
• ბაზა, რომელსაც არასოდეს უვლიათ. ცხრილის გაჯერება და გამოტოვებული ინდექსები ნელ-ნელა უარესდება და გეიმ სერვერის არცერთი restart მათ არ ეხება. PostgreSQL-ისთვის ეს vacuum და bloat-ია; ყველაფრისთვის სხვისთვის ეს სულ მცირე ნელი მოთხოვნების ლოგის დათვალიერებაა.
• mod-ები, რომლებიც არასოდეს იყო თავსებადი. პაკეტი, რომელიც სამი ვერსიიდან არის აწყობილი, საკუთარი გრაფიკით გაფუჭდება. mod-იანი სერვერის სისუფთავის შენარჩუნება პრევენციაა.

თუ ღამის restart ტვირთამტარია, ჩაიწერე, რას მალავს ის. ეს ჩანაწერი ნამდვილი bug ანგარიშია და ერთადერთია, რაც გრაფიკს ოდესმე გამორთავს.

განახლებები restart-ებია მიზეზით#

restart-ის მეორე კანონიერი გამოყენება რამის გამოყენებაა. თამაშის განახლება, mod-ის განახლება, კონფიგურაციის ცვლილება, რომელიც მხოლოდ გაშვებისას იკითხება, Java-ს ახალი ვერსია. ეს ზედმეტი მოვლა არ არის; ეს საქმის არსია.

წესები ღამის შემთხვევისგან განსხვავებულია და ცალკე დასახელებად ღირს:

• ჯერ backup გააკეთე და ჩაკეტე. არა ღამის ბრუნვა - გააზრებული backup ცვლილებამდე უშუალოდ, ჩაკეტილი, რომ ბრუნვამ არ ამოაგდოს. თუ განახლება ცუდად წავიდა, ეს არქივია უკან გზა, და restore-ის გამოცდა, სანამ გჭირდება არის გზა, რომ იცოდე, მუშაობს.
• mod-იან სერვერს patch-დღეს ავტომატურად ნუ განაახლებ. თამაშის ყოველი patch mod-ებს ტეხავს, სანამ მათი ავტორები არ დაეწევიან. გამორთე განახლება, დაელოდე, შემდეგ განაახლე გააზრებულად - რა ვქნა, როცა mod-ის განახლება ტეხავს.
• განაცხადე როგორც განახლება და არა როგორც restart. ხალხი იტანს შეფერხებას, რომელიც ესმის. "ვახლდებით 1.21.4-ზე, თხუთმეტ წუთში ვბრუნდებით" სულ სხვა შეტყობინებაა, ვიდრე სერვერის გაქრობა.
• აპლიკაციებისთვის restart deploy-ა. იგივე თანმიმდევრობა health check-ებით - იხილე zero-downtime deploy-ები პატარა სერვერზე.

როცა ავტომატური restart-ები შენ წინააღმდეგ მუშაობს#

ნებისმიერ მართულ პლატფორმაზე restart-ების მეორე წყარო არსებობს: crash watcher-ი. ჩვენი ყოველ ორ წუთში ამოწმებს სერვერს, რომელიც ოფლაინში გავიდა ან რომლის uptime უკან წავიდა, და მას აბრუნებს. restart-ები, რომლებიც შენ მოითხოვე, არ ითვლება. საათში სამი გეგმის გარეშე restart სერვერის გვერდზე გაფრთხილებას სვამს და ავტომატურად ხსნის ticket-ს; ექვსი სერვერს აჩერებს, რაც მკაცრად ჟღერს, სანამ დღეს სერვერს crash-loop-ში არ უყურებ.

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

ეს ასევე ნიშნავს, რომ შენი დაგეგმილი restart-ები ამ მრიცხველს უხილავია, ამიტომ ღამის გრაფიკი გაფრთხილებას არასოდეს გამოიწვევს. თუ საათში სამის გაფრთხილებას ხედავ, ის ნამდვილია: რაღაც თავისით გადის და არცერთი გრაფიკი ამას არ გაასწორებს.

FAQ#

მჭირდება საერთოდ ღამის restart?

მხოლოდ თუ გრაფიკი ამას ამბობს. გაზომე მეხსიერების ქვედა ზღვარი სამი დღის განმავლობაში; თუ ის პლატოზე გადის, გამოტოვე გრაფიკი და შეამოწმე თავიდან შემდეგი mod-ის ან plugin-ის ცვლილების შემდეგ. კვირაში ერთხელ restart გონივრული ნაგულისხმევია ყველაფრისთვის, რაც mod-იანია, უბრალო vanilla სერვერს კი სტაბილური მოთამაშეების რაოდენობით შესაძლოა საერთოდ არაფერი სჭირდებოდეს.

რომელ საათზე უნდა გაეშვას?

შენი მოთამაშეებისთვის ყველაზე მშვიდ საათზე, 02:00-დან 03:00-მდე თავის არიდებით ზაფხულის დროის გამო. ევროპული საზოგადოებების უმეტესობისთვის ეს 04:00-დან 06:00-მდეა. შეამოწმე შენი პიკის საათები და ნაგულისხმევს ნუ გადაიწერ - სერვერს, რომლის მოთამაშეებიც სხვაგან არიან, მშვიდი საათიც სხვაგან აქვს.

გამოასწორებს restart ლაგს?

მხოლოდ ლაგს, რომელიც პროცესში რაღაცის დაგროვებით არის გამოწვეული. ლაგი, რომელიც ოცი ადამიანის შესვლისას ჩნდება, სიმძლავრის ან კონფიგურაციის პრობლემაა და საათში დაბრუნდება. სწრაფი ტესტი: თუ სერვერი 04:00-ზე სწრაფია და 20:00-ზე ნელი, 05:00-ზე restart არაფერს ცვლის.

კარგავს restart პროგრესს?

სუფთა გაჩერება ჯერ ინახავს, ამიტომ არა. kill ან out-of-memory გაჩერება ყველაფერს ბოლო შენახვის შემდეგ კარგავს, რაც ზოგ თამაშში ნახევარ საათამდეა. ყოველთვის გამოიყენე Stop ან Restart, მის წინ შენახვის ბრძანება ჩასვი და სერვერზე თამაშის საკუთარი შენახვის ინტერვალი მოკლე გქონდეს, რომელიც მეხსიერების ლიმიტთან ახლოსაა.

restart გავაკეთო backup-მდე თუ მის შემდეგ?

ჯერ backup, შემდეგ restart. არქივი დასტაბილურებული, შენახული სამყაროსი უნდა იყოს და არა იმისა, რომელიც გამორთვის შუაშია. სრული თანმიმდევრობა - გააფრთხილე, შეინახე, დააარქივე, გადატვირთე - გრაფიკის იმ თანმიმდევრობაშია, რომელიც დაგეგმილი დავალებები, რომლებიც ღირს-შია.

შემიძლია restart მხოლოდ მაშინ, როცა მეხსიერება მაღალია, და არა ტაიმერით?

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