{"id":200,"date":"2026-06-03T12:42:06","date_gmt":"2026-06-03T12:42:06","guid":{"rendered":"https:\/\/blog.offshorekaka.in\/?p=200"},"modified":"2026-08-27T05:43:39","modified_gmt":"2026-08-27T05:43:39","slug":"choose-offshore-vps-specs","status":"publish","type":"post","link":"https:\/\/offshorekaka.in\/blog\/choose-offshore-vps-specs\/","title":{"rendered":"How to Choose Offshore VPS Specs: CPU, RAM, Storage and Bandwidth"},"content":{"rendered":"<div class=\"ok-pro-panel\">\n<p><span class=\"ok-pro-kicker\">Server Guides<\/span><\/p>\n<h2>Buy for what you use, not what you hope for<\/h2>\n<p>Most people buy too much CPU and too little RAM. It is an easy mistake, because CPU is the number every provider puts in the largest font, and RAM is the one that actually kills sites.<\/p>\n<p>This guide walks through each spec on an <a href=\"https:\/\/offshorekaka.in\/offshore-vps-server\/\">offshore VPS<\/a>, what it really controls, and the commands that tell you what you are using now rather than what you imagine you need.<\/p>\n<div class=\"ok-pro-grid\">\n<div class=\"ok-pro-card\"><strong>Rule of thumb<\/strong><span>RAM first, disk type second, cores last.<\/span><\/div>\n<div class=\"ok-pro-card\"><strong>Common mistake<\/strong><span>4 cores and 2GB RAM. It should be the other way round.<\/span><\/div>\n<div class=\"ok-pro-card\"><strong>Easy to fix later<\/strong><span>All of it, if the provider allows resizing.<\/span><\/div>\n<\/div>\n<\/div>\n<div class=\"ok-toc\"><strong>On this page<\/strong><a href=\"#measure\">Measure what you use now<\/a><a href=\"#ram\">RAM<\/a><a href=\"#cpu\">CPU<\/a><a href=\"#disk\">Storage<\/a><a href=\"#bandwidth\">Bandwidth<\/a><a href=\"#table\">Quick sizing table<\/a><a href=\"#faq\">FAQ<\/a><\/div>\n<h2 id=\"measure\">Measure what you use now<\/h2>\n<p>If you already have a server, this takes thirty seconds and beats any amount of guessing:<\/p>\n<pre><code>nproc\nfree -h\ndf -h\nlsblk -d -o NAME,SIZE,ROTA,MODEL<\/code><\/pre>\n<figure class=\"wp-block-image size-large ok-inline-visual\"><img decoding=\"async\" src=\"https:\/\/offshorekaka.in\/blog\/wp-content\/uploads\/2026\/08\/ok-vps-specs-check.webp\" alt=\"Terminal showing CPU model and core count alongside memory and disk usage\" loading=\"lazy\" width=\"2296\" height=\"818\"><figcaption>Cores, memory and disk in one look. Compare this against what you are paying for.<\/figcaption><\/figure>\n<p>Run it during your busiest hour, not at midnight. A server that looks half empty on a Sunday morning tells you nothing about Monday at 10am.<\/p>\n<h2 id=\"ram\">RAM<\/h2>\n<p>Memory is where sites actually die, and the failure is ugly. When RAM runs out, Linux starts swapping to disk, which is orders of magnitude slower, and then the kernel starts killing processes. Usually it kills MySQL, because MySQL is the biggest thing in memory. The site then throws database connection errors that look like a database problem but are a memory problem.<\/p>\n<p>Rough figures for a LAMP or LEMP stack:<\/p>\n<ul>\n<li><strong>1GB<\/strong> works for one small WordPress site with caching on. It is tight. MySQL alone wants 200 to 300MB before it does anything useful.<\/li>\n<li><strong>2GB<\/strong> is the honest starting point for a real site. Room for MySQL, a few PHP workers, and a burst of traffic.<\/li>\n<li><strong>4GB<\/strong> handles several sites, or one busy one, or WooCommerce, which uses far more memory per request than a blog.<\/li>\n<li><strong>8GB and up<\/strong> when you are running Redis, Elasticsearch, or a control panel with its own services.<\/li>\n<\/ul>\n<p>Read the <strong>available<\/strong> column from <code>free -h<\/code>, not free. Available counts cache the kernel can reclaim on demand, so it is the number that tells you whether you have headroom. If available is consistently under about 15 percent of total and swap is in use, you need more RAM.<\/p>\n<h2 id=\"cpu\">CPU<\/h2>\n<p>Cores control how many things happen at once, not how fast one thing happens. A single page load is mostly one core doing work in sequence, so going from 2 cores to 8 does nothing at all for a single visitor. What it changes is how many visitors you serve simultaneously before they queue.<\/p>\n<ul>\n<li><strong>1 core<\/strong> is enough for a low traffic site with caching. Cached pages barely touch the CPU.<\/li>\n<li><strong>2 cores<\/strong> is the sensible default. One can be busy without everything else stalling.<\/li>\n<li><strong>4 cores<\/strong> for a busy site, a shop, or anything doing real work like image processing or video.<\/li>\n<li><strong>More than 4<\/strong> only if you have measured sustained high load, not because it sounds better.<\/li>\n<\/ul>\n<p>Check whether you are actually CPU bound before paying for more. Run <code>uptime<\/code> and compare load average to core count. Load of 1.5 on a 2 core box is fine. Load of 8 on a 2 core box is a problem. And look at the <code>wa<\/code> figure in <code>top<\/code>: if that is high while CPU is idle, your bottleneck is the disk, and more cores will change nothing.<\/p>\n<h2 id=\"disk\">Storage<\/h2>\n<p>Disk type matters more than disk size for most sites. NVMe against a spinning disk is not a small difference, it is roughly a hundred times faster on the random reads a database does constantly.<\/p>\n<figure class=\"wp-block-image size-large ok-inline-visual\"><img decoding=\"async\" src=\"https:\/\/offshorekaka.in\/blog\/wp-content\/uploads\/2026\/08\/ok-disk-type-check.webp\" alt=\"lsblk output showing an NVMe device with ROTA 0 next to a rotational disk with ROTA 1\" loading=\"lazy\" width=\"2296\" height=\"428\"><figcaption>ROTA 0 means solid state. ROTA 1 means it spins. Check before you buy, not after.<\/figcaption><\/figure>\n<p>On size, add up what you actually store: the site files, the database, and then double it. The doubling is for backups, temporary files during updates, and logs. A WordPress site with 5GB of media needs a 20GB disk, not a 10GB one, or the first backup fills it.<\/p>\n<p>Watch the disk more closely than anything else. A full disk takes the site down in a way that is genuinely confusing to debug, because MySQL stops accepting writes and every error points somewhere else. Our <a href=\"https:\/\/offshorekaka.in\/blog\/offshore-server-monitoring-guide\/\">monitoring guide<\/a> covers alerting on it.<\/p>\n<h2 id=\"bandwidth\">Bandwidth<\/h2>\n<p>Two different numbers get called bandwidth and they are not the same thing.<\/p>\n<p><strong>Transfer<\/strong> is how many terabytes you can move per month. Most sites never come close. A page averaging 2MB with 100,000 monthly visits is about 200GB, and typical plans include far more than that.<\/p>\n<p><strong>Port speed<\/strong> is how fast a single transfer can go. 1Gbps versus 100Mbps decides how quickly a large file downloads and how well you cope with a traffic spike. For streaming or large downloads this matters far more than the monthly allowance.<\/p>\n<p>Where people get caught is the word unmetered, which usually means unlimited transfer at a capped port speed. We wrote about how to read those claims in <a href=\"https:\/\/offshorekaka.in\/blog\/unmetered-dedicated-server-bandwidth\/\">unmetered bandwidth explained<\/a>.<\/p>\n<h2 id=\"table\">Quick sizing table<\/h2>\n<table>\n<thead>\n<tr>\n<th>What you are running<\/th>\n<th>RAM<\/th>\n<th>Cores<\/th>\n<th>Disk<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>One small WordPress blog, cached<\/td>\n<td>1 to 2GB<\/td>\n<td>1<\/td>\n<td>20GB NVMe<\/td>\n<\/tr>\n<tr>\n<td>Business site with forms and email<\/td>\n<td>2GB<\/td>\n<td>2<\/td>\n<td>40GB NVMe<\/td>\n<\/tr>\n<tr>\n<td>WooCommerce shop, moderate traffic<\/td>\n<td>4GB<\/td>\n<td>2 to 4<\/td>\n<td>60GB NVMe<\/td>\n<\/tr>\n<tr>\n<td>Several client sites on one box<\/td>\n<td>4 to 8GB<\/td>\n<td>4<\/td>\n<td>100GB NVMe<\/td>\n<\/tr>\n<tr>\n<td>App with Redis or a search engine<\/td>\n<td>8GB and up<\/td>\n<td>4<\/td>\n<td>100GB and up<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h2 id=\"test\">How to confirm you sized it right<\/h2>\n<ol>\n<li>A week after launch, run <code>free -h<\/code> at your busiest hour. Available should be above 20 percent.<\/li>\n<li>Run <code>uptime<\/code>. Load should sit below your core count most of the time.<\/li>\n<li>Run <code>df -h<\/code>. Disk should be under 70 percent with backups included.<\/li>\n<li>Check <code>top<\/code> for wa. Anything consistently above a few percent means disk pressure.<\/li>\n<li>Check swap usage. Regular swapping means you are short on RAM.<\/li>\n<\/ol>\n<h2 id=\"trouble\">When something breaks<\/h2>\n<table>\n<thead>\n<tr>\n<th>What you see<\/th>\n<th>Why<\/th>\n<th>Fix<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Database connection errors under load<\/td>\n<td>MySQL killed by the out of memory killer<\/td>\n<td>More RAM, or tune MySQL buffers down<\/td>\n<\/tr>\n<tr>\n<td>Site fine alone, slow with visitors<\/td>\n<td>Not enough PHP workers or cores<\/td>\n<td>Turn on page caching first, then add cores<\/td>\n<\/tr>\n<tr>\n<td>Everything slow, CPU idle<\/td>\n<td>Disk bound. Check wa in top<\/td>\n<td>Move to NVMe, or find the query doing the reads<\/td>\n<\/tr>\n<tr>\n<td>Random failures, disk under 100 percent<\/td>\n<td>Out of inodes rather than space<\/td>\n<td><code>df -i<\/code> to confirm, then clear millions of small cache files<\/td>\n<\/tr>\n<tr>\n<td>Backups fail overnight<\/td>\n<td>Disk fills during the backup<\/td>\n<td>Size for double your data, and add retention<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h2 id=\"checklist\">Checklist<\/h2>\n<ul>\n<li>Current usage measured at a busy hour, not at random.<\/li>\n<li>RAM sized with headroom, since this is what fails hardest.<\/li>\n<li>Cores matched to concurrency, not to marketing.<\/li>\n<li>NVMe confirmed with ROTA 0.<\/li>\n<li>Disk sized at roughly double your data.<\/li>\n<li>Port speed checked, not just monthly transfer.<\/li>\n<li>Monitoring in place so you find out before your visitors do.<\/li>\n<\/ul>\n<div class=\"ok-cta-box\">\n<p><strong>Not sure what size you need?<\/strong><\/p>\n<p>OffshoreKaka VPS plans run on AMD EPYC with NVMe storage in Amsterdam and Frankfurt, and you can move up a plan without rebuilding.<\/p>\n<p><a class=\"btn ok-cta-link\" href=\"https:\/\/offshorekaka.in\/offshore-vps-server\/\">See the VPS plans<\/a><\/p>\n<\/div>\n<h2 id=\"faq\">FAQ<\/h2>\n<h3>Start small or start big?<\/h3>\n<p>Start small, but only if resizing is easy with your provider. Check that before you buy. A plan you can grow into next month beats paying for headroom you may never use. What you should not skimp on is RAM, because running out of it is the failure that takes the site down rather than just slowing it.<\/p>\n<h3>How do I tell which spec I am short on?<\/h3>\n<p>Load average above core count means CPU. Available memory near zero with swap in use means RAM. High wa in top with idle CPU means disk. Disk above 85 percent means space. One command each, and they rarely disagree.<\/p>\n<h3>Does a bigger VPS help my search ranking?<\/h3>\n<p>Only through speed, and only if the server was the bottleneck in the first place. On most slow sites it is not. Caching and front end weight matter far more. Our <a href=\"https:\/\/offshorekaka.in\/blog\/optimize-ttfb-on-offshore-hosting\/\">TTFB guide<\/a> shows how to find out which one you have.<\/p>\n<h3>Is shared hosting enough instead?<\/h3>\n<p>For a blog or a brochure site with caching, very often yes, and it costs a fraction as much. You want a VPS when you need root access, a custom stack, isolated resources, or you have simply outgrown the limits. There is a fuller comparison in <a href=\"https:\/\/offshorekaka.in\/blog\/offshore-vps-vs-shared-hosting\/\">VPS versus shared hosting<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Most people buy too much CPU and too little memory. What each spec actually controls, with the commands to measure your real usage.<\/p>\n","protected":false},"author":1,"featured_media":905,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6],"tags":[],"class_list":["post-200","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-server-guides"],"_links":{"self":[{"href":"https:\/\/offshorekaka.in\/blog\/wp-json\/wp\/v2\/posts\/200","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/offshorekaka.in\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/offshorekaka.in\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/offshorekaka.in\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/offshorekaka.in\/blog\/wp-json\/wp\/v2\/comments?post=200"}],"version-history":[{"count":5,"href":"https:\/\/offshorekaka.in\/blog\/wp-json\/wp\/v2\/posts\/200\/revisions"}],"predecessor-version":[{"id":1003,"href":"https:\/\/offshorekaka.in\/blog\/wp-json\/wp\/v2\/posts\/200\/revisions\/1003"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/offshorekaka.in\/blog\/wp-json\/wp\/v2\/media\/905"}],"wp:attachment":[{"href":"https:\/\/offshorekaka.in\/blog\/wp-json\/wp\/v2\/media?parent=200"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/offshorekaka.in\/blog\/wp-json\/wp\/v2\/categories?post=200"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/offshorekaka.in\/blog\/wp-json\/wp\/v2\/tags?post=200"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}