WordPress CPU 100% dù website không có nhiều khách thường không phải do lượng người truy cập thực tế. Nguyên nhân có thể nằm ở bot tự động, wp-cron, admin-ajax.php, plugin/theme chạy tác vụ nặng, truy vấn database, REST API hoặc website đã bị mã độc cài tiến trình ngầm. Muốn xử lý đúng cần xác định request hoặc process nào đang tiêu thụ CPU trước khi tăng cấu hình server.
Nếu bạn đăng nhập hosting hoặc VPS và thấy CPU liên tục 80–100%, phản xạ đầu tiên thường là:

“Website có nhiều người truy cập nên server quá tải.”

Nhưng nếu website chỉ có vài chục hoặc vài trăm lượt truy cập mỗi ngày mà CPU vẫn thường xuyên lên 100%, cách giải thích này chưa đủ.

Một website WordPress ít khách vẫn có thể sử dụng rất nhiều tài nguyên nếu phía sau đang có hàng nghìn request tự động, cron chạy liên tục, plugin thực hiện tác vụ nặng, database bị truy vấn bất thường hoặc mã độc đang chạy trên server.

Theo kinh nghiệm của hungwordpress: CPU 100% không phải là nguyên nhân mà đó là một triệu chứng cần điều tra.

WordPress CPU 100% nhưng ít khách có bình thường không?

Không nên mặc định rằng đây là tình trạng bình thường.

CPU cao trong thời gian ngắn có thể xảy ra khi website thực hiện một tác vụ nặng như:

Backup.
Import/export sản phẩm.
Tạo thumbnail.
Cập nhật plugin/theme.
WooCommerce xử lý dữ liệu.
Chạy cron.
Scan bảo mật.
Xử lý hình ảnh.
Tác vụ database lớn.

Nhưng nếu CPU thường xuyên đạt 100%, đặc biệt khi website gần như không có người dùng thực tế, cần tìm nguyên nhân.

WordPress có thể tự tạo các request nội bộ. Ví dụ, WordPress sử dụng loopback request để tự gọi lại website cho một số tác vụ như WP-Cron và kiểm tra khả năng hoạt động của plugin/theme.

Do đó:

Ít khách ≠ ít request đến server.

Đây là điểm rất nhiều chủ website bỏ qua.

Vì sao WordPress ít khách nhưng CPU vẫn 100%?

Có thể chia nguyên nhân thành 7 nhóm chính:

Nguyên nhân	Khả năng gây CPU cao	Cần kiểm tra
Bot/crawler tự động	Cao	Access log, IP, User-Agent
`wp-cron.php`	Cao	Cron schedule, action
`admin-ajax.php`	Cao	Request AJAX
Plugin/theme lỗi hoặc nặng	Cao	PHP process, plugin
Database/query nặng	Cao	MySQL/MariaDB
REST API/request bất thường	Trung bình–cao	Access log/API
Malware/backdoor	Rất cao	File, process, request, database

Điểm quan trọng là không nên xử lý tất cả trường hợp bằng cách nâng RAM hoặc CPU.

Nếu nguyên nhân là bot, bạn nâng CPU nhưng bot vẫn tiếp tục gửi request.

Nếu nguyên nhân là plugin lỗi, nâng CPU chỉ làm website chịu tải lâu hơn.

Nếu nguyên nhân là malware, nâng server không giải quyết được mã độc.

Phương án xử lý WordPress CPU 100% nhưng không có nhiều khách

Khi WordPress CPU 100% nhưng website không có nhiều khách, không nên nâng cấu hình server ngay. Hãy xác định thành phần nào đang tạo tải trước, sau đó xử lý theo đúng nguyên nhân. Dưới đây là quy trình thực tế có thể áp dụng từ mức đơn giản đến chuyên sâu.

1. Xử lý nhanh khi CPU đang 100%

Nếu website đang chậm hoặc không truy cập được, trước tiên cần giảm tải để website hoạt động trở lại, sau đó mới điều tra nguyên nhân.

Việc đầu tiên: kiểm tra process đang ăn CPU

Trên VPS Linux có thể kiểm tra:

top

hoặc:

htop

Nếu thấy nhiều process như:

php-fpm
php
mysqld
mariadbd
lsphp

đang chiếm CPU, chưa nên kết luận ngay.

Cần xác định process đó thuộc website nào và đang xử lý request gì.

Nếu server chạy nhiều website, đây là bước đặc biệt quan trọng vì một website có thể làm ảnh hưởng toàn bộ VPS.

2. Nếu bot đang gửi quá nhiều request: chặn ở lớp server/CDN

Nếu access log cho thấy một hoặc nhiều IP liên tục gọi:

/wp-login.php
/xmlrpc.php
/wp-cron.php
/wp-json/
/wp-admin/admin-ajax.php

thì không nên để toàn bộ request đi vào WordPress.

*Phương án xử lý:

Có thể triển khai theo thứ tự:

Cloudflare
   ↓
WAF / Rate Limit
   ↓
Web Server
   ↓
PHP
   ↓
WordPress

Mục tiêu là chặn request càng sớm càng tốt.

Ví dụ:

Bot
 ↓
Cloudflare chặn
 ↓
Không tới VPS
 ↓
PHP không phải xử lý
 ↓
CPU giảm

Đây hiệu quả hơn việc để bot đi xuyên qua Cloudflare rồi mới tìm cách xử lý trong WordPress.

*Không nên:

Không nên đưa IP vào blacklist hàng loạt mà không kiểm tra.

Bot có thể sử dụng rất nhiều IP khác nhau.

Trong trường hợp này nên kết hợp:

Rate limiting.
WAF.
Bot detection.
Challenge.
Giới hạn request theo URL.
Giới hạn request theo IP.

3. Nếu `wp-login.php` bị brute-force

Nếu log cho thấy:

POST /wp-login.php
POST /wp-login.php
POST /wp-login.php

liên tục, đây là trường hợp rất dễ gây tải PHP.

*Phương án xử lý:

Có thể áp dụng rate limit cho:

/wp-login.php

Ví dụ logic:

1 IP
↓
10–20 request/phút
↓
vượt ngưỡng
↓
Challenge / Block

Ngưỡng thực tế cần điều chỉnh theo website.

Nếu website chỉ có vài quản trị viên, có thể giới hạn mạnh hơn.

Có thể bổ sung

2FA cho tài khoản quản trị.
Giới hạn quyền truy cập /wp-admin.
Đổi URL đăng nhập không phải là biện pháp bảo mật chính.
Kiểm tra tài khoản admin bất thường.
Kiểm tra log đăng nhập.

Quan trọng: rate limit giúp giảm request nhưng không thay thế việc bảo vệ tài khoản.

4. Nếu `xmlrpc.php` bị abuse

Nếu website không sử dụng XML-RPC nhưng log cho thấy:

POST /xmlrpc.php

xuất hiện với tần suất cao, có thể cân nhắc vô hiệu hóa XML-RPC.

Trong WordPress có thể xử lý bằng filter:

add_filter( 'xmlrpc_enabled', '__return_false' );

Tuy nhiên, không nên áp dụng nếu website hoặc hệ thống bên ngoài thực sự cần XML-RPC.

Nếu vẫn cần XML-RPC

Không nên tắt hoàn toàn.

Thay vào đó có thể:

Rate limit.
WAF.
Giới hạn IP.
Theo dõi request.
Chặn các pattern abuse.

5. Nếu `wp-cron.php` chạy quá nhiều

Nếu xác định CPU cao liên quan tới WP-Cron, hãy kiểm tra cron trước khi tắt.

Có thể dùng WP-CLI:

wp cron event list

Để xem danh sách scheduled events.

Tìm các event:

failed
pending
recurring

hoặc một event xuất hiện với tần suất bất thường.

Nếu website có WP-Cron hoạt động quá thường xuyên

Một phương án phổ biến là chuyển sang system cron.

Trong wp-config.php:

define( 'DISABLE_WP_CRON', true );

Sau đó cấu hình cron hệ thống gọi:

wp cron event run --due-now

hoặc cơ chế cron phù hợp với server.

Nhưng đừng làm kiểu này

Tắt WP-Cron
↓
Không cấu hình system cron
↓
Xong

WooCommerce và các plugin có scheduled task có thể bị ảnh hưởng.

6. WooCommerce Scheduled Actions

WooCommerce có hệ thống Scheduled Actions để xử lý các tác vụ nền.

Nếu có hàng nghìn action pending hoặc failed, cần tìm nguyên nhân.

Có thể kiểm tra bằng WP-CLI:

wp action-scheduler list --status=pending

và:

wp action-scheduler list --status=failed

Nếu có một loại action xuất hiện với số lượng rất lớn, cần xác định plugin nào tạo ra nó.

Không nên chỉ xóa hàng loạt

Ví dụ:

10.000 pending actions
↓
DELETE ALL

có thể làm mất các tác vụ thực sự cần thiết.

Tốt hơn là:

Action
↓
Plugin tạo action
↓
Kiểm tra nguyên nhân
↓
Sửa plugin/configuration
↓
Xử lý backlog

7. Nếu `admin-ajax.php` gây CPU cao

Đây là trường hợp cần điều tra kỹ.

Không nên chặn:

/wp-admin/admin-ajax.php

toàn bộ.

Hãy tìm action đang được gọi.

Có thể xem request trong:

Browser DevTools.
Access log.
Query Monitor.
Application log.

Ví dụ:

admin-ajax.php?action=product_filter

Nếu request này xuất hiện hàng nghìn lần, hãy tìm plugin/theme tạo action đó.

Các hướng xử lý:

Trường hợp 1: request quá thường xuyên

Giảm tần suất JavaScript gọi AJAX.

Trường hợp 2: query quá nặng

Tối ưu query/database.

Trường hợp 3: bot gọi AJAX

Chặn bot/rate limit.

Trường hợp 4: plugin lỗi

Cập nhật hoặc thay thế plugin.

Trường hợp 5: chức năng không cần thiết

Tắt chức năng đó thay vì tắt toàn bộ AJAX.

8. Nếu plugin gây CPU cao: khoanh vùng thay vì tắt bừa

Một trong những cách nhanh nhất để tìm plugin gây tải là so sánh trước và sau khi vô hiệu hóa plugin nghi ngờ.

Nhưng với website production, không nên:

Tắt 30 plugin cùng lúc

vì sau đó không biết plugin nào gây vấn đề.

Nên làm:

Xác định request
↓
Xác định hook/action
↓
Xác định plugin
↓
Test plugin
↓
Đo CPU

Có thể sử dụng Query Monitor:

Query Monitor giúp kiểm tra:

Database queries.
Slow queries.
HTTP API calls.
Hooks/actions.
PHP errors.
Scripts/styles.

Nếu phát hiện một plugin tạo rất nhiều query hoặc HTTP request, đó là dấu hiệu cần điều tra tiếp.

9. Nếu database là nguyên nhân

Nếu CPU MySQL/MariaDB cao, cần kiểm tra query.

Có thể sử dụng:

SHOW FULL PROCESSLIST;

để xem các query đang chạy.

Nếu server có slow query log, nên bật và phân tích các query chạy lâu.

Một số dấu hiệu đáng chú ý

SELECT ...
FROM wp_postmeta

với lượng dữ liệu lớn.

Hoặc:

ORDER BY
LIKE '%keyword%'

trên bảng lớn.

Hoặc query được thực hiện hàng trăm lần trong một request.

Hướng xử lý

Tùy nguyên nhân:

Thêm index phù hợp.
Giảm số query.
Sửa WP_Query.
Cache dữ liệu.
Loại bỏ query dư thừa.
Dọn dữ liệu không cần thiết.
Tối ưu bảng.
Thay plugin.
Tách tác vụ nặng sang background job.

Không nên tự thêm index hàng loạt nếu chưa phân tích query và execution plan.

10. Nếu website có hàng nghìn sản phẩm

Với WooCommerce lớn, cần đặc biệt chú ý:

wp_posts
wp_postmeta
wp_wc_orders
wp_wc_product_meta_lookup

và các bảng liên quan tới plugin đang sử dụng.

Một chức năng tìm kiếm/lọc sản phẩm có thể tạo tải lớn nếu mỗi request phải:

Load WordPress
↓
Query hàng nghìn sản phẩm
↓
Query metadata
↓
Query taxonomy
↓
Sort
↓
Render

Hướng xử lý:

Có thể xem xét:

Tối ưu product lookup.
Tối ưu query filter.
Giảm số query.
Cache kết quả.
Sử dụng object cache.
Redis nếu kiến trúc phù hợp.
Tối ưu search/filter.
Tách các tác vụ import/export khỏi request của người dùng.

11. Nếu PHP-FPM bị đầy worker

Nếu PHP-FPM có quá nhiều process, cần kiểm tra pool configuration.

Một số tham số quan trọng:

pm.max_children
pm.start_servers
pm.min_spare_servers
pm.max_spare_servers

Nhưng không nên tăng pm.max_children một cách máy móc.

Ví dụ:

CPU yếu
↓
PHP worker tăng
↓
Concurrent request tăng
↓
CPU tiếp tục 100%

Bạn có thể biến một vấn đề nhỏ thành tình trạng server quá tải nghiêm trọng hơn.

Cách tiếp cận tốt hơn

Xác định:

PHP worker đầy vì sao?

Có thể là:

Request quá nhiều.
Query quá chậm.
External API chậm.
Plugin chạy lâu.
Bot.
Malware.

Sau đó mới điều chỉnh PHP-FPM.

12. Nếu có HTTP API bên ngoài gây treo PHP

Một plugin có thể gọi API:

Website
 ↓
PHP
 ↓
External API
 ↓
Chờ response

Nếu API bên ngoài chậm, PHP worker có thể bị giữ lâu.

Cần kiểm tra:

HTTP API calls.
Timeout.
Retry.
Số lần gọi.
Plugin thực hiện request.

Cách xử lý

Thiết lập timeout hợp lý:

connect timeout
request timeout
retry limit

và tránh gọi API bên ngoài trong mỗi page request nếu không cần thiết.

Có thể chuyển tác vụ sang:

Cron
Queue
Background process

13. Nếu nghi ngờ malware: dừng tối ưu và chuyển sang xử lý bảo mật

Đây là tình huống không nên dùng cache để “che” vấn đề.

Nếu phát hiện:

PHP file lạ
Cron lạ
Admin user lạ
Redirect
SEO spam
Link cá độ
Backdoor
Shell

hãy ưu tiên điều tra bảo mật.

Quy trình nên làm:

Backup / Snapshot
↓
Bảo toàn log
↓
Kiểm tra user
↓
Kiểm tra file thay đổi
↓
Kiểm tra plugin/theme
↓
Kiểm tra wp-config.php
↓
Kiểm tra database
↓
Kiểm tra cron
↓
Kiểm tra process
↓
Tìm backdoor
↓
Loại bỏ mã độc
↓
Đổi credentials
↓
Cập nhật hệ thống
↓
Kiểm tra lại

Đặc biệt không nên:

Chỉ chạy một plugin scan malware rồi kết luận:

“Website sạch.”

Scanner có thể bỏ sót backdoor được ngụy trang hoặc mã độc nằm trong database.

Nếu website từng bị cài link spam, cần kiểm tra cả:

Database.
wp_options.
Post content.
Widget.
Custom fields.
User metadata.
Plugin settings.
Theme files.
Cron.

=> Xem thêm: Làm sao để bảo mật website WordPress hiệu quả? Hướng dẫn chi tiết từ A đến Z

14. Nếu phát hiện bot nhưng không muốn dùng Cloudflare

Vẫn có thể xử lý tại web server.

Ví dụ có thể:

Rate limit.
Giới hạn connection.
Chặn User-Agent rõ ràng là spam.
Giới hạn request vào login.
Giới hạn XML-RPC.
Chặn các pattern URL rõ ràng bất thường.

Nhưng cần hiểu:

Chặn ở web server vẫn tốt hơn để request đi vào PHP.

Ví dụ:

Bot
 ↓
Nginx/Apache/LSWS
 ↓
BLOCK

tốt hơn:

Bot
 ↓
WordPress
 ↓
PHP
 ↓
Plugin
 ↓
Database
 ↓
BLOCK

Vì ở cách thứ hai, CPU đã bị tiêu tốn trước khi request bị từ chối.

15. Nếu website đang dùng LiteSpeed

Với LiteSpeed/OpenLiteSpeed, cần kiểm tra:

PHP process.
External app.
Request.
Cache hit/miss.
Error log.
Access log.
Connection.
Worker.

Nếu website dùng LiteSpeed Cache, không nên chỉ nhìn vào việc:

“Cache đã bật.”

Mà cần kiểm tra cache có thực sự HIT hay không.

Nếu phần lớn request vẫn:

MISS
↓
PHP
↓
WordPress

thì việc bật cache chưa chắc giải quyết được CPU.

16. Nếu website dùng Cloudflare

Có thể kiểm tra:

Traffic
Bot
Firewall Events
Rate Limiting
Origin requests

Mục tiêu là xác định:

Bao nhiêu request bị chặn ở Cloudflare?
Bao nhiêu request vẫn tới origin?
URL nào bị gọi nhiều?
IP nào bất thường?

Sau đó tạo rule phù hợp.

Ví dụ:

/wp-login.php

có thể áp dụng rate limit.

Hoặc các URL không tồn tại liên tục:

/random-url-1
/random-url-2
/random-url-3

có thể điều tra bot/scraper trước khi quyết định chặn.

17. Nếu CPU chỉ cao vào một thời điểm cố định

Trường hợp này rất đáng chú ý.

Ví dụ:

02:00 → CPU 100%
03:00 → bình thường

hoặc:

12:00 → CPU 100%
13:00 → bình thường

Hãy tìm cron hoặc scheduled task.

Ví dụ:

02:00 Backup
02:05 Image optimization
02:10 Database cleanup
02:20 WooCommerce action

Nhiều tác vụ nặng chạy cùng lúc có thể tạo CPU spike.

Phương án

Thay vì:

02:00
Backup
Import
Scan
Optimize
Cleanup

có thể phân tán:

01:00 Backup
02:00 Scan
03:00 Cleanup
04:00 Optimization

Mục tiêu là tránh nhiều tác vụ nặng chạy đồng thời.

18. Khi nào nên nâng CPU/RAM?

Sau khi đã kiểm tra root cause.

Ví dụ:

Bot đã kiểm soát
Plugin đã tối ưu
Cron đã xử lý
Query đã tối ưu
Cache đã hoạt động
Malware không có

nhưng:

Traffic thật tăng
Concurrent request tăng
CPU vẫn cao
RAM gần đầy

thì lúc này nâng tài nguyên là hợp lý.

Có thể cân nhắc:

Tăng vCPU.
Tăng RAM.
Chuyển VPS mạnh hơn.
Tối ưu PHP-FPM.
Redis/Object Cache.
Database server tốt hơn.
Tách database.
CDN.
Load balancing với hệ thống lớn.

Nâng server nên là bước tăng capacity sau tối ưu, không phải bước đầu tiên để đoán nguyên nhân.

19. Quy trình xử lý CPU 100% thực tế

Tôi khuyên dùng quy trình sau:

CPU 100%
     ↓
Kiểm tra top/htop
     ↓
PHP hay MySQL?
     ↓
Kiểm tra access log
     ↓
URL nào nhiều nhất?
     ↓
IP/User-Agent nào?
     ↓
Có bot?
  ↓        ↓
 Có       Không
 ↓          ↓
WAF/Rate   PHP-FPM
Limit      ↓
          AJAX/API/Cron
              ↓
          Plugin/Theme
              ↓
           Database
              ↓
            Malware
              ↓
          Root Cause
              ↓
           Fix
              ↓
       Theo dõi CPU
              ↓
       Tối ưu tiếp nếu cần

Đây là điểm quan trọng nhất:

Đừng hỏi “làm sao để CPU xuống 50%?” trước khi biết “thứ gì đang làm CPU lên 100%?”.

20. Sau khi xử lý phải đo lại

Một lỗi phổ biến là sửa xong rồi kết luận:

“Đã tối ưu.”

Cần đo lại.

Ví dụ:

Chỉ số	Trước xử lý	Sau xử lý
CPU	100%	35%
PHP worker	30	8
Requests/phút	1.500	250
TTFB	3,2s	0,7s
MySQL CPU	80%	25%
5xx	15/phút	0

Không nhất thiết mọi website đều đạt các con số trên. Điều quan trọng là có số liệu trước và sau để chứng minh thay đổi.

Plugin hỗ trợ kiểm tra và xử lý WordPress CPU 100%

Plugin không thể thay thế việc kiểm tra server, access log hoặc PHP-FPM. Tuy nhiên, với website WordPress, một số công cụ có thể giúp xác định plugin nào tạo query nặng, cron nào chạy bất thường, request nào gây tải hoặc database đang có vấn đề.

Nên chọn công cụ dựa trên nguyên nhân thay vì cài tất cả plugin cùng lúc.

Công cụ	Dùng để làm gì?	Khi nào nên dùng?
Query Monitor	Phân tích PHP, database query, hooks, HTTP API	Khi nghi plugin/theme gây tải
WP Crontrol	Kiểm tra WP-Cron	Khi CPU tăng liên quan cron
Health Check & Troubleshooting	Kiểm tra lỗi và test plugin/theme	Khi cần khoanh vùng plugin
Wordfence	Kiểm tra bảo mật, malware, login	Khi CPU cao kèm dấu hiệu bị hack
WP-CLI	Quản trị và kiểm tra WordPress bằng command line	Khi có SSH/VPS
Redis Object Cache	Object caching	Khi database/query là bottleneck và server phù hợp

WordPress CPU 100% không phải lúc nào cũng cần nâng server

Nếu WordPress ít khách nhưng CPU liên tục 100%, hãy xử lý theo thứ tự:

1. Xác định process → 2. Xác định request → 3. Xác định plugin/task → 4. Kiểm tra database → 5. Kiểm tra bảo mật → 6. Sửa root cause → 7. Đo lại → 8. Cuối cùng mới cân nhắc nâng server.

Trong thực tế, một website có thể giảm tải đáng kể chỉ bằng cách: