Helios1993

Masz pliki hs_err_pid w głównym folderze serwera? Jeśli tak, wyślij jeden z nich. Profiler z serwera i sam skrypt też się przydadzą.

"Inni to robią, więc ja też muszę". Bardzo rzadko spotykam się z hostingami korzystającymi z tej ochrony. Pomijając twój hosting, ostatni raz widziałem taki z 2 lata temu i szybko od niej uciekł. Myślenie typu "zapłaciłem, więc musi być dobre", w którym ignorujesz wszystkie minusy aby usprawiedliwić wydane pieniądze. Niestety bardzo często spotykane. Więc robiłeś testy wydajności bez wykonywania profilerów? Trochę ciężko mi w to uwierzyć. Może chociaż pliki ci po tym zostały? Pusty profiler nie będzie tak dokładnym dowodem, ale zawsze coś.

Same słowa to trochę mało. Jeśli chcesz je potwierdzić, wrzuć tu profilera z tych testów. Wrócę jeszcze do ochrony przed ddosami - korzystanie z usługi należącej do wielokrotnie skazywanych cyberprzestępców raczej nie świadczy dobrze o twoich usługach. Sama jakość tych filtrów też jest bardzo niska - bypassy są łatwe w znalezieniu i rzadko kiedy w ogóle naprawiane, support odpisuje po wielu dniach, a jeśli atak będzie zbyt duży to odetną cię od sieci do momentu rozwiązania sprawy z supportem (co może ciągnąć się tygodniami).

Nawet cały dedyk z takim procesorem nie będzie miał szans z 20 graczami bez ograniczania vanillowych mechanik. Xeony pod ddr3 chodzą po kilkadziesiąt zł, bardziej się oszczędzać nie da.

Więc kolejny współdzielony hosting, dodatkowo z prehistorycznymi prockami pod całkiem inne środowisko niż serwery mc i z filtrami od niemałej grupy cyberprzestępczej. Nic nowego.

Zależnie od wymagań, z niskiej półki możesz użyć darmowy pakiet od Oracle Cloud (24gb ramu, 4 wątki średniego procka) + darmowy pakiet tcpshielda dla ochrony przed ddosami, a ze średniej półki dowolny pakiet z hostingu Pufferfish lub Bloom (Bloom w europejskiej lokalizacji wprowadzi pełną ochronę przed ddosami dopiero pod koniec tego roku).

Wszystkie serwery w danej sieci serwerów powinny stać w tym samym centrum danych, a najlepiej na tej samej maszynie. W znacznym stopniu ogranicza to użycie łącza oraz zmniejsza ping. Pod mniejszą sieć serwerów nada się darmowy vps od Oracle Cloud.

Znam tylko jeden porządny plugin który go wymaga, przy czym autor już od dłuższego czasu myśli nad przejściem na inną bibliotekę. 1. Ten plugin działa na 1.20 2. Jest on przestarzały i posiada lepszą alternatywę: Armor Stand Adjustor 1. Ten plugin działa na 1.20 2. Ten plugin jest bardzo prockożerny i nie ma żadnego powodu by z niego korzystać 1. Ten plugin aktywnie wspiera wersję 1.20. Co więcej, nie wspiera on wersji 1.19 i starszych. Przez miesiące po odkryciu log4shell obserwowałem tego typu pluginy i w każdym przypadku można było łatwo stwierdzić, że autorzy w ogóle nie wiedzą jak działa ten exploit. Podlinkowany przez ciebie plugin nie jest wyjątkiem. Terminal nigdy nie powinien mieć hasła, dużo bezpieczniejsze są klucze autoryzacyjne (które na niektórych hostingach są przygotowane domyślnie). Żadna autoryzacja nie ochroni serwera przed lukami w kodzie, takimi jak log4shell. Kolejny raz piszę, że wielu twórców pluginów porzuca wsparcie dla starszych wersji gry i skupia się wyłącznie na najnowszych. Bardzo mało, a jeśli któryś postanowi skorzystać ze starego silnika to bardzo szybko jest zabijany. Możesz ignorować Fendiego, po przeczytaniu całego tematu ponownie jestem prawie pewny, że najzwyczajniej trolluje.

Protocollib wspiera wersję 1.20.1, wystarczy czytać opis. Dodatkowo, jest to przestarzała i niestabilna biblioteka, z której nie warto korzystać. Zgaduję, że "kompatybilność pluginów" testowałeś w pierwszych dniach od wyjścia silnika i potem już tego nie obserwowałeś. Skoro jesteś taki pewny że większość pluginów nie wspiera najnowszej wersji, wypisz przynajmniej 5 popularnych i używalnych. "Załatanie exploitów" nie jest takie proste jak ci się może wydawać. Wymaga to wielu godzin researchu i pracy oraz dużej wiedzy, a nawet wtedy łatwo coś pominąć. Edytowanie silnika tylko po to by naprawić w nim luki w bezpieczeństwie nie ma żadnego sensu. Z tym co już całkowicie zaszalałeś. Ten silnik jest podatny na lukę log4shell, co pozwala nawet mniej doświadczonym osobom chcącym zaszkodzić serwerowi wykonać na maszynie swój własny kod. Po tym zastanawiam się, czy aby przypadkiem nie robisz tego celowo. Jeśli nie zależy ci na bezpieczeństwie, wydajności, stabilności oraz kompatybilności pluginów, a także jesteś gotów na to, że w dniu otwarcia serwera zostanie on całkowicie zniszczony, to oczywiście. Ale jeśli chcesz robić ten serwer "na poważnie", to - jak już wiele razy pisałem - zainstaluj najnowszy silnik.

Skoro tak myślisz to nigdy nie próbowałeś robić serwera na 1.20. Znalezienie pluginu który będzie wspierał tą wersję graniczy z cudem, podobnie z 1.18.

1. Znaczna większość twórców pluginów skupia się głównie na najnowszej dostępnej wersji, więc korzystając z aktualnego silnika wsparcie pluginów jest dużo wyższe. 2. Porzuconych pluginów powinno się unikać i korzystać ze stale wspieranych alternatyw. Jeśli będziesz miał problem ze znalezieniem alternatywy dla porzuconego pluginu, możesz utworzyć nowy temat. 3. Jeśli plugin nie wykorzystuje NMS, najprawdopodobniej nawet po porzuceniu będzie działał jeszcze przez parę lat. Jak ci wygodniej. Dodam jeszcze, że viaversion w pakietach chunków automatycznie podmienia bloki niedostępne dla danej wersji klienta na podobne, starsze bloki.

Wersja 1.16.5 jest bardzo niestabilną wersją. Pod względem stabilności 1.18.2 jest dużo lepsza, ale nadal nie można jej nazwać stabilną. Kolejny raz powtarzam - silnik serwera zawsze powinien być najnowszy, nie ma znaczenia z jakich wersji wpuszczasz graczy.

1.20.1

Dla 50 graczy wystarczy 6gb ramu, dla 100 8-10gb, a dla 200 16gb, lecz przy tej ilości można już myśleć o bardziej skalowalnym silniku. Pamiętaj, że przy aplikacjach korzystających z garbage collectora(GC) więcej przypisanego ramu = więcej używanego ramu = dłuższe czasy (pause time) GC = bardziej odczuwalne lagi (freezy/spike'i).

Silnik zawsze powinien być najnowszy i nie możesz zapominać o jego częstych aktualizacjach. Gdy wyjdzie mniejsza aktualizacja gry (np. 1.20.1 -> 1.20.2) odczekaj ok. tydzień przed wrzuceniem nowego, a przy większych aktualizacjach (np. 1.20.2 -> 1.21) od dwóch tygodni do miesiąca. W momencie gdy nie wychodzi żadna nowa wersja Minecrafta, aktualizuj silnik przynajmniej raz na tydzień. Warto także aktywnie śledzić changelogi silnika. Silnik wybiera się zależnie od zastosowania: - Fabric dla niedużych, prywatnych serwerów - Paper dla publicznych serwerów do ok. 100 graczy - Pufferfish(+) dla publicznych serwerów do ok. 200 graczy - Folia dla publicznych serwerów powyżej 200 graczy - Purpur dla serwerów, które korzystają z jego dodatkowych customizacji