This article will help you quickly determine why a website on shared hosting is running slowly: due to account resource limits (CPU/RAM/IO) or due to code, the database, and external dependencies. The material is useful when pages start responding more slowly, periodic freezes appear, and the load behaves нестабильно without an obvious reason.

Within this material, you will solve several practical tasks: determine whether the project is hitting hosting limits, identify recurring time-based spikes (bots, cron jobs, imports, mailings), and learn how to capture the situation at the moment of a complaint — so you can act based on facts. Based on the diagnostic results, it will be easier to choose the next step: optimizing cache and resource-intensive components, working with the database, or migrating to a more suitable infrastructure — for example, a virtual or dedicated server.

Checking Load on Hosting

On shared hosting, there is usually no access to root-level system logs, but two practical data sources remain that help determine whether the issue is specifically with account resources (CPU/RAM/IO) and whether it repeats over time:

1. The “System Resource Usage” report in the ISPmanager 4 panel — shows aggregated load over the day and helps identify patterns.
2. Real-time monitoring via top over SSH — shows the current situation when the site is slow.

System Resource Usage

This report usually displays accumulated metrics for a period (for example, how many CPU seconds and how many total process minutes the account consumed).

The purpose of the report is not to catch a spike right now, but to identify trends: what is growing over days (code/system/wait states) and what might have triggered it (traffic growth/bots, new plugins, background tasks, imports, theme changes, cache/log growth).

Metrics and how to interpret them:

• Memory (GB) How much RAM the site processes consumed on average during the day. A sharp increase often coincides with resource-intensive tasks (import/export, image processing, cache warming, updates) or errors that spawn many parallel processes.

• User CPU (sec) CPU time spent executing website code (PHP/application): request handling, plugins, CMS background tasks. Growth in User CPU usually means one of three things:

  • more requests (visitors/bots);
  • requests became more resource-intensive (new plugins/features/personalization);
  • increased share of background tasks (cron, cache rebuild, mailings, imports).

• System CPU (sec) Time spent on system operations: file system, network, disk I/O, logging, etc. Practical comparison logic:

  • User CPU significantly higher than System CPU → application computation dominates (logic/plugins/dynamic content).
  • System CPU high and close to User CPU → a noticeable share of time is spent on service operations (files/disk/logging/overhead around the website).

• Runtime (minutes) Total process runtime per day. If minutes are high but CPU does not grow proportionally, this resembles long waits (files/external requests) or long-running background processes.

• Input/Output Operations (IO) Disk activity indicator. Growth in IO together with System CPU is often associated with log writing, reading/writing cache files, image processing, archiving/backups, or frequent operations involving many files.

Monitoring Account Load Dynamics

The resource report in the panel usually shows aggregated values for the day: how many CPU seconds and how many total process minutes the account consumed. Therefore, it is intended for dynamic analysis: what is gradually increasing, what produces regular spikes, and which events coincide with it (updates, imports, new integrations, traffic growth).

How to Analyze Dynamics Correctly

• Use two time horizons: 7 days (quick diagnostics) and 30 days (sustainable trend).

• Note site changes that may have affected load: CMS/theme/plugin updates, import/export, mailings, caching changes, background task launches.

• Compare not only absolute numbers, but the shape of the graph/table:

  • upward step — a permanent change in load (for example, new functionality or traffic growth);
  • scheduled spikes — cron/background tasks, backups, imports;
  • plateau — a newly established level of hosting resource consumption.

What Growth in Specific Metrics Means

• User CPU (sec) growth most often indicates:

  • more requests (visitors/bots);
  • requests became more resource-intensive (new plugins/logic/personalization);
  • increased share of background tasks (cron, cache rebuild, imports, mailings).

• System CPU (sec) growing together with User CPU indicates a noticeable share of service operations: file system, cache files, logging, network and disk overhead. Practical check: if System CPU approaches User CPU, the load is often related not only to computation but also to infrastructure operations around the application.

• Runtime (minutes) growing faster than CPU suggests waits and long processes: external HTTP requests, locks, slow database, queues/workers, misconfigured cron jobs.

• Memory (GB) sharp growth is typical for resource-intensive operations (import/export, image processing, cache warming, updates) or errors creating many parallel processes.

Correlation with the Load Source via Logs

When metrics increase, the next step is to tie the growth to facts: which requests, errors, or background tasks cause it.

What to check:

• web server/application access and error logs: request spikes, identical URIs, repeated User-Agent strings, sequences of 404/500 errors;
• time-based events: updates, imports, mailings, cron;
• typical triggers (if WordPress): xmlrpc.php, wp-login.php, admin-ajax.php.

mytop — MySQL Load Monitoring

mytop is a top-style console utility that connects to MySQL and periodically collects data, including via SHOW PROCESSLIST and SHOW GLOBAL STATUS, allowing you to quickly see which queries are running, who is executing them, and what is holding up the database.

When to Use It

• when PHP processes take too long to execute, e.g., more than 2-4 seconds;
• there is an increase in User CPU/System CPU and a suspected database load;
• the website starts freezing, timeouts occur, or background task queues build up;
• you need to quickly identify resource-intensive queries and their sources (user/host/database).

How to Launch

A practical launch with explicit parameters (example):

mytop --host localhost --u dbuser --d databasename  --prompt

What to Look for in mytop First

• similar SQL queries that are numerous or take a long time to execute;
• list of threads/queries: long-running (Time), in states like Locked/Sending data/Copying to tmp table, etc.;
• recurring query patterns: the same Info/table/endpoint is a candidate for optimization/caching/indexes;
• QPS (Queries Per Second) spikes: correlate with bots, plugins, cron jobs, or mass imports.

Quick Correlation with the Web Source

If you see a surge of queries in mytop, the next step is to match the time and URI/agent/source using the web server and application logs. To do this, use: Logs and Reports in ISPmanager.

What to Do If the Database Is Overloaded?

If you notice in mytop that the same queries are taking too long to execute or are hanging, the cause is most often an unoptimized table structure and a lack of proper indexes. The server has to scan the entire table every time, which causes immense load on the disk and processor.

To understand this issue more deeply and solve the problem of slow queries, we recommend studying our specialized materials:

• Database Indexes: Why Are They Needed — a basic guide on how indexes multiply data search speed and reduce overall server load.
• B-Tree Indexes: How They Work — a detailed breakdown of the most popular index type. This article will help you understand the internal logic of MySQL and learn how to structure data for maximum performance.

Conclusion

Load diagnostics should conclude with a specific technical solution, not a general assumption.

If, based on observations, the main load falls on the CPU from PHP processes, the priority is application-level optimization. First, check if the page cache is working correctly, then analyze resource-intensive plugins, modules, and dynamic blocks. In practice, slowdowns are most often related to heavy page generation, missing or improperly configured caching, and excessive dynamic content.

If the database consistently dominates the load metrics and a significant portion of time is spent executing SQL queries, the focus shifts to DB optimization: analyzing slow queries, properly placing indexes, optimizing table structures, and eliminating repetitive operations. You can use phpMyAdmin for initial DB structure checks and optimization. Instructions on how to work with and connect to it are available here.

The key principle is to rely on measurements. Decisions to rewrite code, configure database indexes, or change infrastructure should only be made after the confirmed cause of the load has been established.