როდის გადახვიდე უფრო დიდ გეგმაზე და როდის არა

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

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

ოთხი ნიშანი, რომელიც მართლა ზომის პრობლემაა#

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

• მეხსიერების ფსკერი მაღალია და არა მხოლოდ პიკი. ფსკერი არის ყველაზე დაბალი წერტილი, რომელსაც მეხსიერების ხაზი სპაიკებს შორის ეხება, გაზომილი დღის განმავლობაში და არა საათის. როცა ფსკერი ლიმიტის დაახლოებით 80 პროცენტს ზემოთაა, აღარ რჩება სივრცე garbage collection-ის ციკლისთვის, backup-ისთვის ან თორმეტი ადამიანის ერთდროული შემოსვლისთვის. პიკი, რომელიც ჭერს ეხება და პირდაპირ უკან ბრუნდება, ნორმალურია.
• kernel-მა რაღაც დახოცა. out-of-memory გაჩერება, ალოკაციის შეცდომა ლოგში, ან პროცესი, რომელიც საკუთარი შეცდომის გარეშე გაქრა. ეს არ არის აზრი იმაზე, საკმარისად დიდია თუ არა გეგმა; ეს ოპერაციული სისტემა გეუბნება, რომ არ არის.
• დისკი სავსეა ან თითქმის სავსეა. არანაირი ოპტიმიზაცია ადგილს არ ქმნის. შეგიძლია რაღაცების წაშლა, რაც ხშირად სწორი პასუხია, მაგრამ როცა რეალური სამუშაო მონაცემები გეგმას აჭარბებს, ეს ზომის პრობლემაა და სხვა არაფერი.
• შეგნებულად ამატებ დატვირთვას. მეტი მოთამაშე, უფრო დიდი სამყარო, modpack, მეორე სერვისი, launch. დატვირთვის მოსვლამდე გადასვლა ერთადერთი შემთხვევაა, როცა სიმძლავრის წინასწარ ყიდვა გონივრულია, რადგან იცი, რომ რიცხვი იზრდება.

ყველაფერს დანარჩენს ათი წუთი დიაგნოსტიკა ჯობს.

წაიკითხე ფსკერი და არა პიკი#

ჰოსტინგში ყველაზე ხშირი არასწორი წაკითხვა მეხსიერების გრაფიკია, რომელიც თავისი დიაპაზონის ზემოთაა. JVM-ზე გაშვებული ყველაფრისთვის ეს გაფრთხილება არ არის, ეს დიზაინია: runtime იღებს heap-ს, რომელიც მისცეს, და იყენებს მას, garbage-ს კი აგროვებს ლიმიტთან მიახლოებისას და არა განუწყვეტლივ. Minecraft სერვერი, რომელიც ბრტყლად დგას heap-ის ოთხმოცდაათ პროცენტზე, შეიძლება სრულიად ჯანმრთელი იყოს.

რასაც დროში ფორმა გეუბნება:

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

ერთი ხაფანგი კონტეინერებისთვის: free -m კონტეინერში აჩვენებს host მანქანის მეხსიერებას და არა შენს ლიმიტს, ამიტომ ის მხიარულად გეტყვის, რომ 60 GB თავისუფალია, სანამ შენი პროცესი გაჩერების პირასაა. ამის ნაცვლად წაიკითხე cgroup:

$ cat /sys/fs/cgroup/memory.current   # bytes in use$ cat /sys/fs/cgroup/memory.max       # your limit$ cat /sys/fs/cgroup/memory.events    # includes an oom_kill counter

cgroup v1-ის გამოყენებით ძველ სისტემებზე ეკვივალენტებია memory.usage_in_bytes, memory.limit_in_bytes და memory.failcnt. პანელზე მეხსიერების გრაფიკი უკვე აჩვენებს გამოყენებას ლიმიტის მიმართ, რაც იგივე ინფორმაციაა არითმეტიკის გარეშე.

იმის დამტკიცება, რომ მეხსიერება იყო#

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

Exit code 137. კონტეინერში ეს არის 128 პლუს სიგნალი 9, ანუ პროცესი დახოცეს და არ გამოსულა. თითქმის ყოველთვის მეხსიერების ლიმიტია. Exit code 143 არის 128 პლუს სიგნალი 15, სუფთა SIGTERM, რაც ნორმალური გაჩერება ან restart-ია და საერთოდ არ არის შეცდომა.

kernel-ის შეტყობინება. მანქანაზე, რომელსაც აკონტროლებ, dmesg -T | grep -i -E "oom|killed process" გამოიტანს დაახლოებით ასეთს:

Memory cgroup out of memory: Killed process 8123 (java)total-vm:9812344kB, anon-rss:4194304kB, file-rss:0kB

ეს ხაზი ასახელებს პროცესს და მეხსიერებას, რომელსაც ის სიკვდილისას ინახავდა. Swap და OOM killer განმარტავს, როგორ არჩევს kernel მსხვერპლს.

runtime-ის შეცდომა და არა დახოცვა. ესენი ნიშნავს, რომ პროცესი საკუთარ ჭერს მიადგა კონტეინერისაზე ადრე:

java.lang.OutOfMemoryError: Java heap spaceFATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memoryMemoryError

ეს განსხვავება მნიშვნელოვანია და ერთადერთი ყველაზე ხშირი მიზეზია, რის გამოც ხალხი ყიდულობს გეგმას, რომელიც არაფერს ასწორებს. Java სერვერი -Xmx4G-ით heap-ის შეცდომას გამოიტანს 12 GB გეგმაზეც, რადგან ლიმიტი ფლაგია და არა გეგმა. Node პროცესს საკუთარი old-space ჭერი აქვს, კონტეინერისგან დამოუკიდებლად დაყენებული, რაც რატომ კვდება შენი Node აპი 2 GB-ზე 4 GB გეგმაზე-ის თემაა. ჯერ ფლაგი შეამოწმე და მერე tier.

საპირისპირო ხაფანგი JVM-ზე ისევე ხშირია. heap პროცესის მთლიანობა არ არის: metaspace, code cache, thread stack-ები და direct buffer-ები -Xmx-ის გარეთაა და რამდენიმე ასეულ მეგაბაიტს ამატებს. -Xmx-ის კონტეინერის ლიმიტთან გატოლება რაღაც მომენტში out-of-memory გაჩერებას გარანტირებულს ხდის, რადგან პროცესს heap-ზე მეტი სჭირდება. Minecraft სერვერზე გეგმის 20-25 პროცენტი heap-ის გარეთ დატოვე.

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

იმის დამტკიცება, რომ CPU იყო: throttling არ არის დეფიციტი#

სერვერი, რომელიც ჩერდება მშვიდი მეხსიერებით, CPU-ს პრობლემაა და მეხსიერების ყიდვა საერთოდ არაფერს შეცვლის. განსხვავება ადვილი დასადგენია და თითქმის არავინ ადგენს.

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

$ cat /sys/fs/cgroup/cpu.statnr_periods 184320nr_throttled 41277throttled_usec 892134000

nr_throttled-ის ზრდა nr_periods-ის მიმართ არის მტკიცებულება. cgroup v1-ზე ფაილი /sys/fs/cgroup/cpu/cpu.stat-შია და ველი არის throttled_time ნანოწამებში. პანელზე CPU გრაფიკი, რომელიც ბრტყლად დგას შენს წილზე, იგივე სიგნალია ფაილის გარეშე.

გეიმ სერვერისთვის თამაშის საკუთარი გაზომვა ჩვეულებრივ უფრო ნათელია. Paper-ზე ან Spigot-ზე /tps აჩვენებს ticks per second-ს 20-იანი მიზნის მიმართ, ხოლო MSPT აჩვენებს, რამდენ ხანს გაგრძელდა tick 50 ms ბიუჯეტის წინააღმდეგ. სერვერი 18 TPS-ით, 55 ms tick-ებით და 40 პროცენტიანი მეხსიერებით ცალსახაა: გეგმას მეხსიერება ბევრი აქვს და საათი არასაკმარისი. Paper-ის უფრო ახალმა build-ებმა timings spark-ით ჩაანაცვლა, ამიტომ შეამოწმე, რომელი გაქვს, და თუ არის, /spark profiler-ით გააკეთე პროფილირება. რატომ ეცემა TPS და spark ანგარიშის წაკითხვა იქიდან აგრძელებს.

უსიამოვნო ნაწილი: უფრო დიდი tier ჩვეულებრივ გიყიდის მეტ vCPU წილს და არა უფრო სწრაფ ბირთვს. უმეტეს გეიმ სერვერს single-thread წარმადობა ზღუდავს, ამიტომ 1.5-დან 2.5 vCPU-მდე გადასვლა ეხმარება სერვერს, რომელსაც throttle ჰქონდა, და ძალიან ცოტას აძლევს სერვერს, რომლის მთავარ tick thread-ს უბრალოდ ზედმეტი სამუშაო აქვს. გაიგე, რომელი გაქვს, სანამ გადაიხდი. CPU თუ RAM ოცდაათი წამის დიაგნოსტიკაა და ბევრ ფულს გიზოგავს.

სერვერი, რომელიც CPU-ს 100 პროცენტზე დგას, ნელია და არა გატეხილი, და ამის გამო არასოდეს ჩერდება.

დისკი ის არის, რომელსაც ვერ დაარეგულირებ#

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

$ df -h /$ du -sh /* 2>/dev/null | sort -h | tail -20$ du -sh ./* | sort -h | tail -20

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

• ლოგები, რომლებიც არასოდეს ბრუნავს. ხმაურიან სერვერს, რომელიც debug გამოსავალს წერს, კვირაში გიგაბაიტები შეუძლია გამოიმუშაოს. systemd მანქანებზე journalctl --disk-usage და შემდეგ journalctl --vacuum-time=7d.
• Backup-ები იმის გვერდით, რასაც იცავს. თამაშის ჩაშენებული backup საქაღალდე backup არ არის; ის იმავე დისკზე მეორე ასლია და სამუდამოდ იზრდება. ნამდვილი ასლები მანქანის გარეთ შეინახე - backup-ები, რომლებიც მართლა აღდგება იმ ნახევარზეა, რომელსაც ხალხი გამოტოვებს.
• ძველი სამყაროები, ძველი რუკები, ძველი modpack-ები. არავინ შლის ბოლო სეზონის სამყაროს.
• Build არტეფაქტები. სამი deploy-ის წინანდელი node_modules, პაკეტების მენეჯერის cache, Cargo-ს target დირექტორია, Docker image, რომელსაც არავინ ასუფთავებს.
• ატვირთვები. მომხმარებლის მიერ გაგზავნილი სურათები ვებ აპლიკაციაზე, სრული გარჩევადობით, სამუდამოდ.

ჯერ გაწმინდე. სავსე დისკების უმეტესობის 70 პროცენტი ნაგავია და ნაგვის წაშლა უფასოა. თუ რეალური სამუშაო მონაცემები მართლა აჭარბებს გეგმას, ეს ზომის პრობლემაა და უნდა გადახვიდე. ისიც ღირს ცოდნად, რომ tier საცავის ტიპს არ ცვლის: NVMe ყველა გეგმაზეა, ამიტომ გაზრდა ადგილს გიყიდის და არა სიჩქარეს. რას ცვლის NVMe სინამდვილეში ნათლად ამბობს, რომელ ოპერაციებზე ახდენს ეს გავლენას.

სამი სიმპტომი, რომელიც ზომის პრობლემას ჰგავს და არ არის#

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

დაბალი tick rate მშვიდი მეხსიერებით. ზემოთ განვიხილეთ და ღირს გამეორება, რადგან გეიმ ჰოსტინგში ეს ყველაზე ძვირი არასწორი დიაგნოზია. უფრო დიდი მეხსიერების tier არაფერს აძლევს CPU-ზე დამოკიდებულ tick ციკლს. თუ გრაფიკი მეხსიერებას 50 პროცენტზე აჩვენებს და სერვერი 14 TPS-ზეა, მეხსიერება არანაირი გაგებით არ არის პრობლემა.

ერთ მოთამაშეს პრობლემები აქვს და დანარჩენებს არა. ეს მისი კავშირი ან მისკენ მიმავალი მარშრუტია და არცერთს ვერცერთი გეგმა ვერ შეცვლის. სთხოვე, mtr გაუშვას სერვერის მისამართზე და მოძებნოს დანაკარგი, რომელიც რომელიმე hop-ზე იწყება და ბოლომდე გრძელდება. Latency, jitter და packet loss არის პოსტი, რომელიც უნდა გაუგზავნო. დაკავშირებულია: ყველაფერი ერთ ლოკაციაზეა, ამიტომ გაზრდა სერვერს არავის მიუახლოებს.

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

სცადე ეს, სანამ გადაიხდი#

ძალისხმევის მიხედვით ეფექტის წინააღმდეგ. გეიმ სერვერისთვის:

1. შეამცირე view და simulation distance. Minecraft-ზე server.properties-ში view-distance და simulation-distance ორივე ნაგულისხმევად 10-ია. simulation distance-ის 6-მდე დაწევა tick-ზე სამუშაოს მკვეთრად ამცირებს და მოთამაშეებისთვის ძლივს შესამჩნევია. ეს ყველაზე ღირებული ერთადერთი ცვლილებაა.
2. დათვალე plugin-ები და mod-ები. ოცი plugin ოცი რამაა, რაც ყოველ tick-ზე მუშაობს. მოაშორე ისინი, რასაც მარტიდან არავინ იყენებს, და დანარჩენი პროფილირებით შეამოწმე და არა გამოცნობით. Paper-ის ოპტიმიზაცია მნიშვნელოვან კონფიგურაციის ფაილებს ფარავს.
3. შეამოწმე entity-ების რაოდენობა. მობ-ფერმები, მიწაზე დარჩენილი item-ების გროვები და ჩარჩოებში ჩასმული item-ები სერვერის დანელების გავრცელებული მიზეზია, როცა არავის არაფერი შეუცვლია.
4. მეხსიერების ფლაგები გაასწორე და არა გეგმა. ძალიან დაბალი -Xmx heap-ის შეცდომებს იძლევა ნებისმიერ tier-ზე; ძალიან მაღალი კონტეინერის გაჩერებას გარანტირებულს ხდის. რამდენი RAM სჭირდება Minecraft სერვერს გონივრულ რიცხვებს იძლევა მოთამაშეთა რაოდენობისა და modpack-ის მიხედვით.
5. გადატვირთე განრიგით. მეხსიერება, რომელიც დღეების განმავლობაში იზრდება ხანგრძლივად მომუშავე სერვერზე, ხშირად ნორმალური დაგროვებაა და არა leak, და კვირაში ერთი restart დილის 5 საათზე მას უფასოდ ბრტყლად ინახავს.

აპლიკაციისთვის:

1. გააქეშე პასუხები, რომლებიც მომხმარებელზე არ არის დამოკიდებული. ჩვეულებრივ ყველაზე დიდი ერთადერთი მოგებაა და უფასოა.
2. იპოვე ნელი query. ერთი დაკარგული index ხშირად ბაზის CPU-ს უმეტესობას შეადგენს.
3. შეზღუდე ყველა კოლექცია, რომელსაც შენი კოდი ფლობს. cache გამოდევნის გარეშე არის leak განრიგით.
4. heap ან worker-ების რაოდენობა შეგნებულად დააყენე და ლეპტოპისთვის გათვლილ ნაგულისხმევს არ დაეყრდნო.

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

შემდეგი tier-ის არჩევა და რას არ შეცვლის ის#

tier აირჩიე ფსკერით და არა პიკით. აიღე უქმი მეხსიერების მაჩვენებელი, დაამატე შენ მიერ დაკვირვებული პიკსა და ფსკერს შორის სხვაობა, დაამატე 25 პროცენტი და იყიდე ამ რიცხვზე ზემოთ მდგარი tier. გაორმაგება იმიტომ, რომ რიცხვები უკეთ გამოიყურება, სწორედ ის გზაა, რითიც ხალხი 8 GB-ს იხდის იმისთვის, რასაც 3 სჭირდებოდა.

გარკვევით იცოდე, რას აკეთებს და რას არა tier-ის შეცვლა:

• ის ცვლის მეხსიერების, დისკისა და CPU-წილის ლიმიტებს სერვერზე, რომელიც უკვე გაქვს. გეგმის შეცვლა სერვერს არ აშენებს თავიდან, ამიტომ სამყარო, ფაილები, ბაზის slot და დომენი ზუსტად იქ რჩება, სადაც იყო.
• ის არ ცვლის საცავის კლასს, რადგან NVMe ყველა გეგმაზეა; ლოკაციას, რადგან ერთია; იმ ბირთვის single-thread წარმადობას, რომელზეც შენი tick ციკლი მუშაობს; ქსელურ გზას მოთამაშესა და მანქანას შორის; და კონფიგურაციის შეცდომას.
• ის leak-ს არ ასწორებს. პროცესი, რომლის მეხსიერება უსაზღვროდ იზრდება, უფრო დიდ ჭერს უფრო ნელა აღწევს. პარასკევის საღამოს ეს რაღაცას ღირს და გრძელვადიან პერსპექტივაში არაფერს.

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

დააყენე რამე, რაც გეტყვის შემდეგი ჭერის მოსვლამდე და არა მის შემდეგ. მეხსიერების alert ფსკერის 85 პროცენტზე და დისკის alert 80 პროცენტზე ავარიის ნაცვლად დღეების გაფრთხილებას მოგცემს. მონიტორინგი, რომელიც რაღაცას გეუბნება იმაზეა, როგორ გააკეთო ეს მეორე სამსახურის აგების გარეშე.

FAQ#

როგორ გავიგო, მჭირდება მეტი RAM თუ მეტი CPU?

ცუდ მომენტში შეხედე ორივე გრაფიკს. მეხსიერება ჭერზეა და პროცესს ხოცავენ - ეს მეხსიერებაა. CPU შენს წილზე მიჭედებულია და მეხსიერება კომფორტულია - ეს CPU-ა. თუ თამაში დაბალ TPS-ს ან მაღალ MSPT-ს აჩვენებს, სანამ მეხსიერება მშვიდია, ეს CPU-ა და არცერთი მეხსიერების tier არ დაგეხმარება.

ჩემი მეხსიერების გრაფიკი ყოველთვის ზედაა. ეს ცუდია?

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

გადატვირთავს თუ არა გეგმის გაზრდა ჩემს სერვერს?

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

შემიძლია თუ არა უკან დაბრუნება, თუ გაზრდამ არ უშველა?

tier-ები ცალმხრივი არ არის, მაგრამ ჯერ დისკი შეამოწმე, რადგან ეს ერთადერთი განზომილებაა, რომელიც მოხდენილად არ მცირდება: უფრო პატარა tier საკმარისად დიდი უნდა იყოს იმისთვის, რასაც სინამდვილეში ინახავ. გადასვლამდე გაასუფთავე ძველი სამყაროები და მოძველებული backup-ები და თუ დარწმუნებული არ ხარ, ticket-ით იკითხე.

რატომ გადაირთო ჩემი სერვერი თავისით ნელი გახდომის ნაცვლად?

იმიტომ, რომ მეხსიერების ლიმიტზე კონტეინერი ჩერდება და სუფთად გადაირთვება და swap-ში არ რჩება. ის crash-ს ჰგავს და არ არის. შეამოწმე exit code 137 და out-of-memory ხაზი, და თუ იპოვე, გეგმა ან heap-ის ფლაგი მართლა ძალიან პატარაა.

უნდა გადავიდე თუ არა მაღალზე დიდ ღონისძიებამდე ან launch-მდე?

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