개요

최적화는 빼기 작업이다. 서버의 렉 요인을 걷어 내는 것이다. 렉의 원인은 Minecraft 자체의 낮은 성능, 코드 최적화를 신경 쓰지 않는 일부 플러그인 제작자, 너무 많은 엔티티 등 다양하다.

서버마다 렉의 원인이 다를 수 있으니, 여기서는 가장 기본적인 범용 최적화부터 한다. 적용해도 효과가 별로 없다면 성능 분석 부분을 참고하자.

“섣부른 최적화는 만악의 근원이다.” 섣부른 최적화는 서버를 불안정하게 만들고, 심하면 10x slower가 된다.

시작하기 전에 반드시 최적화의 오해를 읽고 효과 없는 “최적화”를 그만둔 다음, 아래 단계를 따르자.

1단계 - Java 최적화

왜 Java 최적화가 첫 단계일까? 거의 모든 경우에 서버는 알맞은 Java로 이득을 본다.

작은 Java 설치 프로그램을 하나 받거나 JVM 인자(쉽게 말해 서버 시작 인자)만 바꾸면 된다.

JVM 최적화를 참고하자.

2단계 - 사전 생성

사전 생성이란 플레이어가 들어오기 전에 서버가 청크의 블록, 구조물 등을 미리 생성해 두는 것이다.

Minecraft 서버에서 새 청크를 생성하는 작업은 서버 자원을 많이 먹는다. 새 맵이나 서버를 연다면 맵을 먼저 사전 생성해 두는 것을 추천한다.

Chunky가 가장 많이 쓰이는 사전 생성 플러그인이다. 보통 ChunkyBorder와 함께 쓰며, 경계와 모양을 취향대로 정할 수 있다.

경계를 두지 않더라도 10000 x 10000 정도 크기는 꼭 사전 생성해 두자. 나중에 서버 부하를 줄이는 데 아주 효과적이다.

사전 생성할 때 주의할 점: 기본 설정의 1.20 바닐라 10000 x 10000 맵은 디스크를 4-5 GB 차지한다. 디스크 크기에 맞춰 사전 생성 크기를 정하자.

3단계 - 서버 코어 교체

플러그인과 설정 수준에서 할 수 있는 최적화는 사실 많지 않다(API와 서버 코어의 한계 때문). 그래서 가장 좋은 방법은 서버 코어를 바꾸는 것이다.

자세한 내용은 서버 코어 선택을 참고하자.

4단계 - 서버 설정 조정

인터넷에 돌아다니는 설정은 대부분 아주 오래된 것이라 추천하지 않는다.

이 문서의 서버 설정 조정은 비교적 최신이라 적극 추천한다.

5단계 - 하드웨어 교체

생각 없이 하드웨어부터 바꾸지 말자! 먼저 하드웨어 병목이 어디인지 알아야 한다. CPU 부하가 너무 높다면 비정상적인 CPU 점유부터 걸러 내고, 그다음 전체 CPU 사용량을 보자. 일반적으로 서버 렉에는 CPU 교체가 가장 효과적이다. 싱글 코어 성능과 MC 서버 TPS는 거의 선형 관계다. 하지만 CPU를 바꾸는 건 사실상 머신을 바꾸는 것과 같고, 이전 작업은 초보자에게 쉬운 일이 아니다.

단일 서버라면 8코어를 넘는 부분은 코어 수를 늘려도 TPS가 거의 오르지 않는다. 걸핏하면 E5를 사고, 렉이 걸리면 4코어 8G 메모리를 더 붙이는 짓은 하지 말자. 더 늘려도 소용없다.

프록시 네트워크라면 보통 코어는 다 쓰지만 메모리가 빠듯할 수 있다. 일반적인 야생 서버 하나당 권장 메모리는 8G - 20G이고, 이보다 많거나 적은 것은 추천하지 않는다.

6단계 - 운영체제 교체

성능과 안정성 모두 Linux가 Windows보다 서버 운영에 적합하다. 배포판은 자신의 경험에 맞춰 고르면 되고, 경험이 없다면 Ubuntu 같은 주류 배포판부터 써 보자.

Linux로 옮긴 뒤에는 커널 최적화도 할 수 있다.

더 알고 싶다면 고급 편의 Linux 서버 운영 가이드로 가자.

7단계 - 성능 분석

“마르크스주의의 살아 있는 영혼은 구체적인 문제에 대한 구체적인 분석에 있다.” - 레닌

범용 최적화는 이제 거의 다 했다. 하지만 서버마다 지연을 일으키는 요인이 따로 있다. 엔티티가 너무 많을 수도, 플레이어들이 만든 자동화 장치가 많을 수도, 어떤 플러그인이 형편없이 짜여 있을 수도 있다…

그렇다면 서버가 왜 렉에 걸리는지는 어떻게 알 수 있을까?

완전 초보라서, 혹은 분석하기 귀찮아서 다른 사람에게 분석을 부탁하고 싶다면 고수에게 성능 분석을 부탁하는 법으로 가자.

남에게 도움을 청하기 싫거나 실력을 좀 키우고 싶다면 성능 분석을 참고하자.