Nội dung
Trang này đăng bài theo lịch hẹn giờ. Mỗi ngày có vài bài được đặt sẵn ngày giờ, tới giờ thì tự hiện ra. Cơ chế đó nghe như thể trong website có một cái đồng hồ luôn chạy. Không có. Ngày 14/08/2026 tôi mở lại toàn bộ đường đi của việc hẹn giờ trên máy chủ này, và thứ tôi tìm thấy là: mọi bài hẹn giờ của trang treo vào đúng một dòng lệnh nằm ngoài WordPress. Mất dòng đó là cả hàng đợi đứng im.
Bài này ghi lại đúng những gì đo được hôm nay, kể cả phần tôi định đếm mà đếm không ra.
Đồng hồ bên trong WordPress đã bị tắt từ lâu
Mặc định, WordPress không có đồng hồ riêng. Nó mượn lượt truy cập của khách: có người vào trang, nó tranh thủ chạy các việc đến hạn. Cách đó tiện nhưng bấp bênh — giờ nào vắng khách là việc treo.
Trên máy chủ này, cách mượn đó đã bị tắt hẳn. Trong tệp cấu hình có đúng một dòng:
wp-config.php dòng 127
define('DISABLE_WP_CRON', true);Tắt như vậy là có chủ đích và nói chung là đúng: không để việc nền bám vào lượt khách nữa. Nhưng nó kéo theo một hệ quả mà tôi đã quên mất — từ lúc đó, bên trong WordPress không còn gì tự nổ. Toàn bộ trách nhiệm gọi việc chuyển sang một dòng lệnh chạy ở tầng máy chủ, ngoài website.
Dòng lệnh ngoài kích 5 phút một lần, sổ tay ghi mỗi phút
Tôi mở bảng lịch chạy của máy chủ ra xem dòng đó thế nào. Nó đây:
*/5 * * * * docker exec mna_wp wp cron event run --due-now ...Năm phút một lần. Trong khi đó sổ tay vận hành của chính tôi ghi là mỗi phút một lần. Chênh nhau gấp năm.
Tôi không đoán theo dòng chữ trong bảng lịch mà xem nhật ký hệ thống, đếm số lần nó thật sự nổ. Trong nửa tiếng trước lúc đo có 6 lần, rơi vào 13:10, 13:15, 13:20, 13:25, 13:30. Đúng nhịp 5 phút, không phải nhịp 1 phút.
Chỗ này còn kéo thêm một thứ nữa. Trang có một lớp vớt bài chạy nền, nhiệm vụ là quét những bài đã tới hạn mà chưa hiện, rồi đẩy chúng lên. Lớp đó tự khai với WordPress rằng “cho tôi chạy mỗi 60 giây”. Nhưng WordPress giờ chẳng tự gọi ai — nó chỉ nhúc nhích khi dòng lệnh ngoài kích vào. Nghĩa là lớp vớt xin chạy mỗi phút, thực tế chạy 5 phút một lần. Và mỗi lần nó chỉ nhận tối đa 50 bài.
Bắt tận tay một việc trễ hơn 10 phút
Nói lý thuyết thì dễ. Tôi muốn nhìn tận mắt một việc bị trễ, nên ngồi hỏi liên tục xem việc vớt bài kia “hẹn chạy lúc mấy giờ” và có nhích không.
13:33:30 → việc đến hạn lúc 13:25:23
13:34:43 → vẫn 13:25:23
13:35:56 → nhảy sang 13:35:23Việc đến hạn lúc 13:25:23, tới 13:35:56 mới được đụng tới. Trễ hơn 10 phút, cho một việc tự khai là chạy mỗi 60 giây. Đây không phải suy luận, đây là ba lần hỏi liên tiếp trong cùng một buổi chiều.
Tại thời điểm đo, trang đang có 12 bài nằm chờ tới lượt và 54 việc hẹn giờ xếp hàng. Tất cả cùng treo vào một dòng.
Muốn đếm xem đã có bao nhiêu bài từng kẹt, ba cách đều trượt
Câu hỏi tự nhiên tiếp theo: từ trước tới nay đã có bao nhiêu bài bị kẹt vì chuyện này? Tôi thử ba cách, và phải bỏ cả ba.
Cách một: lấy giờ sửa lần cuối của bài trừ đi giờ hẹn đăng. Ra 1.195 bài lệch quá một ngày — nghe rất kêu, và sai hoàn toàn. Giờ sửa lần cuối bị chính tôi ghi đè trong các đợt sửa hàng loạt vài tháng qua. Con số đó đo dấu vết tay tôi, không đo độ trễ đăng bài.
Cách hai: tìm trong log truy cập chỗ nào một địa chỉ trả về 404 rồi sau đó mới trả 200 — tức là có người gõ vào lúc bài còn kẹt. Ra 0 trường hợp. Nhưng 0 ở đây không có nghĩa là không ai kẹt. Ba bài tôi biết chắc từng kẹt cũng có 0 dòng 404, đơn giản vì lúc chúng còn kẹt thì chẳng ai gõ vào địa chỉ đó cả. Không có dấu vết khác với không có chuyện xảy ra.
Cách ba: lấy lượt truy cập thành công đầu tiên của mỗi bài trừ đi giờ hẹn đăng. Ra 327 trên 820 bài “trễ hơn 6 tiếng”. Tôi suýt tin, cho tới lúc nhìn cột giờ: hàng chục bài có lượt đầu tiên trùng nhau trong khoảng 14/07 19:20–19:24. Đó là một đợt bot đi quét lại loạt bài cũ, không phải giờ chúng được đăng. Cách này chỉ cho biết bài đã hiện trước lúc đó, tức là một mức trần, và chỉ dùng được khi có người ghé thường xuyên.
Cái bẫy chung của cả ba là giống nhau: tôi đi tìm một dấu vết gián tiếp rồi coi nó là bằng chứng. Tôi vấp đúng kiểu này rồi, hồi bốn lần đoán sai nguồn gây xê dịch bố cục — cứ mỗi lần dữ liệu chiều theo giả thuyết là một lần dễ dừng lại sớm.
Phần đo được chắc: 92 bài tháng 8
Cách ba hỏng ở diện rộng, nhưng nó dùng được cho một khúc hẹp: các bài đăng trong tháng 8, khi lượng bot ghé đủ dày để lượt đầu tiên rơi vào trong vòng vài giây sau khi bài hiện. Với 92 bài đó, khoảng cách từ giờ hẹn tới lượt đọc đầu tiên như sau:
- 17 bài có lượt đọc trước cả giờ hẹn — đó là máy soạn bài tự gọi vào để kiểm tra, không tính.
- 52 bài dưới 1 phút — đăng thẳng, không phải chờ nhịp nào.
- 22 bài trong khoảng 1 đến 5 phút — đây đúng là nhóm phải nằm chờ dòng lệnh ngoài kích.
- 1 bài trên 1 tiếng: bài ngày 12/08, lệch 3 tiếng rưỡi.
Khoảng cách lớn nhất trong nhóm phải chờ là 4 phút 41 giây. Con số đó khớp gần như hoàn hảo với nhịp kích 5 phút — bài xui nhất là bài hiện ra ngay sau khi dòng lệnh vừa chạy xong, phải đợi gần trọn một vòng.
Nói cách khác: ở trạng thái bình thường, cái giá của dòng */5 là tối đa 5 phút chậm cho mỗi bài. Không phải thảm hoạ. Vấn đề nằm ở chỗ khác — nếu dòng đó biến mất, không có gì báo cho ai biết cả.
Hai con số trần, và chỗ tôi phải nhận là không dựng lại được
Hai bài từng kẹt có ghi lại trong sổ tay thì đo được, nhưng chỉ đo được mức trần:
- Bài hẹn 17/06 lúc 05:16, lượt đọc đầu tiên 07:35 → trễ nhiều nhất 2 tiếng 19 phút.
- Bài hẹn 22/06 lúc 03:22, lượt đọc đầu tiên 04:43 → trễ nhiều nhất 1 tiếng 21 phút.
“Nhiều nhất” chứ không phải “đúng bằng”. Bài có thể đã hiện sớm hơn thế và chỉ đơn giản là chưa ai ghé.
Còn tổng số bài từng kẹt trên toàn trang thì tôi không dựng lại được, và bài này nói thẳng là không. Muốn trả lời được câu đó, đáng lẽ phải có sẵn một chỗ ghi lại thời điểm mỗi bài thật sự chuyển sang trạng thái hiện — thứ mà tôi chưa từng dựng. Đó là một khoảng trống về đo đạc, và nó chỉ lộ ra khi có người đặt câu hỏi cần tới nó. Giống hệt chuyện làm hẳn một tệp cho AI đọc rồi 18 ngày không con bot nào mở: làm xong mà không đo thì cứ tưởng là ổn.
Ba thứ tôi rút ra và ghi lại đây để lần sau khỏi mò:
- Tắt đồng hồ bên trong là đúng, nhưng phải nhớ rằng từ đó mọi việc hẹn giờ chỉ còn một sợi dây duy nhất treo ra ngoài.
- Sổ tay ghi một đằng, máy chạy một nẻo là chuyện có thật — hôm nay lệch gấp năm. Đọc sổ tay không thay được việc mở ra đếm.
- Việc nền tự khai chu kỳ bao nhiêu không quan trọng bằng nhịp thứ kích nó. Khai 60 giây mà bị kích 5 phút thì chu kỳ thật là 5 phút.
Tôi chưa đổi dòng */5 thành mỗi phút. Đổi thì dễ, nhưng chưa có gì cho thấy 5 phút đang gây hại thật, còn thứ thiếu hẳn là một chỗ báo khi dòng đó chết. Đo được rồi hãy sửa, chứ không sửa cho yên tâm.
