FiveM MySQL Got Timeout Reading Communication Packets Error 1159 แก้อย่างไร? ตรวจ net_read_timeout, Network และ Database Connection ที่ส่งข้อมูลไม่ทัน

August 17, 2026

ปัญหา FiveM MySQL/MariaDB ขึ้น Got timeout reading communication packets หรือ Error 1159 เกิดเมื่อ MariaDB กำลังรอให้ Client ส่งข้อมูลเพิ่มเติมผ่าน Connection แต่รอนานเกินเวลาที่กำหนด จึงยกเลิกการอ่านและคืน Error ออกมา

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


ER_NET_READ_INTERRUPTED
Got timeout reading communication packets

โดยตรง.

สำหรับ FiveM ตัว Client ที่ MariaDB กำลังรออาจเป็น:

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

และ MariaDB กำหนด net_read_timeout เป็นจำนวนวินาทีที่ Server จะรอให้ Client Connection ส่งข้อมูลเพิ่มเติมก่อนยกเลิกการอ่าน โดยค่าปริยายในเอกสารปัจจุบันคือ 30 วินาที.

ตัวอย่าง Error ที่อาจพบ:


ERROR 1159 (08S01):
Got timeout reading communication packets

หรือ MariaDB Error Log อาจแสดง:


Aborted connection ...
(Got timeout reading communication packets)

MariaDB มีตัวอย่าง Warning ลักษณะนี้ในเอกสาร Error Log โดยตรง.

หลักการแก้คือ:

ดูว่า Client ไหน Timeout → ตรวจ net_read_timeout → ดู Query/Payload → ตรวจ Network → ตรวจ Resource/Wrapper → ตรวจว่าเป็น Timeout จริงหรือมี Error อื่นเกิดก่อนหน้า

① Error 1159 คืออะไร

MariaDB Error 1159 หมายถึง:


Got timeout reading communication packets

และใช้ชื่อภายใน:


ER_NET_READ_INTERRUPTED

SQLSTATE:


08S01

② คำว่า Reading หมายถึงใครอ่านใคร

ใน Error นี้ MariaDB Server กำลัง อ่านข้อมูลจาก Client

Flow โดยย่อ:


FiveM
↓
Database Wrapper
↓
Database Connection
↓
MariaDB รออ่านข้อมูล
↓
Client ส่งไม่ทัน
↓
Timeout

③ ตัวแปรสำคัญคือ `net_read_timeout`

MariaDB ระบุ:


net_read_timeout

คือเวลาที่ Server รอให้ Client ส่งข้อมูลเพิ่มก่อน Abort การ Read.

④ Default ปัจจุบัน

เอกสาร MariaDB ระบุ Default:

วินาที.

แต่ Database ของคุณอาจตั้งต่างจาก Default

⑤ ตรวจค่าปัจจุบัน

ใช้:


SHOW VARIABLES LIKE 'net_read_timeout';

หรือ:


SELECT @@net_read_timeout;

⑥ ถ้าได้ 30

หมายความว่า Session นั้นใช้ค่าที่เกี่ยวข้องกับการรอ Read ตาม Configuration ปัจจุบัน โดย net_read_timeout เป็นตัวแปรแบบ Global/Session และ Dynamic.

⑦ ควรเพิ่มจาก 30 เป็น 300 ทันทีไหม

ไม่ควร

เพราะ Error อาจเกิดจาก:

Resource ค้าง
Network หลุด
Client ถูก Restart
Payload ใหญ่ผิดปกติ
Database Wrapper มีปัญหา

การเพิ่ม Timeout อาจเพียงทำให้ MariaDB รอนานขึ้นก่อน Error

⑧ ต่างจาก Error 1158 อย่างไร

หัวข้อก่อนหน้า:


1158
Got an error reading communication packets

คือ Error ระหว่างการอ่าน

ส่วน:


1159
Got timeout reading communication packets

คือ รออ่านนานเกิน Timeout.

⑨ จำง่าย ๆ


1158 = Read Error
1159 = Read Timeout

⑩ แล้ว Error 1160 คืออะไร

MariaDB กำหนด Error 1160 เป็น:


Got an error writing communication packets

คือฝั่ง Server มีปัญหาตอน เขียนข้อมูลออกไปยัง Client.

⑪ Error 1161

ในชุด Error Code เดียวกัน MariaDB แยก 1161 เป็น Timeout ตอน Write Communication.

⑫ จำชุดนี้ไว้


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

⑬ Error 1159 เป็น SQL Syntax Error ไหม

ไม่

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

1159 อยู่ในกลุ่ม Communication Error และใช้ SQLSTATE 08S01.

⑭ Clear FiveM Cache ช่วยไหม

โดยทั่วไปไม่ใช่จุดแก้ เพราะปัญหาอยู่ระหว่าง Database Client กับ MariaDB

⑮ Restart FiveM ช่วยไหม

อาจทำให้ Connections ถูกสร้างใหม่และอาการหายชั่วคราว

แต่ถ้า Resource หรือ Network ยังมีปัญหา:

Error สามารถกลับมา

⑯ Restart MariaDB ช่วยไหม

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

เพราะ Restart จะตัด Database Connections ทั้งหมดและไม่ได้แก้ Client ที่ส่งข้อมูลช้าหรือผิดปกติ

⑰ Error เกิดตอน Resource Restart

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

เช่น:


MariaDB กำลังอ่าน request
↓
Resource restart
↓
Client หาย/หยุดส่ง
↓
MariaDB รอ
↓
Timeout

⑱ Error เกิดตอน FiveM Shutdown

หาก Process ถูกปิดในขณะที่ Database Communication กำลังเกิด:

MariaDB อาจบันทึก Connection Warning ได้ตาม Timing ของ Client/Server

⑲ Error เกิดตอน Script Crash

ตรวจ FiveM Console ก่อน Error 1159

ถ้ามี:


Lua error
JavaScript exception
resource stopped

อาจเป็น Root Cause ฝั่ง Application

⑳ อย่าปรับ MariaDB ก่อนดู FiveM Console

เพราะ Database อาจเป็นเพียงระบบที่รายงานผลจาก Resource ที่หยุดทำงาน

㉑ Remote Database สำคัญมาก

ถ้า FiveM และ MariaDB อยู่คนละ Server:


FiveM Server
↓
Network
↓
MariaDB Server

Network Latency และความเสถียรจึงเป็นอีกชั้นหนึ่งของระบบ

㉒ Network ช้าสามารถเกี่ยวได้ไหม

ได้ในเชิงการส่งข้อมูล เพราะ MariaDB กำลังรอ Client ส่งข้อมูลเพิ่มเติมและ net_read_timeout กำหนดเวลารอนั้น.

㉓ แต่ Ping สูงไม่ได้แปลว่าจะเกิด 1159 แน่นอน

ต้องดู Database Connection จริง

ไม่ใช่ดู ICMP Ping อย่างเดียว

㉔ Packet Loss

ถ้า Connection มี Loss หรือ Stall หนัก:

Data Transfer อาจช้าหรือหยุดกลางทาง

จึงควรตรวจ Network เพิ่มเมื่อเป็น Remote DB

㉕ Database อยู่ localhost

1159 ก็ยังเกิดได้

เพราะ Client Application สามารถค้างหรือหยุดส่งข้อมูลได้โดยไม่เกี่ยวกับ Internet

㉖ Connection Pool เกี่ยวไหม

เกี่ยวได้

ถ้า Pool/Connector ถือ Connection ไว้แล้ว Resource เริ่มส่ง Request แต่ Flow ถูกขัดจังหวะ:

Server อาจรอข้อมูลต่อ

㉗ Pool ไม่ใช่ปัญหาโดยตัวมันเอง

Connection Pool เป็นแนวทางมาตรฐานใน Database Clients

ต้องดู Implementation จริง

㉘ อย่าสร้าง Pool ใหม่ทุก Event

ตัวอย่างไม่เหมาะ:


player opens phone
↓
create database pool
↓
query

ทำซ้ำทุกครั้ง

㉙ Database Wrapper ควรจัดการ Pool ตาม Lifecycle ของ Library

ถ้า Framework มี Wrapper หลักอยู่แล้ว:

Resource ทั่วไปควรใช้ API ตามที่ Wrapper ออกแบบ

㉚ Error หลัง Update Database Wrapper

ตรวจ:

Wrapper Version
Resource Compatibility
Pool Configuration
Timeout Configuration

㉛ Error หลังติด Resource ใหม่

ถ้า 1159 เริ่มทันทีหลังติด Script:

ตรวจ Resource นั้นก่อนปรับ MariaDB Global Settings

㉜ Resource อาจส่ง Payload ใหญ่

เช่น:

Inventory JSON
Character Metadata
Vehicle Properties
Furniture

㉝ Payload ใหญ่เกี่ยวอย่างไร

Payload ที่ใหญ่มากใช้เวลาส่งมากขึ้น

ถ้า Client ส่งข้อมูลช้าหรือหยุดกลางทาง:

MariaDB อาจรอเกิน net_read_timeout

㉞ แต่ Packet ใหญ่เกิน Limit มี Error เฉพาะ

MariaDB Error 1153 คือ:


Got a packet bigger than
'max_allowed_packet' bytes

ดังนั้นถ้ามี 1153 เกิดก่อน 1159:

ให้ตรวจ Packet Size ก่อน.

㉟ อ่าน Error ก่อนหน้าเสมอ

ตัวอย่าง:


1153 packet too large
↓
connection/problem
↓
1159 read timeout

Root Cause อาจไม่ใช่ net_read_timeout

㊱ Character Save

ถ้า Error เกิดตอน Save Character:

ตรวจ Payload ของ:

Metadata
Inventory
Appearance

㊲ Error เฉพาะ Character หนึ่งคน

น่าสงสัย Data เฉพาะ Record นั้น

㊳ Error ทุก Character

น่าสงสัย:

Database Wrapper
Core Save
Network

มากขึ้น

㊴ Inventory Save

Inventory ที่มี Metadata ใหญ่หรือผิดปกติอาจสร้าง Request ขนาดใหญ่

㊵ Housing Save

Furniture/Object JSON อาจมี Data จำนวนมาก

㊶ Phone Resource

Attachment หรือ Social/Message Payload ที่ใหญ่ผิดปกติควรถูกตรวจ

㊷ Vehicle Properties

รถคันเดียว Error:

เปรียบเทียบ Serialized Properties กับรถปกติ

㊸ Error เฉพาะตอน Auto Save

อาจเกิด Write Burst:


players จำนวนมาก
↓
save พร้อมกัน
↓
DB client workload เพิ่ม

㊹ Auto Save กับ net_read_timeout

อย่าเพิ่ม Timeoutทันที

ตรวจว่ามี Resourceส่ง Query/Payloadผิดปกติหรือ Threads ค้างก่อน

㊺ Error ตอน Payday

Paydayอาจทำ Database Requestsจำนวนมากพร้อมกัน

ถ้า Errorเกิดเวลาเดียวกันทุกครั้ง:

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

㊻ Error ทุก 30 นาที

ค้นหา:

Scheduled save
Cleanup
Report
Cron-like Resource

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

㊼ Error เวลาเดิมทุกวัน

ตรวจ:

Backup
Maintenance
Auto restart
Database jobs

㊽ Error เฉพาะช่วง Server Restart

ต่างจาก Errorที่เกิดระหว่าง Gameplayปกติ

อาจเป็นเพียง Lifecycle/Shutdown Behavior

㊾ Error ระหว่าง Gameplay ทุกไม่กี่นาที

ควร Debug จริงจัง

㊿ MariaDB Error Log ช่วยได้

MariaDB Error Log สามารถแสดง Warning ของ Aborted Connection พร้อมข้อความ Got timeout reading communication packets.

51. Error Log อาจบอกอะไร

เช่น:

User
Host
Database
Connection ID

ช่วยหา Client ต้นทาง

52. ถ้ามีหลาย Applications ใช้ DB เดียวกัน

เช่น:

FiveM
Website
API

1159 อาจไม่ได้มาจาก FiveM

53. Database User แยกกันมีประโยชน์

เช่น:


fivem_user
web_user
api_user

ช่วย Observability

54. แต่ไม่ต้องเปลี่ยน User เพราะ Error ครั้งเดียว

ใช้ Existing Logs ก่อน

55. `Aborted_clients`

MariaDB มี Status Variables สำหรับ Aborted Client Connections ซึ่งสามารถใช้ประกอบการวิเคราะห์ Connection ที่จบผิดปกติได้.

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


SHOW GLOBAL STATUS LIKE 'Aborted_clients';

57. ดูเป็น Trend

ไม่ใช่ดูเลขเดียว

เช่น:


เวลา 16:00 = 120
เวลา 17:00 = 125

ต่างจาก:


เวลา 16:00 = 120
เวลา 17:00 = 5000

58. Counter สูงไม่ได้แปลว่าโดนโจมตี

ต้องดู:

Server uptime
Traffic
Logs

ร่วมกัน

59. Error1159หมายถึงโดนแฮ็กไหม

ไม่

Error นี้เป็น Communication Read Timeout ไม่ใช่หลักฐานการถูกแฮ็ก.

60. ต้องเปลี่ยน Database Passwordไหม

ไม่ใช่ First Fix

Authentication Errors มี Error Codes แยก

61. `wait_timeout` เหมือน `net_read_timeout` ไหม

ไม่

`wait_timeout`

เกี่ยวกับ Connection ที่ไม่มี Activity

`net_read_timeout`

Server กำลังรอ Client ส่งข้อมูลเพิ่มระหว่างการอ่าน.

62. อย่าสับสนสองค่า

การเพิ่ม wait_timeout ไม่ได้แปลว่าแก้ Read Timeout 1159 ได้

63. Errorหลัง Idleนาน

ถ้า Connectionไม่ทำอะไรเลยนานแล้วถูกปิด:

wait_timeout อาจเกี่ยวมากกว่า

64. Errorระหว่างกำลังส่ง Query/Payload

net_read_timeout มีความเกี่ยวข้องมากขึ้น

65. `net_write_timeout` คือคนละฝั่ง

Serverกำลังเขียน Data กลับ Client

ไม่ใช่กำลังอ่านจาก Client

66. ถ้า Errorคือ1161

ค่อยเน้น Write Timeout

67. เพิ่ม `net_read_timeout` ได้ไหม

ได้เพราะ MariaDB ระบุเป็น Dynamic Global/Session Variable.

แต่ควรปรับเมื่อมีหลักฐานว่าค่าเดิมต่ำเกิน Workload จริง

68. อย่าใช้ค่ามหาศาล

เช่นปรับจาก:

เป็น:

เพียงเพื่อให้ Errorหาย

69. ทำไม

MariaDB จะรอ Client ที่มีปัญหานานขึ้น

อาจทำให้ Connection ถูก Occupy นานโดยไม่จำเป็น

70. ก่อนเพิ่มควรถาม

ทำไม FiveM Client ต้องใช้เวลาส่งข้อมูลเกิน 30 วินาที?

ถ้าเป็น Query/Payloadปกติ:

นี่อาจชี้ว่ามีปัญหาอื่น

71. ถ้า Payloadใหญ่มากจริง

ต้องถามอีกว่า:

มันควรใหญ่ขนาดนั้นหรือไม่?

72. Inventory JSONหลายสิบ MB

ไม่ควรรีบถือเป็น Normal Requirement

ตรวจ Data Growth Bug

73. Character Metadata โตทุก Save

เป็น Red Flag

74. Furniture Data โตทุก Save

เป็น Red Flag

75. Double Serialization

อาจทำ Payloadโตแบบไม่จำเป็น

76. Duplicate Data

Resourceอาจ Append Stateเดิมซ้ำ

77. ตรวจ Data Size

เช่น:


SELECT LENGTH(metadata)
FROM characters
WHERE id = ?;

ใช้ Table/Columnจริงของ Server

78. หา Record ใหญ่


SELECT id, LENGTH(metadata)
FROM characters
ORDER BY LENGTH(metadata) DESC
LIMIT 20;

ใช้เป็นแนวคิด Read-only Diagnosis

79. Playerปกติ 20 KB แต่ Playerหนึ่ง 50 MB

ควรตรวจ Recordนั้นก่อนปรับ Global Timeout

80. ถ้าทุก Recordใหญ่ใกล้เคียงกัน

อาจเป็น Requirementจริง

แล้วจึงประเมิน Config/Architecture

81. Error1159กับQueryช้า

Queryช้าไม่เท่ากับ Read Timeoutโดยตรง

เพราะ 1159เกี่ยวกับ Serverรอ อ่านจาก Client

82. อย่าสับสนกับ Query Execution Time

ถ้า SQLส่งครบแล้วและ Databaseกำลังประมวลผลช้า:

ต้องตรวจ Query Performanceคนละเรื่อง

83. Errorนี้มักเกิดก่อน Query Executionเต็มรูปแบบได้

เพราะ Serverยังรอรับ Client Data

84. Bulk INSERT

StatementหรือParametersขนาดใหญ่อาจใช้เวลา Transferมากขึ้น

85. Logger Resource

ถ้ารวม Logsจำนวนมากเป็น Batchเดียว:

Payloadอาจโต

86. Batchเล็กลงช่วยไหม

อาจช่วยสำหรับ Logging/Background Data หาก Resourceรองรับ

แต่ต้องออกแบบตาม Use Case

87. Bankingไม่ควรแบ่งแบบสุ่ม

Money Transactionมี Atomicity Requirementsสูงกว่า

88. Network Compression

อย่าปรับ Compression Protocolเองถ้า Database Wrapperไม่ได้รองรับอย่างชัดเจน

89. TLS/SSL

Remote Databaseที่ใช้ TLSมี Layerเพิ่มเติม แต่ไม่ควรปิด Encryptionเพื่อทดสอบโดยไม่จำเป็น

90. Securityไม่ควรถูกลดเพื่อแก้ Timeout

ให้หา:

Network
Resource
Payload

ก่อน

91. Database Proxy

ถ้าใช้ Proxy หรือ Load Balancer:

อาจมี Timeoutของ Proxyอีกชั้น

92. แต่ FiveM Serverทั่วไปอาจไม่มี Proxy

อย่าแก้ Componentที่ Serverไม่ได้ใช้

93. Firewall

Remote DBอาจผ่าน Firewall/NAT

Connection ResetหรือSession Handlingของ Infrastructureควรถูกตรวจเมื่อมีหลักฐาน Network Issue

94. อย่าเปิด Port3306ให้ทุกคน

เพื่อแก้1159

Databaseควรจำกัด Accessตาม Infrastructureจริง

95. Error1159บน Same Host

ตัด Internet Providerออกจาก Listได้บางส่วน

แต่ยังต้องตรวจ:

Resource
Wrapper
Local system load

96. CPUเต็มเกี่ยวไหม

ถ้า FiveM/Database Clientไม่สามารถทำงานได้ทันและหยุดส่งข้อมูลเป็นเวลานาน:

System Loadอาจเป็นปัจจัยทางอ้อม

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

97. RAMไม่พอ

ถ้า Process Swapหนักหรือถูก OOM:

Connectionsอาจผิดปกติได้

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

98. Disk I/O

ไม่ใช่สาเหตุโดยตรงของ Client Read Timeoutเสมอไป

ต้องดูว่า Resourceกำลังติด I/Oจนหยุดส่ง Dataหรือไม่

99. อย่า Upgrade Hardwareก่อนหา Root Cause

1159อาจเป็นเพียง Resource Bug

100. Errorหลัง Playerใช้ Featureหนึ่ง

เช่น:


เปิด inventory
↓
1159

ให้ตรวจ Inventory Resourceก่อน

101. Errorหลัง Upload Image

Payloadอาจมีขนาดใหญ่

ตรวจ:

Base64
Attachment
Packet

102. Base64 เพิ่มขนาด Data

ถ้า Resourceส่งรูปเป็น Text:

Payloadอาจใหญ่กว่าต้นฉบับ Binary

103. Server-side Size Limitสำคัญ

อย่าพึ่ง Client UI จำกัดขนาดอย่างเดียว

104. Clientสามารถถูกแก้ไข

Validationต้องอยู่ Serverด้วย

105. Errorหลัง Crafting Item

Item Metadataอาจถูก Copyซ้อนจนใหญ่ขึ้น

106. Errorหลัง Vehicle Save

Vehicle Propertiesอาจมี Objectที่ไม่ควรถูก Serializeเข้ามา

107. Parameter Mappingผิด

เช่น Queryต้องการ:


vehicleProperties

แต่ Resourceส่ง:


allVehicles

Payloadจะใหญ่ผิดปกติ

108. ตรวจ Query Parameters

สำคัญกว่าการดู SQL Textอย่างเดียว

เพราะ SQLอาจสั้น:


UPDATE vehicles SET props = ? WHERE id = ?

แต่ ? ตัวแรกอาจใหญ่หลายสิบ MB

109. Prepared Statementไม่ได้ทำ Payloadหาย

Parameterยังต้องถูกส่งไป Database

110. Errorหลัง NUIส่ง Objectใหญ่

Flow:


NUI
↓
Client
↓
Server
↓
Database

Root Causeอาจเริ่มตั้งแต่ NUI

111. Serverควร Whitelist Fields

ไม่รับ Arbitrary Objectทั้งก้อนแล้ว Save

112. Error1159หลัง Player Disconnect

ถ้า Resourceมี Database Operationที่ผูก Lifecycleกับ Clientผิด:

ควรตรวจ Callback/Promise Flow

113. Player Disconnectไม่ควรทำให้ Databaseค้างโดยอัตโนมัติ

ขึ้นกับ Resource Design

114. Resource Stopมีผลมากกว่า

เพราะ Process/Moduleที่ส่งข้อมูลอาจถูกยุติโดยตรง

115. Errorหลัง `restart resource`

ถ้า Resourceมี Pending DB Operations:

ยิ่งควรตรวจ

116. Productionไม่ควร Restart Core Resourcesสุ่ม

โดยเฉพาะ:

Banking
Inventory
Character Core

117. Graceful Maintenance

ทำช่วงคนเล่นน้อยหรือ Maintenance Windowจะปลอดภัยกว่า

118. Errorหลัง Database Migration

Migration Toolอาจส่ง Statementขนาดใหญ่มาก

119. ถ้า Runtimeไม่ Error

แต่ Import SQLเกิด1159:

โฟกัส Import Workflow

ไม่ต้อง Rewrite FiveM Runtime

120. Errorหลัง SQL Dump Restore

ตรวจ:

Statement Size
Network
Import Tool
net_read_timeout

121. Error1153ร่วมด้วย

ตรวจ max_allowed_packetก่อน

เพราะ MariaDBมี Errorเฉพาะเรื่อง Packetใหญ่.

122. Error2006ร่วมด้วย

อาจหมายถึง Connectionต่อมาไม่สามารถใช้ได้

123. Error2013ร่วมด้วย

อาจพบ Connectionหลุดกลาง Queryใน Client Layer

124. Error1040ร่วมด้วย

Connectionsอาจเต็ม

เป็นอีก Root Causeหนึ่ง

125. อ่าน Timeline

ตัวอย่าง:


1040 Too many connections
↓
resources retry
↓
network/client stress
↓
1159

อาจเป็น Connection Storm

126. หรือ:


1153 packet too large
↓
connection disturbed
↓
1159

อาจเป็น Payload Problem

127. Errorแรกมักมีคุณค่า

อย่าแก้ Errorบรรทัดสุดท้ายอย่างเดียว

128. Quick Check

ใช้:


SHOW VARIABLES LIKE 'net_read_timeout';

แล้ว:


SHOW GLOBAL STATUS LIKE 'Aborted_clients';

พร้อมดู MariaDB Error Log

129. ถ้าค่า net_read_timeout ต่ำผิดปกติ

เช่นถูกปรับเหลือ:

วินาที

อาจมีโอกาส Timeoutง่ายกว่า Default 30วินาทีที่ MariaDBระบุ.

130. แต่ถ้าค่า30แล้วยังเกิด

อย่ารีบเพิ่ม

หา Clientที่ใช้เวลาเกิน30วินาที

131. ถ้าค่า600แล้วยังเกิด

ยิ่งต้องสงสัย Resource/Networkหนัก

เพราะ MariaDBต้องรอนานมากก่อน Timeout

132. Query Diagnostic

เก็บ:

Resource name
Timestamp
Feature
Payload size
Remote/local DB

133. Database Diagnostic

เก็บ:

net_read_timeout
Error Log
Aborted_clients
Uptime

134. Network Diagnostic

ถ้า Remote:

packet loss
latency
route/network incidents

135. Resource Diagnostic

ตรวจ:

crashes
restarts
promise/callback timeout
payload

136. Database Uptime

หาก MariaDBเพิ่ง Restart:

Connection Errorหลายชนิดอาจตามมา

จึงควรดู:


SHOW GLOBAL STATUS LIKE 'Uptime';

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

ให้ตรวจ Database/Network/Wrapperส่วนกลางก่อน

138. Error Resourceเดียว

ตรวจ Resourceนั้น

139. Error Playerเดียว

ตรวจ Player Data

140. Error Featureเดียว

ตรวจ Query/Payloadของ Featureนั้น

141. Errorเฉพาะ Remote DB

ตรวจ Network Pathก่อนปรับ SQL Schema

142. Errorหลัง Serverว่างนาน

ตรวจ wait_timeout และ Pool Stalenessร่วมด้วย

แต่แยกจาก net_read_timeout

143. Errorตอนกำลังส่งข้อมูล

เน้น net_read_timeout

144. Errorตอนรับ Resultจาก Database

ฝั่ง Write Timeout/Errorของ Serverอาจมีความเกี่ยวข้องมากกว่า

145. อย่าปรับ `net_write_timeout`เพื่อแก้1159โดยไม่มีเหตุผล

เพราะเป็นคนละ Direction

146. Error 1159 FAQ

FiveM MySQL Error 1159 คืออะไร

MariaDB Error1159 / SQLSTATE08S01 / ER_NET_READ_INTERRUPTED หมายถึง Got timeout reading communication packets.

`net_read_timeout` คืออะไร

เวลาที่ MariaDBรอให้ Client Connectionส่งข้อมูลเพิ่มเติมก่อนยกเลิกการอ่าน.

Default เท่าไร

MariaDB Documentationปัจจุบันระบุ Default30วินาที.

ดูค่าอย่างไร


SHOW VARIABLES LIKE 'net_read_timeout';

Error1159กับ1158ต่างกันอย่างไร

1158คือ Errorตอนอ่าน Communication Packets ส่วน1159คือ Timeoutตอนอ่าน.

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

1159คือ Read Timeout ส่วน1160คือ Errorตอน Serverเขียน Communication Packets.

Error1159กับ1161ต่างกันอย่างไร

1159คือ Read Timeout ส่วน1161คือ Write Timeout.

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

ช่วยได้เฉพาะเมื่อ Workloadต้องใช้เวลาส่งข้อมูลนานจริงและค่าเดิมต่ำเกินไป ไม่ควรใช้แทนการแก้ ResourceหรือNetworkที่ผิดปกติ

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

ไม่มีค่าที่เหมาะกับ FiveMทุก Server ต้องวิเคราะห์ Workloadจริง

Restart FiveMช่วยไหม

อาจ Reset Connectionsแต่ไม่แก้ Root Cause

Restart MariaDBช่วยไหม

ไม่ใช่ First Fixและจะตัด Connectionsอื่นทั้งหมด

Clear FiveM Cacheช่วยไหม

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

Remote Databaseเกี่ยวไหม

เกี่ยวได้ เพราะ Networkอยู่ระหว่าง FiveMกับMariaDB

Localhostเกิดได้ไหม

ได้ ถ้า Database Clientค้างหรือหยุดส่งข้อมูล

Payloadใหญ่เกี่ยวไหม

เกี่ยวได้ในเชิงใช้เวลาส่งนาน แต่ถ้าใหญ่เกิน max_allowed_packet โดยตรง MariaDBมี Error1153เฉพาะ.

Inventory JSONเกี่ยวไหม

ควรตรวจหาก Errorเกิดเฉพาะ Inventory Saveหรือ Playerที่มี Metadataขนาดผิดปกติ

Housing Furnitureเกี่ยวไหม

ควรตรวจหาก Resourceส่ง Furniture Dataจำนวนมากใน Requestเดียว

Vehicle Propertiesเกี่ยวไหม

ควรตรวจหาก Errorเกิดเฉพาะรถบางคัน

Phone Attachmentเกี่ยวไหม

ควรตรวจ Payload โดยเฉพาะ Base64/Attachmentsขนาดใหญ่

Auto Saveเกี่ยวไหม

อาจเกี่ยวหากมี Concurrent Writes/Payloadจำนวนมากพร้อมกัน

Paydayเกี่ยวไหม

อาจสร้าง Database Burstและควรถูกตรวจหาก Errorตรงเวลา Paydayเสมอ

SQL Importเกี่ยวไหม

ได้ โดยเฉพาะเมื่อ Clientส่ง StatementsหรือDataขนาดใหญ่ผ่าน Network

Errorหลัง Restart Resourceเกี่ยวไหม

ได้ในเชิง Connection Lifecycle หาก Clientหยุดส่ง Dataกลาง Communication

Aborted_clientsช่วยตรวจไหม

ช่วยดูแนวโน้ม Client Connectionsที่ถูก Abortร่วมกับ Error Log

Error Logสำคัญไหม

สำคัญ MariaDB Documentationแสดง Warning Aborted connection ... Got timeout reading communication packets โดยตรง.

ต้องเพิ่ม max_allowed_packetไหม

เฉพาะเมื่อมีหลักฐาน Packetใหญ่ เช่น1153หรือ Payloadจริงใหญ่เกิน Configuration

ต้องเพิ่ม wait_timeoutไหม

ไม่ควรสับสนกับ net_read_timeout; wait_timeoutเกี่ยวกับ Idle Connectionมากกว่า

ต้องเพิ่ม RAMไหม

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

ต้อง Upgrade VPSไหม

ยังไม่ควรสรุปจนมี CPU/RAM/Network Metricsรองรับ

Error1159หมายถึงโดน DDoSไหม

ไม่ Errorนี้อย่างเดียวไม่ใช่หลักฐาน DDoSหรือการแฮ็ก

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

ไม่ใช่ First Fix

ต้อง Reinstall MariaDBไหม

ไม่

ต้องลบ Databaseไหม

ไม่

ต้อง Backupไหม

ถ้าจะแก้:

Player Data
JSON
Migration
Schema

ควร Backupก่อน แต่การตรวจ Timeout/Logsไม่ต้องลบข้อมูลใด ๆ

สรุป FiveM MySQL Got Timeout Reading Communication Packets Error 1159

FiveM MySQL/MariaDB Error 1159 Got timeout reading communication packets หมายถึง MariaDB รอข้อมูลเพิ่มเติมจาก Client นานเกินกำหนด โดย Error นี้คือ ER_NET_READ_INTERRUPTED, SQLSTATE 08S01 และตัวแปรหลักที่เกี่ยวข้องคือ net_read_timeout ซึ่ง MariaDB Documentation ปัจจุบันระบุ Default 30 วินาที.

จำขั้นตอนนี้:


Error 1159
↓
Resource ไหน?
↓
Local หรือ Remote DB?
↓
ตรวจ net_read_timeout
↓
ดู MariaDB Error Log
↓
ตรวจ Aborted Connections
↓
Payload ใหญ่ไหม?
↓
มี 1153 / 1158 / 2006 / 2013 ก่อนหน้าหรือไม่?
↓
ตรวจ Wrapper / Network / Resource
↓
แก้ Root Cause

สิ่งที่ comsiam แนะนำคืออย่าเริ่มจากเพิ่ม net_read_timeout หลายสิบเท่าทันที เพราะค่าปริยายของ MariaDBคือ30วินาที และถ้า FiveM Resourceต้องใช้เวลานานกว่านั้นในการส่ง Requestปกติ ก็ควรถามก่อนว่ามี Payloadใหญ่, Resourceค้าง, Networkสะดุดหรือ Database Clientผิด Lifecycleหรือไม่ การเพิ่ม Timeoutอาจเพียงทำให้ MariaDBรอ Connectionที่มีปัญหานานกว่าเดิม.

อีกหลักที่ comsiam แนะนำคือให้ดู Error1159ร่วมกับ MariaDB Error Logและ Errorก่อนหน้าเสมอ ถ้ามี1153ก่อนหน้าให้ตรวจ Packet, ถ้ามี1158ให้ตรวจ Connection Abort, ถ้าเกิดเฉพาะ Remote Databaseให้ตรวจ Network และถ้าเกิดเฉพาะ Playerหรือ Featureหนึ่งให้ตรวจ Payload/Resourceนั้นก่อนปรับ Global Database Configuration วิธีนี้จะตรงจุดกว่าการ Restart Serverหรือเพิ่ม Timeoutแบบสุ่ม