![](/_astro/b91de7554435578bd6a01e668a0246658c3c0f77cb976e9db814f6dfc36c0ed0-cover.DQPTP_zX.webp)
Table of contents
TL;DR (โม้ก่อน.. ข้ามได้)
เรื่องมีอยู่ว่าผมมี Dedicated Server ที่ว่างเว้นอยู่หลังจากไม่ได้ทำ FiveM, RedM, etc. เลยขอเอามารันเซิร์ฟเวอร์เกม Palworld เล่นกับเพื่อน เพราะเห็นว่าเป็นเกมที่กระแสมาแรง และอยากจะเล่นกันเฉพาะกับกลุ่มเพื่อน ไม่อยากจะเข้าไป Official Server เพราะเคยเจอประสบการณ์ไม่ดีจากบางเกม (ไม่ขอยุ่งเรื่องดราม่ากับเกมข้างเคียงนะครับ ผมก็เป็นแฟนบอยของอีกเกมด้วยเหมือนกัน)
เกมบน Steam นั้นทำ Dedicated Server ไม่ยากครับ ทำได้หลายวิธี SteamCmd (ได้ทั้ง Win, Linux), WindowsGSM, LinuxGSM ในกรณีนี้ผมเปิดผ่าน SteamCmd เพราะว่าง่ายที่สุดแล้ว พิมพ์ command ไม่กี่ตัวก็เปิดได้เลย ขี้เกียจจนเขียน bat ให้เช็คอัพเดทแล้วเปิดไปเลยทีเดียว
ในครั้งแรกที่เปิดกับเพื่อน ก็ไม่ได้คิดว่าตัวเกมจะมีปัญหาอะไร ถึงแม้ว่าช่วงแรกไปไล่อ่านรีวิวเกมมีการพูดถึงประวัติของ Developer ว่าขยันออกเกมเป็น Early Access แล้วดองงานทิ้งไว้ก็ตาม
เอาง่ายๆคือรันเซิร์ฟเสร็จแล้วก็เล่นเลยอะครับ ไม่ได้มานั่งมอนิเตอร์อะไรเลย (อย่าหาทำ เป็นนิสัยในการ develop ที่ไม่ดีเลย ฮ่าๆๆ)
เปิดไว้แบบนั้นจนเวลาผ่านไปเกือบ 2 วัน (ใช่ครับอ่านไม่ผิด) ในเกมเริ่มมีอาการกระตุกจนเริ่มสังเกตได้ ก็เลยคิดว่าจะ restart สักหน่อย ก่อนทำการ restart โดยปกติผมจะทำการเช็คดูว่า ก่อนปิดมันกิน resource เครื่องอยู่ที่ประมาณไหน เพื่อเป็นตัวเปรียบเทียบไปในตัว
ผลก็คือ Process ของ PalServer ซดแรมไป 30GB จาก 32GB
ช็อคเลยทีนี้ ทำไมมันกินเยอะขนาดนี้เนี่ย!? เก็บความตกใจไว้ก่อน ทำการแบ็คอัพเซฟเกมไว้ก่อนเผื่อมีปัญหาจะได้ restore กลับมาได้ จากนั้นเปิดต่อโดยที่รอบนี้มอนิเตอร์เครื่องเซิร์ฟเวอร์ไปด้วย
สิ่งที่สังเกตได้ (ก่อน v.1.3.0)
แจ้งก่อนว่าเซิร์ฟเวอร์ของผมรันอยู่บน Windows server 2019 เป็น Dedicate แยกต่างหาก ไม่ได้เป็น Share Server ที่ซอยปล่อยเช่ากัน (ได้มาเพราะไปไถหัวหน้ามาครับ อิอิ) แรมที่มีคือ 32GB
- เมื่อรัน server ของ Palword ใหม่ๆแรมจะไต่ขึ้นไปอยู่ที่ประมาณ 7-8 GB
- จากนั้นจะมีการใช้แรมเพิ่มขึ้นไปเรื่อยๆไม่หยุด (Memory Leaked)
ตอนนั้นมี Developer ทำการ patch แก้ไขโค้ดเพื่อลดการกินแรมลง ใช้ได้ผลพอสมควร ก่อนที่ตัวเกมหลักจะปล่อยอัพเดท v.1.3.0 ตามมาภายหลัง
- ทดลอง Restart ช่วงที่ไม่มีคนเล่นเลย (เพื่อนนอนกันหมด) พบว่า อัตราการบริโภคจะช้า หรือ คงที่
- ทุกครั้งที่มี Raid Event จะมีการกินแรมที่เพิ่มขึ้น (ในฝั่ง support discord คุยกันว่าปิดไปก่อน) **ตอนแรกเปิดไว้ เพราะจะได้มีอะไรทำ แต่มอนฯก็เกิดแล้วบั๊กในกำแพง ไม่ยอมวิ่งมาที่บ้าน เลยปิดดีกว่า
- หากมีการเปิดแผนที่ และ ลง Dungeon การใช้แรมก็จะเพิ่มสูงอย่างรวดเร็วจนสังเกตได้ (ข้อนี้ คุยกับคนที่เปิด Dedicated ท่านอื่นๆใน official discord ก็พบตรงกัน)
- หากมีการ config ให้ pal ที่บ้านทำงานตลอดเวลาก็กินแรมมากขึ้น แต่ช้ากว่าข้ออื่นๆทั้งหมด (อันนี้ผมเปิดไว้ เพราะถ้าปิดก็ไม่ต่างจากเปิด multi player ปกติสิ)
โดยส่วนตัวไม่พบปัญหากินแรมจนเกิดการ crash ตามที่พบในรีพอร์ท หลายๆคนเจอปัญหานี้ ฝั่ง Linux เองก็เช่นกัน เท่าที่สอบถามมา ส่วนใหญ่ที่พบจะเป็น Share host หรือไม่ก็รันผ่าน docker ที่จะพบอาการกินแรมจน out of Memory จนพังไปทั้ง instance ซึ่งน่ากลัวมาก ถ้าหากลากกันพังไปทั้งเครื่องที่มีหลาย instance รันอยู่พร้อมกัน
Update v.1.4.0
- อาการ Memory Leaked ได้รับการแก้ไขแต่ยังไม่ทั้งหมด (เมื่อมีการเปิด Raid, ลง Dungeon ก็ยังเป็นอยู่ เพียงแต่ใช้เวลานานมากขึ้นกว่าแรมจะหมดถัง)
- หากเซิร์ฟเวอร์อยู่ในสถานะคงที่ เริ่มสังเกตว่ามีการคืนแรมกลับเล็กน้อยในบางช่วง (ในกรณีที่ไม่มีคนวิ่งเปิด map, ลง dungeon)
ผมขอพูดถึงในฝั่ง Server อย่างเดียวก่อน เพราะฝั่งผู้เล่นมีการแก้บั๊กไปพอสมควรแล้ว เรื่อง Pal ชาร์จทะลุกำแพงก็ไม่เจอแล้ว ก่อนหน้านี้ลงดันบอส ชาร์จพุ่งเข้ากำแพง งงกันทั้งปาร์ตี้เลยทีเดียว
อย่างไรก็ตาม ปัจจุบันปัญหาใหญ่ตรงนี้ก็ยังไม่ได้รับการแก้ไข จนกระทั้งมีข่าวล่าสุดว่า Official Server นั้นค่าใช้จ่ายพุ่งสูงมากถึง 70 ล้านเยน (16.72 ล้านบาท ค่าเงิน 1 JPY/ 0.24 THB ณ วันเขียน) ไปแล้ว ซึ่งโดยส่วนตัวมองว่า ปัญหาอาจจะเกิดจากเรื่อง Memory Leaked นี่ด้วย ผมเลยเอามาเขียนโพสต์นี้
![Blog Image](/_astro/20ee27d0104b12df2f3c96bdfe8230778d099d44183e7c3d24a458529b7a67ed.DZt2cBH__Z1nB5tL.webp)
Update 4/02/2024 ผมไปเจอข้อมูลเพิ่มเติมว่า ในบรรดา Server จำนวน 1000 กว่า server นั้น จัดการผ่าน K8s (Kubernetes) โดยชายเพียงคนเดียว 😱 ซึ่งก็เป็นไปตามที่คาดการไว้ในเรื่องของการ auto scaling ทำให้ค่าใช้จ่ายพอกพูนไปเรื่อยๆ
![Blog Image](/_astro/c60eb943664f2b54db3bd9138159bfbc70f3f901455dd15e2cecf1ed881f4a2a.CuHidPpY_1COrYw.webp)
ส่วนตัวคาดว่าการที่ได้รับคำสั่งมาว่า server ต้องห้ามล่ม เลยทำให้เลือกวางระบบอยู่บน Cloud server และใช้งานแบบ Auto Scaling และด้วยความที่ไม่ได้มีการ optimizing ที่ดีพอ ทำให้ Ram Leaked เมื่อ Ram usage ทะลุเพดานระบบ cloud จะทำการขยาย Memory base ขึ้นไปเรื่อยๆ เพื่อเลี้ยงไม่ให้ระบบล่ม และเมื่อขาดการมอนิเตอร์ (แบบผมนีี่ล่ะ ฮ่าๆๆ) ก็ทำให้เมื่อบิลค่า cloud server ออกมาตอนสิ้นเดือนเป็นแบบที่เห็น
ขอบคุณทุกท่านที่สละเวลาอันมีค่าอ่านโพสต์นี้จนจบนะครับ หากมีอัพเดทผมจะทำการอัพเดทในโพสต์นี้ต่อไปครับ 🙏🏻