{"id":6457,"date":"2026-10-23T09:33:20","date_gmt":"2026-10-23T06:33:20","guid":{"rendered":"https:\/\/www.scalahosting.com\/kb\/?p=6457"},"modified":"2026-10-23T14:57:22","modified_gmt":"2026-10-23T11:57:22","slug":"find-heavy-hosting-accounts-spanel","status":"publish","type":"post","link":"https:\/\/www.scalahosting.com\/kb\/find-heavy-hosting-accounts-spanel\/","title":{"rendered":"Find Your Heavy Accounts in Five Minutes: Usage History, CPU Profiles, and Data-Driven Plans"},"content":{"rendered":"\n

SPanel’s Admin Interface gives ScalaHosting server owners four tools for finding resource-heavy accounts: the accounts list shows quota, disk, and inode usage against each plan; the weekly Usage History shows each account’s CPU against its own limit and its limit-hit count; per-account CPU history charts any account’s load across the recorded dates; and the admin process viewer shows and stops running processes. Together they turn a monthly check into a five-minute routine, included free on every ScalaHosting managed VPS.<\/p>\n\n\n\n

When “the site feels slow” lands in your inbox<\/strong><\/h2>\n\n\n\n

“The site feels slow lately” is the least actionable sentence in hosting. Without data, the conversation goes in circles: maybe it’s a plugin, maybe the plan is too small, maybe it was one bad afternoon. Everyone guesses, someone upgrades anyway, and nobody learns anything.<\/p>\n\n\n\n

The data is already there, because SPanel has been recording it. The weekly Usage History shows which accounts pressed against their CPU ceiling and how often. The per-account CPU history charts one account across the noisy neighbor problem  the recorded dates, so “lately” resolves into a date and a time of day. A backup plugin pinning an account against its ceiling every afternoon looks exactly like that on the chart, and finding it takes under five minutes.<\/p>\n\n\n\n

That’s the monthly resource review: a short pass through four Admin Interface screens that shows which accounts are heavy, how heavy, and what to do about it. Limits keep accounts inside their lane. This review is how you watch the lanes, setting plans from evidence instead of vibes and catching the account that quietly outgrew its plan before its neighbors feel it. In our guide to every SPanel package dial<\/a>, you’ll see what each limit actually does.<\/p>\n\n\n\n

Four tools, four questions<\/strong><\/h2>\n\n\n\n

Each screen answers one question; run them in order.<\/p>\n\n\n\n

SPanel tool<\/td>The question it answers<\/td>What you do with it<\/td><\/tr>
Accounts list usage<\/td>Who is near the upper limit right now?<\/td>Scan quota, disk, and inodes against each plan<\/td><\/tr>
Weekly Usage History<\/td>Who ran hot over the last week?<\/td>Read CPU used vs each account’s limit, plus CPU Limit Hits<\/td><\/tr>
Per-account CPU history<\/td>When exactly was this account heavy?<\/td>Chart any account’s load across the recorded dates<\/td><\/tr>
Process viewer<\/td>What is running on the server right now?<\/td>Inspect or stop a single process<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

SPanel samples every account’s CPU and memory continuously through the day and stores it by date, so the history is there when you need it.<\/p>\n\n\n\n

The five-minute review, screen by screen<\/strong><\/h2>\n\n\n\n

Step 1 – Scan the accounts list.<\/strong> Open Accounts Management \u2192 Manage Accounts<\/strong>. The columns show each account’s Quota, Disk Usage, and Inodes, next to its package, owner, and status. Sort by Disk Usage and your near-the-ceiling accounts rise to the top.<\/p>\n\n\n\n

\"Find<\/figure>\n\n\n\n

Step 2 – Scan the weekly Usage History.<\/strong> Open Resource Usage \u2192 Usage History<\/strong> and read the Weekly Usage By Users<\/strong> table. For the selected week it shows each account’s CPU usage against its own limit, how many times it hit that limit (the CPU Limit Hits<\/strong> column), and the same pair for RAM. Accounts high against their limit – especially any with limit hits – are the ones to open next.<\/p>\n\n\n\n

\"Find<\/figure>\n\n\n\n

Step 3 – Pull the CPU history for a flagged account.<\/strong> Click View<\/strong> on the heaviest account’s row to open its own CPU history. The chart plots that account’s CPU (and RAM) by date across the period, the account’s ceiling drawn as a dashed line. A flat, low line is a healthy account. A line pinned near that ceiling every afternoon is a story: a scheduled job, a crawler, or a plugin doing too much.<\/p>\n\n\n\n

\"Find<\/figure>\n\n\n\n

Step 4 – Look at what is running.<\/strong> Open Resource Usage \u2192 Currently Running Users Processes<\/strong>, the admin’s server-wide live process list – each row shows the process ID, the owning account, and its CPU and RAM use. Find the flagged account’s processes; if one is clearly the culprit and is hurting its neighbors this minute, stop that single process from the panel, no SSH session needed. Use it as a scalpel, not a habit. The goal is the conversation, not a kill switch.<\/p>\n\n\n\n

\"Find<\/figure>\n\n\n\n

Want to run this review on your own accounts?<\/strong> Every screen here ships with SPanel – included free on every ScalaHosting managed VPS, with no per-feature add-ons. Import your accounts and the whole toolkit is there for your first five-minute pass.<\/p>\n\n\n\n

Step 5 – Act on the evidence.<\/strong> Now you have a decision, not a hunch. If the account has outgrown its plan, select it and use Mass Actions \u2192 Change Package<\/strong> to assign a larger plan; every limit re-applies in place, live, with no migration. A client who does not fit a named tier gets individual values instead, via Actions \u2192 Change Limits<\/strong> with Use Custom Limits<\/strong> enabled. If the cause is a runaway plugin, the data is your case for an optimization conversation. Moving a plan is one action that takes effect immediately.<\/p>\n\n\n\n

\"Find<\/figure>\n\n\n\n

Reading CPU numbers without panic<\/strong><\/h2>\n\n\n\n

One number trips people up, so here’s a quick explanation: a CPU limit of 100 means one full core, 50 means half a core, and 200 means two cores. It is a share of a core, not of the whole server – so read CPU history against the account’s own ceiling.<\/p>\n\n\n\n

And remember what the ceiling does. SPanel throttles at the CPU limit rather than killing anything: the site slows under its own excess load while every other account keeps full performance. A throttled account is not broken; it has hit the size of plan it pays for – the signal this review is built to catch, and the same containment that eliminates the noisy neighbor problem.<\/p>\n\n\n\n

Set limits from data, defend them with data. The history is already recorded; you just have to read it.<\/p>\n\n\n\n

Turning a review into a plan catalog<\/strong><\/h2>\n\n\n\n

Run this monthly and patterns appear. The same three accounts at the top of the weekly Usage History are upgrade conversations waiting to happen. A site that is heavy only between 1 and 2 a.m. is a cron job, not a capacity problem. Over a few months this review becomes the input to your plan design.<\/p>\n\n\n\n

FAQ<\/strong><\/h2>\n\n\n\n

Q:<\/strong> How do I find which accounts use the most CPU on my server?<\/strong> <\/p>\n\n\n\n

A:<\/strong> Open Resource Usage \u2192 Usage History<\/strong> and read the Weekly Usage By Users table: each account’s CPU against its own limit, plus a CPU Limit Hits count, for the selected week. Click View on an account to see its CPU history charted by date.<\/p>\n\n\n\n

Q:<\/strong> What does a CPU reading of 100 mean?<\/strong> <\/p>\n\n\n\n

A:<\/strong> One full core. 50 means half a core; 200 means two cores. It is a share of a core, not a percentage of the whole server.<\/p>\n\n\n\n

Q:<\/strong> What happens to an account constantly over its CPU limit?<\/strong> <\/p>\n\n\n\n

A:<\/strong> It is throttled, not killed. Its processes get only their share of CPU time, so the site slows under its own load while other accounts keep full performance. Persistent throttling is your cue to upgrade or fix the cause.<\/p>\n\n\n\n

Q:<\/strong> Can I stop a runaway process without logging in over SSH?<\/strong> <\/p>\n\n\n\n

A:<\/strong> Yes. The admin Currently Running Users Processes panel lists live processes server-wide and lets you stop a single process from the panel.<\/p>\n\n\n\n

Q:<\/strong> Do I need CloudLinux to see this usage data?<\/strong> <\/p>\n\n\n\n

A:<\/strong> No. The accounts list, Usage History, CPU history, and process viewer are part of SPanel, included free on every ScalaHosting managed VPS. SPanel’s per-account limits run on the Linux kernel’s own control groups; this is resource measurement and enforcement, not a separate filesystem product.<\/p>\n\n\n\n

Q:<\/strong> An account outgrew its plan: what is the cleanest fix?<\/strong> <\/p>\n\n\n\n

A:<\/strong> Assign it a larger package from Mass Actions \u2192 Change Package; every limit re-applies in place with no migration or downtime. For a client who does not fit a named tier, set individual values via Actions \u2192 Change Limits with Use Custom Limits enabled.<\/p>\n\n\n\n