CyberPanel dead lock issue No request delivery notification has been received from LSAPI application

[TenHoshi]

Cách xử lý lỗi​

“No request delivery notification has been received from LSAPI application, possible dead lock”
trên CyberPanel / OpenLiteSpeed

Lỗi này là gì?​

Thông báo:

No request delivery notification has been received from LSAPI application, possible dead lock

Có nghĩa là OpenLiteSpeed đã gửi request sang PHP (LSAPI / lsphp) nhưng không nhận được phản hồi đúng hạn, nên nghi ngờ PHP bị “kẹt”.

Đây không phải bug CyberPanel, mà là dấu hiệu backend (PHP / MySQL) đang bị nghẽn tạm thời.

Vì sao lỗi này hay gặp trên CyberPanel?​

Do CyberPanel dùng OpenLiteSpeed + LSAPI, cơ chế giao tiếp khác với Nginx + php-fpm.

• Khi PHP bị block (chờ DB, IO, API ngoài…)
• LiteSpeed không nhận được tín hiệu ACK
• ⇒ ghi log “possible dead lock”

Trong khi đó:

• Nginx thường báo upstream timed out
• Bản chất lỗi là giống nhau

Dấu hiệu thường thấy khi gặp lỗi​

• CPU thấp, load thấp
• Nhưng:
  • RAM gần đầy
  • MySQL có rất nhiều connection ở trạng thái Sleep
  • Log LiteSpeed spam dòng possible dead lock
• Restart lsphp/MySQL thì hết tạm, nhưng vài giờ sau lại bị

Nguyên nhân phổ biến (theo mức độ hay gặp)​

Nguyên nhân #1: MySQL giữ connection “Sleep” quá lâu​

MySQL mặc định:

wait_timeout = 28800 (8 tiếng)
interactive_timeout = 28800

Nếu app:

• mở nhiều connection
• không đóng đúng cách
• hoặc dùng connection pool lớn

thì connection sẽ nằm Sleep hàng giờ, tốn RAM, làm PHP dễ bị kẹt khi traffic tăng.

Nguyên nhân #2: App backend mở quá nhiều connection​

Thường gặp khi:

• Node.js dùng pool lớn + PM2 cluster
• PHP dùng persistent connection
• Cron / job mở connection nhưng không đóng

Mỗi request chiếm 1 connection → dồn lại rất nhanh.

Nguyên nhân #3: DB lock / query nặng ngắn hạn​

Ví dụ:

• ALTER TABLE
• metadata lock
• query thiếu index

PHP chờ DB → LSAPI không phản hồi kịp.

Cách kiểm tra nhanh (khuyến nghị)​

Kiểm tra MySQL connection​

SHOW FULL PROCESSLIST;

Nếu thấy:

• nhiều dòng Command = Sleep
• Time lên tới hàng nghìn giây

chính là vấn đề.

Xem nhóm connection Sleep theo user​

SELECT user, db, COUNT(*) conns, MAX(time) max_sleep
FROM information_schema.processlist
WHERE command='Sleep'
GROUP BY user, db
ORDER BY conns DESC;

User nào nhiều nhất = app gây ra vấn đề.

Cách FIX nhanh – an toàn – hiệu quả​

Bước 1: Giảm timeout MySQL (quan trọng nhất)​

Áp dụng ngay, không cần restart:

SET GLOBAL wait_timeout = 120;
SET GLOBAL interactive_timeout = 120;

Với API, có thể để 60–120 giây là hợp lý.

Sau đó kiểm tra lại:

SHOW VARIABLES LIKE 'wait_timeout';

Bước 2: Ghi vĩnh viễn vào config MySQL​

Mở file cấu hình MySQL (tuỳ hệ):

• /etc/mysql/my.cnf
• /etc/mysql/mysql.conf.d/mysqld.cnf
• /etc/my.cnf

Thêm:

[mysqld]
wait_timeout=120
interactive_timeout=120

Restart MySQL.

Bước 3: Dọn connection Sleep quá lâu (tùy chọn)​

Chỉ kill connection đang Sleep, không ảnh hưởng query đang chạy:

SELECT CONCAT('KILL ', id, ';')
FROM information_schema.processlist
WHERE command='Sleep' AND time > 300;

Copy output và chạy.

Fix gốc ở application (rất quan trọng)​

Nếu backend là Node.js​

• Không để pool quá lớn
• Pool nên giới hạn:
  • max: 5–10
  • idle: 30–60s
• Nếu dùng PM2 cluster → nhớ pool × số instance

Ví dụ:

pool: {
max: 10,
min: 0,
idle: 60000,
acquire: 30000
}

Nếu backend là PHP​

• Tránh dùng persistent connection nếu không kiểm soát tốt
• Đảm bảo đóng connection:
  • PDO: $pdo = null;
  • mysqli: $mysqli->close();
• Đặc biệt chú ý cron / script chạy nền

Gợi ý cấu hình phù hợp VPS 4GB​

• MySQL:
  • wait_timeout = 60–120
• lsphp (CyberPanel):
  • 8–10 children (không nên để 16 trên RAM thấp)
• Có traffic public:
  • thêm rate limit (Cloudflare / firewall)

Kết luận​

Không phải lỗi CyberPanel
Không phải lỗi OpenLiteSpeed
Nguyên nhân chính là MySQL connection Sleep quá lâu + backend mở nhiều connection
Giảm wait_timeout + chỉnh pool app = hết lỗi triệt để