[{"data":1,"prerenderedAt":197},["ShallowReactive",2],{"seo-verification":3,"blog-sizing-a-vps-for-a-client-site-ram-and-cpu-en":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-sizing-a-vps-for-a-client-site-ram-and-cpu-en",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":27,"featuredImage":29,"bgImage":30,"posterImage":31,"relatedSolution":29,"intro":32,"sections":33,"ctaTitle":140,"ctaBody":141,"ctaButton":142,"ctaUrl":143,"relatedPosts":144},547,"sizing-a-vps-for-a-client-site-ram-and-cpu",{"fr":12,"en":10,"ar":13,"es":14},"dimensionner-vps-ram-cpu-site-client","تحديد-حجم-vps-لموقع-عميل-الذاكرة-والمعالج","dimensionar-un-vps-para-el-sitio-de-un-cliente-ram-y-cpu","Sizing a VPS for a client site: RAM and CPU","Measure the RAM, CPU and disk a client's site really uses at peak, then choose the VPS plan with a written margin you can defend to the client.",10,0,false,"2026-10-31T00:00:00+00:00","2026-10-31T20:50:39+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":25},5,"Comparison","comparatif","bg-info\u002F10 text-info",[28],{"id":23,"name":24,"slug":25,"color":26,"icon":25},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fdimensionner-vps-ram-cpu-site-client-poster.svg","Choosing a VPS blind means either billing a dead margin or suffering an outage at the first peak. This guide shows how to read the real RAM, CPU and disk consumption of a client site with tools present everywhere, keeping the peak rather than the average. It derives an explicit calculation rule, spots undersizing signals before the client does, and locates the plan to take. The first choice is not final, since a VPS can be resized.",[34,38,48,51,79,111,114,117,121,124,134,137],{"type":35,"title":36,"body":37},"h2","Why measure before choosing a plan","A client asks \"which VPS does my site need?\" and the answer is too often a hunch. Two mistakes follow. The first is to take the next plan up \"just in case\": across a portfolio of twenty clients, that dead margin is paid every month and eats into the agency's margin. The second is to cut it too fine: the first traffic peak, a backup or a catalogue import takes the site down, and the client finds out before you do.\n\nThe usual objection is \"no time to measure\". Yet the measurement takes about an hour of active observation, with tools already present on every Linux distribution. And the first choice is not final: a VPS can be resized vertically, meaning you move to a larger plan without rebuilding the architecture. The goal is not to guess right the first time, but to choose with figures and a written margin that you can defend in front of the client.\n\nThe reasoning also applies to a professional running their own site, for example an online shop: the cost of an oversized plan shows on the monthly bill, that of an undersized one in revenue lost during an order peak. The same readings then let you decide with full knowledge, without an intermediary.\n\nThis guide covers measurement before purchase and plan selection. To decide between a VPS and shared hosting, read \u003Ca href=\"\u002Fen\u002Fblog\u002Fshared-hosting-or-vps-for-agency-client-site\">VPS or shared hosting for a client site\u003C\u002Fa> first. For continuous alerts once the VPS is live, see \u003Ca href=\"\u002Fen\u002Fblog\u002Fdisk-full-and-ram-alerts-on-a-vps-no-monitoring-stack-needed\">disk and RAM alerts on a VPS\u003C\u002Fa>.",{"type":39,"title":40,"items":41},"ul","What measuring gives you",[42,43,44,45,46,47],"**A defensible quote** — you size the plan from dated readings, not an impression.","**No dead margin** — you stop billing or absorbing an oversized plan on every client.","**Fewer outages at the first peak** — you see memory saturation coming before it kills a process.","**A baseline for comparison** — today's reading lets you judge growth six months from now.","**An honest diagnosis** — you tell a site that lacks resources from one that is badly configured.","**A calmer migration** — you arrive on the new VPS with a plan already proven against the real load.",{"type":35,"title":49,"body":50},"Prerequisites: what to prepare before measuring","Measure on the client's current server, the one carrying the real load, not on an empty copy. You need SSH access with read rights, permission to run `ps`, `free` and `df`, and ideally the ability to install the `sysstat` package, which provides `sar` and keeps a history of the load.\n\nOn duration, plan for at least a week of history if `sysstat` is already running, otherwise an observation window of at least one hour that deliberately includes a busy moment: a known traffic peak, the nightly backup, a scheduled task or an import. Measuring on a Tuesday at 3 a.m. says nothing about sale day. Finally, note the context: application (WordPress, shop, custom application), presence of containers, database on the same machine or not.",{"type":52,"title":53,"steps":54},"steps","Reading real consumption, step by step",[55,58,61,64,67,70,73,76],{"title":56,"body":57},"Count the cores","Run `nproc`. This number is the reference for reading load: a load average of 4 is healthy on 8 vCPU and critical on 2.",{"title":59,"body":60},"Read memory from the right column","Run `free -h` and look at the `available` column, not `free`. Linux deliberately fills free memory with disk cache that can be reclaimed on demand: `free` always looks low, while `available` shows what is really left for new applications without using swap.",{"title":62,"body":63},"Watch CPU, memory and I\u002FO","Run `vmstat 1 10`. Watch `si` and `so` (swap exchanges, which should stay at zero), `wa` (I\u002FO wait) and `r` (processes waiting for CPU).",{"title":65,"body":66},"Read the load average","Run `uptime`. The three values are averages over 1, 5 and 15 minutes. Compare them with `nproc`: a load durably above the number of cores signals waiting.",{"title":68,"body":69},"Identify the heavy consumers","Run `ps aux --sort=-%mem | head -15`. With containers, add `docker stats --no-stream`; with systemd, `systemd-cgtop` ranks services by consumption.",{"title":71,"body":72},"Measure disk and inodes","Run `df -h` for space and `df -i` for inodes. A disk can refuse writes while bytes remain free, if inodes are exhausted. Also note the size of the folders that grow: media, database, logs, local backups.",{"title":74,"body":75},"Record a history with sar","Install `sysstat`, enable collection according to your distribution, then read memory with `sar -r`, CPU with `sar -u` and load with `sar -q`. Without history, sample it yourself: `vmstat 60 120` produces one reading per minute for two hours.",{"title":77,"body":78},"Log the maximum values","Put the memory-used peak, the load peak and the disk growth in a table. That table, not the average, is what you use to compute the plan.",{"type":80,"title":81,"headers":82,"rows":86},"comparison","What dominates load by site type",[83,84,85],"Site type","Resource that saturates first","What to record",[87,91,95,99,103,107],[88,89,90],"Brochure site or low-traffic WordPress","Memory, through PHP and the database","`free -h` at peak, RAM per PHP process",[92,93,94],"Online shop","Memory and CPU during order peaks","Load during a promotion, number of simultaneous PHP processes",[96,97,98],"Business application with a database","Disk I\u002FO and memory","`wa` in `vmstat`, database size, slow queries",[100,101,102],"Media site or image catalogue","Disk and bandwidth","`df -h`, monthly growth of the media folder",[104,105,106],"Site with a heavy import or scheduled task","Occasional CPU and memory","Load and memory during the task, task duration",[108,109,110],"Containerised application","Combined memory of the containers","`docker stats --no-stream`, declared memory limits",{"type":35,"title":112,"body":113},"Measure the peak, not the average","A server showing 25% average CPU over 24 hours can be saturated for ten minutes every evening. The average erases exactly what takes a site down. To size, keep the maximum value observed over the window, and check that it contains the worst known moment: traffic peak, backup, heavy cron, import.\n\nIf the client does not know when their peaks are, cross-check with the web server access logs and with the dates of email campaigns or promotions. A week of `sar` history covers a full cycle, weekend included. When the site is already slow, a reading taken during the slowdown is worth more than ten readings taken at rest.",{"type":35,"title":115,"body":116},"A simple calculation rule, flagged as an assumption","The following rule is editorial, neither a standard nor a catalogue promise: **required memory = peak consumption, plus a 30% margin**. The 30% figure is this article's assumption; it covers short-term growth and peaks your window did not see. For disk, count used space, plus expected growth over six months, plus at least 20% free.\n\nFor a PHP-FPM site, compute the process memory rather than reading it globally: **PHP memory = measured RAM per process multiplied by `pm.max_children`**. Measure RAM per process with `ps -eo rss,args | awk '\u002F[p]hp-fpm: pool\u002F {s+=$1; n++} END {print s\u002Fn\u002F1024 \" MB\"}'`. The result slightly overestimates, because part of the memory is shared between processes.\n\nFictional worked example: 600 MB for the system, web server and database, plus 20 processes of 60 MB, that is 1,200 MB, make 1,800 MB at peak. With a 30% margin, about 2.4 GB is needed: choose the plan whose RAM is immediately above that.",{"type":118,"title":119,"body":120},"tip","Write the margin into the quote","Record in the quote the measured peak, the margin chosen and the date of the reading. When the client asks why this plan and not the next one, the answer is written down. Repeat the reading every six months: a growing site changes plan before it falls over, not after.",{"type":35,"title":122,"body":123},"Recognise an undersized VPS before the client does","Once the site is in production, a few signals say the plan is too tight. Each leaves a precise trace you can look for without waiting for the client to complain.",{"type":39,"title":125,"items":126},"The signals, with their exact message",[127,128,129,130,131,132,133],"**Process killed for lack of memory** — search with `journalctl -k | grep -i \"out of memory\"` or `dmesg -T | grep -i \"killed process\"` for a line like `Out of memory: Killed process`. The kernel sacrificed a process, often the database.","**Active swap** — non-zero `si` and `so` in `vmstat 1`: the server is swapping memory to disk, and everything slows down.","**High I\u002FO wait** — `wa` durably high in `top`: the disk or the database is the brake, sometimes for lack of cache in memory.","**Load above the number of cores** — a load average durably above `nproc` means processes are waiting their turn.","**Saturated PHP-FPM** — the line `server reached pm.max_children setting (N), consider raising it` in the error log means every process is busy and requests are queuing.","**502 and 504 errors from nginx** — `502` or `504` responses, together with `upstream timed out (110: Connection timed out)`, often accompany PHP-FPM saturation.","**Full disk or exhausted inodes** — `df -h` and `df -i` approach 100%, and writes fail.",{"type":35,"title":135,"body":136},"What more RAM does not fix","Before moving up a plan, check that the problem really is a resource question. A slow SQL query saturates the CPU whatever the plan: the missing index gets fixed, it cannot be compensated for. The absence of an object cache forces PHP to recompute the same pages on every visit. An 8 MB image served as is consumes bandwidth and processing time. Finally, raising `pm.max_children` without raising RAM causes exactly the kill-by-the-kernel you wanted to avoid.\n\nThe healthy approach is to fix these points first, take a new reading, then size on the result. That way you avoid billing the client for a bigger plan that only hides a configuration defect.",{"type":35,"title":138,"body":139},"Choose the plan, then scale up","Once the need is quantified, match it to the range. The VPS Start plan offers 2 vCPU, 4 GB of RAM and 50 GB SSD of storage; the VPS Power plan offers 4 vCPU, 8 GB and 100 GB SSD; the VPS Business plan offers 8 vCPU, 16 GB and 200 GB SSD. Entry price of the range: 99 DH\u002Fmonth.\n\nChoose the smallest plan that covers your need with the written margin, then let vertical scaling do the rest: if the next reading shows the margin melting, you move to the next plan without changing architecture. So you don't wait for that reading, set up continuous alerts, and to know whether the site answers from outside, an availability probe: see \u003Ca href=\"\u002Fen\u002Fblog\u002Fmonitor-client-site-availability-agency-monthly-report\">availability monitoring for client sites\u003C\u002Fa>.","A VPS plan that follows the measurement","Domains, hosting and VPS are managed on a single platform, ServOrbit.com, with VPS plans that resize vertically when the measurement justifies it.","See solutions for professionals","\u002Fsolutions\u002Fprofessionnels",[145,161,182],{"id":146,"slug":147,"slugs":148,"title":152,"excerpt":153,"readTime":154,"views":18,"isPinned":19,"publishedAt":155,"updatedAt":156,"category":157,"categories":158,"featuredImage":29,"bgImage":30,"posterImage":160,"relatedSolution":29},528,"shared-hosting-or-vps-for-agency-client-site",{"fr":149,"en":147,"ar":150,"es":151},"choisir-vps-ou-mutualise-site-client-agence","استضافة-مشتركة-أم-vps-لموقع-عميل-الوكالة","hosting-compartido-o-vps-para-sitio-de-cliente-agencia","VPS or shared hosting for a client site: a decision grid","Shared hosting or VPS for a client site: comparison table, monthly maintenance hours, a five-question grid and the signals that call for a migration.",9,"2026-10-29T00:00:00+00:00","2026-10-29T15:45:55+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":25},[159],{"id":23,"name":24,"slug":25,"color":26,"icon":25},"\u002Fblog\u002Fcovers\u002Fchoisir-vps-ou-mutualise-site-client-agence-poster.svg",{"id":162,"slug":163,"slugs":164,"title":168,"excerpt":169,"readTime":170,"views":18,"isPinned":19,"publishedAt":171,"updatedAt":172,"category":173,"categories":179,"featuredImage":29,"bgImage":30,"posterImage":181,"relatedSolution":29},506,"disk-full-and-ram-alerts-on-a-vps-no-monitoring-stack-needed",{"fr":165,"en":163,"ar":166,"es":167},"alertes-disque-ram-vps-monitoring-proactif","تنبيهات-امتلاء-القرص-والذاكرة-على-vps-دون-منظومة-مراقبة","alertas-de-disco-lleno-y-ram-en-un-vps-sin-pila-de-supervision","Disk full and RAM alerts on a VPS, no monitoring stack needed","Six shell alerts for your client VPS: disk, inodes, OOM, systemd services, certificates, backups, plus a heartbeat that watches the check itself.",13,"2026-10-27T00:00:00+00:00","2026-10-27T23:58:39+00:00",{"id":174,"name":175,"slug":176,"color":177,"icon":178},8,"Security & Monitoring","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[180],{"id":174,"name":175,"slug":176,"color":177,"icon":178},"\u002Fblog\u002Fcovers\u002Falertes-disque-ram-vps-monitoring-proactif-poster.svg",{"id":183,"slug":184,"slugs":185,"title":189,"excerpt":190,"readTime":17,"views":18,"isPinned":19,"publishedAt":191,"updatedAt":192,"category":193,"categories":194,"featuredImage":29,"bgImage":30,"posterImage":196,"relatedSolution":29},541,"monitor-client-site-availability-agency-monthly-report",{"fr":186,"en":184,"ar":187,"es":188},"monitoring-disponibilite-sites-clients-agence-rapport","مراقبة-توفر-مواقع-العملاء-الوكالة-التقرير-الشهري","monitorizar-disponibilidad-sitios-clientes-agencia-informe-mensual","Monitoring client site uptime: the monthly report","Probes, checks before alerting, maintenance windows and a monthly report: how an agency monitors client sites without drowning in false positives.","2026-10-30T00:00:00+00:00","2026-10-31T01:54:06+00:00",{"id":174,"name":175,"slug":176,"color":177,"icon":178},[195],{"id":174,"name":175,"slug":176,"color":177,"icon":178},"\u002Fblog\u002Fcovers\u002Fmonitoring-disponibilite-sites-clients-agence-rapport-poster.svg",1793480377819]