Plesk reports high PHP usage, but the graph does not reveal whether visitors, bots, cron, admin AJAX or a plugin task occupied the pool. Raising process counts without identifying request duration can increase memory and database pressure.
Use timestamps to connect the panel metric to a URL and PHP stack.
Define the affected subscription and handler
Confirm the domain, subscription, PHP version and handler shown in Plesk. Several sites can run different pools or share server resources.
Record when usage rises and whether the symptom is CPU, memory, active processes or queued requests. Review the hosting or server health view over a window containing the incident.
Do not change global PHP settings when only one subscription is affected.
Compare access and error logs
Use Plesk’s domain logs for the same period. Group frequent or slow-looking URLs and status codes. Common WordPress targets include:
wp-cron.php;admin-ajax.php;- REST API routes;
wp-login.php;- WooCommerce cart/checkout calls;
- search and filtered archive parameters.
Request count alone is incomplete. One long import call can consume a worker longer than hundreds of cached page hits.
Protect personal data when exporting logs; query strings can contain emails or tokens.
Enable PHP-FPM slow logging deliberately
Where server access and policy allow, PHP-FPM can log stack traces for requests exceeding a threshold. Configure it for the specific pool using Plesk-supported directives or provider assistance.
Choose a threshold that captures abnormal work without logging every request. Store logs outside public web access, restrict permissions and disable the diagnostic after enough evidence is collected.
Do not restart pools casually on a busy store. Follow the platform’s supported apply/reload process and plan a rollback.
Correlate with WordPress activity
Compare slow stacks with WordPress plugin/theme paths, cron schedules and Action Scheduler. A backup, malware scan or product import may explain a regular plateau.
Check page-cache hit status. If a deployment or stock update purges the cache, normal traffic can suddenly become PHP traffic.
Inspect external HTTP calls in slow stacks. A licensing server or SMTP connection can hold a process even when local CPU looks moderate.
Review pool settings with memory evidence
Plesk may allow settings such as process manager mode, maximum children and idle timeouts. Before increasing them, measure approximate process memory and total server headroom.
More children allow more concurrent PHP work but can exhaust RAM, increase swapping and overwhelm MySQL. Too few can queue legitimate requests even when CPU remains available.
Tune only the affected pool and document previous values. Managed hosting limits may override subscription settings.
Reduce unnecessary PHP entry
Serve safe public pages from page cache or CDN, while excluding account, cart and checkout. Rate-limit abusive login or search traffic using appropriate security controls.
Replace visitor-triggered WP-Cron with a scheduled task only after the Plesk cron command is verified. Stagger backups and scans away from traffic peaks.
Do not block admin-ajax.php globally; public forms, carts and plugins may depend on specific actions.
Compare public traffic with authenticated administration separately. A bulk product edit, page-builder save or media regeneration can legitimately use considerable PHP for a short period. If the public site remains healthy, schedule that editorial work instead of applying a front-end restriction that will not affect it.
Verify with the next comparable period
After repairing the identified request or adjusting a measured pool limit, compare active processes, queueing, response time and error rate. Confirm forms, scheduled jobs and authorised checkout flows still work.
Keep a brief incident record linking timestamps, request, owner, change and evidence. This makes a recurrence much faster to diagnose.
Request an assessment when slow logging is unavailable, several sites share the bottleneck or pool changes risk ecommerce traffic. Start with Plesk graphs and sanitised log excerpts rather than credentials.