Minecraft 로그에서 가장 흔한 세 가지 렉 메시지는 같은 뜻이 아니야. Can't keep up! Is the server overloaded?는 서버가 계속 실행 중이지만 처리 속도가 따라가지 못한다는 뜻이야. A single server tick took 60.00 seconds는 내장 비상 브레이크가 서버를 강제로 종료했다는 뜻이야. Exception in server tick loop는 구체적인 프로그램 오류가 게임 루프를 터뜨렸다는 뜻이야. 이 셋을 모두 똑같이 다루면 대부분 엉뚱한 것을 고치게 돼.
세 가지 메시지 구분하기
Minecraft는 게임 월드를 초당 20번 계산해. 이런 한 번의 계산 주기를 Tick이라고 하며, 최대 50밀리초 안에 끝나야 해. 네가 느끼는 모든 렉은 이 한 숫자에서 벗어난 상태야.
| 로그 메시지 | 실제로 일어난 일 | 서버가 아직 실행 중인가? |
|---|---|---|
Can't keep up! Is the server overloaded? Running 5074ms or 101 ticks behind |
Tick이 50ms보다 오래 걸리고, 서버가 밀린 작업을 처리하는 중 | 예, 하지만 눈에 띄게 버벅임 |
A single server tick took 60.00 seconds + Considering it to be crashed |
하나의 Tick이 max-tick-time을 넘었고 Watchdog이 프로세스를 종료함 |
아니요, 강제 종료됨 |
Exception in server tick loop |
오류가 메인 루프까지 전파됨 | 아니요, 대부분 Crash-Report와 함께 종료됨 |
Dispatched async TPS command (Paper 경고) |
우리의 자체 TPS 측정이 서버를 외부에서 조회함 | 예 — 정상임 |
마지막 줄은 자주 헷갈려. Paper는 외부에서 들어오는 모든 조회를 경고로 표시해. 이건 약 5분마다 실행되는 우리의 예정된 성능 측정이며, 오류도 아니고 네 게임에 개입하는 것도 아니야.
가장 중요한 처리법: Watchdog 메시지는 위쪽을 읽기
Watchdog-Kill은 증상이지 원인이 아니야. 단지 무언가가 서버 Thread를 허용 시간보다 오래 막았다는 말뿐이야. 무엇이 막았는지는 다른 곳에 있어.
두 가지 경우가 있고, 각각 완전히 다른 조치로 이어져:
경우 1 — Watchdog이 먼저 왔을 때. Watchdog 줄 앞에 정상적인 게임 실행 로그가 있어. 이때는 Tick 시간이 실제 메시지야. 실행 중인 서버를 무언가가 얼려버린 거야.
경우 2 — Watchdog이 뒤늦게 왔을 때. Watchdog 줄 앞에 이미 Stopping server 또는 Preparing crash report가 있어. 이때는 서버가 이미 죽었거나 종료 중이었고, Watchdog은 멈춘 종료 과정을 정리했을 뿐이야.
이 두 번째 경우는 드문 예외가 아니야. 2026년 8월 22일의 한 지원 사례에서 서버 Thread는 13:20:15에 충돌했고, 정상적인 Stopping server를 시작했어. 그리고 60초 뒤에야 Watchdog이 작동했지. 여기서 Tick 시간을 원인이라고 설명하면 운영자는 실제 오류 메시지를 놓치게 돼. 그 메시지는 1분 위에 있었거든. 그래서 우리의 콘솔 분석은 Watchdog Treffer를 의도적으로 가장 마지막에 평가해. 같은 로그 구간에 더 구체적인 Signature가 있으면 „Tick이 느렸다“가 아니라 그 메시지를 보여줘.
원인을 찾는 단계별 방법
1. 패널에서 TPS 추이 확인하기
패널에서 네 서버를 열어. „Performance (letzte 24h)“ 아래에서 TPS 추이를 볼 수 있어. 서버가 실행 중인 동안 약 5분마다 측정돼. 곡선 모양만 봐도 많은 걸 알 수 있어:
- 특정 시각의 날카로운 하락 → 하나의 사건. 로그와 시간을 맞춰봐: 월드 생성, Backup, 미탐험 지역에 들어간 플레이어, Plugin-Task.
- 지속적으로 낮은 값 → 구조적 과부하. 여기엔 재시작이 아니라 부하 감소가 필요해.
- 톱니 모양 패턴 → 메모리 압박에서 흔함: 서버가 작업하고, Garbage Collection이 끊고, 이게 반복돼.
값이 긴 시간 동안 낮게 유지되면 패널이 자동으로 „TPS dauerhaft niedrig“ 알림을 표시해.
2. MSPT 측정하기 — TPS만으로는 부족해
콘솔에 /spark tps를 입력해. 이 명령은 두 숫자를 보여주는데, 두 번째가 더 중요해:
- TPS — 초당 Tick 수, 최대 20.
- MSPT — Tick당 밀리초. 50ms까지는 정상 범위야.
왜 MSPT일까? Bukkit, Spigot, Paper는 충돌을 피하려고 서버 프로세스를 제한해. 그래서 표시상으로는 깔끔한 20 TPS가 보여도, 실제 서버는 이미 한계에 닿아 있을 수 있어. MSPT 값이 45ms라는 뜻은: Mob-Farm 하나만 더 있어도 눈에 띄는 렉이 생길 수 있다는 말이야. TPS 표시는 아직 완벽해 보여도 말이야.
Paper 1.21 이상에는 spark가 이미 포함되어 있어서, 따로 설치할 필요가 없어.
3. 원인 제공자 프로파일링하기
어떤 Plugin이 문제인지 추측하지 말고 측정해:
/spark profiler start --timeout 120
이 2분 동안 렉이 나는 상황을 재현해. 그다음 서버가 출력하는 결과 링크를 열어. Report는 Tick 시간이 어디로 흘러가는지 시간 비중순으로 보여줘: 특정 Mod, Plugin-Task, Chunk 로딩, Entity 처리 또는 Garbage Collection.
여기가 이 Guide가 „RAM 더 사기“와 갈라지는 지점이야. Profiler는 추천 표가 답하지 못하는 질문에 답해줘: 네 서버에서 정확히 무엇이 시간을 잡아먹고 있는가?
4. 정확히 부하 줄이기
Profiler가 보여주는 내용에 따라 조치가 달라져:
| Profiler가 보여주는 것 | 효과적인 조치 |
|---|---|
| Chunk 로딩, 월드 생성 | simulation-distance 낮추기 (Default 10, Minimum 3) — view-distance보다 효과가 큼. 시뮬레이션되는 Chunk만 계산 시간을 쓰기 때문 |
| Entity 처리 | Mob-Farm 제한, 동물을 자유롭게 돌아다니게 두지 말고 울타리에 넣기, Item 더미 정리 |
| Redstone / Block-Ticks | Repeater 루프 대신 Observer로 Redstone Clock 만들기, 계속 도는 장치 끄기 |
| 단일 Plugin 또는 Mod | 테스트로 비활성화하고 다시 측정하기; 대체품이나 최신 버전 찾기 |
| Garbage Collection | 이제야 RAM 증설이 맞는 답이야 — 그 전에는 아님 |
마지막 항목이 중요해. RAM은 메모리 문제만 해결해. Redstone Clock이 Tick 시간을 먹고 있다면 더 큰 요금제로 바꿔도 서버는 빨라지지 않아. 플레이어 수와 Modpack 크기에 맞는 메모리 용량은 우리의 Minecraft-RAM-Rechner가 계산해줘.
5. max-tick-time — 예외이지 해결책이 아님
이 값은 server.properties에 있으며, Watchdog이 개입할 Tick 시간을 정해. 기본값은 60000밀리초, 즉 60초야. 이 값을 넘으면 서버가 스스로 종료돼.
인터넷의 많은 안내는 여기서 Watchdog을 -1로 끄라고 추천해. 그걸 기본 해결책으로 쓰지 마. Watchdog은 진짜 Deadlock을 알아차릴 수 있는 유일한 내장 장치야. -1을 쓰면 죽은 서버가 Port에 몇 시간 동안 걸린 채로 남아: 플레이어는 접속하지 못하고, 로그에는 이유가 없고, 아무도 알림을 받지 못해. 문제를 없앤 게 아니라 표시만 지운 거야.
값을 올릴 만한 좋은 이유는 딱 하나야: 알려진 작업이 정당하게 오래 걸리는 경우. 대표적인 예는 큰 Modpack의 첫 시작이야. 월드 생성과 Mod 초기화가 한 Tick 안에서 합쳐져 1분을 넘길 수 있어. 이때는 예를 들어 180000(3분) 같은 값이 허용될 수 있어. 단, 임시로만 쓰고 첫 성공적인 시작 이후 되돌릴 생각이어야 해.
로그에 Exception in server tick loop가 있을 때
이 메시지는 셋 중 가장 쉬워. 원인을 함께 가져오기 때문이야. 바로 아래나 몇 줄 뒤에 Caused by: 줄이 있어. 거기에 실제 오류가 있고, 대부분 책임 있는 Mod나 Plugin 이름도 함께 나와.
진행 방법:
Caused by:를 찾고 Class 이름을 적어.- 거기에 Mod 또는 Plugin 이름이 포함되어 있으면 원인 제공자가 명시된 거야.
- 오류가 변경 후에 발생했다면(새 Mod, Update, 새 월드), 그 변경을 먼저 되돌려.
- 그래도 오류가 불분명하면 전체 구간을 시간과 함께 Support에 보내.
네 서버의 콘솔 분석은 이런 줄을 자동으로 인식하고, 감지된 각 메시지를 빈도와 함께 쉬운 말로 설명해줘. 다른 곳에서 가져온 로그 일부만 있다면 우리의 Crash-Report-Analyzer에 붙여넣을 수 있어. 우리 서버가 아니어도 돼.
우리가 자동으로 대신 처리하는 것
- 추가 작업 없는 성능 측정. TPS는 약 5분마다 수집되고 패널에 24시간 동안 표시돼. 이를 위해 Plugin을 설치할 필요가 없어.
- 지속적인 성능 저하 경고. 신뢰할 만한 시간 구간 동안 성능이 낮게 유지되면, 네가 직접 알아차리기 전에 알림을 받아.
- 설명된 로그 줄. 감지된 메시지는 원인과 해결책을 네 언어로 쉬운 말로 보여줘. 적절한 Guide가 있으면 그 링크도 함께 제공돼.
- 증상보다 원인 우선 규칙. 같은 로그 구간에 Watchdog-Kill보다 더 의미 있는 오류 메시지가 있으면, 우리는 그 메시지를 보여줘.
Troubleshooting: 증상, 확인, 해결책
| 증상 | 확인 | 가능한 해결책 |
|---|---|---|
| 새 지역을 탐험할 때만 렉 | 플레이어가 미탐험 지역으로 들어갈 때 발생하나? | 월드 생성; simulation-distance 낮추기, 월드 사전 생성 맡기기 |
| 특정 시각마다 렉 | 예정된 작업과 시각 맞춰보기 | Backup 또는 재시작 계획 시간을 옮기기 |
| 서버가 오류 없이 멈추고 로그가 갑자기 끝남 | 끝에 A single server tick took가 있나? |
Watchdog-Kill; 그 전 1분 읽기 |
| TPS는 20인데 여전히 끊김 | /spark tps — MSPT 확인 |
TPS-Limiter가 부하를 가림; MSPT 기준으로 판단 |
| Mod 추가 후 발생 | Mod 제거 후 다시 측정 | Mod 충돌 또는 부하가 큰 Mod |
| TPS 추이에 톱니 모양 | Profiler에서 Garbage Collection 확인 | 메모리 압박; RAM 늘리기 |
| 로그에 „Dispatched async TPS command“ | 이 줄만 있고 나머지는 정상 | 할 일 없음 — 우리의 측정 |
FAQ
몇 TPS부터 플레이어가 체감하나?
약 18 TPS까지는 게임에서 거의 티가 나지 않아. 15 아래로 내려가면 눈에 띄게 답답해져. 하지만 이 숫자만 믿지는 마. TPS-Limiter가 건강한 숫자를 보여주는 동안에도 서버가 이미 한계에서 작동할 수 있으니 MSPT도 함께 확인해.
RAM을 늘리면 렉에 도움이 되나?
메모리가 실제 병목일 때만 그래. Profiler가 Garbage Collection을 주요 항목으로 보여주면 맞아. Redstone Clock이나 Mob-Farm을 보여준다면 RAM을 늘려도 달라지지 않아. 먼저 측정하고, 그다음 구매해.
Watchdog을 꺼야 하나?
아니, 영구적으로 끄면 안 돼. -1은 진짜 멈춤을 자동으로 감지하는 유일한 기능을 빼앗아. 큰 Modpack의 첫 시작처럼 알려진 느린 작업을 위해 max-tick-time을 임시로 올리는 건 괜찮아. 그 후에는 되돌려.
왜 Watchdog 메시지가 „Stopping server“ 뒤에 나오나?
서버가 이미 종료 중이었고 그 과정에서 멈췄기 때문이야. Watchdog은 실행 중인 서버를 죽인 게 아니라 멈춘 종료 과정을 정리한 거야. 원인은 Stopping server 앞에 있어.
재시작이 도움이 되나?
당장의 밀린 작업에는 도움이 돼. 하지만 원인은 해결하지 못해. 재시작 후 짧은 시간 안에 렉이 매번 돌아온다면 구조적인 문제야. 그때는 측정만이 다음 단계로 이어져.
view-distance와 simulation-distance의 차이는 뭐야?
view-distance는 플레이어가 얼마나 멀리 보는지를 정하고, simulation-distance는 월드가 실제로 얼마나 멀리 계산되는지를 정해. 둘 다 기본값은 10 Chunks야. 계산 시간을 쓰는 것은 시뮬레이션되는 Chunk뿐이므로, simulation-distance를 낮추는 것이 보이는 손실은 적으면서 더 큰 부하 감소를 가져와.
그래도 계속 렉이 걸린다면
Support에 문의하기 전에 세 가지를 모아: 마지막 사건의 정확한 시각, spark-Profiler-Report 링크, 최근에 추가된 Mods 또는 Plugins 목록. 이렇게 하면 일반적인 최적화만 돌리는 대신 로그의 알맞은 구간을 정확히 확인할 수 있어.
모든 게임에 공통으로 적용되는 일반 설정 — 재시작 계획, 요금제 선택, 네트워크 — 은 Gameserver-Performance verbessern Guide에서 볼 수 있어. Mods와 Plugins를 깔끔하게 설치하고 제거하는 방법은 Minecraft-Mods und Plugins installieren에 있어.
TPS 측정, 로그 설명, 경고가 추가 작업 없이 포함된 서버를 원해? Minecraft Java 서버 임대에서 알맞은 요금제를 찾을 수 있어.
출처와 검증 기준
max-tick-time, Tickrate와 거리: PaperMC — server.properties. 60000밀리초 기본값, 초과 시 강제 종료,-1을 통한 비활성화, 그리고view-distance와simulation-distance의 기본값 10을 문서화해.- spark는 Paper에 포함됨: PaperMC — Profiling. Paper 1.21부터는 별도 Download가 필요 없어.
- TPS보다 MSPT 우선: spark — TPS and MSPT. 서버가 실제로 느리게 실행되는 동안 TPS-Limiter가 깔끔한 20을 보여줄 수 있는 이유를 설명해.
- Profiler 명령: spark — Command Usage.
/spark profiler start --timeout <sekunden>와/spark profiler stop의 출처야.
검증 기준: 2026년 8월 24일. 기본값과 명령은 새 서버 버전에 따라 바뀔 수 있어. 의심스러우면 링크된 제조사 문서를 확인해.