FiveM MySQL Got Timeout Writing Communication Packets Error 1161 แก้อย่างไร? ตรวจ net_write_timeout, Result Set ใหญ่ และ Client ที่รับข้อมูลไม่ทัน

August 17, 2026

ปัญหา FiveM MySQL/MariaDB ขึ้น Got timeout writing communication packets หรือ Error 1161 หมายความว่า MariaDB กำลังพยายามส่งข้อมูลกลับไปยัง Database Client แต่ Client ไม่สามารถรับข้อมูลออกจาก Connection ได้ทันภายในช่วงเวลาที่กำหนด จน Server ยกเลิกการ Write และคืน Error 1161

MariaDB กำหนด Error 1161, SQLSTATE 08S01 เป็น:


ER_NET_WRITE_INTERRUPTED
Got timeout writing communication packets

โดยตรง.

สำหรับ FiveM ตัว Client ฝั่งรับข้อมูลอาจเป็น:

Database Wrapper
Connection Pool
FiveM Server
Resource
Database Connector
Admin/API Service
Application อื่นที่ใช้ MariaDB เดียวกัน

ปัญหานี้มักควรตรวจเมื่อ:

Query คืน Result จำนวนมาก
SELECT * จาก Table ใหญ่
Logs โตมาก
Phone Messages จำนวนมาก
Transaction History จำนวนมาก
Inventory/Metadata JSON ใหญ่
Housing Furniture ใหญ่
Remote Database Network ช้า
Database Client ค้าง
FiveM Server CPU หนัก
Resource ไม่อ่าน Result ต่อ
Connection ถูกขัดจังหวะ
net_write_timeout ต่ำเกิน Workload จริง

MariaDB Connector/J Documentation ระบุว่า Server คาดหวังให้ Client อ่าน Result Set ออกไปค่อนข้างเร็ว และ net_write_timeout เป็นตัวกำหนดช่วงเวลาที่เกี่ยวข้อง โดยค่าปริยายที่เอกสารปัจจุบันระบุคือ 60 วินาที.

ดังนั้นวิธีแก้ที่ถูกต้องไม่ใช่:


เห็น 1161
↓
เพิ่ม net_write_timeout เป็น 3600

ทันที

แต่ควรเป็น:


หา Query
↓
ดู Result Size
↓
ดู Client
↓
ดู Network
↓
ตรวจ net_write_timeout
↓
ลดข้อมูลที่ไม่จำเป็น
↓
แก้ Client/Resource
↓
เพิ่ม Timeout เฉพาะเมื่อจำเป็นจริง

① FiveM MySQL Error 1161 คืออะไร

MariaDB Error 1161 คือ:


1161
08S01
ER_NET_WRITE_INTERRUPTED
Got timeout writing communication packets

หมายความว่า Database Server ใช้เวลาในการส่งข้อมูลผ่าน Connection ไปยัง Client นานเกินเงื่อนไขที่กำหนด.

② คำว่า Writing หมายถึงใครกำลังเขียน

ใน Error นี้:

MariaDB Server กำลัง Write Data ไปยัง Client

Flow คือ:


MariaDB
↓
Query Result
↓
TCP / Database Connection
↓
Database Wrapper
↓
FiveM Resource

③ FiveM กำลังส่งข้อมูลเข้า Database หรือไม่

ไม่ใช่ Direction หลักของ Error นี้

ถ้า MariaDB กำลังรอ อ่าน ข้อมูลจาก FiveM จะอยู่ฝั่ง Error 1158/1159 มากกว่า

④ ต่างจาก Error 1159 อย่างไร

Error 1159


Got timeout reading communication packets

MariaDB รอ ข้อมูลจาก Client นานเกินไป.

Error 1161


Got timeout writing communication packets

MariaDB กำลัง ส่งข้อมูลกลับ Client แต่ส่งไม่สำเร็จภายในเวลา

⑤ จำง่าย ๆ


1159 = Server รอรับ
1161 = Server รอส่ง

⑥ แล้ว Error 1158 ล่ะ

1158 คือ:


Got an error reading communication packets

เป็น Read Error ไม่ใช่ Read Timeout.

⑦ Error 1160 ล่ะ

1160 คือ:


Got an error writing communication packets

เป็น Write Error ไม่ใช่ Write Timeout.

⑧ ชุด Error ทั้ง 4 ตัว

จำดังนี้:


1158 = Read Error
1159 = Read Timeout
1160 = Write Error
1161 = Write Timeout

MariaDB แยกทั้งสี่ Error ไว้อย่างชัดเจนใน Error Code Reference.

⑨ Error 1161 เป็น SQL Syntax Error ไหม

ไม่ใช่

SQL Syntax Error อยู่คนละกลุ่ม เช่น 1064 หรือ 1149

1161 เป็น Communication Error

⑩ Clear FiveM Cache ช่วยไหม

โดยทั่วไปไม่

ปัญหาอยู่ในเส้นทาง:


MariaDB
↔
Database Client

มากกว่า FiveM Client Cache

⑪ Restart FiveM ช่วยไหม

อาจทำให้ Connections ถูกสร้างใหม่

จึงอาจทำให้อาการหายชั่วคราว

แต่ไม่ได้แก้:

Query Result ใหญ่
Network ช้า
Client อ่านไม่ทัน
Resource Bug

⑫ Restart MariaDB ช่วยไหม

ไม่ควรเป็น First Fix

และ Restart Database จะตัด Connections ของ Resources อื่นทั้งหมดด้วย

⑬ ตัวแปรสำคัญคืออะไร

คือ:


net_write_timeout

MariaDB Connector/J Documentation ระบุว่าค่านี้ควบคุมระยะเวลาที่ Server ยอมรอ Client ขณะส่ง Result Set และระบุ Default ปัจจุบันไว้ที่ 60 วินาที.

⑭ ตรวจ `net_write_timeout` อย่างไร

ใช้:


SHOW VARIABLES LIKE 'net_write_timeout';

⑮ หรือ


SELECT @@net_write_timeout;

⑯ ถ้าได้ 60

นั่นสอดคล้องกับค่าปริยายที่ MariaDB Connector/J Documentation ระบุในปัจจุบัน.

⑰ ควรเพิ่ม 60 เป็น 600 เลยไหม

ไม่ควร

ก่อนเพิ่มต้องตอบให้ได้ว่า:

ทำไม FiveM Database Client ถึงใช้เวลานานเกิน 60 วินาทีในการรับ Result จาก Database?

⑱ ถ้า Result มีแค่ 1 Row

แต่ใช้เวลานานมาก:

อาจไม่ได้เป็นปัญหา Result Size

ต้องตรวจ:

Network
Client
Wrapper
Server Load

⑲ ถ้า Result มี 5 ล้าน Rows

นี่เป็นคนละเรื่อง

Query Design ควรถูกตรวจเป็นอันดับต้น ๆ

⑳ MariaDB บอกอะไรเกี่ยวกับ Result Set ใหญ่

MariaDB Connector/J Documentation ระบุว่ากรณีที่พบบ่อยของปัญหาที่เกี่ยวกับ net_write_timeout คือ Query ที่มี Result Set ใหญ่ เพราะ Serverคาดหวังให้ Clientอ่าน Resultออกไปภายในช่วงเวลาที่เหมาะสม.

㉑ FiveM Query ไหนอาจคืน Result ใหญ่

ตัวอย่าง:

Player Logs
Transactions
Phone Messages
Business History
Vehicle History
Admin Logs
Inventory History
Audit Logs

㉒ ตัวอย่าง Query เสี่ยง


SELECT *
FROM logs;

หาก Table มีข้อมูลหลายล้าน Rows

㉓ Syntax ถูกไหม

ถูก

แต่ Query Design อาจไม่เหมาะกับ Use Case

㉔ ถ้า UI ต้องการแค่ 50 รายการล่าสุด

ไม่ควรโหลดข้อมูลหลายล้านรายการทั้งหมด

㉕ แนวคิดที่เหมาะกว่า

เช่น:


SELECT ...
FROM logs
ORDER BY id DESC
LIMIT 50;

แต่ต้องปรับ Table/Column และ Logic ให้ตรง Resource จริง

㉖ อย่า Copy Query ตัวอย่างไปวางทันที

เพราะ Resource บางตัวใช้:

created_at
id
timestamp

ต่างกัน

㉗ Pagination สำคัญ

ข้อมูลที่โตเรื่อย ๆ เช่น Logs หรือ Transaction History ควรพิจารณา Pagination หาก UI แสดงทีละหน้า

㉘ ตัวอย่าง

แทนที่จะโหลด:


100,000 records

ครั้งเดียว

อาจโหลด:


50 records

ต่อหน้า

หาก Business Logic รองรับ

㉙ Phone Messages

FiveM Phone Resource เป็น Case ที่เห็นภาพชัด

Player เปิด Conversation หนึ่งรายการ

Resourceไม่ควรจำเป็นต้องโหลด:


ข้อความทั้งหมดของผู้เล่นทุกคน

㉚ Query ควร Scope

เช่นตาม:

Conversation
Phone Number
Account
Character

ตาม Schemaจริง

㉛ Banking Transaction History

หน้า Mobile Bankingอาจต้องแสดง:


20 รายการล่าสุด

ไม่จำเป็นต้องส่งประวัติหลายปีทุกครั้ง

㉜ Business Logs

Business Resource อาจมี:

Sales
Deposits
Withdrawals
Employees

ถ้าดึง Historyทั้งหมดทุกครั้ง:

Result Setโตตามอายุ Server

㉝ Admin Logs

หนึ่งใน Tableที่โตเร็วที่สุดใน Serverบางประเภท

โดยเฉพาะถ้า Log:

Inventory
Vehicle
Money
Staff Actions
Deaths
Connections

㉞ Query ที่เคยเร็วอาจเริ่มมีปัญหา

ช่วงแรก:


10,000 rows

ต่อมา:


10,000,000 rows

Queryเดิมอาจไม่ Scale

㉟ เพิ่ม net_write_timeout อย่างเดียวจึงไม่ยั่งยืน

วันนี้เพิ่มจาก:


60 → 300

แล้วผ่าน

แต่ Table โตต่อ:


20 ล้าน
50 ล้าน
100 ล้าน rows

ปัญหาสามารถกลับมา

㊱ Root Fix อาจเป็น Query Scope

เช่น:

WHERE
LIMIT
Pagination
Date Range

ตาม Use Case

㊲ `SELECT *` เป็นปัญหาเสมอไหม

ไม่

ถ้า Application ต้องใช้ทุก Column จริง:

ก็ไม่มีอะไรผิด

㊳ แต่ต้องระวัง Column ใหญ่

เช่น:


inventory
metadata
appearance
props
json
longtext

㊴ Admin Player List

สมมติหน้าจอต้องแสดงแค่:


Name
ID
Job
Online

แต่ Queryดึง:


Inventory JSON
Character Skin
Metadata
Housing Data

ด้วย

Resultใหญ่โดยไม่จำเป็น

㊵ เลือกเฉพาะ Columns ที่ใช้

สามารถลด:

Network Data
Client Memory
Serialization
Database Work

ได้

㊶ Character List

Multicharacter Resource อาจไม่จำเป็นต้องโหลด Inventoryเต็มทุก Characterเพื่อแสดงหน้าเลือกตัวละคร

ขึ้นกับ Framework

㊷ Vehicle List

Garage UI อาจต้อง:

Plate
Model
State

แต่ไม่จำเป็นต้องโหลด Historyทั้งหมดของรถถ้าไม่ได้ใช้

㊸ Inventory

Inventory JSONของ Playerหนึ่งคนอาจไม่ใหญ่

แต่ Queryที่ดึง Inventoriesของ Playersทั้ง Serverพร้อมกันอาจใหญ่

㊹ Admin Inventory Search

อย่าดึง Inventoriesทุกคนมาที่ Lua แล้วค่อย Search ถ้า Databaseสามารถ Filterข้อมูลที่ต้องการได้ตาม Schema/Indexที่เหมาะสม

㊺ แต่ไม่ควร Rewrite Third-party Inventoryเอง

ตรวจ Official Documentation/Updateก่อน

㊻ Housing Furniture

Houseหนึ่งหลังอาจมี Furniture Dataจำนวนมาก

ถ้า Admin Queryโหลด Furnitureของ Housesทุกหลังพร้อมกัน:

Resultสามารถใหญ่ขึ้นมาก

㊼ Phone Attachments

หาก Resourceเก็บ Attachmentหรือข้อมูลรูปภาพใน Database:

Result Sizeอาจสูง

㊽ Base64

ข้อมูล Binaryที่แปลงเป็น Base64จะมี Encoding Overhead

จึงควรระวัง Queryที่ส่ง Base64ขนาดใหญ่หลายรายการพร้อมกัน

㊾ Errorเฉพาะ Phone

ถ้า Resourceอื่นปกติ:

ตรวจ Phone Queryก่อน MariaDB Global Config

㊿ Errorเฉพาะ Admin Logs

ตรวจ Admin Logs Query

ไม่ต้องเปลี่ยน Database Wrapper ทั้ง Serverทันที

51. Errorทุก Resourceพร้อมกัน

ถ้า:


bank error
inventory error
garage error
phone error

พร้อมกัน

Scopeกว้างขึ้น

ให้ตรวจ:

Database Client
Network
MariaDB
FiveM Server Load

52. Remote Database

ถ้า FiveM กับ MariaDB อยู่คนละเครื่อง:


MariaDB
↓
Network
↓
FiveM

Result Setต้องผ่าน Networkจริง

53. Network Slow/Stall

หาก Clientไม่สามารถรับข้อมูลออกจาก Socketได้ตามปกติ:

Write Operationฝั่ง Serverอาจติด

54. Ping อย่างเดียวพอไหม

ไม่

Pingไม่ใช่ Database TCP Session

ควรดู:

Packet loss
Connection resets
Network incidents
Database logs

55. Network Latencyสูงแต่เสถียร

อาจยังทำงานได้

แต่ Large Result Set + Slow Client + Unstable Networkจะมีความเสี่ยงสูงขึ้น

56. Firewall/NAT

ถ้า Database Connectionผ่าน:

Firewall
NAT
VPN
Tunnel
Proxy

ก็มี Network Layerเพิ่ม

57. Errorหลัง Firewall Change

ถ้า 1161เริ่มหลังเปลี่ยน Infrastructure:

นี่เป็น Correlationที่ควรตรวจ

58. อย่าเปิด MariaDB ให้ Public

เพื่อแก้ Timeout

Databaseควรเปิดเฉพาะ Source Hostsที่จำเป็น

59. Errorบน localhost

ก็เกิดได้

จึงไม่ใช่ Internet Errorเสมอไป

60. FiveM Process อ่าน Result ไม่ทัน

เป็นไปได้ในเชิง Client-side processing

เช่น Server Loadสูงมาก

61. CPU FiveM เต็ม

ถ้า Main ProcessหรือDatabase Clientช้าผิดปกติ:

การ Consume Resultอาจล่าช้า

แต่ต้องใช้ Metricsยืนยัน

62. RAMไม่พอ

หาก FiveM ProcessหรือDatabase Clientถูกกดดันด้าน Memoryอย่างรุนแรง:

อาจมีผลต่อ Application Stability

แต่ 1161เพียงตัวเดียวไม่ได้พิสูจน์ว่า RAMไม่พอ

63. อย่า Upgrade VPSทันที

ก่อนตรวจ:

Query
Result
Network
Timeout

64. Resource Crash

ถ้า Client Processหาย:

อาจเห็น Write Communication Error เช่น 1160 มากกว่า หรือ Errorอื่นตาม Timing

แต่ควรตรวจ Consoleร่วมกัน

65. Resource Stop

ถ้า Resourceถูก Restartกลาง Query:

Connection/Result Handlingอาจถูกขัดจังหวะตาม Implementation

66. Error 1161 แตกต่างจาก Resource Crashเล็กน้อย

1161ชี้ว่า MariaDB รอเขียนนานจน Timeout

จึงควรสนใจ Clientที่ไม่ Consume Dataมากกว่าการ Connectionถูกตัดทันที

67. Query Execution ช้ากับ Result Consumption ช้าต่างกัน

นี่สำคัญมาก

Query Execution ช้า

Databaseใช้เวลาคำนวณก่อนสร้าง Result

Write Timeout

Serverมีข้อมูลที่จะส่ง แต่ Clientรับข้อมูลไม่ทันในบริบท Write Communication

68. ดังนั้นเพิ่ม Indexช่วย1161ไหม

ถ้า Root Causeคือ Query Execution/Result Volume:

อาจช่วยทางอ้อม

แต่ถ้า Clientไม่อ่าน Resultเพราะ Processค้าง:

Indexไม่ได้แก้

69. Index ต้องดู Query จริง

อย่าเพิ่ม Indexทุก Column

70. Missing Index

Queryที่ต้อง Scan Tableใหญ่สามารถทำให้ Database Workหนักขึ้น

และอาจทำ Result/Responseช้าตามมา

71. EXPLAIN

Custom Developerสามารถใช้ Query Planเพื่อดูการเข้าถึงข้อมูล

แต่ต้องใช้กับ Queryจริง

72. ไม่ควร Run Heavy Diagnosticบน Productionช่วง Peak

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

73. Staging Database มีประโยชน์

สำหรับ:

Query tuning
Pagination
Index testing

74. Server Ownerที่ใช้ Paid Script

ตรวจ Official Updateก่อนแก้ SQLเอง

เพราะ Developerอาจแก้:

Query
Index
Pagination

แล้ว

75. Errorหลัง Resource Update

ควรตรวจ Changelog

ถ้า Versionใหม่เปลี่ยน Queryจาก:


paginated

เป็น:


all rows

อาจเกิด Regression

76. Errorหลัง Rollback Resource

ระวัง Database Schemaอาจถูก Migrationแล้ว

Codeเก่าอาจไม่เข้ากับ Schemaใหม่

77. Backupก่อน Rollback

สำคัญ

78. Errorหลัง Framework Update

Core Player Queriesอาจเปลี่ยน

Third-party Resourcesอาจเริ่มดึงข้อมูลมากขึ้น

79. Errorหลัง Database Wrapper Update

ตรวจ:

Connection Pool
Streaming Result behavior
Resource Compatibility

80. MariaDB Connector/J มีวิธี Streaming Result หรือไม่

MariaDB Connector/J Documentation พูดถึงวิธีจัดการ Result Set ใหญ่และเตือนเรื่อง net_write_timeout; แต่ FiveM Resourceอาจไม่ได้ใช้ Connector/J เลย จึงไม่ควรนำ Configของ Connector/Jไปใส่ Wrapperอื่นโดยตรง.

81. นี่เป็นหลักสำคัญ

ใช้ Documentationของ:

Database Clientที่ Serverใช้จริง

ไม่ใช่ Connectorอื่นที่ชื่อคล้ายกัน

82. Errorหลัง oxmysql/Wrapperเปลี่ยน Version

ตรวจ Official Wrapper Docs/Release Notesของ Versionนั้น

83. อย่าเปิด Database Wrapperสองตัวเพราะ Error1161

จะเพิ่ม Complexityและ Connectionsโดยไม่แก้ Result Set

84. Login Burst

หลัง Server Restart Playersจำนวนมากเข้าใกล้พร้อมกัน

Resourceอาจโหลด:

Character
Vehicles
Inventory
Phone
Housing

พร้อมกัน

85. MariaDBต้องส่ง Result Setsจำนวนมาก

ถ้า FiveM Serverกำลัง Loadหนัก:

Client Consumptionอาจช้าลง

86. Errorเฉพาะหลัง Restart

ตรวจ Login Stormก่อน

87. Errorหลัง Whitelistเปิด

ผู้เล่นจำนวนมากเข้าเมืองพร้อมกัน

เป็น Scenarioคล้ายกัน

88. อย่าเพิ่ม Timeoutอย่างเดียว

ถ้า Architectureโหลดข้อมูลมหาศาลตอน Login

89. Lazy Loading

บาง Featureสามารถโหลดข้อมูลเมื่อจำเป็นแทนโหลดทั้งหมดตอน Login

แต่ต้องเป็นสิ่งที่ Frameworkรองรับ

90. อย่า Rewrite Coreเพื่อทำ Lazy Loadingเองโดยไม่มี Design

อาจทำ Stateไม่ครบ

91. Auto Saveเกี่ยวไหม

1161เป็น Serverส่ง Resultกลับ Client

Auto Saveส่วนใหญ่เน้น Writeเข้าDatabase

จึงไม่ควรสรุปว่า Auto Saveเป็นต้นเหตุทันที

92. แต่ Save Queryอาจมี RETURNING/Result/Callbacks

ขึ้นกับ SQL/Wrapper

ดังนั้นดู Queryจริง

93. SELECT-heavy Resourceน่าสงสัยกว่า

เช่น:

Admin Search
Phone History
Log Viewer
Reports

94. Reports

Resourceที่สร้าง Reportจำนวนมากอาจทำ Result Setใหญ่

95. Scheduled Report

ถ้า Errorเกิดเวลา:


00:00 ทุกวัน

ตรวจ Report/Cron Resource

96. Errorทุก30นาที

หา Taskที่รันทุก30นาที

97. Errorทุกครั้งเมื่อเปิดเมนู Admin

เกือบจะชี้ Scopeไปที่ Admin Queryได้มาก

98. Error Playerเดียว

ตรวจ Dataของ Playerนั้น

99. Error Houseเดียว

ตรวจ Furniture/Storageของ Houseนั้น

100. Error Businessเดียว

ตรวจ Transaction/Historyของ Businessนั้น

101. Errorทุกคน

ตรวจ Shared Resource/Infrastructure

102. `max_allowed_packet` เกี่ยวไหม

ถ้า ResultหรือPacketใหญ่ผิดปกติ:

ควรตรวจ

แต่ Error1161ไม่ใช่ Error Packet Limitโดยตรง

103. Packet Limitมี Errorเฉพาะ

เช่น Error1153:


Got a packet bigger than
'max_allowed_packet' bytes

MariaDBมี Errorนี้แยกชัดเจน.

104. ถ้ามี1153ก่อน1161

ตรวจ Packetก่อน

105. Error Chain

ตัวอย่าง:


1153
↓
connection problem
↓
1161

อย่าเพิ่ม net_write_timeoutอย่างเดียว

106. Error2013ร่วมด้วย

Clientอาจรายงาน:


Lost connection to MySQL server during query

ตาม Connection Stack

107. Error2006ร่วมด้วย

Connectionหลังเหตุการณ์อาจไม่สามารถ Reuseต่อได้

108. Error1160ร่วมด้วย

มีทั้ง Write ErrorและWrite Timeout

ควรตรวจ:

Client
Network
Result

จริงจัง

109. Error1158/1159ร่วมด้วย

ทั้ง ReadและWrite Communicationมีปัญหา

อาจชี้ไป:

network
wrapper
general connection instability

มากขึ้น

110. Error1040ร่วมด้วย

ตรวจ Too Many Connectionsแยก

Connection Capacityเป็นอีกปัญหาหนึ่ง

111. อย่าปรับ Variablesทุกตัวพร้อมกัน

เช่น:


wait_timeout
net_read_timeout
net_write_timeout
max_allowed_packet
max_connections

พร้อมกัน

112. ทำไมไม่ควร

ถ้าปัญหาหาย:

คุณไม่รู้ว่าอะไรแก้จริง

และอาจทำให้ Serverมี Configurationกว้างเกินจำเป็น

113. เปลี่ยนทีละปัจจัย

หลังมี Evidence

114. ถ้าจะเพิ่ม `net_write_timeout`

ควร:

จดค่าเดิม
วัด Query/Result
ปรับอย่างมีเหตุผล
ทดสอบ Queryเดิม
Monitor Error

115. Large Data Transfers

MariaDB Documentation ระบุในบริบทการโหลด Tablesขนาดใหญ่ว่าอาจจำเป็นต้องเพิ่มทั้ง net_read_timeout และ net_write_timeout เมื่อ Transferขนาดใหญ่ต้องใช้เวลามากจริง.

116. แต่ FiveM Gameplay Queryทั่วไปไม่ควรใช้หลักเดียวกันอัตโนมัติ

การ Restore Databaseหลาย GB กับเปิด Phone UI เป็น Workloadคนละประเภท

117. SQL Dump/Backup

ถ้า 1161เกิดเฉพาะตอน Exportข้อมูลจำนวนมาก:

Database Clientที่ทำ Backupอาจเป็นตัวที่มีปัญหา

118. FiveMอาจไม่เกี่ยวเลย

ดู:

Database User
Host
Timestamp

119. MariaDB Error Log

MariaDBสามารถ Log Connectionที่ถูก Abortจาก Errors/Timeouts และระดับ log_warnings ที่สูงขึ้นสามารถเพิ่มรายละเอียด Read/Write Connection Errorsได้.

120. Error Log สำคัญอย่างไร

ช่วยดูว่า Errorเกิด:

เวลาใด
Connectionใด
Clientใด

ตามข้อมูลที่ระบบบันทึก

121. `Aborted_clients`

MariaDBมี Status Variableนี้เพื่อรายงาน Client Connectionsที่ถูก Abort.

122. ตรวจได้ด้วย


SHOW GLOBAL STATUS LIKE 'Aborted_clients';

123. ถ้าเพิ่มเร็วพร้อม1161

เป็นหลักฐานว่ามี Client Connectionsที่จบผิดปกติ/Timeoutจำนวนมาก

124. อย่าดูเลขรวมอย่างเดียว

ดูอัตราการเพิ่ม

ตัวอย่าง:


12:00 = 100
13:00 = 102

ต่างจาก:


12:00 = 100
13:00 = 8000

125. Uptimeสำคัญ

Counterสะสมตาม Server Runtime

จึงควรดู:


SHOW GLOBAL STATUS LIKE 'Uptime';

ประกอบ

126. Errorเกิดหลัง MariaDB Restart

Connections/Statusอาจเปลี่ยน

ควรดู Timelineก่อน

127. Errorเกิดหลัง FiveM Restartแต่ DBไม่ Restart

น่าสงสัย Login Burst/Client Lifecycleมากขึ้น

128. Errorเกิดหลัง Network Incident

ถ้า Database Remote:

ตรวจ Infrastructure

129. Errorเกิดหลัง VPS Migration

เปรียบเทียบ:

Network latency
packet loss
firewall
DB connection config

130. Errorหลังเปลี่ยน Region

Distanceระหว่าง FiveMกับDatabaseอาจเพิ่ม

131. ควรวาง Databaseใกล้ FiveMไหม

โดยทั่วไป Networkที่เสถียรและ Latencyต่ำมีประโยชน์

แต่ไม่ต้องย้าย Databaseเพราะ1161เพียงครั้งเดียว

132. Errorซ้ำทุกวันจึงค่อยพิจารณา Architecture

หลัง Optimize Queryแล้ว

133. Security

อย่าลด Security เช่น:

เปิด Database Public
ปิด Firewall
ปิด TLS

เพียงเพื่อทดสอบ1161โดยไม่มีเหตุผล

134. Error1161ไม่ใช่หลักฐานโดน Hack

เป็น Write Communication Timeout

135. ไม่ต้องเปลี่ยน Password

เว้นแต่มี Authentication/Security Evidenceแยก

136. ไม่ต้อง Reinstall MariaDB

Error1161ไม่ใช่หลักฐาน Installationเสีย

137. ไม่ต้องลบ Database

เด็ดขาด

138. ไม่ต้องลบ Character

ถ้า Errorเกิด Playerเดียว ให้ตรวจ Data/Queryก่อน

139. ไม่ต้องล้าง Inventory

วัด Sizeก่อน

140. ไม่ต้องเพิ่ม RAMทันที

เพราะ Root Causeอาจเป็น Queryที่คืน Dataมากเกิน

141. ขั้นตอนตรวจแบบเร็ว


1161
↓
Queryอะไร?
↓
Resourceไหน?
↓
Resultกี่ Rows / ใหญ่แค่ไหน?
↓
Local หรือ Remote DB?
↓
net_write_timeout เท่าไร?
↓
Clientอ่าน Resultช้าหรือไม่?
↓
มี Errorอื่นก่อนหน้าหรือไม่?
↓
แก้ Query / Client / Network
↓
เพิ่ม Timeoutเมื่อจำเป็นจริง

142. ถ้า Errorเกิดเฉพาะ Queryเดียว

ตรวจ Queryนั้นก่อน

143. ถ้า Errorเกิดเฉพาะ Admin Logs

เพิ่ม:

WHERE
LIMIT
Pagination

ตาม Requirementจริง

144. ถ้า Errorเกิดเฉพาะ Phone

ตรวจ Messages/Attachments Result

145. ถ้า Errorเกิดเฉพาะ Banking History

ตรวจ Transaction History Query

146. ถ้า Errorเกิดเฉพาะ Playerหนึ่ง

วัด:

metadata
inventory
history

ของ Playerนั้น

147. ถ้า Errorเกิดทุก Player

ตรวจ Shared Query/Core Resource

148. ถ้า Errorเกิดทุก Resource

ตรวจ Database Wrapper/Network/Server Load

149. ถ้า Errorเกิดเฉพาะ Remote DB

Networkควรเป็นหนึ่งใน Priorityหลัก

150. ถ้า Errorเกิด Localhost

เน้น:

FiveM process
wrapper
query
system load

151. FiveM Error 1161 FAQ

FiveM MySQL Error 1161 คืออะไร

MariaDB Error1161 / SQLSTATE08S01 / ER_NET_WRITE_INTERRUPTED หมายถึง Got timeout writing communication packets.

Error1161กับ1160ต่างกันอย่างไร

1160คือ Errorตอน Write Communication ส่วน1161คือ Timeoutตอน Write Communication.

Error1161กับ1159ต่างกันอย่างไร

1159คือ Timeoutตอน MariaDBอ่านจาก Client ส่วน1161คือ Timeoutตอน MariaDBส่งข้อมูลไป Client.

net_write_timeout คืออะไร

เป็น Server Settingที่ควบคุมช่วงเวลาที่เกี่ยวกับการส่งข้อมูลไป Client; MariaDB Connector/J Documentationปัจจุบันระบุ Default60วินาที.

ดู net_write_timeoutอย่างไร


SHOW VARIABLES LIKE 'net_write_timeout';

เพิ่ม net_write_timeoutช่วยไหม

ช่วยได้หาก Clientจำเป็นต้องใช้เวลารับ Result Setนานจริง แต่ไม่ควรใช้แทนการแก้ Queryที่คืนข้อมูลมากเกินหรือ Clientที่ค้าง

ตั้งเป็น600ได้ไหม

ทำได้หรือไม่ได้ขึ้นกับ MariaDB Version/Configuration แต่ไม่มีเหตุผลให้ใช้ค่า600เป็นมาตรฐาน FiveMทุก Server

Result Setใหญ่ทำ Error1161ได้ไหม

เป็นหนึ่งในกรณีสำคัญที่ควรตรวจ เพราะ MariaDB Connector/J Documentationระบุว่า Clientที่อ่าน Result Setใหญ่ช้าอาจชน net_write_timeout.

SELECT * เกี่ยวไหม

ถ้า Queryดึง ColumnsหรือRowsจำนวนมากเกิน Featureต้องใช้ ก็สามารถทำ Resultใหญ่โดยไม่จำเป็น

Logsเกี่ยวไหม

มาก เพราะ Logs Tablesมักโตตามเวลา

Phone Messagesเกี่ยวไหม

ควรตรวจถ้า Resourceดึง Message Historyจำนวนมาก

Inventoryเกี่ยวไหม

ควรตรวจถ้า Resourceดึง Inventories/Metadataจำนวนมากพร้อมกัน

Housingเกี่ยวไหม

ควรตรวจหาก Queryส่ง Furniture JSONจำนวนมาก

Vehicle Propertiesเกี่ยวไหม

ควรตรวจหาก Resourceดึงรถจำนวนมากพร้อม Propertiesขนาดใหญ่

Error Playerเดียวทำอย่างไร

เปรียบเทียบ Data/Result Sizeของ Playerนั้นกับคนปกติ

Errorทุก Playerทำอย่างไร

ตรวจ Core Query, Database Wrapperและ Infrastructure

Errorเฉพาะ Admin Panelทำอย่างไร

ตรวจ Query Scope, Paginationและ Result Size

Errorหลัง Server Restartทำอย่างไร

ตรวจ Login Burstและ Database Client Load

Errorหลัง Resource Restartทำอย่างไร

ตรวจ Resource/Wrapper Lifecycleและ Pending Queries

Errorหลัง Hosting Migrationทำอย่างไร

ตรวจ Network Route, Firewallและ Database Configuration

Error Remote Databaseทำอย่างไร

ตรวจ Network Stabilityร่วมกับ Query Result Sizeและ Timeout

Pingปกติแปลว่า Networkไม่มีปัญหาไหม

ไม่ เพราะ Pingไม่ใช่ Database TCP Session

Error1161หมายถึง Serverช้าไหม

ไม่เสมอไป อาจเป็น Clientอ่าน Resultช้า, Network Stallหรือ Resultใหญ่เกินไป

เพิ่ม CPUช่วยไหม

เฉพาะเมื่อ Metricsพิสูจน์ว่า CPU Bottleneckเป็นต้นเหตุ ไม่ใช่ First Fix

เพิ่ม RAMช่วยไหม

เช่นเดียวกัน Error1161อย่างเดียวไม่พิสูจน์ว่า RAMไม่พอ

max_allowed_packetเกี่ยวไหม

เป็นคนละ Limit แต่ควรตรวจเมื่อมี Error1153หรือ Payload/Resultขนาดใหญ่มาก

net_read_timeoutเกี่ยวไหม

เป็นคนละ Direction; net_read_timeoutเกี่ยวกับ Serverรออ่านข้อมูลจาก Client

wait_timeoutเกี่ยวไหม

เป็นคนละเรื่อง โดยทั่วไปเกี่ยวกับ Idle Connectionมากกว่า

MariaDB Error Logช่วยไหม

ช่วย เพราะ MariaDBสามารถบันทึก Connection Errors/Timeouts และเพิ่มรายละเอียด Read/Write Connection Errorsผ่านระดับ Loggingที่เหมาะสม.

Aborted_clientsช่วยไหม

ใช้ดูจำนวน Client Connectionsที่ถูก Abortเป็นข้อมูลประกอบได้.

SQL Backupทำ Error1161ได้ไหม

Large Data Transferเป็นอีก Use Caseหนึ่ง และ MariaDB Documentationระบุว่าการ Transfer Tablesขนาดใหญ่อาจต้องพิจารณา net_read_timeout/net_write_timeoutตาม Workloadจริง.

Clear FiveM Cacheช่วยไหม

โดยทั่วไปไม่

Restart FiveMช่วยไหม

อาจ Reset Connectionsชั่วคราว แต่ไม่แก้ Query/Networkที่เป็น Root Cause

Restart MariaDBช่วยไหม

ไม่ควรเป็น First Fix

Reinstall MariaDBช่วยไหม

ไม่

ต้องลบ Databaseไหม

ไม่

ต้อง Backupไหม

หากจะแก้:

Queryอย่างเดียว — ไม่จำเป็นต้องแก้ Data
Index/Schema — ควร Backupก่อน
JSON/Player Data — ควร Backupก่อน
Migration — ควร Backupก่อน

สรุป FiveM MySQL Got Timeout Writing Communication Packets Error 1161

FiveM MySQL/MariaDB Error 1161 Got timeout writing communication packets หมายถึง MariaDB ใช้เวลาส่งข้อมูลกลับไปยัง Database Client นานเกินช่วงเวลาที่กำหนด โดย MariaDBกำหนด Errorนี้เป็น ER_NET_WRITE_INTERRUPTED, SQLSTATE 08S01.

จุดสำคัญคือ net_write_timeout โดย MariaDB Connector/J Documentation ปัจจุบันระบุ Default ไว้ที่ 60 วินาที และระบุว่ากรณี Result Setขนาดใหญ่เป็นสถานการณ์สำคัญที่ควรพิจารณา เพราะ Serverคาดหวังให้ Clientอ่านข้อมูลออกไปในเวลาที่เหมาะสม.

จำ Flow นี้:


Error 1161
↓
หา Resource
↓
หา Query
↓
ดู Result Size
↓
ตรวจ net_write_timeout
↓
Local หรือ Remote DB?
↓
Client ค้างหรือไม่?
↓
Network มีปัญหาหรือไม่?
↓
มี 1153 / 1160 / 2006 / 2013 ก่อนหน้าหรือไม่?
↓
ลด Result ที่ไม่จำเป็น
↓
แก้ Client / Network
↓
ค่อยเพิ่ม Timeoutเมื่อจำเป็นจริง

สิ่งที่ comsiam แนะนำคืออย่าเพิ่ม net_write_timeout จาก60เป็นหลายร้อยหรือหลายพันวินาทีทันที หาก Queryกำลัง SELECT * จาก Logsหลายล้าน Rows, โหลด Phone Messagesทั้งหมดหรือดึง JSONขนาดใหญ่ที่ไม่ได้ใช้ การเพิ่ม Timeoutเพียงเปิดทางให้ Queryที่ไม่ Scaleทำงานนานขึ้น แต่ไม่ได้ลด Dataที่ MariaDBต้องส่ง

อีกหลักที่ comsiam แนะนำคือให้มอง Error1161เป็นปัญหา “MariaDBส่งข้อมูลออกแต่ปลายทางรับไม่ทัน” แล้วแยกสาเหตุเป็นสามกลุ่ม: Result ใหญ่เกินจำเป็น, Client/Wrapperประมวลผลไม่ทัน หรือ Networkไม่เสถียร หาก Queryถูกออกแบบถูกต้องและ Resultขนาดใหญ่เป็น Requirementจริง จึงค่อยเพิ่ม net_write_timeoutอย่างมีข้อมูลรองรับ พร้อมทดสอบ Queryเดิมและ Monitorว่า Errorหายโดยไม่สร้าง Latencyหรือ Connectionค้างผิดปกติ