SSD Nodes Learn Hosting plans →
คู่มือ Matt Connorโดย Matt Connor

วิธีเลือกเช่า VPS สำหรับรัน Game Server ให้ลื่นไหล

การเลือก VPS รันเกมต้องเน้น CPU Single Core ความเร็วสูงและ RAM ที่เพียงพอ เรียนรู้การคำนวณสเปก การจัดการ Port การตั้งค่า systemd และเหตุผลที่ตำแหน่ง Server มีผลต่อค่า Latency

คุณหมายถึง Gaming VPS ประเภทใด

VPS สำหรับเซิร์ฟเวอร์เกมเป็นการลงทุนที่คุ้มค่าสำหรับงานเดียว คือการรัน dedicated server เพื่อให้คุณและเพื่อนเชื่อมต่อเข้ามาจากเครื่องส่วนตัว แต่จะเป็นการลงทุนที่ไม่คุ้มค่าสำหรับอีกความหมายหนึ่งที่ผู้คนมักเข้าใจผิด ซึ่งก็คือการเล่นเกมบนตัว VPS โดยตรงผ่าน remote desktop งานทั้งสองประเภทนี้ต้องการฮาร์ดแวร์ที่แตกต่างกันอย่างสิ้นเชิง dedicated server ต้องการ CPU core ที่มีความเร็วสูงหนึ่งคอร์และ RAM ที่เพียงพอต่อการโหลดข้อมูลโลกของเกม ส่วนการเล่นเกมต้องการ GPU (graphics processing unit) ซึ่งแผนบริการ VPS มาตรฐานไม่มีให้

เนื้อหาทั้งหมดด้านล่างนี้เกี่ยวข้องกับงานประเภทแรกเท่านั้น งานประเภทที่สองควรค่าแก่การสละเวลาอ่านสัก 2 นาที เพราะมีผู้คนจำนวนมากซื้อเครื่องผิดประเภทสำหรับงานนี้

เหตุผลที่คุณไม่สามารถเล่นเกมบน VPS ได้

VPS มาตรฐานให้คุณใช้งาน virtual CPU core เท่านั้นและไม่มีการ์ดจอมาให้ ไม่มีการส่งผ่านทรัพยากรจากโฮสต์จริง ดังนั้นจึงไม่มี hardware renderer สำหรับให้เกมใช้งาน คุณสามารถตรวจสอบสิ่งที่คุณได้รับจริงได้ด้วยคำสั่งนี้:

sudo apt install -y pciutils
lspci | grep -iE "vga|3d"

คำตอบที่ได้จะเป็น virtual display adapter เช่น อุปกรณ์ประเภท Cirrus Logic หรือ virtio GPU ซึ่งมีไว้เพื่อให้ web console ของผู้ให้บริการแสดงหน้าจอให้คุณเห็นเท่านั้น และมันไม่มีระบบ 3D acceleration รองรับ หากคุณติดตั้ง desktop และ VNC server ลงไป glxinfo -B จะรายงาน renderer เป็น llvmpipe ซึ่งก็คือ Mesa software renderer ที่ทำงานบน CPU เกม 3D สมัยใหม่ที่ประมวลผลด้วย CPU จะทำงานได้เพียงไม่กี่เฟรมต่อวินาที จึงไม่สามารถเล่นได้ตั้งแต่ก่อนที่ข้อมูลจะถูกส่งออกจากเครื่องเสียอีก สำหรับ Windows instance ก็ประสบปัญหาเดียวกัน หลายเกมจะปิดตัวลงทันทีที่เปิดใช้งานโดยแจ้งเตือนว่าไม่สามารถสร้าง Direct3D device ได้ เนื่องจากไม่มี display adapter ให้ใช้งาน

ปัญหาที่สองคือการส่งข้อมูลกลับมายังคุณ การเล่นเกมบนเครื่องระยะไกลหมายความว่าทุกเฟรมจะต้องถูกเข้ารหัสเป็นวิดีโอ ส่งผ่านอินเทอร์เน็ต และถอดรหัสบนหน้าจอของคุณ ซึ่งจะเพิ่มเวลาในการเข้ารหัสและถอดรหัสเข้าไปรวมกับ input lag ของตัวเกมเอง อีกทั้ง RDP และ VNC ถูกออกแบบมาเพื่อการใช้งาน desktop ไม่ใช่สำหรับการแสดงผลภาพเคลื่อนไหวที่ 60 เฟรมต่อวินาที บริการ cloud gaming แก้ปัญหานี้ด้วยการใช้ GPU จริงและโปรโตคอลสตรีมมิ่งที่สร้างขึ้นมาโดยเฉพาะ แต่ VPS ทั่วไปไม่มีทั้งสองอย่าง หากคุณต้องการเล่นเกม ให้เช่าเวลาใช้งาน GPU หากคุณต้องการโฮสต์บริการ ให้ศึกษาเนื้อหาถัดไป

สิ่งที่เซิร์ฟเวอร์เกมแบบเฉพาะ (Dedicated Game Server) ต้องการจริงๆ

เซิร์ฟเวอร์เกมคือลูปการจำลองสถานการณ์ (simulation loop) ซึ่งเก็บข้อมูลโลกของเกมไว้ในหน่วยความจำและประมวลผลตามจำนวนรอบที่กำหนดต่อวินาที จากนั้นจะส่งข้อมูลส่วนที่ผู้เล่นแต่ละคนมองเห็นไปยังเครื่องของผู้เล่นนั้น

ลักษณะการทำงานนี้เป็นตัวกำหนดความต้องการของฮาร์ดแวร์ ลูปดังกล่าวส่วนใหญ่ทำงานบนเธรดเดียว ดังนั้นความเร็วของคอร์ (core speed) จึงมีความสำคัญมากกว่าจำนวนคอร์ ข้อมูลโลกของเกมถูกเก็บไว้ในหน่วยความจำ ดังนั้น RAM มักจะเป็นข้อจำกัดแรกที่คุณจะพบ ดิสก์จะทำงานน้อยในระหว่างการเล่น แต่จะทำงานหนักในช่วงโหลดและบันทึกข้อมูล เส้นทางเครือข่ายของคุณเป็นตัวกำหนดค่า ping และไม่มีแพ็กเกจบริการใดที่สามารถเปลี่ยนแปลงค่านี้ได้

ความเร็วต่อคอร์สำคัญกว่าจำนวนคอร์

เซิร์ฟเวอร์เกมส่วนใหญ่ประมวลผลโลกของเกมผ่านเธรดหลักเพียงเธรดเดียว ทั้งลูปการทำงานของ Minecraft และเฟรมเซิร์ฟเวอร์ของ Source engine ต่างทำงานในลักษณะนี้ ซึ่งการประมวลผลแต่ละรอบ (tick) จะมีกำหนดเวลาที่จำกัด Minecraft Java ทำงานที่ 20 ticks ต่อวินาที ซึ่งหมายความว่าแต่ละ tick จะมีงบเวลาให้ 50 มิลลิวินาที เมื่อการประมวลผลไม่เสร็จสิ้นภายในเวลาที่กำหนด เซิร์ฟเวอร์จะแสดงข้อความนี้:

[12:04:51] [Server thread/WARN]: Can't keep up! Is the server overloaded? Running 2547ms or 50 ticks behind

บรรทัดดังกล่าวหมายความว่าเธรดหลักทำงานไม่ทันเวลา การเพิ่มจำนวนคอร์ไม่ได้ช่วยให้เธรดนั้นมีเวลาทำงานมากขึ้น แผนบริการที่มี 2 vCPU ความเร็วสูงจะสามารถรักษาอัตรา tick ได้ดีกว่าแผนที่มี 8 vCPU ความเร็วต่ำ เพราะมีเพียงคอร์เดียวจาก 8 คอร์นั้นที่ทำหน้าที่ประมวลผลส่วนสำคัญ

ควรวัดความเร็วของเธรดเดี่ยว (single thread) ก่อนตัดสินใจเลือกแผนบริการ:

sudo apt install -y sysbench
sysbench cpu --cpu-max-prime=20000 --threads=1 run

ให้อ่านค่าในบรรทัด events per second ตัวเลขนี้ไม่มีความหมายในตัวเองหากไม่มีการเปรียบเทียบ ดังนั้นควรทดสอบกับแผนบริการสองแผนที่สนใจแล้วนำผลลัพธ์มาเปรียบเทียบกัน การรัน benchmark เต็มรูปแบบสำหรับ VPS จะครอบคลุมถึงการทดสอบดิสก์และเครือข่ายในลักษณะเดียวกัน

อย่างไรก็ตาม จำนวนคอร์ที่เพิ่มขึ้นยังคงมีประโยชน์ โดยสามารถนำไปใช้รันเซิร์ฟเวอร์เกมที่สอง, ฐานข้อมูล, การสำรองข้อมูลรายคืน และการสร้าง chunk ล่วงหน้าได้ โดยไม่แย่งเวลาประมวลผลจากเธรดหลัก นอกจากนี้ซอฟต์แวร์เซิร์ฟเวอร์ในปัจจุบันเริ่มรองรับการกระจายงานมากขึ้น เช่น Paper ซึ่งเป็น fork ยอดนิยมของ Minecraft ที่มีการย้ายงานบางส่วนออกจากเธรดหลัก ดังนั้น รูปแบบที่ควรเลือกซื้อคือคอร์จำนวนน้อยแต่มีความเร็วสูง ไม่ใช่คอร์จำนวนมากแต่ความเร็วต่ำ

มีตัวเลขหนึ่งที่ไม่เคยปรากฏบนหน้าแผนบริการ แต่เป็นตัวตัดสินว่าคอร์ความเร็วสูงที่คุณจ่ายเงินไปนั้นเป็นของคุณจริงหรือไม่:

vmstat 1 5

คอลัมน์ st คือเปอร์เซ็นต์ของเวลาที่ vCPU ของคุณพร้อมทำงาน แต่โฮสต์จริงกลับจัดสรรคอร์นั้นให้ผู้อื่นใช้งาน หากค่า st สูงกว่าระดับไม่กี่เปอร์เซ็นต์อย่างต่อเนื่อง แสดงว่าโฮสต์มีการขายทรัพยากรเกินจริง (oversold) ผู้เล่นจะรู้สึกถึงอาการกระตุก (stutter) ในขณะที่ค่า top บนเครื่องของคุณยังคงแสดงว่า CPU ว่างอยู่ นั่นเป็นเพราะเวลาที่ว่างอยู่นั้นไม่ใช่ของคุณที่จะนำไปใช้งานได้จริง

เซิร์ฟเวอร์เกมต้องการ RAM เท่าใด

แผนภูมิCommon starting RAM per game server (published guidance, not a measurement)
ข้อมูลเบื้องหลังแผนภูมินี้
[
  {
    "label": "Minecraft Java, vanilla",
    "players": 10,
    "ram_gb": 2
  },
  {
    "label": "Minecraft Java, large modpack",
    "players": 10,
    "ram_gb": 8
  },
  {
    "label": "Valheim",
    "players": 10,
    "ram_gb": 4
  },
  {
    "label": "Palworld",
    "players": 32,
    "ram_gb": 16
  }
]

นี่คือการจัดสรรทรัพยากรเริ่มต้นที่เอกสารประกอบของเกมและ modpack ระบุไว้ ณ เดือนสิงหาคม 2026 ตัวเลขเหล่านี้เป็นเพียงแนวทาง ไม่ใช่ค่าที่วัดได้จากเครื่องเซิร์ฟเวอร์เพียงเครื่องเดียว Minecraft Java รุ่น Vanilla สามารถทำงานได้ดีด้วย heap ขนาด 2 GB สำหรับผู้เล่นประมาณ 10 คน หากเป็น modpack ขนาดใหญ่ที่มีจำนวนผู้เล่นเท่ากันจะต้องการ RAM 8 GB เนื่องจาก mod ต่างๆ จะเพิ่ม entity และโครงสร้างที่ถูกสร้างขึ้นใหม่ซึ่งทั้งหมดต้องใช้พื้นที่ใน heap สำหรับ Valheim นั้น ขั้นต่ำที่ระบุไว้คือ 2 GB แต่ผู้ดูแลเซิร์ฟเวอร์ที่มีโลกขนาดเล็กรายงานว่ากระบวนการทำงานจะใช้ RAM อยู่ที่ประมาณ 3 GB ดังนั้นการเริ่มต้นที่ 4 GB จึงเป็นจุดเริ่มต้นที่เหมาะสม ส่วน Palworld เป็นกรณีพิเศษที่ต้องการ RAM 16 GB สำหรับผู้เล่นสูงสุด 32 คน ตามที่ Pocketpair แนะนำ

RAM ไม่ได้เพิ่มขึ้นตามจำนวนการเชื่อมต่อ แต่เพิ่มขึ้นตามขนาดของโลกที่ถูกโหลดไว้ ผู้เล่นแต่ละคนจะทำให้พื้นที่รอบตัวถูกโหลดไว้เสมอ ดังนั้นผู้เล่นสองคนที่ยืนอยู่ด้วยกันจะใช้ทรัพยากรน้อยกว่าผู้เล่นสองคนที่กำลังสำรวจแผนที่คนละมุม นี่คือเหตุผลว่าทำไม "RAM ต่อผู้เล่น" จึงเป็นเพียงแนวทางคร่าวๆ ในขณะที่ "RAM ต่อพื้นที่ที่ใช้งาน" คือปัจจัยหลัก และเป็นเหตุผลว่าทำไมกลุ่มผู้เล่นขนาดเล็กที่ชอบสำรวจจึงอาจใช้ทรัพยากรเกินกว่าแผนที่คำนวณไว้สำหรับจำนวนคนสองเท่า

เซิร์ฟเวอร์ Java มีกฎเพิ่มเติมอีกสองข้อ ให้ตั้งค่า heap ขั้นต่ำและสูงสุดให้เท่ากัน เพื่อไม่ให้ JVM ต้องหยุดทำงานเพื่อปรับขนาด heap:

java -Xms4G -Xmx4G -jar server.jar nogui

จากนั้นให้เผื่อพื้นที่หน่วยความจำไว้ด้วย JVM จะใช้หน่วยความจำภายนอก heap ที่คุณกำหนดไว้สำหรับ thread stack และ native buffer นอกจากนี้ kernel ยังต้องการ page cache เพื่ออ่านไฟล์โลกอย่างรวดเร็ว บนเครื่องที่มี RAM 6 GB การกำหนด heap ขนาด 4 GB ถือว่าสมเหตุสมผล แต่การกำหนด 6 GB นั้นไม่เหมาะสม

ความล้มเหลวที่เกิดจากหน่วยความจำมีสองรูปแบบที่แตกต่างกันโดยสิ้นเชิง คุณควรทำความเข้าใจทั้งสองกรณี กรณีที่ heap เล็กเกินไปจะเกิดข้อผิดพลาดภายใน Java และเซิร์ฟเวอร์มักจะยังคงทำงานต่อไปได้แบบติดขัด:

java.lang.OutOfMemoryError: Java heap space

กรณีที่ heap ใหญ่กว่าหน่วยความจำของเครื่อง กระบวนการทั้งหมดจะถูกสั่งยุติจากภายนอก ใน console จะแสดงเพียง Killed และหลักฐานจะปรากฏอยู่ใน kernel log:

sudo dmesg -T | grep -i "out of memory"

การเพิ่ม swap จะช่วยป้องกันการถูกสั่งยุติกระบวนการ แต่ไม่ได้แก้ไขปัญหาที่ต้นเหตุ หาก tick loop ต้องอ่านข้อมูลโลกจาก swap จะทำให้การประมวลผลล่าช้าจนไม่ทันเวลา ส่งผลให้ผู้เล่นพบกับเซิร์ฟเวอร์ที่ค้างแทนที่จะเป็นเซิร์ฟเวอร์ที่ล่ม

หมายเหตุเกี่ยวกับเวอร์ชัน ซึ่งตรวจสอบเมื่อ 2026-10-11 ตาม metadata เวอร์ชันของ Mojang: Minecraft Java ตั้งแต่ 1.20.5 ถึง 1.21.11 ต้องการ Java 21 ส่วนเวอร์ชัน 26.1 ขึ้นไป รวมถึงเวอร์ชันปัจจุบันคือ 26.3 ต้องการ Java 25 หากใช้ runtime เวอร์ชันเก่า เซิร์ฟเวอร์จะเริ่มทำงานแล้วล้มเหลวพร้อมข้อความแจ้งเตือน unsupported class file version ซึ่งดูเหมือนข้อความจาก compiler และมักทำให้ผู้ใช้งานสับสนในครั้งแรกที่พบ Ubuntu 22.04, 24.04 และ 26.04 มี Java 25 runtime มาให้ใน standard archive:

sudo apt install -y openjdk-25-jre-headless
java -version

ความเร็วของดิสก์มีผลต่อเซิร์ฟเวอร์เกมหรือไม่

มีผลน้อยกว่าที่หลายคนคาดคิดในระหว่างการเล่น แต่มีความสำคัญอย่างมากใน 2 ช่วงเวลาหลัก ข้อมูลโลกจะถูกอ่านเข้าสู่หน่วยความจำในขณะเริ่มระบบและเขียนกลับลงดิสก์เมื่อมีการบันทึกอัตโนมัติ (autosave) ดังนั้นความเร็วของดิสก์จะส่งผลให้การบูตเครื่องช้าลงและเกิดอาการค้างชั่วขณะเมื่อระบบบันทึกข้อมูล ในระหว่างนั้นการอ่านข้อมูลส่วนใหญ่จะทำผ่าน RAM

มี 2 ปัจจัยที่ทำให้ดิสก์มีความสำคัญมากกว่าที่สรุปไว้ข้างต้น ประการแรก การสำรวจพื้นที่ใหม่จะมีการโหลด chunk หรือโซนใหม่จากดิสก์ในขณะที่ผู้เล่นกำลังเคลื่อนที่ ซึ่งการอ่านข้อมูลนี้ต้องเกิดขึ้นภายในกรอบเวลาของ tick ประการที่สอง การบันทึกอัตโนมัติในโลกขนาดใหญ่จะมีการเขียนข้อมูลจำนวนมากในคราวเดียว และบนไดรฟ์ที่ช้า การเขียนข้อมูลจะขัดจังหวะลูปการทำงานนานพอที่จะทำให้เกิดข้อความแจ้งเตือน "Can't keep up" ทั้งสองกรณีนี้เป็นปัญหาด้าน latency มากกว่าปัญหาด้าน throughput ซึ่งเป็นเหตุผลว่าทำไม ช่องว่างระหว่าง NVMe และ SATA SSD บน VPS จึงมีความสำคัญมากกว่าตัวเลขความเร็วเมกะไบต์ต่อวินาทีที่ระบุไว้ สิ่งที่คุณควรให้ความสำคัญคือระยะเวลาที่ใช้ในการดำเนินการขนาดเล็กหนึ่งรายการ

ควรจัดสรรขนาดพื้นที่จัดเก็บข้อมูลให้รองรับการขยายตัว โลกของเกมจะขยายขนาดขึ้นทุกครั้งที่มีผู้เล่นเดินไปยังพื้นที่ใหม่ และไฟล์สำรองข้อมูลจะทวีคูณขนาดตามข้อมูลที่มีอยู่ ให้รัน du -sh world สัปดาห์ละครั้งเป็นเวลา 1 เดือน แล้วคุณจะทราบอัตราการเติบโตที่แท้จริงของข้อมูลคุณ

Tick rate, ping และความแตกต่างระหว่างทั้งสองค่า

Tick rate คือจำนวนครั้งต่อวินาทีที่เซิร์ฟเวอร์คำนวณสถานะของโลกในเกมใหม่ Minecraft Java ทำงานที่ 20 ส่วนเซิร์ฟเวอร์ที่ใช้ Source engine มักทำงานที่ 64 สำหรับ Minecraft นั้น 20 คือค่าที่เกมถูกออกแบบมาให้รองรับ คำสั่ง /tick rate สามารถเปลี่ยนค่านี้ได้ แต่การทำเช่นนั้นจะเป็นการเร่งหรือลดความเร็วของโลกทั้งใบแทนที่จะทำให้การเล่นลื่นไหลขึ้น และการเพิ่มสเปกเครื่องก็ไม่ได้ช่วยให้ค่านี้สูงขึ้น ดังนั้นเป้าหมายคือการรักษาค่าให้คงที่ที่ 20 ไม่ใช่การทำให้เกินกว่านั้น

Ping คือระยะเวลาที่ข้อมูลเดินทางไปกลับระหว่างผู้เล่นหนึ่งคนกับเซิร์ฟเวอร์ ค่าทั้งสองนี้ทำให้เกิดปัญหาที่แตกต่างกัน จึงควรแยกแยะให้ชัดเจนก่อนตัดสินใจใช้จ่ายเงินเพิ่ม เมื่อเซิร์ฟเวอร์ประมวลผล tick ไม่ทัน ผู้เล่นทุกคนจะเกิดอาการกระตุก (rubber-banding) พร้อมกัน และปกติแล้ว log ของเซิร์ฟเวอร์จะระบุข้อความแจ้งเตือนไว้อย่างชัดเจน แต่เมื่อผู้เล่นคนใดคนหนึ่งมีปัญหาที่เส้นทางเครือข่าย จะมีเพียงผู้เล่นคนนั้นที่เกิดอาการแล็ก ในขณะที่ผู้เล่นคนอื่นยังคงเล่นได้ตามปกติ การอัปเกรด CPU ให้แรงขึ้นจะไม่สามารถแก้ไขปัญหาในกรณีหลังนี้ได้เลย

ความหน่วงขึ้นอยู่กับตำแหน่งที่ตั้ง ไม่ใช่ระดับของแพ็กเกจบริการ

แสงที่เดินทางในสายไฟเบอร์มีความเร็วประมาณ 200 กิโลเมตรต่อมิลลิวินาที การเดินทางไป-กลับต้องใช้ระยะทางเป็นสองเท่า ดังนั้นค่าต่ำสุดทางทฤษฎีจึงอยู่ที่ประมาณ 1 ms ต่อทุกๆ 100 กม. ระหว่างผู้เล่นกับเซิร์ฟเวอร์ ไม่มีผู้ให้บริการรายใดที่ทำได้เร็วกว่านี้ และการอัปเกรดแพ็กเกจก็ไม่สามารถเปลี่ยนแปลงค่านี้ได้

แผนภูมิRound trip floor by distance, fibre physics only
ข้อมูลเบื้องหลังแผนภูมินี้
[
  {
    "label": "Toronto to New York",
    "distance_km": 550,
    "rtt_floor_ms": 5.5
  },
  {
    "label": "Dallas to Chicago",
    "distance_km": 1290,
    "rtt_floor_ms": 12.9
  },
  {
    "label": "Dallas to Los Angeles",
    "distance_km": 1990,
    "rtt_floor_ms": 19.9
  },
  {
    "label": "New York to London",
    "distance_km": 5570,
    "rtt_floor_ms": 55.7
  },
  {
    "label": "Los Angeles to Sydney",
    "distance_km": 12070,
    "rtt_floor_ms": 120.7
  }
]

ค่าเหล่านี้เป็นค่าต่ำสุดที่คำนวณจากระยะทางวงกลมใหญ่ (great circle distance) ในความเป็นจริงสายไฟเบอร์ไม่ได้วางเป็นเส้นตรง และเราเตอร์ทุกตัวบนเส้นทางจะเพิ่มความหน่วงเข้าไปเล็กน้อย ดังนั้นผลลัพธ์ที่ใช้งานจริงมักจะอยู่ที่ประมาณสองเท่าของค่าต่ำสุด ผู้เล่นใน Toronto ที่เชื่อมต่อไปยังเซิร์ฟเวอร์ใน New York ซึ่งห่างออกไป 550 กม. จะมีค่าต่ำสุดอยู่ที่ 5.5 ms และโดยปกติจะเห็นค่าอยู่ที่หลักสิบต้นๆ ส่วนเส้นทางจาก Los Angeles ไปยัง Sydney มีค่าต่ำสุดอยู่ที่ 120.7 ms ซึ่งไม่ว่าคุณจะจ่ายเงินมากเท่าใดก็ไม่สามารถทำให้เร็วกว่านี้ได้

ดังนั้นควรวางเซิร์ฟเวอร์ไว้ใกล้กับกลุ่มผู้เล่น หากกลุ่มของคุณอยู่คนละฝั่งมหาสมุทร ย่อมมีใครบางคนต้องใช้เส้นทางที่ยาวกว่า และวิธีที่ยุติธรรมที่สุดคือการเลือกภูมิภาคที่มีผู้เล่นส่วนใหญ่อยู่

จงวัดค่าเส้นทางแทนการคาดเดา:

sudo apt install -y mtr-tiny
mtr -rwzc 100 203.0.113.10

ให้อ่านบรรทัดสุดท้ายก่อน บรรทัดนั้นคือเซิร์ฟเวอร์ปลายทาง ซึ่งค่า loss และ latency ของบรรทัดนี้เท่านั้นที่เป็นตัวตัดสินว่าเกมจะลื่นไหลเพียงใด หากพบค่า loss ใน hop ระหว่างทางแต่ hop สุดท้ายมีค่าปกติ มักเกิดจากการที่เราเตอร์ตัวนั้นทำ ICMP rate limiting เนื่องจากเราเตอร์จะลดลำดับความสำคัญของการตอบกลับ probe packets ในขณะที่ยังคงส่ง traffic จริงตามปกติ ควรให้ผู้เล่นแต่ละคนรันคำสั่งทดสอบไปยังเซิร์ฟเวอร์ เนื่องจากแต่ละคนใช้เส้นทางที่แตกต่างกัน

วิธีการคำนวณค่าต่ำสุดของการเดินทางไป-กลับ (round trip floor)

แสงในแก้วเคลื่อนที่ด้วยความเร็วประมาณสองในสามของความเร็วในสุญญากาศ ซึ่งคิดเป็นระยะทางใกล้เคียงกับ 200 กม. ต่อมิลลิวินาที การเดินทางไป-กลับต้องใช้ระยะทางเป็นสองเท่า ดังนั้นค่าต่ำสุดในหน่วยมิลลิวินาทีจึงเท่ากับระยะทางเที่ยวเดียวในหน่วยกิโลเมตรหารด้วย 100 ระยะทางจาก New York ไป London คือ 5,570 กม. เมื่อนำ 5570 หารด้วย 100 จะได้ 55.7 ms ตัวเลขที่วัดได้จริงทุกครั้งจะสูงกว่าค่านี้เสมอ เนื่องจากสายเคเบิลต้องวางตามแนวชายฝั่งและเราเตอร์ต้องใช้เวลาในการประมวลผล

เปิดเฉพาะพอร์ตที่เกมจำเป็นต้องใช้

เซิร์ฟเวอร์เกมต้องการพอร์ตเพียงหนึ่งหรือสองพอร์ตเท่านั้น ไม่จำเป็นต้องเปิดพอร์ตอื่น ค่าเริ่มต้นที่พบบ่อยมีดังนี้:

  • Minecraft Java Edition: TCP 25565
  • Minecraft Bedrock Edition: UDP 19132
  • Valheim: UDP 2456 และ UDP 2457
  • Palworld: UDP 8211
  • เกมที่ใช้เอนจิน Source และ Source 2 ของ Valve เช่น Counter-Strike 2: UDP 27015

โปรดตรวจสอบเอกสารประกอบของเกมนั้นๆ เนื่องจากหลายเกมจำเป็นต้องใช้พอร์ต query เพิ่มเติม ตัวอย่างที่ชัดเจนที่สุดคือ Valheim ซึ่งพอร์ต 2456 ใช้สำหรับรับส่งข้อมูลเกม ส่วนพอร์ต 2457 ใช้ตอบกลับ Steam server query เพื่อให้เซิร์ฟเวอร์ของคุณปรากฏในรายการค้นหา การเปิดพอร์ตเหล่านี้ด้วยโปรโตคอล TCP จะไม่เกิดผลใดๆ เนื่องจาก Valheim ใช้เฉพาะโปรโตคอล UDP เท่านั้น

อนุญาตการเชื่อมต่อ SSH ก่อนเปิดใช้งาน firewall มิฉะนั้นคุณจะถูกตัดสิทธิ์การเข้าถึงเซิร์ฟเวอร์ของตนเอง:

sudo ufw allow 22/tcp
sudo ufw allow 25565/tcp
sudo ufw enable
sudo ufw status verbose

ผู้ให้บริการหลายรายมี network firewall ในแผงควบคุมแยกต่างหากจาก firewall ภายในตัวเครื่อง หากพอร์ตถูกเปิดใน ufw แต่ถูกปิดที่แผงควบคุม การเชื่อมต่อจะยังคงถูกปฏิเสธ ซึ่งอาการที่พบจากภายนอกจะเหมือนกันทุกประการ ดังนั้นควรตรวจสอบทั้งสองจุดก่อนเริ่มแก้ไขไฟล์ config

การตรวจสอบพอร์ต TCP จากเครื่องอื่นสามารถทำได้ง่ายๆ ดังนี้:

sudo apt install -y netcat-openbsd
nc -vz 203.0.113.10 25565

โปรโตคอล UDP ไม่สามารถทดสอบด้วยวิธีดังกล่าวได้ เนื่องจากพอร์ต UDP ที่ปิดอยู่มักจะไม่ตอบสนองใดๆ ทำให้การส่ง probe ไปแล้วไม่ได้รับคำตอบไม่สามารถสรุปผลได้ ให้ตรวจสอบจากฝั่งเซิร์ฟเวอร์แทนโดยดูว่ามีกระบวนการของเกมผูกอยู่กับพอร์ตที่ต้องการหรือไม่:

sudo ss -lunp | grep 2456

ห้ามเปิดเผย RCON ซึ่งเป็นโปรโตคอลสำหรับรีโมทคอนโซลสู่สาธารณะโดยเด็ดขาด เนื่องจากเป็นการส่งรหัสผ่านผ่านการเชื่อมต่อแบบ plaintext โดยค่าเริ่มต้นจะใช้พอร์ต 25575 ให้ผูก (bind) ไว้กับ 127.0.0.1 และเข้าถึงผ่าน SSH tunnel เท่านั้น นอกจากนี้ควรเรียกใช้งานเซิร์ฟเวอร์เกมด้วยบัญชีผู้ใช้ที่ไม่มีสิทธิ์ระดับสูง (unprivileged user) เพื่อป้องกันไม่ให้บั๊กใน mod เข้าถึงส่วนอื่นๆ ของเครื่องได้ สิบนาทีแรกบน VPS เครื่องใหม่ ได้อธิบายเกี่ยวกับการจัดการบัญชีผู้ใช้และการรักษาความปลอดภัย SSH ซึ่งเป็นสิ่งที่ส่วนนี้ถือว่าคุณได้ดำเนินการเรียบร้อยแล้ว

การรันเซิร์ฟเวอร์ภายใต้ systemd เพื่อให้รีสตาร์ทอัตโนมัติ

เซิร์ฟเวอร์ที่เริ่มทำงานด้วยตนเองในเซสชัน SSH จะหยุดทำงานเมื่อปิดเซสชัน และจะไม่เริ่มทำงานใหม่หลังจากรีบูตระบบ systemd จะช่วยแก้ไขปัญหาทั้งสองอย่างนี้ โดย unit จะรันเซิร์ฟเวอร์ในฐานะผู้ใช้ minecraft ซึ่งเป็นเจ้าของ /opt/minecraft และไม่มีสิทธิ์เข้าถึงส่วนอื่น

sudo useradd --system --home-dir /opt/minecraft --shell /usr/sbin/nologin minecraft
sudo chown -R minecraft:minecraft /opt/minecraft

จากนั้นให้เขียน /etc/systemd/system/minecraft.service:

[Unit]
Description=Minecraft Java server
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=minecraft
WorkingDirectory=/opt/minecraft
ExecStart=/usr/bin/java -Xms4G -Xmx4G -jar server.jar nogui
Restart=on-failure
RestartSec=15
TimeoutStopSec=180

[Install]
WantedBy=multi-user.target

Restart=on-failure จะช่วยให้เซิร์ฟเวอร์กลับมาทำงานใหม่หลังจากเกิดการขัดข้อง และจะหยุดทำงานหลังจากปิดระบบอย่างถูกต้อง ซึ่งเป็นพฤติกรรมที่ต้องการ ส่วน Restart=always จะพยายามรีสตาร์ทเซิร์ฟเวอร์ทุกครั้งที่คุณสั่งหยุดทำงานโดยเจตนา ค่า TimeoutStopSec=180 มีความสำคัญมากกว่าที่เห็น systemctl stop จะส่งสัญญาณ SIGTERM ซึ่งเซิร์ฟเวอร์ Minecraft แบบมาตรฐานจะรับสัญญาณนี้เพื่อบันทึกข้อมูลโลกก่อนปิดตัวลง และเมื่อหมดเวลาที่กำหนด systemd จะส่งสัญญาณ SIGKILL แทน โลกขนาดใหญ่ที่ใช้เวลาบันทึกข้อมูลนานกว่าค่าเริ่มต้น 90 วินาทีอาจทำให้ข้อมูลที่ยังเขียนไม่เสร็จสูญหายไปเมื่อได้รับ SIGKILL

sudo systemctl daemon-reload
sudo systemctl enable --now minecraft
sudo journalctl -u minecraft -f

การเริ่มต้นที่สมบูรณ์จะจบลงด้วยบรรทัดที่คล้ายกับ Done (12.345s)! For help, type "help" หาก unit มีสถานะสลับไปมาระหว่าง activating และ failed ให้ดูที่ journalctl -u minecraft -n 50 เพื่อหาสาเหตุ ซึ่งมักเกิดจาก path ใน WorkingDirectory ไม่ถูกต้อง หรือมีการกำหนดขนาด heap ใหญ่เกินกว่าที่เครื่องจะรองรับ

บริการ systemd เช่นนี้จะรันโดยไม่มี interactive console เป็นค่าเริ่มต้น ดังนั้นควรวางแผนล่วงหน้า ให้ใช้ RCON บน localhost สำหรับการส่งคำสั่ง หรือรันเซิร์ฟเวอร์ภายในเซสชัน tmux ซึ่งเป็นวิธีเดียวกับที่ใช้ รักษาเซสชัน Claude Code ที่รันค้างไว้บน VPS ระหว่างการล็อกอิน

เกมที่แจกจ่ายผ่าน Steam จำเป็นต้องใช้ SteamCMD ก่อนดำเนินการขั้นตอนเหล่านี้ แพ็กเกจบน Ubuntu เป็นไบนารีแบบ 32 บิต ซึ่งเป็นเหตุผลว่าทำไมจึงต้องมีบรรทัดระบุสถาปัตยกรรม หากข้ามบรรทัดนั้นไป apt จะรายงานว่าไม่พบตัวเลือกสำหรับการติดตั้ง:

sudo add-apt-repository multiverse
sudo dpkg --add-architecture i386
sudo apt update
sudo apt install -y steamcmd

เซิร์ฟเวอร์เกมบางตัวมีการใช้หน่วยความจำเพิ่มขึ้นเรื่อยๆ ตามระยะเวลาที่รัน การตั้งเวลาให้รีสตาร์ทในช่วงเวลาที่มีผู้ใช้งานน้อยเป็นวิธีแก้ปัญหาที่ยอมรับได้มากกว่าการแก้ไขที่ตัวซอฟต์แวร์เอง การใช้ systemd timer เพื่อเรียก systemctl restart นั้นเข้าใจได้ง่ายกว่าการใช้ cron entry เนื่องจาก systemctl list-timers จะแสดงให้เห็นอย่างชัดเจนว่าการทำงานครั้งถัดไปจะเกิดขึ้นเมื่อใด

การสำรองข้อมูลโลกของเกมตามกำหนดเวลา

ทุกอย่างบนเซิร์ฟเวอร์เกมสามารถหามาทดแทนได้ ยกเว้นไดเรกทอรีของโลก (world directory) และข้อมูลผู้เล่น การติดตั้งเกมใหม่ใช้เวลาเพียงไม่กี่นาที แต่การสร้างสิ่งที่กลุ่มของคุณสร้างขึ้นมาใหม่นั้นต้องใช้เวลาหลายเดือน

การสำรองข้อมูลที่ปลอดภัยคือการสำรองข้อมูลในขณะที่ไม่มีการเขียนข้อมูลใดๆ ลงดิสก์ การหยุดเซิร์ฟเวอร์เป็นเวลาหนึ่งนาทีเป็นวิธีที่ง่ายที่สุดในการรับประกันความปลอดภัยนี้:

sudo systemctl stop minecraft
sudo tar czf /var/backups/mc-$(date +%F).tgz -C /opt/minecraft world world_nether world_the_end
sudo systemctl start minecraft

หากการหยุดเซิร์ฟเวอร์ทุกคืนเป็นสิ่งที่ยอมรับไม่ได้ ให้ใช้วิธีสั่ง flush ข้อมูลโลกแทน ในคอนโซลของ Minecraft คำสั่ง save-off จะหยุดการบันทึกอัตโนมัติ (autosave), save-all flush จะเขียนข้อมูลที่ค้างอยู่ทั้งหมดลงดิสก์ และ save-on จะเปิดการบันทึกอัตโนมัติอีกครั้งหลังจากคัดลอกเสร็จสิ้น การคัดลอกโลกในขณะที่เซิร์ฟเวอร์กำลังเขียนข้อมูลอยู่อาจทำให้ได้ไฟล์ region ที่เขียนไม่สมบูรณ์ ซึ่งคุณจะไม่ทราบจนกว่าจะถึงวันที่คุณต้องการกู้คืนข้อมูลนั้น

ควรเก็บสำเนาไว้นอกเครื่องอย่างน้อยหนึ่งชุด การสำรองข้อมูลไว้บนดิสก์ลูกเดียวกันจะไม่ช่วยหากดิสก์เสียหาย และ snapshot ของผู้ให้บริการเป็นเพียงความสะดวกสบายมากกว่าจะเป็นการสำรองข้อมูลที่แท้จริง เพราะมันอยู่ในบัญชีเดียวกับที่คุณอาจสูญเสียการเข้าถึงได้ การสำรองข้อมูลด้วย restic ไปยังพื้นที่จัดเก็บภายนอกตามกำหนดเวลา จะช่วยจัดการเรื่องระยะเวลาการเก็บรักษา (retention) และการลดความซ้ำซ้อนของข้อมูล (deduplication) ทำให้การสำรองข้อมูลโลกทุกคืนตลอดทั้งเดือนไม่ทำให้พื้นที่จัดเก็บของคุณเต็ม

จากนั้นให้ลองกู้คืนข้อมูลดูสักครั้ง การสำรองข้อมูลที่คุณไม่เคยทดสอบกู้คืนถือเป็นการคาดเดาเท่านั้น ให้แตกไฟล์ที่สำรองไว้เมื่อคืนลงในไดเรกทอรีสำรอง ชี้เซิร์ฟเวอร์ทดสอบไปที่ไดเรกทอรีนั้น แล้วตรวจสอบว่าโลกของเกมโหลดได้ปกติและสิ่งก่อสร้างต่างๆ ยังคงอยู่ครบถ้วนตามเดิม

ตรวจสอบให้แน่ใจก่อนตัดสินใจเลือกใช้

ให้เลือกซื้อแบบรายเดือนแทนรายปี และทดสอบกับผู้เล่นจริงเป็นเวลาหนึ่งช่วงเย็น ให้รันตัวเลข sysbench แบบ single thread จากนั้นให้ผู้เล่นทุกคนรัน mtr ไปยังเซิร์ฟเวอร์ ขั้นตอนการทำ benchmark VPS ฉบับเต็ม จะอธิบายการใช้เครื่องมือเหล่านี้และแสดงให้เห็นว่าผลลัพธ์ที่ไม่ดีเป็นอย่างไร ส่วน ต้นทุนที่แท้จริงของ VPS ต่อเดือน จะช่วยให้คุณตรวจสอบได้ว่าคุณกำลังจ่ายเงินเพื่อทรัพยากรที่เป็นคอขวดของเซิร์ฟเวอร์จริงๆ ไม่ใช่จ่ายตามตัวเลขที่พิมพ์ไว้ตัวใหญ่ที่สุดบนหน้าแผนบริการ

มีบทความอีกสองหัวข้อที่ต่อยอดจากเนื้อหานี้ การสร้างเซิร์ฟเวอร์ Minecraft บน VPS เป็นขั้นตอนการปฏิบัติจริงสำหรับทุกสิ่งที่กล่าวมาข้างต้น โดยใช้เกมที่คนส่วนใหญ่เริ่มต้นใช้งาน และ รายการสิ่งที่ VPS สามารถรันได้เพิ่มเติม เป็นบทความที่น่าอ่านหากคุณต้องการให้เซิร์ฟเวอร์ทำประโยชน์อย่างอื่นในช่วงเวลาที่ไม่ได้เปิดให้เล่นเกม

FAQ

ฉันสามารถเล่นเกมบน VPS แทนการซื้อคอมพิวเตอร์สำหรับเล่นเกมได้หรือไม่?

ไม่ได้ VPS มาตรฐานไม่มี GPU มีเพียง virtual display adapter สำหรับ console ของผู้ให้บริการเท่านั้น ดังนั้นเมื่อติดตั้ง desktop แล้ว glxinfo -B จะรายงานว่าเป็น software renderer llvmpipe และเกม 3D จะทำงานได้เพียงไม่กี่เฟรมต่อวินาที แม้จะมีการติดตั้ง GPU เพิ่มเติม การเล่นผ่านรีโมทจะเพิ่มภาระการเข้ารหัสและถอดรหัสวิดีโอในทุกเฟรม ซึ่งโปรโตคอลอย่าง RDP และ VNC ไม่ได้ถูกออกแบบมาเพื่อการนี้ VPS มีไว้สำหรับโฮสต์ dedicated server ที่กลุ่มของคุณเข้ามาเชื่อมต่อเท่านั้น หากคุณต้องการเล่นเกม ให้เช่าเวลาใช้งาน GPU หรือใช้บริการ cloud gaming แทน

เซิร์ฟเวอร์เกมต้องการ CPU กี่คอร์?

สำหรับเกมส่วนใหญ่ CPU ที่มี 2 คอร์ความเร็วสูงนั้นดีกว่า 8 คอร์ความเร็วต่ำ เพราะการจำลองโลกของเกมทำงานบน main thread เพียงเธรดเดียว และคอร์ที่เพิ่มเข้ามาไม่สามารถช่วยให้เธรดนั้นทำงานได้ทันตามกำหนดเวลา 50 ms ให้เปรียบเทียบแผนบริการต่างๆ ด้วย sysbench cpu --cpu-max-prime=20000 --threads=1 run และดูค่า events per second คอร์ที่เพิ่มขึ้นจะคุ้มค่าเมื่อคุณรันเซิร์ฟเวอร์ที่สองหรือฐานข้อมูลบนเครื่องเดียวกัน เนื่องจากภาระงานเหล่านั้นจะสามารถทำงานได้โดยไม่แย่งเวลาประมวลผลจาก tick thread

เซิร์ฟเวอร์ Minecraft ต้องการ RAM เท่าไหร่?

สำหรับโลกแบบ vanilla ที่มีผู้เล่นประมาณ 10 คน ควรใช้ heap ประมาณ 2 GB และสำหรับ modpack ขนาดใหญ่ที่มีจำนวนผู้เล่นเท่ากันควรใช้ 8 GB ให้ตั้งค่า -Xms และ -Xmx ให้มีค่าเท่ากัน และเหลือ RAM ไว้ให้ระบบปฏิบัติการประมาณ 1 GB ถึง 2 GB เนื่องจาก JVM มีการใช้หน่วยความจำนอกเหนือจาก heap และ kernel จำเป็นต้องใช้ page cache หากตั้งค่า heap ใหญ่กว่าหน่วยความจำที่มีในเครื่อง กระบวนการจะถูก kernel สั่งยุติการทำงาน ซึ่งจะปรากฏใน dmesg ว่าเป็นข้อความ out of memory แทนที่จะเป็นข้อผิดพลาดของ Java

ทำไมผู้เล่นถึงพบอาการแล็กทั้งที่ CPU และ RAM ของเซิร์ฟเวอร์ยังเหลือ?

มีสาเหตุสองประการที่ตรงกับอาการนี้ ให้ตรวจสอบ log ของเซิร์ฟเวอร์เพื่อหา Can't keep up! Is the server overloaded? ซึ่งหมายความว่า main thread ไม่สามารถประมวลผล tick ได้ทันภายในงบเวลา 50 ms ในขณะที่คอร์อื่นยังว่างอยู่ สำหรับ Paper สามารถปิดคำเตือนนี้ได้ด้วย warn-on-overload: false ใน bukkit.yml ดังนั้นให้ตรวจสอบว่ายังเปิดใช้งานอยู่ก่อนที่จะเชื่อว่าไม่มีปัญหา หากเปิดใช้งานคำเตือนแล้วแต่ไม่พบข้อความ ให้ตรวจสอบเส้นทางเครือข่าย: ให้ผู้เล่นแต่ละคนรัน mtr -rwzc 100 203.0.113.10 ไปยังที่อยู่เซิร์ฟเวอร์ของคุณแล้วดูบรรทัดสุดท้าย นอกจากนี้ให้ตรวจสอบคอลัมน์ st ใน vmstat 1 หากค่า steal time สูงกว่าไม่กี่เปอร์เซ็นต์ แสดงว่าโฮสต์มีการขายทรัพยากรเกินจริง (oversold) ทำให้ CPU ที่คุณเห็นว่าว่างอยู่นั้นไม่สามารถใช้งานได้จริง

ฉันต้องเปิดพอร์ตใดบ้างสำหรับเซิร์ฟเวอร์เกม?

เปิดเฉพาะพอร์ตของเกมนั้นๆ และ SSH เท่านั้น Minecraft Java ใช้ TCP 25565, Minecraft Bedrock ใช้ UDP 19132, Valheim ใช้ UDP 2456 และ 2457 และ Palworld ใช้ UDP 8211 ให้เพิ่มกฎสำหรับ SSH ก่อนรัน ufw enable มิฉะนั้นคุณจะสูญเสียการเข้าถึงเครื่อง โปรดจำไว้ว่าผู้ให้บริการหลายรายมี firewall ชั้นที่สองในแผงควบคุม ซึ่งต้องเปิดพอร์ตในนั้นด้วยเช่นกัน ห้ามเปิด RCON บนพอร์ต 25575 สู่สาธารณะเด็ดขาด เพราะเป็นการส่งรหัสผ่านแบบ plaintext