FiveM Server CPU สูง แก้อย่างไร หา Script ตัวปัญหาให้เจอ

August 26, 2026

FiveM Server CPU สูงควรแก้ด้วยการหา Resource หรือ Thread ที่เป็น Bottleneck ก่อน ไม่ใช่รีบเพิ่มสเปกเครื่องทันที เพราะ CPU สูงสามารถเกิดจาก Script เพียงตัวเดียว, Loop ที่ทำงานถี่เกินไป, SQL Query ช้า, Event Spam, Entity จำนวนมาก หรือ Resource ที่ Scale ไม่ดีเมื่อผู้เล่นเพิ่มขึ้น

วิธีที่ถูกต้องคือ

CPU สูง
↓
ตรวจ txAdmin / Server Threads
↓
ดู Hitch Warning
↓
Capture Profiler
↓
หา Resource ที่ Spike
↓
ลงไปถึง Function / Code
↓
ตรวจ SQL / Loop / Event / Entity
↓
แก้ Root Cause
↓
Profile ซ้ำ

FiveM มีเครื่องมือสำคัญอย่าง Profiler สำหรับหา Resource และ Code ที่ทำให้ Server Hitch ขณะที่ txAdmin สามารถดู CPU/RAM และกราฟ Performance ของ Server Threads เทียบกับจำนวนผู้เล่นได้

สำหรับ FiveM Enhanced ยังเพิ่ม Perfetto Profiler และ Metrics จำนวนมาก ทำให้สามารถตรวจ Main Thread, Network, Sync, Lua/JavaScript Memory, OneSync Entities และข้อมูลระบบได้ละเอียดขึ้น

บทความนี้จาก comsiam จะสอนวิธีไล่หา FiveM Script กิน CPU แบบเป็นขั้นตอน ตั้งแต่ระดับ Server จนถึงบรรทัด Code

① CPU สูงแปลว่า FiveM Server มีปัญหาเสมอไหม?

ไม่เสมอ

CPU Usage สูงชั่วคราวสามารถเกิดได้ตอน

Server Start
Resource Start
ผู้เล่นจำนวนมาก Join พร้อมกัน
Event ใหญ่
Database Loading
Asset Processing

สิ่งที่ต้องระวังคือ CPU สูงต่อเนื่องหรือเกิด Spike จน Gameplay มีอาการ

Delay
Hitch
Inventory ช้า
Garage หน่วง
Player กระตุก

② CPU 100% ต้องดูอะไรเพิ่มเติม?

อย่าดู Total CPU เพียงตัวเดียว

ต้องดู

CPU ต่อ Core
Server Thread Performance
Player Count
Resource Activity
Hitch Warning

FiveM Workload บางส่วนสามารถติด Bottleneck ที่ Thread สำคัญ แม้ Total CPU ของเครื่องยังไม่เต็มทุก Core

③ CPU รวม 40% แต่ Server ยัง Lag ได้ไหม?

ได้

สมมติเครื่องมีหลาย Core

แต่ Thread สำคัญหนึ่งตัวเต็ม

Core 1 → 100%
Core 2 → 20%
Core 3 → 15%
Core 4 → 25%

Total CPU อาจดูไม่สูงมาก

แต่ Server ยัง Hitch ได้

ดังนั้นต้องดู Thread Performance ไม่ใช่ Task Manager อย่างเดียว

④ ใช้ txAdmin ดู CPU ก่อน

txAdmin มี Monitoring สำหรับ

Server CPU
RAM
Server Threads Performance
Player Count
Live Console

จึงเป็นจุดเริ่มต้นที่ดี

ลองเปรียบเทียบ

ผู้เล่น 30 คน → CPU 20%
ผู้เล่น 80 คน → CPU 35%
ผู้เล่น 120 คน → CPU 75%

ถ้า CPU เพิ่มผิดปกติเมื่อ Player ถึงระดับหนึ่ง แสดงว่าอาจมี Scaling Problem

⑤ ดูกราฟ Player Count คู่กับ CPU

นี่สำคัญมาก

ถ้า CPU เพิ่มสัมพันธ์กับ Player Count อาจเกิดจาก

Player Loop
Player Data
Inventory
Voice
Database
Entity
OneSync

แต่ถ้า CPU Spike แม้ Server ว่าง อาจเป็น Resource Background Task

⑥ Hitch Warning คืออะไร?

Hitch Warning คือสัญญาณว่า Thread หรือ Resource ใช้เวลาประมวลผลนานผิดปกติ

Cfx.re ระบุว่าสาเหตุสามารถเป็น

SQL Query ช้า
Loop ที่ไม่ Optimize
Script Execution ที่ใช้เวลานาน

ถ้า CPU สูงพร้อม Hitch Warning ให้เริ่มจาก Profiler

⑦ อย่า Ignore Hitch Warning ที่เกิดซ้ำ

Hitch หนึ่งครั้งตอน Server Startup อาจไม่สำคัญ

แต่ถ้า Console ขึ้น

server thread hitch warning

ซ้ำ ๆ ระหว่าง Gameplay ต้องตรวจ

โดยเฉพาะเมื่อ Player รู้สึกหน่วงพร้อมกัน

⑧ ใช้ FiveM Profiler

Profiler ถูกสร้างมาเพื่อหา

Resource → Thread → Function → Code

ที่ใช้เวลามาก

สามารถใช้ได้ทั้ง

Server-side
Client-side

แต่ในกรณี CPU Server สูง ให้ Capture จาก Server Console

⑨ วิธีเริ่ม Profiler

ตัวอย่าง

profiler record 500

จากนั้นตรวจสถานะ

profiler status

เมื่อ Capture เสร็จจึงนำ Profile มาวิเคราะห์

⑩ ควร Profile นานแค่ไหน?

ให้ Capture ครอบคลุมช่วงที่เกิดปัญหา

ถ้า Hitch เกิดทุก 5 วินาที ควร Capture ให้ผ่านเหตุการณ์นั้นหลายครั้ง

ถ้า CPU สูงเฉพาะตอน

Player เข้า Garage
Inventory Save
Payday

ให้ Capture ช่วงนั้น

⑪ อย่า Profile ตอน Server ว่าง

ถ้าปัญหาเกิดตอน 150 Players

การ Profile ตอนมี 5 Players อาจไม่พบอะไร

ควร Capture ตอนใกล้ Peak Load หรือจำลอง Workload เดิมบน Staging

⑫ Enhanced ใช้ Perfetto Profiler

FiveM Enhanced เปลี่ยน Profiler Backend เป็น Perfetto

คำสั่งหลักยังใช้แนวทาง เช่น

profiler record <duration>
profiler save <filename>.json

จากนั้นเปิด Trace เพื่อดู Timeline ได้ละเอียด

⑬ Profiler ต้องดูอะไรเป็นอันดับแรก?

มองหา

CPU Time Spike
Long Tick
Resource ที่กินเวลามาก
Function ทำงานซ้ำถี่
Script ที่สัมพันธ์กับ Hitch

อย่ามองเพียง Resource ที่มีชื่อใหญ่หรือ Framework หลัก

⑭ Framework ไม่ใช่ต้นเหตุเสมอ

Server ใช้ ESX แล้ว CPU สูงไม่ได้แปลว่า

ESX = ตัวปัญหา

อาจเป็น Third-party Resource เช่น

custom-police
custom-garage
phone
housing
vehicle-system

ที่พึ่ง Framework

ต้อง Profile ก่อนตัดสิน

⑮ Script ตัวเดียวทำ CPU สูงทั้ง Server ได้ไหม?

ได้

โดยเฉพาะ Script ที่มี

while true do
    Wait(0)
    -- งานหนักจำนวนมาก
end

หรือทำ Player/Entity Scan จำนวนมาก

Resource เพียงตัวเดียวสามารถเป็น Bottleneck ของ Server ทั้งระบบได้

⑯ Wait(0) คืออะไร?

หมายถึงให้ Loop กลับมาทำงานเร็วมาก

เหมาะกับบาง Client Logic เช่นการอ่าน Input

แต่ Server-side Logic ส่วนใหญ่ไม่ควรใช้ Wait(0) โดยไม่มีเหตุผลชัดเจน

⑰ ตัวอย่าง Loop ที่ควรตรวจ

CreateThread(function()
    while true do
        Wait(0)

        for _, playerId in ipairs(GetPlayers()) do
            -- process
        end
    end
end)

เมื่อมี Player 200 คน Logic นี้จะ Loop ผ่าน 200 Players ถี่มาก

หากทำ SQL หรือ Calculation เพิ่มข้างในยิ่งหนัก

⑱ เพิ่ม Wait ช่วยได้หรือไม่?

ถ้า Logic ไม่ต้อง Real-time ทุก Tick ช่วยได้มาก

จาก

Wait(0)

เป็น

Wait(500)

ลด Frequency ลงอย่างมหาศาล

แต่ต้องเลือก Interval ตาม Gameplay

⑲ งานประเภทไหนไม่ต้องรันทุก Frame?

เช่น

ตรวจ Payday
Update Database
Cleanup Entities
Check AFK
Save Player
Refresh Cache

งานเหล่านี้มักไม่ต้องทำทุก Frame

⑳ Adaptive Interval ใช้ได้ไหม?

ได้

เช่น

ไม่มี Player ใช้ Feature
→ Check ทุก 5 วินาที

มี Player ใช้
→ Check ทุก 500 ms

ช่วยลด CPU ในช่วง Idle

㉑ Player Loop ต้องระวัง

ทุกครั้งที่เขียน

GetPlayers()

แล้ว Loop ทั้งหมด ให้ถามว่า

จำเป็นต้องทำกับผู้เล่นทุกคนไหม?

บาง Logic สามารถใช้ Event เมื่อ Player State เปลี่ยนแทนได้

㉒ O(n) คืออะไร?

ถ้ามี Player n คน และ Script Loop หนึ่งครั้งต่อ Player

จำนวนงานเพิ่มตาม Player

ตัวอย่าง

50 Players → 50 Operations
500 Players → 500 Operations

ยังอาจ Scale ได้หาก Frequency ต่ำและงานเบา

㉓ O(n²) อันตรายกว่า

ถ้า Player ทุกคนถูกเปรียบเทียบกับ Player ทุกคน

50 → 2,500
100 → 10,000
500 → 250,000
1,000 → 1,000,000

Operations ต่อรอบ

ถ้าทำหลายครั้งต่อวินาที CPU สามารถพุ่งอย่างรวดเร็ว

㉔ Distance Check ทุก Player กับทุก Player ควรระวัง

ตัวอย่างระบบที่อาจใช้ Pattern นี้

Nearby Players
Police Detection
Proximity System
Custom Voice Logic

ควรใช้ OneSync Scope, Zones หรือ Server Architecture ที่เหมาะสมแทน Global Comparison เมื่อทำได้

㉕ Entity Scan ก็ทำ CPU สูงได้

Script บางตัว Scan

Vehicles
Peds
Objects

ทั้ง Server ซ้ำ ๆ

เช่น

GetAllVehicles
→ Loop ทุกคัน
→ Check ทุกวินาที

เมื่อ Entity เพิ่มเป็นหลายพันตัว Cost จะสูงขึ้น

㉖ Cleanup Script เองก็ทำ Server หนักได้

Ironically Script ที่ตั้งใจ “Optimize Server” บางตัวกลับ Scan Entity ทั้งโลกถี่เกินไป

ตัวอย่าง

ทุก 100 ms
→ Scan รถทั้งหมด
→ Check ทุกคัน

อาจสร้าง CPU Load มากกว่ารถที่ต้องการลบเสียอีก

㉗ Cleanup ควรทำเป็น Interval

เช่น

ทุก 5 นาที
→ ตรวจรถที่ไม่มีผู้เล่น

หรือใช้ Entity Lifecycle ตั้งแต่ Resource สร้าง Entity

ดีกว่า Scan ทุก Entity ถี่ ๆ โดยไม่มีเหตุผล

㉘ Entity Leak ทำ CPU สูงตามเวลาได้

ถ้า Resource Spawn Object แล้วไม่ Delete

จำนวน Entity อาจเพิ่ม

เปิดใหม่ → 2,000
6 ชั่วโมง → 5,000
12 ชั่วโมง → 10,000

OneSync และ Resource ที่ Iterate Entity จะหนักขึ้นตามไปด้วย

㉙ CPU สูงขึ้นเรื่อย ๆ หลังเปิด Server นาน ให้ตรวจ Entity Count

โดยเฉพาะ

Vehicles
Job Props
NPC
Mission Objects

ถ้า Restart แล้ว CPU ลดมาก อาจมี Entity/State สะสม

㉚ Database Query ทำ CPU Server สูงได้หรือไม่?

ได้ทางอ้อมและทำ Hitch ได้โดยตรง

Cfx.re ยก Slow SQL Query เป็นสาเหตุหนึ่งของ Hitch

Resource ที่รอ Query หรือประมวลผล Result ใหญ่มากสามารถทำให้ Server Tick ช้าลง

㉛ หา Slow Query ใน Resource สำคัญ

ตรวจ

Character
Inventory
Garage
Phone
Housing
Banking
Logs

โดยเฉพาะ Query ที่ทำบ่อยมาก

㉜ ห้าม Query Database ทุก Tick

ตัวอย่างที่ไม่ควรมี

while true do
    Wait(0)
    MySQL.query(...)
end

นี่เป็นปัญหาร้ายแรง

Database ไม่ควรถูก Poll แบบ Frame-based

㉝ Query ต่อ Player ก็ต้องระวัง

สมมติทุก 10 วินาทีทำ

300 Players
×
5 Queries
=
1,500 Queries

พร้อมกัน

อาจสร้าง Burst Load สูง

ควรพิจารณา

Cache
Batch
Event-driven Update

㉞ SELECT * ใช้ข้อมูลมากเกินจำเป็น

ถ้าต้องการเพียง ID กับ Balance

อย่าดึง Column จำนวนมาก

ตัวอย่าง

SELECT identifier, money
FROM users
WHERE identifier = ?

ช่วยลด Data Processing

㉟ Index ช่วย CPU/Database ได้

Query ที่ Search Column ไม่มี Index บน Table ใหญ่อาจต้อง Scan ข้อมูลจำนวนมาก

ตรวจ Column เช่น

identifier
citizenid
plate
owner

ตาม Query จริง

㊱ Cache ช่วยลด CPU และ SQL ได้

ข้อมูลที่ Static เช่น

Items
Vehicles Definitions
Jobs
Shops Config

สามารถ Load ครั้งเดียวและ Cache

แทนการ Query ทุก Interaction

㊲ Cache ใหญ่เกินก็มีปัญหา

อย่า Cache ทุกอย่างตลอดอายุ Server

ต้องมี

Invalidation
Cleanup
Expiry

ไม่เช่นนั้น RAM จะสูงและ Garbage Collection อาจมี Workload เพิ่ม

㊳ Lua Table ใหญ่เกินไปต้องระวัง

เช่นเก็บข้อมูล Player เก่าทุกคนโดยไม่ Remove

Players[source] = data

แต่ไม่มี Cleanup ตอน playerDropped

Server เปิดนาน Data จะสะสม

㊴ JavaScript Map/Array ก็เหมือนกัน

ตัวอย่าง

const players = new Map();

ต้อง Delete ตอน Player ออกถ้าข้อมูลไม่จำเป็น

Runtime ใหม่ไม่ได้แก้ Logical Memory Leak ให้อัตโนมัติ

㊵ Error Spam ทำ CPU สูงได้

Resource ที่ Error หลายร้อยครั้งต่อวินาทีสร้างทั้ง

Script Work
Console Output
Log I/O

ตรวจ Console ว่ามี Error ซ้ำหรือไม่

㊶ Debug Print ก็สร้าง Load ได้

หลีกเลี่ยง

print(json.encode(playerData))

ทุก Tick

โดยเฉพาะ Data ใหญ่

Production ควรมี Debug Mode

㊷ Event Spam ต้องตรวจ

เช่น

TriggerServerEvent('updatePosition', coords)

ทุก Frame

จาก Player จำนวนมาก

จะสร้างทั้ง Network และ Server Event Processing

㊸ Event ควรเกิดเมื่อจำเป็น

ตัวอย่าง Position อาจไม่ต้อง Custom Sync หาก Engine/OneSync มีข้อมูลอยู่แล้ว

ถามก่อนสร้าง Network Eventว่า

FiveM Sync สิ่งนี้ให้เราอยู่แล้วหรือไม่?

ลดการทำงานซ้ำกับ Platform

㊹ Payload ใหญ่ทำ CPU เพิ่มได้

การ Encode/Decode Table ใหญ่ซ้ำ ๆ ใช้ CPU

เช่นส่ง Inventory ทั้งชุดเมื่อ Item เดียวเปลี่ยน

สามารถพิจารณา Delta Update

item bread
amount +1

แทน Full Dataset

㊺ JSON ใหญ่มากต้องระวัง

ทั้ง Lua/JavaScript สามารถเสียเวลาจาก

Encode
Decode
Copy

ถ้าเกิดถี่

ควร Profile ก่อนตัดสินว่า Network เป็นปัญหาเพียงอย่างเดียว

㊻ State Bag Spam ก็ทำ CPU ได้

แม้ Enhanced ปรับ State Bags ให้มีประสิทธิภาพขึ้นมาก

แต่ถ้า Script Set State หลายพันครั้งต่อวินาทีโดยไม่จำเป็น ก็ยังสร้าง Workload

Platform Optimization ไม่แทน Resource Design

㊼ Set State เฉพาะเมื่อค่าเปลี่ยน

จาก

locked=true
locked=true
locked=true

ทุก Tick

ให้ Set ครั้งเดียวตอน State เปลี่ยน

นี่เป็น Optimization ที่ง่ายแต่มีผลมากเมื่อ Entity เยอะ

㊽ Routing Bucket Logic ต้องระวัง

Housing/Mission Systems ที่ Loop

Player ทุกคน
Bucket ทุกอัน
Entity ทุกตัว

ถี่เกินไปสามารถสร้าง Scaling Problem

ใช้ Events เมื่อ Player เข้า/ออก Bucket จะเหมาะกว่าในหลายกรณี

㊾ Resource Restart แล้ว CPU ลดลงทันทีเป็นเบาะแสสำคัญ

สมมติ

CPU 85%
restart custom-resource
CPU 35%

Resource นั้นต้องถูกตรวจอย่างจริงจัง

แต่ยังอย่าเพิ่งสรุป 100%

ต้อง Re-enable และ Reproduce เพื่อยืนยัน

㊿ ใช้ Binary Isolation ได้

ถ้าไม่รู้ Resource ไหนเป็นปัญหาและมี Custom Resources หลายตัว

บน Test Server สามารถ

ปิดครึ่งหนึ่ง
ทดสอบ
เลือกกลุ่มที่ยังมีปัญหา
แบ่งครึ่งอีก
ทำซ้ำ

ช่วยหา Resource ต้องสงสัยได้เร็ว

51. อย่าปิด Core Resource สุ่มบน Production

เช่น

Framework
Inventory
Database
Multicharacter

อาจทำให้ Data หรือ Gameplay มีปัญหา

ควรใช้ Staging เมื่อทำ Isolation

52. Script Start ได้ไม่ได้แปลว่า Optimize

Resource สามารถ

Started resource xyz

ปกติ

แต่ทำ Heavy Loop หลัง Start ทุก Tick

Console ไม่มี Errorก็ยังสามารถกิน CPU สูงได้

Profiler จึงสำคัญ

53. Resmon ใช้หา Server CPU ได้ไหม?

ไม่ใช่เครื่องมือหลัก

Resmon เป็น Resource Monitor ฝั่ง Client สำหรับดู CPU Time และ Memory ของ Client Resources

ถ้า FXServer CPU สูง ใช้

Profiler
txAdmin
Server Metrics

ก่อน

54. ทำไมต้องแยก Client กับ Server CPU?

Resource หนึ่งตัวอาจมี

client.lua → 2.0 ms
server.lua → เบามาก

หรือกลับกัน

Server CPU สูงไม่ได้หมายความว่า Resmon ต้องสูง

เป็นคนละ Process/Workload

55. CPU สูงแต่ผู้เล่น FPS ดีเกิดได้ไหม?

ได้

ถ้า Bottleneck อยู่ Server-side

ผู้เล่นอาจมี FPS 100 แต่

Inventory Delay
Event Delay
Vehicle Spawn ช้า

เพราะ Client Rendering ปกติแต่ Server Processing ช้า

56. FPS ต่ำแต่ Server CPU ต่ำก็เกิดได้

ถ้า

MLO หนัก
Vehicle High-poly
NUI หนัก
Client Loop หนัก

Server CPU อาจ 20% แต่ผู้เล่น FPS ต่ำ

อย่าปะปนปัญหา

57. CPU สูงจาก Voice ได้ไหม?

Voice และ Networking เพิ่ม Workload ตามจำนวน Player

โดยเฉพาะ Community ใหญ่

แต่ก่อนสรุปว่า Voice เป็นต้นเหตุให้ดู Metrics/Profiler และทดสอบ Configuration จริง

อย่าปิด Voice Production เพื่อเดาสุ่ม

58. OneSync มีผลกับ CPU อย่างไร?

OneSync ต้องจัดการ

Players
Entities
Culling
Network State

เมื่อ Player/Entity เพิ่ม Workload ก็เพิ่ม

FiveM Enhanced ได้ปรับ Culling และ Server-side Performance เพื่อใช้ CPU ได้มีประสิทธิภาพขึ้นในหลาย Scenario

59. Enhanced ลด CPU ได้อัตโนมัติไหม?

Cfx.re ระบุว่า Cfx Server Enhanced ใช้ CPU ต่ำลงในบาง Scenario

แต่คำสำคัญคือ

บาง Scenario

Heavy Script ที่เขียนไม่ดีจะยังหนักอยู่

60. Enhanced Metrics ช่วยหา CPU Bottleneck ได้อย่างไร?

Enhanced เพิ่ม Prometheus-compatible Metrics มากกว่า 80 รายการ

รวมถึงข้อมูลเกี่ยวกับ

Main/Network/Sync Thread Tick Times
OneSync Entities
State Bags
JavaScript/Lua Memory
NetID
Network
Event Loop Queue

ทำให้ดูได้ว่า CPU Problem สัมพันธ์กับ Layer ไหน

61. ถ้า svMain Tick สูงควรคิดถึงอะไร?

โดยทั่วไปให้ตรวจ Server Main Workload เช่น

Scripts
Events
Gameplay Logic

จากนั้นใช้ Profiler เจาะ Resource

ไม่ควรใช้ Thread Metric เพียงตัวเดียวฟันธงชื่อ Resource

62. ถ้า Sync Load สูงต้องดูอะไร?

ตรวจ

Player Count
Entity Count
OneSync
State Bags
Resource ที่สร้าง Entities

Server ที่มี Entity Leak สามารถเพิ่ม Sync Workload ได้มาก

63. JavaScript Event Loop Queue สูงควรตรวจอะไร?

Resource JavaScript อาจมี Workload ที่สะสม

เช่น

CPU-heavy Logic
Callback จำนวนมาก
I/O Workflow

Enhanced Metrics มีข้อมูล Event Loop Queue Depth ช่วยเป็นเบาะแส

แล้วใช้ Profiler/Code Audit ต่อ

64. Lua Memory สูงคือ CPU Problem หรือไม่?

ไม่โดยตรง

แต่ Memory และ Garbage Collection สามารถสัมพันธ์กับ CPU ได้

Script ที่สร้าง Table/Object จำนวนมหาศาลแล้วทิ้งตลอดเวลาอาจสร้าง GC Pressure

ต้อง Profile จริง

65. สร้าง Table ใหม่ทุก Tick ต้องระวัง

ตัวอย่าง

while true do
    Wait(0)

    local data = {
        -- ข้อมูลจำนวนมาก
    }
end

ถ้าทำบ่อยมากจะสร้าง Allocation จำนวนมาก

ควรดูว่า Cache/Reuse Data ได้หรือไม่

66. JavaScript สร้าง Object จำนวนมากก็เช่นกัน

Garbage Collector ต้องจัดการ Object ที่หมดอายุ

Modern Node.js มี GC ที่มีประสิทธิภาพ แต่ไม่ใช่เหตุผลให้สร้าง Object จำนวนมหาศาลโดยไม่จำเป็น

67. String Concatenation/JSON Logging จำนวนมากต้องระวัง

โดยเฉพาะใน Loop

สร้าง JSON
↓
สร้าง String
↓
Print
↓
เขียน Log

ทำหลายพันครั้งอาจกิน CPU/I/O

68. CPU Spike ตอน Autosave ต้องตรวจ Save Architecture

Server RP อาจ Save Player ทุกคนพร้อมกัน

เช่นทุก 5 นาที

Player 300 คน
↓
Save พร้อมกัน
↓
SQL Burst
↓
CPU/DB Spike

สามารถพิจารณากระจาย Save Load หรือใช้ Strategy ที่เหมาะสม

69. Payday ก็เป็น Burst Event

ถ้า Payday ทำ

เงิน
SQL
Society
Logs
Notifications

กับ Player ทุกคนพร้อมกัน อาจเกิด Spike

Profiler ตอน Payday จะช่วยเห็น Resource ได้ชัด

70. Player Connect Spike ต้องตรวจ

ตอน Restart แล้ว Player 200 คน Reconnect พร้อมกัน Resource หลายตัวอาจ

Query Character
Load Inventory
Load Phone
Load Housing
Send Config

พร้อมกัน

ต้องทดสอบ Join Storm ด้วย

71. Resource Start Order มีผลได้

Resource ที่ Start ก่อน Dependency พร้อมอาจ Error/Retry ซ้ำ ๆ

ตรวจ

Database
↓
Libraries
↓
Framework
↓
Core Resources
↓
Gameplay Resources

ตาม Dependency จริง

ลด Error Loop และ Retry ที่ไม่จำเป็น

72. CPU สูงจาก Anti-cheat ได้ไหม?

Anti-cheat บางระบบตรวจ Player/Entity/Event ถี่มาก

ควรใช้ Version ที่ผู้พัฒนารองรับและ Benchmark บน Player Count จริง

แต่ไม่ควรปิด Security System บน Production เพียงเพื่อให้ CPU ลด

ใช้ Staging ทดสอบ

73. Logging Resource ก็หนักได้

Server ที่ Log ทุก

Movement
Inventory Action
Entity
Event

ไป Database/Webhookทันที สามารถสร้าง Load สูง

พิจารณา

Batch
Queue
Rate Limit

ตามความเหมาะสม

74. Discord Webhook ทุก Action ควรระวัง

HTTP Request จำนวนมากมี Cost

เช่น 500 Players ทำ Interaction บ่อย

หากส่ง Webhook ทุกครั้งอาจเพิ่ม I/O/Queue

Log เฉพาะสิ่งจำเป็นและรวม Event เมื่อเหมาะ

75. ซื้อ CPU ใหม่ควรเป็นขั้นตอนสุดท้ายหรือไม่?

ไม่จำเป็นต้องสุดท้ายเสมอ แต่ควรมีข้อมูลก่อน

ถ้า Profile แล้วพบว่า

Scripts สมเหตุสมผล
Database ดี
Entity ไม่ Leak
Workload จำเป็น
CPU Thread ยังเต็ม

การ Upgrade Hardware จึงมีเหตุผล

76. CPU รุ่นใหม่ช่วย FiveM อย่างไร?

ให้ความสำคัญกับ

Strong per-core Performance
Adequate Core Count
Stable Clock
Cooling

FiveM มีทั้ง Thread-sensitive และ Multi-core Workload

อย่าดูเพียงจำนวน Core สูงที่สุด

77. VPS CPU อาจเป็นปัญหาได้

VPS บางแห่งใช้ Shared CPU

แม้ Dashboard แสดง vCPU หลาย Core แต่ Performance อาจแกว่งตาม Neighbor Load

Production Server ขนาดใหญ่ควร Benchmark CPU จริง

78. Dedicated Server เหมาะเมื่อไร?

เมื่อ

Player Count สูง
Performance ต้องคาดการณ์ได้
Shared CPU เป็น Bottleneck
ต้องควบคุม Network/Storage มากขึ้น

แต่ Dedicated ไม่ได้แก้ Script ที่ทำ O(n²)

79. CPU สูงเฉพาะ Peak Hour แปลว่าอะไร?

มีแนวโน้มว่า Workload Scale ตาม

Players
Entities
Voice
Database

ให้ Capture Profiler ตอน Peak

อย่า Restart ก่อน Capture ทุกครั้ง เพราะจะเสียหลักฐาน

80. ก่อน Restart Server ที่กำลัง CPU สูงควรทำอะไร?

ถ้ายังพอใช้งานได้และปลอดภัย ให้เก็บ

Player Count
CPU/RAM
Console
Profiler Capture
Metrics Snapshot

ก่อน Restart

ข้อมูลนี้มีค่ามากสำหรับหาต้นเหตุ

81. ทำ Performance Regression Test

หลังแก้ Resource ให้เปรียบเทียบ

ก่อนแก้
CPU 75%
Hitch 20 ครั้ง/10 นาที

หลังแก้
CPU 45%
Hitch 1 ครั้ง/10 นาที

แบบนี้จึงรู้ว่าแก้ได้จริง

82. อย่าใช้แค่ “รู้สึกลื่นขึ้น”

Performance Optimization ต้องมีตัวเลข

อย่างน้อยเปรียบเทียบ

Player Count เท่ากัน
Scenario เท่ากัน
Resource Version ชัดเจน

จึงจะเชื่อถือได้

83. Checklist หา Script กิน CPU

ขั้นแรก

ดู txAdmin CPU/RAM
ดู Thread Chart
ดู Player Count

Console

Hitch Warning
Error Spam
SQL Warning

Profiler

Capture ตอน CPU สูง
หา Spike
หา Resource
หา Function

Code

Wait(0)
Player Loop
Entity Loop
O(n²)
JSON
Logging

Database

Slow Query
Query Loop
Missing Index

Network

Event Spam
Large Payload

Entity

Leak
Cleanup

หลังแก้

Profile ซ้ำ
Load Test
Compare

84. วิธีแก้แบบเร็วเมื่อไม่รู้ Resource ไหน

ถ้ามี Test Server:

Clone Production Config
จำลอง Player/Workload
Profile
ดู Top Resource
Disable Resource ต้องสงสัย
Reproduce
ถ้า CPU ลด เปิด Resource กลับ
Reproduceอีกครั้ง
ยืนยัน
แก้ Source

นี่ดีกว่าลบ Resource จาก Production แบบเดาสุ่ม

85. ถ้าเป็น Paid Script ทำอย่างไร?

หากไม่มี Source

เก็บหลักฐาน เช่น

Profiler
CPU Pattern
Player Count
Steps to Reproduce

แล้วส่งให้ Developer

ถามหา

Updated Version
Optimization Patch
Enhanced-compatible Build

ถ้า Resource Critical และไม่ได้รับการดูแล อาจต้องเริ่มหา Alternative

86. Resource ที่อ้างว่า 0.00 ms เชื่อได้ไหม?

ตัวเลข Client Resmon ไม่ได้บอก Server-side CPU ทั้งหมด

Resource สามารถ Client เบามากแต่ Server หนัก

อย่าใช้คำว่า

0.00 ms optimized

เป็นหลักฐานว่า Resource ทั้งระบบเบา

ต้อง Profile Server ด้วย

87. สิ่งที่ไม่ควรทำเมื่อ CPU สูง

หลีกเลี่ยง

Restart แล้วจบ
เพิ่ม RAMเพื่อแก้ CPU
ล้าง Cache
ปิด Resource สุ่มใน Production
เปลี่ยน Framework ทั้งระบบก่อน Profile
ใช้ Resmon แทน Server Profiler
เพิ่ม Wait แบบสุ่มจน Gameplay ช้า
ซื้อ Dedicated Server ก่อนรู้ Bottleneck
Ignore SQL
Ignore Entity Count

ต้องแก้สาเหตุ ไม่ใช่กลบอาการ

88. คำถามที่พบบ่อย

FiveM Server CPU สูงเกิดจากอะไร?

มักเกิดจาก Script Loop, Player/Entity Scan, SQL ช้า, Event Spam, Entity จำนวนมาก หรือ Resource ที่ Scale ไม่ดี

ดู Resource กิน CPU อย่างไร?

ใช้ Server Profiler และดู txAdmin Server Thread Performance

Resmon ใช้ดู Server CPU ได้ไหม?

Resmon เน้น Client Resource CPU/Memory ไม่ใช่เครื่องมือหลักสำหรับ FXServer CPU

Hitch Warning เกี่ยวกับ CPU ไหม?

เกี่ยวข้องได้ และเป็นสัญญาณว่า Resource/Thread ใช้เวลานานผิดปกติ

SQL ทำ CPU สูงได้ไหม?

Slow Queries และการประมวลผล Database สามารถสร้าง Hitch และเพิ่ม Workload ได้

Wait(0) ต้องลบทั้งหมดไหม?

ไม่ ต้องดูว่า Logic นั้นจำเป็นต้องทำทุก Frameหรือไม่

Restart แล้ว CPU ลดแปลว่าอะไร?

อาจมี Resource State, Entity, Cache หรือ Memory สะสม ต้อง Profile ก่อนและหลังเพื่อหาสาเหตุ

Resource ไหนกิน CPU มากที่สุดดูจากชื่อได้ไหม?

ไม่ได้ ต้องวัดด้วย Profiler

เพิ่ม RAM ช่วย CPU สูงไหม?

ไม่ถ้า CPU เป็น Bottleneck จริง

ซื้อ CPU แรงขึ้นช่วยไหม?

ช่วยเมื่อ Workload ถูก Optimizeแล้วแต่ Hardware ยังเป็นข้อจำกัด

89. สรุป FiveM Server CPU สูง แก้อย่างไร หา Script ตัวปัญหาให้เจอ

ถ้า FiveM Server CPU สูง สิ่งแรกที่ไม่ควรทำคือเดาว่า

Framework หนัก

หรือ

ต้องซื้อเครื่องใหม่

ให้เริ่มจาก

txAdmin
↓
CPU / RAM / Thread Performance
↓
Console
↓
Hitch Warning
↓
Profiler
↓
Resource
↓
Function
↓
Root Cause

จากนั้นตรวจ Root Cause ยอดนิยม ได้แก่

Loop ถี่เกินไป

โดยเฉพาะ Wait(0) บน Server

Player Loop

ที่ทำงานทุก Tick

O(n²)

ที่ Scale แย่มากเมื่อ Player เพิ่ม

Entity Scan

ที่ Loop รถ/Ped/Object ทั้งโลก

SQL Query ช้า

หรือ Query ใน Loop

Event Spam

จาก Client จำนวนมาก

Large Payload / JSON

ที่ Encode/Decode ถี่

Entity Leak

ทำ Entity Count เพิ่มตามเวลาที่ Server เปิด

Logging

ที่เขียน Console, Database หรือ Webhook มากเกินไป

สำหรับ FiveM Enhanced การวิเคราะห์ง่ายขึ้นอีกระดับ เพราะ Cfx.re เปลี่ยน Profiler Backend ไปใช้ Perfetto และเพิ่ม Metrics มากกว่า 80 รายการ ครอบคลุม Main/Network/Sync Threads, OneSync, Entities, State Bags, JavaScript/Lua Memory และ Network Activity

txAdmin เองสามารถแสดง CPU/RAM และ Server Threads Performance Chart พร้อม Player Count ทำให้เห็นได้ว่า CPU เพิ่มตามจำนวนผู้เล่นหรือเกิดจาก Background Resource

แนวทางที่ comsiam แนะนำคือ

Measure
↓
Capture ตอนปัญหาเกิด
↓
Find Resource
↓
Find Function
↓
Fix Loop / SQL / Events / Entities
↓
Load Test
↓
Profile Again
↓
Production

จำสั้น ๆ:

CPU สูง → ดู Thread

Hitch → Profiler

Player เพิ่มแล้ว CPU พุ่ง → ตรวจ Scaling

CPU เพิ่มตามเวลาที่เปิด → ตรวจ Leak

CPU Spike ตอน Save → ตรวจ SQL/Autosave

CPU Spike ตอน Event → Profile Event Resource

Resource Restart แล้ว CPU ลด → ตรวจ Resource นั้น

Resmon → Client ไม่ใช่คำตอบหลักของ Server CPU

Hardware → Upgrade หลังรู้ Bottleneck

FiveM Server ที่ Optimize ดีไม่ใช่ Server ที่ CPU ต่ำตลอดเวลา แต่คือ Server ที่มี Headroom เพียงพอ ไม่มี Thread Hitch ต่อเนื่อง และสามารถรองรับ Peak Gameplay ได้โดย Resource แต่ละตัวทำงานเฉพาะเท่าที่จำเป็น