{"id":1152,"date":"2026-09-17T02:39:09","date_gmt":"2026-09-17T02:39:09","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=1152"},"modified":"2026-09-17T02:39:09","modified_gmt":"2026-09-17T02:39:09","slug":"mysql-memory-budget-1gb-vps-tuning","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/mysql-memory-budget-1gb-vps-tuning\/","title":{"rendered":"MySQL Memory Trimming on a 1\u20132 GB VPS: A Budget You Can Actually Defend"},"content":{"rendered":"\n\n<p class=\"wp-block-paragraph\">Running MySQL on a 1 GB VPS is entirely possible \u2014 the default configuration is just built for a machine with 8 GB or more, and the surplus is spent on buffers that a small instance will never use efficiently. This article is a budget exercise: enumerate what MySQL allocates, cut what cannot pay for itself at this scale, and verify the result with numbers. Before any of it, though, confirm you are actually memory-constrained rather than I\/O-constrained; the two present identically from the outside.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Where the memory goes<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Component<\/th><th>Default (MySQL 8.0)<\/th><th>Per-connection?<\/th><th>Sensible 1 GB value<\/th><\/tr><\/thead><tbody><tr><td><code>innodb_buffer_pool_size<\/code><\/td><td>128 MB<\/td><td>No<\/td><td>256\u2013384 MB<\/td><\/tr><tr><td><code>innodb_log_buffer_size<\/code><\/td><td>16 MB<\/td><td>No<\/td><td>8\u201316 MB<\/td><\/tr><tr><td><code>key_buffer_size<\/code><\/td><td>8 MB (deprecated MyISAM)<\/td><td>No<\/td><td>16 MB<\/td><\/tr><tr><td><code>tmp_table_size<\/code> \/ <code>max_heap_table_size<\/code><\/td><td>16 MB each<\/td><td>No (per temp table)<\/td><td>16\u201332 MB, kept equal<\/td><\/tr><tr><td><code>sort_buffer_size<\/code><\/td><td>256 KB<\/td><td><strong>Yes<\/strong><\/td><td>256 KB\u2013512 KB<\/td><\/tr><tr><td><code>join_buffer_size<\/code><\/td><td>256 KB<\/td><td><strong>Yes<\/strong><\/td><td>256 KB<\/td><\/tr><tr><td><code>read_buffer_size<\/code> \/ <code>read_rnd_buffer_size<\/code><\/td><td>128 KB \/ 256 KB<\/td><td><strong>Yes<\/strong><\/td><td>128 KB \/ 256 KB<\/td><\/tr><tr><td><code>binlog_cache_size<\/code><\/td><td>32 KB<\/td><td><strong>Yes<\/strong><\/td><td>32 KB<\/td><\/tr><tr><td>Table definition cache<\/td><td>~400 entries<\/td><td>No<\/td><td>Largely handles it<\/td><\/tr><tr><td>Performance Schema<\/td><td>Enabled, ~200 MB+<\/td><td>No<\/td><td>Disable on 1 GB<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">The per-connection column is the one that surprises people. MySQL does not allocate those buffers per connection continuously \u2014 it allocates them on demand for the duration of a query \u2014 but the theoretical worst case is a sum across all connections, and that is what determines whether you OOM. Twenty connections multiplied by several megabytes of per-query buffers is how a &#8220;tuned&#8221; server dies under load.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Step 1: measure what you have before changing anything<\/h2>\n\n\n\n<pre class=\"wp-block-code\"><code>-- Current settings that matter\nSELECT @@innodb_buffer_pool_size\/1024\/1024 AS bp_mb,\n       @@innodb_log_buffer_size\/1024\/1024  AS log_buf_mb,\n       @@sort_buffer_size\/1024\/1024        AS sort_mb,\n       @@join_buffer_size\/1024\/1024        AS join_mb,\n       @@tmp_table_size\/1024\/1024          AS tmp_mb,\n       @@max_connections                   AS max_conn;\n\n-- Actual peak memory demanded by MySQL\nSELECT * FROM sys.memory_global_by_current_bytes LIMIT 10;\n\n-- Who is holding memory, by component\nSELECT event_name, current_alloc\/1024\/1024 AS mb\nFROM performance_schema.memory_summary_global_by_event_name\nWHERE current_alloc &gt; 10*1024*1024\nORDER BY current_alloc DESC;<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">And from the shell, observe the real residency:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ps -o rss= -C mysqld | awk '{ printf \"mysqld RSS: %.0f MB\\n\", $1\/1024 }'\n# Sample over time to catch growth that indicates a leak vs steady state\nwhile true; do\n  printf \"%s  \" \"$(date +%H:%M:%S)\"\n  ps -o rss= -C mysqld | awk '{ printf \"%.0f MB\\n\", $1\/1024 }'\n  sleep 30\ndone<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\">Step 2: apply a defensible budget<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Here is the arithmetic for a 1 GB VPS that also runs nginx and PHP-FPM. Write it down; the point is to be able to explain why each number is what it is.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># 1 GB VPS budget\nOS + systemd + sshd + cron ........  180 MB\nnginx ..............................   60 MB\nPHP-FPM (8 children x 40 MB) ......  320 MB\nRedis (optional, small) ...........   80 MB\nMySQL .............................  310 MB   &lt;-- the share we will defend\n--------------------------------------------\nheadroom (unallocated) ............   50 MB\n\n# Inside the 310 MB MySQL share:\ninnodb_buffer_pool_size ...........  192 MB   (60%)\ninnodb_log_buffer_size ............    8 MB\nperformance_schema ................  OFF\ntmp_table_size\/max_heap_table .....   16 MB   (equal values)\nkey_buffer_size ...................    8 MB\nper-connection buffers ............  ~40 KB per query, worst case capped\nmax_connections ...................   30<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Note that the buffer pool is deliberately not the largest possible number. On a 1 GB instance the buffer pool is competing with the OS page cache for the same physical RAM, and InnoDB reads go through both. Oversizing the pool past roughly 60% of the MySQL share usually produces no hit-rate improvement while increasing the chance that a checkpoint stall coincides with high write load. Sizing it precisely is arithmetic, and <a href=\"https:\/\/virtualserversvps.com\/blog\/mysql-innodb-buffer-pool-sizing-1gb-vps\/\">the InnoDB buffer pool sizing walkthrough<\/a> shows the per-table calculation for the specific case of a 1 GB VPS.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Step 3: the actual configuration<\/h2>\n\n\n\n<pre class=\"wp-block-code\"><code>[mysqld]\n# --- Memory ---\ninnodb_buffer_pool_size     = 192M\ninnodb_buffer_pool_instances = 1\ninnodb_log_buffer_size      = 8M\nkey_buffer_size             = 8M\n\n# --- Temp tables: keep the pair equal or MySQL picks the smaller ---\ntmp_table_size              = 16M\nmax_heap_table_size         = 16M\ninternal_tmp_mem_storage_engine = MEMORY\n\n# --- Per-connection buffers: conservative, not generous ---\nsort_buffer_size            = 256K\njoin_buffer_size            = 256K\nread_buffer_size            = 128K\nread_rnd_buffer_size        = 256K\n\n# --- Connections: bound them, then let a pooler handle the rest ---\nmax_connections             = 30\nthread_cache_size           = 8\n\n# --- Disable what a 1 GB instance cannot afford ---\nperformance_schema          = OFF\ninnodb_stats_persistent     = ON\ntable_open_cache            = 400\ntable_definition_cache      = 400\n\n# --- I\/O behaviour appropriate to shared storage ---\ninnodb_io_capacity          = 200\ninnodb_io_capacity_max      = 400\ninnodb_flush_method         = O_DIRECT\ninnodb_flush_log_at_trx_commit = 2   # 1 extra second of loss window; big fsync saving<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Three notes on the risky-looking lines. <code>performance_schema = OFF<\/code> saves a substantial amount of memory (commonly 150\u2013250 MB in MySQL 8.0) but you lose the instrumentation used in Step 1 \u2014 do the measurement first, then disable it. <code>innodb_flush_log_at_trx_commit = 2<\/code> means a crash can lose up to one second of committed transactions; for a web application that is usually acceptable and it reduces fsync pressure significantly. Do not set it to 2 for anything with a financial or inventory consistency requirement.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">If you need more concurrency than 30 connections can provide, do not raise <code>max_connections<\/code> \u2014 put a connection pooler in front. A pooler multiplexes hundreds of application connections onto a small number of database connections, which is exactly the right architecture when the database&#8217;s memory is the constraint. PgBouncer&#8217;s equivalent for MySQL is ProxySQL; the pooling argument is covered in <a href=\"https:\/\/virtualserversvps.com\/blog\/pgbouncer-connection-pooling-postgresql-vps\/\">our connection pooling article<\/a> and translates directly.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Step 4: verify the reduction is real<\/h2>\n\n\n\n<pre class=\"wp-block-code\"><code># Restart, then confirm RSS settled lower\nsystemctl restart mysql\nsleep 30\nps -o rss= -C mysqld | awk '{ printf \"post-tune RSS: %.0f MB\\n\", $1\/1024 }'\n\n# Confirm the buffer pool is being used, not wasted\nmysql -e \"SHOW ENGINE INNODB STATUS\\G\" | grep -A2 'BUFFER POOL AND MEMORY'\nmysql -e \"SELECT ROUND(1 - (SELECT VARIABLE_VALUE FROM performance_schema.global_status\n  WHERE VARIABLE_NAME='Innodb_buffer_pool_reads') \/\n  (SELECT VARIABLE_VALUE FROM performance_schema.global_status\n  WHERE VARIABLE_NAME='Innodb_buffer_pool_read_requests'), 4) AS hit_ratio;\"\n\n# Confirm nothing is spilling to disk temp tables excessively\nmysql -e \"SHOW GLOBAL STATUS LIKE 'Created_tmp_disk_tables';\"<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Interpret the results:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Buffer pool hit ratio above 0.99<\/strong> \u2014 the pool is adequate. Do not increase it; that memory is better spent on PHP or the OS page cache.<\/li>\n\n\n\n<li><strong>Hit ratio between 0.95 and 0.99 with low disk I\/O<\/strong> \u2014 usually fine. Chasing the last fraction of a percent costs far more memory than it returns.<\/li>\n\n\n\n<li><strong>Hit ratio below 0.95<\/strong> \u2014 either the working set genuinely does not fit, or a query is scanning the whole table repeatedly. Check the slow log before adding memory; a missing index looks exactly like an undersized pool.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">Step 5: guard against the OOM killer<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Even with a good budget, a spike in connections or a runaway query can push the system over. Give MySQL a nudge toward being killed rather than the kernel or your database being the victim:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>mkdir -p \/etc\/systemd\/system\/mysql.service.d\ncat &gt; \/etc\/systemd\/system\/mysql.service.d\/oom.conf &lt;&lt;'EOF'\n[Service]\nOOMScoreAdjust=-500\nEOF\nsystemctl daemon-reload &amp;&amp; systemctl restart mysql\n\n# And add a monitored swap file so pressure surfaces as latency, not death\nfallocate -l 1G \/swapfile &amp;&amp; chmod 600 \/swapfile\nmkswap \/swapfile &amp;&amp; swapon \/swapfile\necho '\/swapfile none swap sw 0 0' &gt;&gt; \/etc\/fstab<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Note that <code>OOMScoreAdjust=-500<\/code> makes MySQL <em>less<\/em> likely to be killed \u2014 negative values lower the score, positive values raise it. The intent is to sacrifice a PHP worker before the database. Verify with <code>cat \/proc\/$(pgrep -x mysqld)\/oom_score_adj<\/code>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">When trimming stops being the answer<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">There is a floor below which tuning MySQL is just removing capability. If the buffer pool is at 192 MB and the hit ratio is 0.92, the dataset is bigger than the machine. The options at that point are: reduce the dataset (archive old rows \u2014 usually the cheapest and most effective intervention), move the database to its own instance, or move to a plan with more RAM. Compare the cost of the latter against the alternatives honestly, and remember that a database instance needs predictable I\/O as much as it needs memory, which is why <a href=\"https:\/\/virtualserversvps.com\/vps-vs-dedicated-server\">the VPS versus dedicated server decision<\/a> is most finely balanced for database hosts.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">If you prefer to keep the budget above but stop babysitting it, the practical alternative is a provider whose plan ships with a working low-memory default. <a href=\"https:\/\/interserver.net\/vps?id=1067805&amp;sid=virtualserversvps\" rel=\"noreferrer noopener sponsored\" target=\"_blank\">InterServer&#8217;s VPS plans<\/a> include memory allocations you can map onto the budget above, and their self-managed model means root access to apply it. If you would rather not own MySQL tuning at all, <a href=\"https:\/\/cloudways.com\/en\/?id=2010927&amp;data1=virtualserversvps\" rel=\"noreferrer noopener sponsored\" target=\"_blank\">Cloudways&#8217; managed database stack<\/a> handles the buffer configuration for you.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Final note on the order of operations: trim the buffer pool only after you have confirmed the hit ratio is acceptable, disable Performance Schema only after you have collected your measurements, and always restart with a monitoring loop running so you can see RSS settle. A memory edit made blind is indistinguishable from a memory leak.<\/p>\n\n","protected":false},"excerpt":{"rendered":"<p>A concrete memory budget for running MySQL or MariaDB on a 1\u20132 GB VPS: which buffers to shrink, which to leave alone, and how to verify the reduction on a live server.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":1,"footnotes":""},"categories":[3],"tags":[],"class_list":["post-1152","post","type-post","status-publish","format-standard","hentry","category-performance-optimization"],"yoast_head":"<!-- This site is optimized with the Yoast SEO Premium plugin v26.1 (Yoast SEO v26.1) - https:\/\/yoast.com\/wordpress\/plugins\/seo\/ -->\n<title>MySQL Memory Trimming on a 1\u20132 GB VPS: A Budget You Can Actually Defend - Virtual Servers VPS Blog<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/virtualserversvps.com\/blog\/mysql-memory-budget-1gb-vps-tuning\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"MySQL Memory Trimming on a 1\u20132 GB VPS: A Budget You Can Actually Defend\" \/>\n<meta property=\"og:description\" content=\"MySQL Memory Trimming on a 1\u20132 GB VPS: A Budget You Can Actually Defend\" \/>\n<meta property=\"og:url\" content=\"https:\/\/virtualserversvps.com\/blog\/mysql-memory-budget-1gb-vps-tuning\/\" \/>\n<meta property=\"og:site_name\" content=\"Virtual Servers VPS Blog\" \/>\n<meta property=\"article:published_time\" content=\"2026-09-17T02:39:09+00:00\" \/>\n<meta name=\"author\" content=\"Virtual-Servers-Vps-Editor\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Virtual-Servers-Vps-Editor\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"7 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"https:\/\/virtualserversvps.com\/blog\/mysql-memory-budget-1gb-vps-tuning\/\",\"url\":\"https:\/\/virtualserversvps.com\/blog\/mysql-memory-budget-1gb-vps-tuning\/\",\"name\":\"MySQL Memory Trimming on a 1\u20132 GB VPS: A Budget You Can Actually Defend - Virtual Servers VPS Blog\",\"isPartOf\":{\"@id\":\"https:\/\/virtualserversvps.com\/blog\/#website\"},\"datePublished\":\"2026-09-17T02:39:09+00:00\",\"author\":{\"@id\":\"https:\/\/virtualserversvps.com\/blog\/#\/schema\/person\/82a299a8284a66ff49f97c74684724a0\"},\"breadcrumb\":{\"@id\":\"https:\/\/virtualserversvps.com\/blog\/mysql-memory-budget-1gb-vps-tuning\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/virtualserversvps.com\/blog\/mysql-memory-budget-1gb-vps-tuning\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/virtualserversvps.com\/blog\/mysql-memory-budget-1gb-vps-tuning\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/virtualserversvps.com\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"MySQL Memory Trimming on a 1\u20132 GB VPS: A Budget You Can Actually Defend\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/virtualserversvps.com\/blog\/#website\",\"url\":\"https:\/\/virtualserversvps.com\/blog\/\",\"name\":\"Virtual Servers VPS Blog\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/virtualserversvps.com\/blog\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"https:\/\/virtualserversvps.com\/blog\/#\/schema\/person\/82a299a8284a66ff49f97c74684724a0\",\"name\":\"Virtual-Servers-Vps-Editor\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/virtualserversvps.com\/blog\/#\/schema\/person\/image\/\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/d820b15f1cd028e97610d9adf536df7be5cb6423869967037d468d5355fa003f?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/d820b15f1cd028e97610d9adf536df7be5cb6423869967037d468d5355fa003f?s=96&d=mm&r=g\",\"caption\":\"Virtual-Servers-Vps-Editor\"},\"sameAs\":[\"https:\/\/virtualserversvps.com\/blog\"],\"url\":\"https:\/\/virtualserversvps.com\/blog\/author\/virtualserversvps\/\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"MySQL Memory Trimming on a 1\u20132 GB VPS: A Budget You Can Actually Defend - Virtual Servers VPS Blog","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/virtualserversvps.com\/blog\/mysql-memory-budget-1gb-vps-tuning\/","og_locale":"en_US","og_type":"article","og_title":"MySQL Memory Trimming on a 1\u20132 GB VPS: A Budget You Can Actually Defend","og_description":"MySQL Memory Trimming on a 1\u20132 GB VPS: A Budget You Can Actually Defend","og_url":"https:\/\/virtualserversvps.com\/blog\/mysql-memory-budget-1gb-vps-tuning\/","og_site_name":"Virtual Servers VPS Blog","article_published_time":"2026-09-17T02:39:09+00:00","author":"Virtual-Servers-Vps-Editor","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Virtual-Servers-Vps-Editor","Est. reading time":"7 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/virtualserversvps.com\/blog\/mysql-memory-budget-1gb-vps-tuning\/","url":"https:\/\/virtualserversvps.com\/blog\/mysql-memory-budget-1gb-vps-tuning\/","name":"MySQL Memory Trimming on a 1\u20132 GB VPS: A Budget You Can Actually Defend - Virtual Servers VPS Blog","isPartOf":{"@id":"https:\/\/virtualserversvps.com\/blog\/#website"},"datePublished":"2026-09-17T02:39:09+00:00","author":{"@id":"https:\/\/virtualserversvps.com\/blog\/#\/schema\/person\/82a299a8284a66ff49f97c74684724a0"},"breadcrumb":{"@id":"https:\/\/virtualserversvps.com\/blog\/mysql-memory-budget-1gb-vps-tuning\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/virtualserversvps.com\/blog\/mysql-memory-budget-1gb-vps-tuning\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/virtualserversvps.com\/blog\/mysql-memory-budget-1gb-vps-tuning\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/virtualserversvps.com\/blog\/"},{"@type":"ListItem","position":2,"name":"MySQL Memory Trimming on a 1\u20132 GB VPS: A Budget You Can Actually Defend"}]},{"@type":"WebSite","@id":"https:\/\/virtualserversvps.com\/blog\/#website","url":"https:\/\/virtualserversvps.com\/blog\/","name":"Virtual Servers VPS Blog","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/virtualserversvps.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Person","@id":"https:\/\/virtualserversvps.com\/blog\/#\/schema\/person\/82a299a8284a66ff49f97c74684724a0","name":"Virtual-Servers-Vps-Editor","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/virtualserversvps.com\/blog\/#\/schema\/person\/image\/","url":"https:\/\/secure.gravatar.com\/avatar\/d820b15f1cd028e97610d9adf536df7be5cb6423869967037d468d5355fa003f?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/d820b15f1cd028e97610d9adf536df7be5cb6423869967037d468d5355fa003f?s=96&d=mm&r=g","caption":"Virtual-Servers-Vps-Editor"},"sameAs":["https:\/\/virtualserversvps.com\/blog"],"url":"https:\/\/virtualserversvps.com\/blog\/author\/virtualserversvps\/"}]}},"_links":{"self":[{"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/posts\/1152","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/comments?post=1152"}],"version-history":[{"count":1,"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/posts\/1152\/revisions"}],"predecessor-version":[{"id":1153,"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/posts\/1152\/revisions\/1153"}],"wp:attachment":[{"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/media?parent=1152"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/categories?post=1152"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/tags?post=1152"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}