Hosting resource limits explained: CPU, RAM, I/O, processes and inodes

CPU limits measure work, not page count

Dynamic applications use CPU when PHP code runs, templates render, plugins execute, archives are created, background jobs run, or expensive database work is triggered.

A small website with inefficient code can use more CPU than a larger static site, which is why “number of pages” is not a useful capacity measure by itself.

Memory limits affect concurrent work

Applications, PHP workers, database queries, image processing, and background tasks all consume memory. Repeatedly reaching a memory limit can cause requests to fail, workers to be killed, or the hosting platform to throttle the account.

Disk I/O can make a site feel slow

I/O measures how quickly the workload can read and write storage. Cache creation, backups, imports, logging, databases, and large file operations can all become I/O-heavy even when CPU usage looks reasonable.

Processes and concurrent requests matter

Shared platforms often limit how many processes or simultaneous application requests one account can run. Those boundaries prevent a single customer from consuming the entire server, but they can also expose applications that create too much concurrent work.

Inodes are basically file-count pressure

A hosting account can have free disk space and still contain an excessive number of files. Caches, sessions, logs, email, thumbnails, dependency trees, and old backups can create huge file counts. Providers may enforce an inode or file-count limit to keep filesystems manageable.

Treat limits as diagnostic information

When a site repeatedly reaches a resource boundary, determine why before upgrading blindly. The right fix might be caching, removing a broken plugin, optimizing a query, cleaning old files, changing a scheduled job, or moving to a plan with more appropriate resources.