DDoS czy po prostu MC 1.14.4 jest tak niestabilne?

r3cord | 2019-11-09 23:00:18 UTC | #1

Witam!
Przychodzę do was z nurtującym mnie pytaniem. Prowadzę serwer minecraft na maszynie KVM 8GB i potrafi mi wywalić serwer przy 15-25 osobach online (17 pluginów). Trochę rozumiem, że 1.14.4 ma słabą optymalizację, ale no bez przesady. Macie jakiś sposób na naprawę tego?
To jedna sprawa, ale bardziej mnie interesuje to co się stało dzisiaj, 24 osoby na serwerze, nagle tps drastycznie spada do 10, RAM skacze jak szalony i wywala serwer. Nie dziwiło by mnie to gdyby nie to, że serwer uciągnął atak botów, łącznie około 1500. Więc postanowiłem sobie wejść na proxmoxa i sprawdziłem zużycie RAMu, bo podczas tego obciążenia nie mogłem zalogować się do PuTTy. Warto zaznaczyć, że na serwer mam przeznaczone 7168MB, czyli cały 1GB jest wolny na działanie maszyny i utrzymanie prostego ItemShopu, a wchodząc w proxmoxa ujrzałem taki oto widok:

Pełne zużycie RAMu maszyny, czy to mógł być jakiś DDoS? Bo jednak na MC mam przeznaczone 7GB, czyli nie powinno być całkowitego zuzycia RAMu maszyny. Jakieś sugestie?

Nieznajomy11 | 2019-11-09 23:07:00 UTC | #3

Mimo ustawienia parametru Xmx na 7G może dojść do sytuacji, że JVM ukradnie więcej niż ten limit. Parametr ten odpowiada tylko za limit heap, czyli takiej podstawowej przestrzeni, gdzie java alokuje swoje objekty, są jeszcze inne flagi, takie jak:

-XX:PermSize
-XX:MaxPermSize
-Xss

Nazwałbym je jednak bardziej zaawansowanymi i nie zalecam zbytnio zmiany ich wartości.

Timo | 2019-11-09 23:18:39 UTC | #4

[quote=”r3cord, post:1, topic:12582”]
nagle tps drastycznie spada do 10
[/quote]
Zrób timingsy. Pomogą zdiagnozować problem.
/timings on i po jakimś czasie /timings paste.

A co do RAM-u to tak jak przedmówcy, sprawdzanie w Proxmox nie odzwierciedla rzeczywistej sytuacji z wolną pamięcią. Java allokuje zazwyczaj wszystko co może, a system może używać wolnej pamięci jako cache.

r3cord | 2019-11-10 00:50:05 UTC | #5

https://timings.aikar.co/?id=002374dc47ad4ac08465874dad365106
Proszę o to timingsy, trochę czerwonego jest. Robione przy 14 osobach online, serwer pokazuje stałe 20 TPS.

Nieznajomy11 | 2019-11-10 03:54:47 UTC | #6

To tylko pojedyncze ticki, które trwały dłużej niż powinny. Serwer działa stabilnie, nie ma tps loss. Aby określić, co zjada pamięć, musiałbyś zrobić heap dump i użyc np. eclipse memory analyzer. Druga opcja to jakieś VisualVM, pewnie też da radę.

r3cord | 2019-11-10 11:40:23 UTC | #7

Okej, postaram się tym VisualemVM ogarnąć. Ogólnie to znalazłem takie flagi optymalizacyjne na necie:
java -Xms6G -Xmx6G -XX:+UseG1GC -XX:+UnlockExperimentalVMOptions -XX:MaxGCPauseMillis=100 -XX:+DisableExplicitGC -XX:TargetSurvivorRatio=90 -XX:G1NewSizePercent=50 -XX:G1MaxNewSizePercent=80 -XX:G1MixedGCLiveThresholdPercent=35 -XX:+AlwaysPreTouch -XX:+ParallelRefProcEnabled -Dusing.aikars.flags=mcflags.emc.gs -jar paperclip.jar
Pomogłyby choć trochę w stabilności?

SystemZ | 2019-11-10 15:37:49 UTC | #8

MC 1.14 biorąc pod uwagę tickety i rozmowy na discordzie to porażka wydajnościowa.
Jak jest w rzeczywistości to pewnie zależy od przypadku.

Dla mnie osobiście JVM to trochę czarna magia, nie stosowałbym flag których nie rozumiem, zwłaszcza że jest ich tak dużo.
Sugerowałbym wprowadzać je po jednej, notować wyniki w miarodajny sposób i wtedy decydować czy używać w produkcji.

Nieznajomy11 | 2019-11-10 17:15:58 UTC | #9

To flagi aikara, twórcy PaperSpigot. Mogę je polecić, są w porządku do używania, a już na pewno lepsze niż odpalanie serwera java -jar spigot.jar. Skupiają się one głównie na jednej rzeczy, więc wprowadzanie “po jednej”, dużo sensu raczej nie będzie mieć. Tutaj źródło (zresztą dostępne też w parametrze using.aikars.flags): https://aikar.co/2018/07/02/tuning-the-jvm-g1gc-garbage-collector-flags-for-minecraft/

r3cord | 2019-11-10 19:31:25 UTC | #10

Powiem wam, że to jest masakra, 40 osób i wywala serwer. Teraz miałem taki spam w logach:
https://pastebin.com/Zp7PhUy8
Jeszcze nie było dnia, żeby nie wywaliło serwera, ale chyba będę musiał się z tym pogodzić i czekać na 1.15 :c Spróbuję jeszcze odpalić serwer z tymi flagami, tylko właśnie też coś mi to nie działa. Ale no muszę próbować. Ma ktoś jeszcze jakiś sposób na optymalizację oprócz tych flag?

r3cord | 2019-11-10 19:41:28 UTC | #11

Nie rozumiem tez innej rzeczy, tps na poziomie 14-15, a żadnych lagów nie ma, gracze nic nie narzekają :thinking:
https://timings.aikar.co/?id=526111cbf3764f648175bc85c3cf50e0

SystemZ | 2019-11-10 20:22:13 UTC | #12

[quote=”r3cord, post:10, topic:12582”]
wywaliło serwera
[/quote]

Po logach rozumiem że chodzi Ci o crash serwera MC (wyłączenie się procesu).
Każdy może mieć trochę co innego na myśli i inne osoby ze zbliżonym problemem mogą wyciągnąć złe wnioski z tego wątku.

Piszę o tym ze względu na to że w ticketach klienci tak samo mówią na:
- restart VM
- odcięcie sieci VM
- crash procesu aplikacji
- niską wydajność aplikacji
- udany atak DoS
- udany atak DDoS
- brak wolnej pamięci RAM
- za mało CPU

a rozwiązania do tych problemów są zazwyczaj zupełnie inne

aggankx | 2019-11-10 20:50:10 UTC | #13

To o czym mówisz jest dość “normalne” na 1.14

Moje timingsy wyglądają podobnie [chociaż gorzej ale to pewnie dlatego że Ty masz 1k entity a ja 7k entity ;)]

Od siebie tylko dodam, że mi na najnowszym paperze też wywalało serwer
Ten “spam” o którym mówisz na konsoli był omawiany na dc paper’a i mi odpisali że “widocznie gracze za szybko chunki ładują”. Well…
Paper-213 to ostatni paper na którym nie mam problemów i jest moim zdaniem najwydajniejszy i z niego korzystam bo nie wywala mi serwera XD [Ze starej wersji paper’a korzystam na własną odpowiedzialność]

r3cord | 2019-11-10 21:40:17 UTC | #14

Raz całkowicie zrobił mi się reboot vps, ale to tylko raz, a tak to chodzi mi o crash serwera MC. Przepraszam za moją nieścisłość.

r3cord | 2019-11-10 21:43:39 UTC | #15

Okej, spróbuję jeszcze flagami naprawić, ale jak nic nie pomoże to też wezmę starszą wersję Papera i zobaczymy co to będzie. Trzeba kombinować, dzięki!

system | 2019-12-12 21:43:40 UTC | #16

Ten temat został automatycznie zamknięty 32 dni po ostatnim wpisie. Tworzenie nowych odpowiedzi nie jest już możliwe.