Common Causes of High Resource Usage in PHP Applications and How to Fix Them

When a PHP site uses too much CPU, memory or disk I/O, the cause is usually in the code, not the server. A script that fails the same way thousands of times a day, a cron job that crashes and restarts every minute, or an error log that grows by gigabytes can all push your account into its limits. This guide shows which PHP errors actually cost resources, how to find them in your logs and how to fix them properly.

1. How PHP errors turn into high resource usage

A fatal error ends the request, so on its own it uses very little. Errors become expensive when they repeat or when the code around them keeps working hard before it fails:

• The same error thousands of times. A broken form, API endpoint or page that bots and visitors keep hitting. Every hit runs PHP, opens a database connection and writes a log line.
• Error log floods. Notices and warnings inside a loop can write megabytes a minute. That is disk I/O on every request, and the error_log file counts towards your disk space.
• Failing cron jobs. A job scheduled every minute that crashes half-way never finishes its work, so the next run starts the whole job again.
• Retry loops. Code that retries a failed query or API call in a loop with no limit or delay can hold a PHP process until the time limit.
• Heavy work before the crash. A script that loads a large table into memory and then fails on one bad row pays the full cost every time.

2. Find the errors

PHP errors are logged by default on our cPanel and DirectAdmin servers; you only need to find them.

Download the log and summarise it on your computer, or run the same commands on the server if SSH is enabled on your account:

# Which fatal errors repeat most
grep "PHP Fatal" error_log | sed 's/^\[[^]]*\] //' | sort | uniq -c | sort -rn | head -20

# How big the log files are
find ~/public_html -name error_log -size +10M -exec ls -lh {} \;

For the full tour of logs on both panels, see A guide to reviewing error logs in cPanel and DirectAdmin.

3. The errors we see most, and the real fix

Since PHP 8.1, mysqli throws an exception on database errors by default, which is why these messages start with Uncaught mysqli_sql_exception.

The first three have one cure: validate the input and use prepared statements. Never put user input directly into SQL.

<?php
$date = $_POST['date'] ?? '';
$fees = $_POST['fees'] ?? '';

$d = DateTime::createFromFormat('Y-m-d', $date);
$dateValue = ($d && $d->format('Y-m-d') === $date) ? $date : null;
$feesValue = filter_var($fees, FILTER_VALIDATE_INT, ['options' => ['min_range' => 0]]);

if ($feesValue === false) {
    http_response_code(422);
    exit('Please enter a valid fee.');
}

try {
    $stmt = $mysqli->prepare('INSERT INTO payments (paid_on, fees) VALUES (?, ?)');
    $stmt->bind_param('si', $dateValue, $feesValue);
    $stmt->execute();
} catch (mysqli_sql_exception $e) {
    error_log('Payment insert failed: ' . $e->getMessage());
    http_response_code(500);
    exit('Sorry, something went wrong.');
}

About "Undefined constant ABSPATH". This almost always means a bot or scanner requested a plugin or theme file directly. Don't "fix" it by defining ABSPATH in the file, which makes the file run outside WordPress. Instead, make the file stop immediately when loaded directly by putting this line at the top:

<?php defined('ABSPATH') || exit;

If the error comes from a plugin you didn't write, update the plugin, or remove it if it is abandoned.

For memory errors, see How to fix "Allowed memory size exhausted" PHP errors.

4. Stop the repeat, not just the error

• Fix or pause failing cron jobs. In cPanel's Cron Jobs page, comment out or delete the job until it is fixed, and make long jobs work in small batches so each run finishes.
• Put limits on retries. Retry a failed call two or three times with a delay, then give up and log it once.
• Give outside calls a timeout. A cURL call with no timeout can hold a PHP process for minutes; see section 5 of the Resource Limit article linked at the top.
• Silence noise the right way. Fix notices and deprecation warnings in loops rather than hiding them; they cost a disk write each time.
• Clear huge logs after the fix. Once the cause is fixed, delete the oversized error_log file; PHP creates a new one the next time something fails.
• Never display errors to visitors on a live site. Keep display_errors off and read the log. See How to show PHP error messages safely.

5. Things that look like code errors but aren't

Some failures come from the server's security settings, not from a bug. Shared hosting disables PHP functions such as exec, proc_open and shell_exec. Code that calls them fails every time and can fill a log quickly. See PHP disabled functions on shared hosting for the list and the alternatives.

6. Where Domain India fits

Our shared hosting runs on CloudLinux, which gives every account its own share of CPU, memory and simultaneous PHP requests, so a runaway script shows up in your own Resource Usage page and can't take over the server. Once the code is fixed, upgrade only if the faults continue: an active cPanel or DirectAdmin plan can be changed at any time, as explained in Can I upgrade my web hosting package?. Applications that need to run programs or long background workers belong on a VPS or the App Platform.

Ready to track it down? Read your logs with the error log guide, check your limits in hosting resource usage, or open a ticket and we will look at the logs with you.