რატომ გადაიტვირთება შენი გეიმ სერვერი და როგორ გამოასწორო

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

შევიწროება ერთ წუთში#

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

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

Exit კოდები: რამ დაასრულა პროცესი სინამდვილეში#

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

ერთი გაფრთხილება 137-ზე: ეს ის კოდიცაა, რასაც Kill ღილაკიდან ან ხელით kill -9-დან იღებ. თუ არავის არაფერი დაუჭერია, ეს მეხსიერების ზღვარია. თუ shell-ზე წვდომა გაქვს, შეამოწმე ბირთვის საკუთარი ჩანაწერი:

$ dmesg -T | grep -i "killed process"$ cat /sys/fs/cgroup/memory.eventslow 0high 0max 4812oom 19oom_kill 19

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

მეხსიერების ამოწურვა, გავრცელებული მიზეზი#

როცა კონტეინერი მეხსიერების ზღვარს აღწევს, ბირთვი მას აჩერებს და ის სუფთად ბრუნდება. RE:NODE-ზე ეს შეგნებულია - upstream Pterodactyl პირიქითაა: კონტეინერი, რომელიც ჭერზეა, დგას და swap-ს იყენებს და მთელ მანქანას თან ჩაათრევს. მოკლე შეფერხება, რომელიც თავისით გამოსწორდება, სჯობს ნელ დაღმასვლას, რომელიც მეზობლებსაც წაიღებს. ამ არჩევანის ფასი ისაა, რასაც კითხულობ: პროცესს გაფრთხილება არ ეძლევა და დამშვიდობების ჩანაწერს არ წერს, ამიტომ კონსოლი უბრალოდ წყდება.

არსებობს ორი ცალკე მეხსიერების ჭერი და ისინი განსხვავებულ მტკიცებულებას იძლევა:

• Runtime-ის საკუთარი ზღვარი. JVM, რომელიც -Xmx-ს გადააჭარბებს, ისვრის java.lang.OutOfMemoryError: Java heap space-ს, რაც იწერება, ხშირად განმეორებით, და სერვერი ხშირად გატეხილ მდგომარეობაში ცოტა ხანს კვლავ მუშაობს. Node პროცესი წყდება FATAL ERROR: ... JavaScript heap out of memory-ით და exit კოდით 134. ორივე რაღაცას ბეჭდავს.
• კონტეინერის ზღვარი. არაფერი იბეჭდება, რადგან არავის ეძლევა საამისო შანსი. Exit კოდი 137, ვერტიკალური მეხსიერების გრაფიკი და სიჩუმე.

ყველაზე გავრცელებული საკუთარი თავისთვის მიყენებული ვერსია heap-ია, რომელიც მთელ გეგმაზეა დაყენებული. -Xmx4G 4 GB კონტეინერში მოკლული იქნება, რადგან JVM-ს heap-ის გარეთ მეხსიერება სჭირდება thread stack-ებისთვის, metaspace-ისთვის, direct byte buffer-ებისთვის, JIT კოდის cache-ისთვის და collector-ის საკუთარი სტრუქტურებისთვის. დააყენე -Xmx კონტეინერის ზღვრის დაახლოებით 80-85%-ზე, დატოვე სულ მცირე 512 MB თავისუფალი და მთელი გიგაბაიტი ყველაფერზე, რაც მოდირებულია. Minecraft-ის JVM flag-ები და Java ვერსიები სრულ flag ნაკრებს შეიცავს, ხოლო Node.js-ის მეხსიერების ზღვრები იგივე პრობლემაა აპლიკაციებისთვის, რომლებსაც საკუთარი ცალკე ჭერი აქვთ.

შემდეგ გაიარე ეს ამ თანმიმდევრობით, რადგან ყველაზე იაფი გამოსწორებები პირველია:

1. შეამოწმე heap-ის პარამეტრი კონტეინერის ზღვართან. სერვერების უფრო მეტს არასწორი heap კლავს, ვიდრე ნამდვილი დეფიციტი, და მისი გამოსწორება არაფერს ჯდება.
2. შეამცირე ჩატვირთული. შეამცირე view და simulation distance, დაავიწროვე სამყაროს საზღვარი, წინასწარ დაგენერირე და არა ცოცხლად, გაწმინდე დაგროვილი entity-ები. ყოველი chunk, რომელსაც არ ინახავ, მეხსიერებაა, რომელიც არ გჭირდება.
3. იპოვე გაჟონვა, სანამ მას გამოკვებავ. მეხსიერება, რომელიც მუდმივი დატვირთვისას უსასრულოდ იზრდება, plugin-ია ან მოდი, და დიდი გეგმა ვადას უბრალოდ გადაწევს.
4. მერე იყიდე მეხსიერება. ეს ერთადერთი პრობლემაა, რომელსაც მეტი მეხსიერება ნამდვილად წყვეტს.

CPU თუ RAM: რომელი აკავებს შენს სერვერს სინამდვილეში ამას განასხვავებს იმ შემთხვევისგან, როცა მეხსიერების გრაფიკი მცდარი კვალია, ხოლო Linux swap და OOM killer განმარტავს, რას აკეთებს ბირთვი სინამდვილეში.

ავარია საკუთარ ფაილებზე#

თუ არის stack trace, წაიკითხე ის ზევით და არა ბოლოში. ბოლო ხაზი ის ადგილია, სადაც პროცესმა უარი თქვა; მიზეზი ჩვეულებრივ ათიდან ორმოცი ხაზით ზევითაა და ის პირველი ხაზია, რომელიც იმას ასახელებს, რაც შენ დააყენე და არა იმას, რასაც თამაში აწვდის. Java trace-ში გაჰყევი Caused by: ჯაჭვს ბოლომდე - ბოლო არის ძირი.

[21:14:07] [Server thread/ERROR]: Could not pass event PlayerJoinEvent to ShopPlus v3.2java.lang.NoSuchMethodError: org.bukkit.inventory.ItemStack.getItemMeta()    at net.example.shopplus.JoinListener.onJoin(JoinListener.java:64)    ...Caused by: java.lang.ClassNotFoundException: com.example.vaultapi.Economy

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

ოთხი რამ, რომელიც ამ კლასის გადატვირთვას იწვევს:

• ვერსიის შეუსაბამობა განახლების შემდეგ. თამაში განახლდა, მოდები არა. ეს არსებულ ავარიის ციკლებს შორის ყველაზე გავრცელებულია და სწორედ ამიტომ არ უნდა განახლდეს მოდირებული სერვერი patch-ის დღეს ავტომატურად. შეინახე მუშა მოდების საქაღალდის ასლი. რა გავაკეთო, როცა მოდის განახლება აფუჭებს აღდგენაა.
• ორი მოდი, რომლებიც ერთმანეთს ეწინააღმდეგება. ჩვეულებრივ ჩანს exception-ით, რომელიც ორივეს ასახელებს, ან ავარიით, რომელიც მხოლოდ კონკრეტული წყვილის დაყენებისას ხდება.
• დამოკიდებულება აკლია. უფლებების ან ეკონომიკის API, რომელსაც plugin ვარაუდობს, რომ არსებობს.
• დაზიანებული სამყაროს region ან save. ნიშანი ისაა, რომ ავარია გამეორებადია ერთსა და იმავე მომენტში: როცა კონკრეტული მოთამაშე შედის, ან როცა კონკრეტული chunk იტვირთება, ან იმ save-ის დროს, რომელიც კონკრეტულ მოვლენას მოჰყვება. აღადგინე backup-იდან და არ გამოარკვიო, ხოლო backup-ები, რომლებიც მართლა აღდგება განმარტავს, რატომ შეიძლება შენი backup ასეთი არ იყოს.

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

გადატვირთვები, რომლებიც შენ ითხოვე და დაგავიწყდა#

„ჩემი სერვერი განუწყვეტლივ გადაიტვირთება“ ticket-ების გასაოცარი ნაწილი განრიგია. შეამოწმე ეს ყველაფერი, სანამ დაასკვნი, რომ რამე არასწორადაა:

• პანელის საკუთარი schedules. RE:NODE-ზე ისინი Schedules ჩანართზეა: cron გამოსახულება და ამოცანების დალაგებული სია დაყოვნებებით, რომელიც შეიძლება power action-ს შეიცავდეს. ექვსი თვის წინ დამატებული გადატვირთვა ისევ მუშაობს. Cron გამოსახულებები ახსნილი გამოსახულების კითხვას განიხილავს, ხოლო დაგეგმილი ამოცანები, რომლებიც ღირს იმას, რა უნდა იყოს იქ.
• გადატვირთვის plugin ან მოდი თამაშის შიგნით. ბევრი საზოგადოება ერთს აყენებს და ივიწყებს. მას საკუთარი კონფიგურაციის ფაილი და საკუთარი განრიგი ექნება, პანელისგან დამოუკიდებელი.
• Watchdog. Paper-ის spigot.yml-ში არის settings.timeout-time (ნაგულისხმევად 60 წამი) და settings.restart-on-crash, ხოლო tick, რომელიც timeout-ს აჭარბებს, აიძულებს watchdog-ს, სერვერი მოკლას და გადატვირთოს ლოგში The server has stopped responding!-ით. ეს ავარია არ არის, ეს გაჭედვაა, რომელსაც ავარიად თვლიან, და გამოსწორება ის არის, რამაც tick ერთ წუთს გაახანგრძლივა.
• განახლება გაშვებისას. კონტეინერი, რომელიც ყოველ ჩატვირთვაზე უახლეს build-ს იღებს, სუფთად ჩაეშვება ციკლში, თუ უახლესი build გატეხილია. დიაგნოსტიკისას ვერსია დააფიქსირე.
• პროცესის მენეჯერი შენს მანქანაზე. systemd unit Restart=always-ით ან Docker-ის --restart unless-stopped პოლიტიკა მუდამ ხელახლა გაუშვებს პროცესს, რომელსაც გაშვება არ შეუძლია, მიზეზი კი ყოველ ჯერზე გადაგირბენს.

RE:NODE-ზე არის თითო სერვერის აქტივობის ჟურნალი, რომელიც power action-ებს და მათ გამომწვევს იწერს. ეს ყველაზე სწრაფი გზაა კითხვაზე პასუხისთვის: „რამე გადატვირთა თუ თავად მოკვდა“. გადატვირთვა, რომელიც შენ ითხოვე, და ის, რასაც სერვერი თავისით აკეთებს, კონსოლში იდენტურია და ჟურნალში სრულიად განსხვავებული.

თამაში თავს ანებებს: მონაცემები, ვერსიები და პორტები#

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

• ვადაგასული ან გაუქმებული credential. CS2-სა და Unturned-ს Steam game-server login token სჭირდება, FiveM-ს Cfx.re გასაღები, Don't Starve Together-ს Klei token, BeamMP-ს auth გასაღები. Steam შლის login token-ს, რომელიც დიდი ხნით არ გამოუყენებიათ, და დაბანილ სერვერზე მიბმული token უქმდება, ამიტომ სერვერს, რომელიც წელიწადი მუშაობდა, შეიძლება ერთ ღამეში საჯაროდ გასვლის უნარი დაეკარგოს იმის გარეშე, რომ შენს მხარეს რამე შეცვლილა. Steam game server token-ები განიხილავს მათ შექმნასა და ჩანაცვლებას.
• ვერსიის შეუსაბამობა კლიენტთან. სერვერი განახლდა და მოდები არა, ან კლიენტი განახლდა და სერვერი არა. სერვერი ჩვეულებრივ კარგად მუშაობს და შესვლა არავის შეუძლია, რაც სხვა საჩივარია, რომელიც იმავე ticket-ად მოდის.
• პორტი უკვე გამოიყენება. java.net.BindException: Address already in use ან Minecraft-ის FAILED TO BIND TO PORT!. პანელზე ეს თითქმის ყოველთვის ნიშნავს, რომ წინა პროცესი შემდეგ გაშვებამდე სრულად არ გასულა, რასაც სრული გაჩერება და პაუზა ასწორებს, ან ორ სერვერს შემთხვევით ერთი allocation მიეცა.
• EULA. ახალი Minecraft სერვერი წერს eula.txt-ს და გადის კოდით 0, სანამ eula=true არ დაყენდება. ზედიზედ ორი სუფთა გასვლა შეცდომის გარეშე ეს არის, ყოველთვის.
• სავსე დისკი. სერვერი, რომელსაც წერა არ შეუძლია, ვერ ინახავს და ბევრი თამაში გაგრძელების ნაცვლად ვარდება. დისკი ყველაფერზე ადრე შეამოწმე; ერთ ბრძანებას ჭირდება და კონსოლში უხილავია მომენტამდე, სანამ ფატალური გახდება.

$ df -h /home/container$ du -sh /home/container/* | sort -h | tail -10

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

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

• გადატვირთვა, რომელიც შენ ითხოვე, არ ითვლება. ყველაფერი ჩაწერილი power action-ის შემწყნარებელ ფანჯარაში ღილაკის დაჭერაა და არა მარცხი.
• მიუწვდომელი node ორმოცდაათი გაჩერებული სერვერი არ არის. ჩავარდნილი შემოწმება არაფერს წერს და watcher-ის მეხსიერებას ხელუხლებლად ტოვებს, ამიტომ ქსელის მცირე შეფერხებას მანქანის ნახევრის შეჩერება არ შეუძლია.
• ერთ საათში სამი გადატვირთვა სერვერის გვერდზე გაფრთხილებას აყენებს და ავტომატურად ხსნის support ticket-ს. ექვსი მას აჩერებს და ამ დროისთვის ორჯერ უკვე გაგაფრთხილეს.

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

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

ციკლის გაწყვეტა: პროცედურა#

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

1. სერვერი სწორად გააჩერე. არა Restart. ციკლი, რომელიც შეაჩერე, პრობლემაა, რომლის წაკითხვაც შეგიძლია.
2. აიღე backup რამის შეხებამდე. დიაგნოსტიკა ფაილების გადატანას გულისხმობს, ფაილების გადატანა კი დაკარგვას.
3. კონსოლი გადმოიწერე. ასი ხაზი პირველ გადატვირთვამდე და არა ბოლოს. ბოლო გადატვირთვა პრობლემის ყველაზე ნაკლებად ინფორმატიული ეგზემპლარია. კონსოლის კითხვა განმარტავს, რა შეინახო.
4. შეამოწმე დისკი და მეხსიერება. ერთი df -h, ერთი ნახვა მეხსიერების გრაფიკზე სიკვდილამდე ორ წუთში. ეს ორი შემოწმება ჩუმ მიზეზებს გამორიცხავს და ოცდაათ წამს ჯდება.
5. გამორთე ყველაფერი, რაც მას გადატვირთავს. პანელის განრიგი, გადატვირთვის plugin, restart-on-crash. ციკლს ვერ წაიკითხავ, თუ ის თავს განუწყვეტლივ რესტარტავს.
6. გაუშვი მასში არაფრის დამატების გარეშე. მოდების საქაღალდე განზე, კონფიგურაცია ნაგულისხმევზე, plugin-ები ამოღებული. თუ ის გაეშვა, პრობლემა იმაშია, რაც გადაიტანე. თუ არა, პრობლემა სამყაროა, runtime-ის ვერსია ან მანქანა.
7. გამოსცადე ახალი სამყაროთი. ეს ერთი გაშვებით განასხვავებს დაზიანებულ save-ს გატეხილი ინსტალაციისგან და ეს ის შემოწმებაა, რომელსაც ხალხი საათობით გამოტოვებს.
8. ბრუნდი უკან გაყოფით. ნახევარ-ნახევარი.
9. გახსენი ticket კონსოლის დართვით. RE:NODE-ზე პანელიდან ticket ყველა თანამშრომელს აღწევს და კერძო დანართებს იღებს, რაც სწორი ადგილია ლოგისთვის, რომელშიც token არის.

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

FAQ#

ჩემი სერვერი გადაიტვირთება და ლოგში არაფერია. რა არის ეს?

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

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

Exit კოდით და გამორთვის ხაზებით. მოთხოვნილი გაჩერება იძლევა 143-ს ან 0-ს და შენახვისა და გამორთვის შეტყობინებების მოწესრიგებულ თანმიმდევრობას. ავარია იძლევა trace-ს, abort-ს ან საერთოდ არაფერს. პანელის თითო სერვერის აქტივობის ჟურნალი წყვეტს, ვინ რა დააჭირა.

შეაჩერებს გადატვირთვებს დიდი გეგმა?

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

კარგი იდეაა ავტომატური გადატვირთვა ყოველ ღამე?

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

რატომ შეჩერდა ჩემი სერვერი გადატვირთვების გამო?

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

სერვერი ყოველდღე ზუსტად ერთსა და იმავე დროს გადაიტვირთება. სად ვიყურო?

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