Every file and directory uses an inode, so millions of tiny cache, session or email files can exhaust the account before its GB storage appears full.
Applies to: CloudLinux performance and resource limits
CloudLinux limits protect the shared platform and are burstable ceilings rather than dedicated resources. A limit event is a symptom to investigate; repeated events usually require application optimisation, traffic control or a larger plan.
Before you start
- Open the affected hosting service and note the exact time, URL and operation that was slow or failed.
- Have recent CloudLinux usage, application logs and any monitoring alert available for the same time window.
Work through these checks
- Check current inode usage and whether the account is near its soft or hard plan limit.
- Find directories with very large file counts, including cache, sessions, logs, backups, mail folders and staging copies.
- Remove obsolete cache and temporary data through the owning application rather than deleting active session or queue files blindly.
- Archive or download old backups instead of retaining several full copies inside the same hosting account.
- Review mailbox folders and delete or export unneeded messages while preserving legal or operational retention requirements.
- Recheck inode and storage use and prevent recurrence with application cleanup schedules and sensible retention.
Confirm the result
- The same operation completes without another limit event during a comparable test.
- CloudLinux graphs and application logs show which change improved the workload rather than merely hiding the symptom.
Common problems
| Symptom | Likely cause | What to do |
|---|---|---|
| The site is slow but no limit is currently shown. | The event has passed, the bottleneck is remote, or application/database work is slow without reaching a hard ceiling. | Use exact timestamps, request logs and slow-query or application profiling rather than relying on a single live graph. |
| Resource faults return after a temporary improvement. | A cache clear or process restart treated the symptom but did not reduce expensive requests, bots or scheduled work. | Identify the repeating URL, job or query and optimise or rate-limit it before choosing a larger plan. |
When to contact Tudor Internet
Open a ticket through the Customer Portal when the checks above do not resolve the issue, when an action is unavailable for your service, or when continuing could risk data loss or service interruption. Include the following so the request can be investigated efficiently:
- The affected domain and SiteWorx account
- The exact error text and time
- The last change made
- Relevant log lines with passwords and personal data removed
Do not send passwords, private keys, full payment-card details, one-time authentication codes or unredacted identity documents in an ordinary support reply.
Related articles
- Check website, database and email storage usage
- Reduce hosting storage usage safely
- Resolve a full mailbox or quota warning
- How hosting backups and self-restore work
- Understand a CloudLinux CPU limit event
Last reviewed: 2026-07-18.
