{"id":4491,"date":"2026-02-05T13:20:43","date_gmt":"2026-02-05T10:20:43","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/vps-hosting-for-moodle-and-lms-cpu-ram-and-database-sizing\/"},"modified":"2026-02-05T13:20:43","modified_gmt":"2026-02-05T10:20:43","slug":"vps-hosting-for-moodle-and-lms-cpu-ram-and-database-sizing","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/vps-hosting-for-moodle-and-lms-cpu-ram-and-database-sizing\/","title":{"rendered":"VPS Hosting for Moodle and LMS: CPU, RAM and Database Sizing"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><p>Moodle and other LMS platforms can look lightweight from the outside: a few courses, some videos, a quiz here and there. But the moment real users start clicking \u201cStart quiz\u201d at the same time, CPU, RAM and database performance become the difference between a smooth learning experience and a support nightmare. In this guide, we\u2019ll walk through how to size a <a href=\"https:\/\/www.dchost.com\/vps\">VPS<\/a> correctly for Moodle and similar LMS workloads, focusing on vCPU, RAM and database requirements for different sizes of deployments. We\u2019ll look at realistic scenarios, explain what \u201cconcurrent users\u201d really means in practice, and show how to plan an architecture that can grow from a small training portal to a serious multi\u2011faculty environment. As dchost.com, we see the same patterns again and again: under\u2011estimated CPU for quiz peaks, not enough RAM for the database buffer pool, and storage that simply can\u2019t keep up with I\/O. This article is our practical playbook to avoid those mistakes from day one.<\/p>\n<div id=\"toc_container\" class=\"toc_transparent no_bullets\"><p class=\"toc_title\">\u0130&ccedil;indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#Why_VPS_Hosting_Fits_Moodle_and_LMS_Platforms\"><span class=\"toc_number toc_depth_1\">1<\/span> Why VPS Hosting Fits Moodle and LMS Platforms<\/a><\/li><li><a href=\"#Key_Resource_Types_for_Moodle_CPU_RAM_Storage_and_Database\"><span class=\"toc_number toc_depth_1\">2<\/span> Key Resource Types for Moodle: CPU, RAM, Storage and Database<\/a><ul><li><a href=\"#CPU_Where_the_Cycles_Go\"><span class=\"toc_number toc_depth_2\">2.1<\/span> CPU: Where the Cycles Go<\/a><\/li><li><a href=\"#RAM_PHP_Workers_Database_Buffers_and_Caches\"><span class=\"toc_number toc_depth_2\">2.2<\/span> RAM: PHP Workers, Database Buffers and Caches<\/a><\/li><li><a href=\"#Storage_and_IOPS_More_Than_Just_Disk_Size\"><span class=\"toc_number toc_depth_2\">2.3<\/span> Storage and IOPS: More Than Just Disk Size<\/a><\/li><li><a href=\"#Database_The_Real_Bottleneck_Under_Load\"><span class=\"toc_number toc_depth_2\">2.4<\/span> Database: The Real Bottleneck Under Load<\/a><\/li><\/ul><\/li><li><a href=\"#Understanding_Concurrent_Users_for_Moodle_and_LMS\"><span class=\"toc_number toc_depth_1\">3<\/span> Understanding Concurrent Users for Moodle and LMS<\/a><\/li><li><a href=\"#Baseline_VPS_Sizing_for_Moodle_and_LMS_Deployments\"><span class=\"toc_number toc_depth_1\">4<\/span> Baseline VPS Sizing for Moodle and LMS Deployments<\/a><ul><li><a href=\"#Scenario_1_Small_School_or_Pilot_Project\"><span class=\"toc_number toc_depth_2\">4.1<\/span> Scenario 1: Small School or Pilot Project<\/a><\/li><li><a href=\"#Scenario_2_Corporate_Training_Portal_or_MediumSized_School\"><span class=\"toc_number toc_depth_2\">4.2<\/span> Scenario 2: Corporate Training Portal or Medium\u2011Sized School<\/a><\/li><li><a href=\"#Scenario_3_FacultyLevel_Moodle_or_Large_Training_Department\"><span class=\"toc_number toc_depth_2\">4.3<\/span> Scenario 3: Faculty\u2011Level Moodle or Large Training Department<\/a><\/li><li><a href=\"#Scenario_4_UniversityWide_or_Enterprise_LMS\"><span class=\"toc_number toc_depth_2\">4.4<\/span> Scenario 4: University\u2011Wide or Enterprise LMS<\/a><\/li><\/ul><\/li><li><a href=\"#CPU_Planning_for_Moodle_on_a_VPS\"><span class=\"toc_number toc_depth_1\">5<\/span> CPU Planning for Moodle on a VPS<\/a><ul><li><a href=\"#PHPFPM_Worker_Counts\"><span class=\"toc_number toc_depth_2\">5.1<\/span> PHP\u2011FPM Worker Counts<\/a><\/li><\/ul><\/li><li><a href=\"#RAM_Planning_and_Database_Requirements\"><span class=\"toc_number toc_depth_1\">6<\/span> RAM Planning and Database Requirements<\/a><ul><li><a href=\"#How_Much_RAM_for_the_Database\"><span class=\"toc_number toc_depth_2\">6.1<\/span> How Much RAM for the Database?<\/a><\/li><li><a href=\"#Choosing_Between_MySQLMariaDB_and_PostgreSQL\"><span class=\"toc_number toc_depth_2\">6.2<\/span> Choosing Between MySQL\/MariaDB and PostgreSQL<\/a><\/li><li><a href=\"#Connections_and_Pooling\"><span class=\"toc_number toc_depth_2\">6.3<\/span> Connections and Pooling<\/a><\/li><\/ul><\/li><li><a href=\"#Example_VPS_Architectures_for_Moodle_and_LMS\"><span class=\"toc_number toc_depth_1\">7<\/span> Example VPS Architectures for Moodle and LMS<\/a><ul><li><a href=\"#Stage_1_AllinOne_VPS\"><span class=\"toc_number toc_depth_2\">7.1<\/span> Stage 1: All\u2011in\u2011One VPS<\/a><\/li><li><a href=\"#Stage_2_Split_Application_and_Database_VPS\"><span class=\"toc_number toc_depth_2\">7.2<\/span> Stage 2: Split Application and Database VPS<\/a><\/li><li><a href=\"#Stage_3_HighAvailability_and_Scaling_Out\"><span class=\"toc_number toc_depth_2\">7.3<\/span> Stage 3: High\u2011Availability and Scaling Out<\/a><\/li><\/ul><\/li><li><a href=\"#Performance_Tuning_Tips_Specific_to_Moodle_and_LMS\"><span class=\"toc_number toc_depth_1\">8<\/span> Performance Tuning Tips Specific to Moodle and LMS<\/a><ul><li><a href=\"#1_Use_PHP_8x_and_OPcache_Properly\"><span class=\"toc_number toc_depth_2\">8.1<\/span> 1. Use PHP 8.x and OPcache Properly<\/a><\/li><li><a href=\"#2_Enable_and_Configure_Caching\"><span class=\"toc_number toc_depth_2\">8.2<\/span> 2. Enable and Configure Caching<\/a><\/li><li><a href=\"#3_Keep_the_Database_Clean_and_Indexed\"><span class=\"toc_number toc_depth_2\">8.3<\/span> 3. Keep the Database Clean and Indexed<\/a><\/li><li><a href=\"#4_Watch_RAM_Swap_and_IOwait\"><span class=\"toc_number toc_depth_2\">8.4<\/span> 4. Watch RAM, Swap and IOwait<\/a><\/li><li><a href=\"#5_Schedule_Heavy_Tasks_Outside_Peak_Hours\"><span class=\"toc_number toc_depth_2\">8.5<\/span> 5. Schedule Heavy Tasks Outside Peak Hours<\/a><\/li><\/ul><\/li><li><a href=\"#Backups_Scalability_and_FutureProofing\"><span class=\"toc_number toc_depth_1\">9<\/span> Backups, Scalability and Future\u2011Proofing<\/a><ul><li><a href=\"#Backup_Strategy\"><span class=\"toc_number toc_depth_2\">9.1<\/span> Backup Strategy<\/a><\/li><li><a href=\"#Vertical_vs_Horizontal_Scaling\"><span class=\"toc_number toc_depth_2\">9.2<\/span> Vertical vs Horizontal Scaling<\/a><\/li><\/ul><\/li><li><a href=\"#Putting_It_All_Together_A_Practical_Sizing_Checklist\"><span class=\"toc_number toc_depth_1\">10<\/span> Putting It All Together: A Practical Sizing Checklist<\/a><\/li><li><a href=\"#Conclusion_A_Calm_Path_to_Reliable_Moodle_VPS_Hosting\"><span class=\"toc_number toc_depth_1\">11<\/span> Conclusion: A Calm Path to Reliable Moodle VPS Hosting<\/a><\/li><\/ul><\/div>\n<h2><span id=\"Why_VPS_Hosting_Fits_Moodle_and_LMS_Platforms\">Why VPS Hosting Fits Moodle and LMS Platforms<\/span><\/h2>\n<p>From a hosting perspective, Moodle and most LMSs are classic stateful web applications: PHP (or similar) on the application side, a relational database, file storage for course content and user uploads, plus optional caching and search components. A VPS is often the sweet spot for this stack, especially when you need more control than shared hosting offers, but don\u2019t yet want the complexity of a multi\u2011server cluster.<\/p>\n<p>With a VPS, you control:<\/p>\n<ul>\n<li><strong>vCPU allocation<\/strong> \u2013 how many cores you dedicate to PHP, web server processes and background tasks.<\/li>\n<li><strong>RAM distribution<\/strong> \u2013 how much memory you reserve for PHP workers vs database buffer pools vs caching layers.<\/li>\n<li><strong>Storage and IOPS<\/strong> \u2013 SSD or NVMe disks, file system layout, separate volumes for database vs content.<\/li>\n<li><strong>Network and security<\/strong> \u2013 firewall rules, TLS configuration, VPNs and remote access policies.<\/li>\n<\/ul>\n<p>That control is exactly what Moodle and LMS platforms need to stay predictable under load. Shared hosting hides (and often limits) CPU and RAM usage per account. <a href=\"https:\/\/www.dchost.com\/dedicated-server\">dedicated server<\/a>s give full control but may be overkill at the early stages. VPS hosting, especially when it\u2019s easy to resize up or move to a larger node, lets you start with a sensible baseline and grow with your users.<\/p>\n<h2><span id=\"Key_Resource_Types_for_Moodle_CPU_RAM_Storage_and_Database\">Key Resource Types for Moodle: CPU, RAM, Storage and Database<\/span><\/h2>\n<p>Before jumping into sizing tables, it helps to understand where resources are actually consumed inside Moodle or a typical LMS.<\/p>\n<h3><span id=\"CPU_Where_the_Cycles_Go\">CPU: Where the Cycles Go<\/span><\/h3>\n<p>CPU time is mainly spent in:<\/p>\n<ul>\n<li><strong>PHP execution<\/strong> \u2013 rendering course pages, processing quiz attempts, grading, report generation.<\/li>\n<li><strong>Web server overhead<\/strong> \u2013 Nginx or Apache handling TLS, HTTP\/2, compression and logging.<\/li>\n<li><strong>Database queries<\/strong> \u2013 parsing, planning and executing SQL, especially for reporting and gradebook views.<\/li>\n<li><strong>Background tasks<\/strong> \u2013 Moodle\u2019s cron, scheduled reports, email sending, backup jobs.<\/li>\n<\/ul>\n<p>LMS traffic is bursty: for example, everyone starting a timed quiz at the same minute. CPU sizing needs to account for these short peaks rather than just average daily traffic.<\/p>\n<h3><span id=\"RAM_PHP_Workers_Database_Buffers_and_Caches\">RAM: PHP Workers, Database Buffers and Caches<\/span><\/h3>\n<p>RAM is critical because low memory doesn\u2019t just slow things down \u2013 it can cause processes to crash or the kernel\u2019s OOM killer to terminate your database. Memory is used by:<\/p>\n<ul>\n<li><strong>PHP workers<\/strong> \u2013 each PHP\u2011FPM\/Apache worker has its own memory footprint.<\/li>\n<li><strong>Database buffer pools<\/strong> \u2013 MySQL\/MariaDB or PostgreSQL caching tables and indexes in memory.<\/li>\n<li><strong>File system cache<\/strong> \u2013 the OS caching frequently accessed PHP files and course content.<\/li>\n<li><strong>Caching layers<\/strong> \u2013 Redis or Memcached for sessions or application cache, if you use them.<\/li>\n<\/ul>\n<p>If you haven\u2019t seen it yet, our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/vpste-ram-swap-ve-oom-killer-yonetimi\/\">managing RAM, swap and the OOM killer on VPS servers<\/a> goes deeper into how Linux behaves when memory runs low \u2013 useful background when planning an LMS server.<\/p>\n<h3><span id=\"Storage_and_IOPS_More_Than_Just_Disk_Size\">Storage and IOPS: More Than Just Disk Size<\/span><\/h3>\n<p>LMS platforms typically store:<\/p>\n<ul>\n<li><strong>Database data<\/strong> \u2013 tables for users, enrolments, grades, attempts, logs.<\/li>\n<li><strong>Course files<\/strong> \u2013 PDFs, slides, images, SCORM packages.<\/li>\n<li><strong>Media<\/strong> \u2013 video and audio (sometimes offloaded to external storage or streaming platforms).<\/li>\n<li><strong>Backups<\/strong> \u2013 full course backups, automatic site backups.<\/li>\n<\/ul>\n<p>For performance, disk <strong>speed and IOPS<\/strong> matter more than pure capacity. NVMe or high\u2011quality SSD storage is strongly recommended for Moodle\u2019s database and application files, while large media libraries can be offloaded to object storage or external systems if needed.<\/p>\n<h3><span id=\"Database_The_Real_Bottleneck_Under_Load\">Database: The Real Bottleneck Under Load<\/span><\/h3>\n<p>Moodle is database\u2011heavy. Pages that look simple \u2013 a course overview, a grade report \u2013 may trigger dozens of queries in the background. When you increase concurrent users, you\u2019re really increasing concurrent queries. That\u2019s why vCPU and RAM sizing must always consider database needs, not just PHP.<\/p>\n<p>If you want a broader comparison of database engines, our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/mariadb-vs-mysql-vs-postgresql-wordpress-woocommerce-ve-laravel-icin-dogru-veritabani-motoru-secimi\/\">MariaDB vs MySQL vs PostgreSQL for web applications<\/a> gives a practical overview that also applies to Moodle deployments.<\/p>\n<h2><span id=\"Understanding_Concurrent_Users_for_Moodle_and_LMS\">Understanding Concurrent Users for Moodle and LMS<\/span><\/h2>\n<p>One of the most common sources of confusion in LMS sizing is the phrase <strong>\u201cconcurrent users\u201d<\/strong>. A site with 5,000 registered students does not mean 5,000 concurrent users.<\/p>\n<p>For capacity planning, we usually define concurrent users as:<\/p>\n<ul>\n<li>Users who have made at least one <strong>active request in the last 5 minutes<\/strong> (page view, quiz action, upload etc.), and<\/li>\n<li>Users who are <strong>actively interacting at the same time<\/strong>, not just logged in with a tab open in the background.<\/li>\n<\/ul>\n<p>In practice, many institutions see peak concurrency like:<\/p>\n<ul>\n<li>Up to 30\u201350 concurrent users for a small school with 500\u20131,000 registered students.<\/li>\n<li>100\u2013300 concurrent users for a faculty or mid\u2011sized training portal with a few thousand students.<\/li>\n<li>500+ concurrent users for university\u2011wide platforms or large enterprises.<\/li>\n<\/ul>\n<p>We\u2019ll use these ranges in the sizing examples below. If you want a more general look at resource estimation, our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/wordpress-blog-woocommerce-ve-saas-icin-kac-cpu-ne-kadar-ram\/\">how many vCPUs and how much RAM you really need<\/a> complements this article well.<\/p>\n<h2><span id=\"Baseline_VPS_Sizing_for_Moodle_and_LMS_Deployments\">Baseline VPS Sizing for Moodle and LMS Deployments<\/span><\/h2>\n<p>These are starting points based on what we regularly see on dchost.com VPS plans. Real requirements depend on course design (heavy quizzes vs video), plugins, and peak usage patterns, but these scenarios give a solid baseline.<\/p>\n<h3><span id=\"Scenario_1_Small_School_or_Pilot_Project\">Scenario 1: Small School or Pilot Project<\/span><\/h3>\n<ul>\n<li><strong>Registered users:<\/strong> up to 500<\/li>\n<li><strong>Peak concurrent users:<\/strong> ~20\u201330<\/li>\n<li><strong>Usage pattern:<\/strong> primarily course browsing, occasional quizzes, light reporting<\/li>\n<\/ul>\n<p><strong>Recommended VPS specs:<\/strong><\/p>\n<ul>\n<li><strong>vCPU:<\/strong> 2 vCPUs<\/li>\n<li><strong>RAM:<\/strong> 4 GB<\/li>\n<li><strong>Storage:<\/strong> 80\u2013120 GB SSD\/NVMe (OS + database + Moodledata)<\/li>\n<li><strong>Database:<\/strong> Single MySQL\/MariaDB or PostgreSQL instance on the same VPS<\/li>\n<\/ul>\n<p>On this size, it\u2019s reasonable to run everything on a single VPS: Nginx\/Apache, PHP\u2011FPM, database and cron. Focus on correct PHP limits (memory_limit, max_execution_time) and regular backups.<\/p>\n<h3><span id=\"Scenario_2_Corporate_Training_Portal_or_MediumSized_School\">Scenario 2: Corporate Training Portal or Medium\u2011Sized School<\/span><\/h3>\n<ul>\n<li><strong>Registered users:<\/strong> 1,000\u20133,000<\/li>\n<li><strong>Peak concurrent users:<\/strong> 50\u2013100<\/li>\n<li><strong>Usage pattern:<\/strong> frequent quizzes, SCORM packages, regular completion reports<\/li>\n<\/ul>\n<p><strong>Recommended VPS specs:<\/strong><\/p>\n<ul>\n<li><strong>vCPU:<\/strong> 4 vCPUs<\/li>\n<li><strong>RAM:<\/strong> 8 GB<\/li>\n<li><strong>Storage:<\/strong> 150\u2013250 GB SSD\/NVMe<\/li>\n<li><strong>Database:<\/strong> Still acceptable on the same VPS, but allocate at least 3\u20134 GB RAM to the database buffer pool.<\/li>\n<\/ul>\n<p>At this tier, CPU spikes happen during exams and mandatory training deadlines. PHP\u2011FPM worker counts and database connection limits become more important. You\u2019ll also start to benefit from a dedicated cache store (Redis) for sessions and application cache.<\/p>\n<h3><span id=\"Scenario_3_FacultyLevel_Moodle_or_Large_Training_Department\">Scenario 3: Faculty\u2011Level Moodle or Large Training Department<\/span><\/h3>\n<ul>\n<li><strong>Registered users:<\/strong> 3,000\u201310,000<\/li>\n<li><strong>Peak concurrent users:<\/strong> 100\u2013300<\/li>\n<li><strong>Usage pattern:<\/strong> heavy quiz usage, simultaneous exams, large gradebooks and reports<\/li>\n<\/ul>\n<p><strong>Recommended starting specs (single VPS, but near the upper limit):<\/strong><\/p>\n<ul>\n<li><strong>vCPU:<\/strong> 6\u20138 vCPUs<\/li>\n<li><strong>RAM:<\/strong> 16 GB<\/li>\n<li><strong>Storage:<\/strong> 250\u2013500 GB NVMe (especially for database and Moodledata)<\/li>\n<li><strong>Database:<\/strong> Ideally move to a <strong>separate VPS<\/strong> at this stage; see the architecture section below.<\/li>\n<\/ul>\n<p>Here, the main risk of staying on a single VPS is that CPU\u2011intensive PHP tasks and database operations compete for the same cores. Separating application and database roles gives clearer performance and easier scaling.<\/p>\n<h3><span id=\"Scenario_4_UniversityWide_or_Enterprise_LMS\">Scenario 4: University\u2011Wide or Enterprise LMS<\/span><\/h3>\n<ul>\n<li><strong>Registered users:<\/strong> 10,000\u201350,000+<\/li>\n<li><strong>Peak concurrent users:<\/strong> 300\u20131,000+<\/li>\n<li><strong>Usage pattern:<\/strong> multiple faculties or business units, high concurrency during exam windows, extensive reporting and integrations<\/li>\n<\/ul>\n<p>At this level, you\u2019re typically beyond a single VPS and into multi\u2011VPS or dedicated server architecture:<\/p>\n<ul>\n<li><strong>App tier:<\/strong> 2+ VPS nodes, each with 8+ vCPUs and 16\u201332 GB RAM, behind a load balancer.<\/li>\n<li><strong>Database tier:<\/strong> 1\u20132 VPS or dedicated servers, 8+ vCPUs and 32\u201364 GB RAM, possibly with replication and read replicas.<\/li>\n<li><strong>Cache tier:<\/strong> Dedicated Redis\/Memcached instance.<\/li>\n<\/ul>\n<p>Even if you\u2019re not there yet, it\u2019s worth planning your Moodle setup so that moving to this architecture later is straightforward (for example, by separating web root, Moodledata and database from day one).<\/p>\n<h2><span id=\"CPU_Planning_for_Moodle_on_a_VPS\">CPU Planning for Moodle on a VPS<\/span><\/h2>\n<p>The rough relationship between CPU and concurrency for Moodle\u2011style workloads is:<\/p>\n<ul>\n<li><strong>Light usage (browsing, small quizzes):<\/strong> ~10\u201320 concurrent users per vCPU.<\/li>\n<li><strong>Heavy usage (large timed quizzes, complex reports):<\/strong> ~5\u201310 concurrent users per vCPU.<\/li>\n<\/ul>\n<p>This is not a hard rule, but it\u2019s a useful sanity check. If you expect 100 concurrent users hitting quizzes, planning for <em>at least<\/em> 8 vCPUs gives room for PHP, database and background tasks.<\/p>\n<h3><span id=\"PHPFPM_Worker_Counts\">PHP\u2011FPM Worker Counts<\/span><\/h3>\n<p>On a typical Nginx + PHP\u2011FPM setup, each PHP\u2011FPM worker handles one request at a time and consumes a certain amount of RAM. A simple starting approach is:<\/p>\n<ul>\n<li>Estimate <strong>average memory per PHP process<\/strong> (e.g. 80\u2013120 MB with common plugins).<\/li>\n<li>Decide how much of your RAM you can allocate to PHP (for example, 3 GB out of 8 GB).<\/li>\n<li>Set <code>pm.max_children<\/code> = (PHP RAM) \/ (memory per process), then adjust based on monitoring.<\/li>\n<\/ul>\n<p>For example, on an 8 GB VPS you might allocate ~3 GB to PHP and see 100 MB per process on average:<\/p>\n<ul>\n<li><strong>3,000 MB \/ 100 MB \u2248 30 PHP workers<\/strong><\/li>\n<\/ul>\n<p>If you want to go deeper into PHP\u2011FPM tuning, many of the ideas in our PHP\u2011focused articles (e.g. OPcache, FPM pool settings) also apply to LMS platforms, and we cover Moodle\u2011specific tuning separately in our <a href=\"https:\/\/www.dchost.com\/blog\/en\/moodle-ve-diger-lmsler-icin-hosting-performans-rehberi\/\">Moodle and LMS hosting performance guide for PHP, database and caching<\/a>.<\/p>\n<h2><span id=\"RAM_Planning_and_Database_Requirements\">RAM Planning and Database Requirements<\/span><\/h2>\n<p>For Moodle, RAM is usually split among:<\/p>\n<ul>\n<li>Operating system and file system cache (1\u20132 GB minimum).<\/li>\n<li>PHP\u2011FPM processes (as calculated above).<\/li>\n<li>Database buffer pool and caches.<\/li>\n<li>Redis\/Memcached if used.<\/li>\n<\/ul>\n<h3><span id=\"How_Much_RAM_for_the_Database\">How Much RAM for the Database?<\/span><\/h3>\n<p>A common rule of thumb for MySQL\/MariaDB or PostgreSQL on an LMS VPS:<\/p>\n<ul>\n<li><strong>Small instance (4 GB RAM total):<\/strong> 1\u20131.5 GB for database buffer pool.<\/li>\n<li><strong>Medium instance (8 GB RAM total):<\/strong> 3\u20134 GB for database.<\/li>\n<li><strong>Larger instance (16 GB RAM total):<\/strong> 6\u20138 GB for database.<\/li>\n<\/ul>\n<p>For busy Moodle sites, the database often ends up using at least <strong>40\u201350% of total VPS RAM<\/strong>, especially once you have large quiz attempt tables and logs.<\/p>\n<h3><span id=\"Choosing_Between_MySQLMariaDB_and_PostgreSQL\">Choosing Between MySQL\/MariaDB and PostgreSQL<\/span><\/h3>\n<p>Moodle supports both MySQL\/MariaDB and PostgreSQL. All three work well when tuned correctly. In the field, we commonly see:<\/p>\n<ul>\n<li><strong>MariaDB\/MySQL:<\/strong> very common, many admins already familiar, good tooling, plenty of documentation.<\/li>\n<li><strong>PostgreSQL:<\/strong> attractive for some teams for standards compliance and advanced query features.<\/li>\n<\/ul>\n<p>The important part is to tune your chosen engine for LMS\u2011style workloads: sufficient buffer pool size, appropriate connection limits, and slow query logging enabled so you can spot bottlenecks.<\/p>\n<h3><span id=\"Connections_and_Pooling\">Connections and Pooling<\/span><\/h3>\n<p>If you run everything on a single VPS, you may rely on Moodle\u2019s own database connections directly. For larger setups or multiple app servers, using a connection pooler (such as PgBouncer in transaction mode for PostgreSQL) can reduce the overhead of many short\u2011lived connections. This matters most when concurrency grows into the hundreds.<\/p>\n<h2><span id=\"Example_VPS_Architectures_for_Moodle_and_LMS\">Example VPS Architectures for Moodle and LMS<\/span><\/h2>\n<h3><span id=\"Stage_1_AllinOne_VPS\">Stage 1: All\u2011in\u2011One VPS<\/span><\/h3>\n<p>This is where most projects start and where many small schools stay for years:<\/p>\n<ul>\n<li>Single VPS (2\u20134 vCPUs, 4\u20138 GB RAM).<\/li>\n<li>Nginx or Apache + PHP\u2011FPM, database, Redis (optional) and cron all on the same node.<\/li>\n<li>Regular off\u2011site backups.<\/li>\n<\/ul>\n<p>Keep the architecture clean from day one:<\/p>\n<ul>\n<li>Separate directories for <code>moodledata<\/code> and web root.<\/li>\n<li>Use proper config management or at least a clear documentation of custom changes.<\/li>\n<li>Plan your backup strategy so it can later be extended to multiple servers.<\/li>\n<\/ul>\n<h3><span id=\"Stage_2_Split_Application_and_Database_VPS\">Stage 2: Split Application and Database VPS<\/span><\/h3>\n<p>When CPU and RAM usage start to climb, the first big step is separating the database onto its own server:<\/p>\n<ul>\n<li><strong>App VPS:<\/strong> 4\u20138 vCPUs, 8\u201316 GB RAM \u2013 Nginx\/Apache, PHP\u2011FPM, Moodle code, Moodledata, Redis.<\/li>\n<li><strong>DB VPS:<\/strong> 4\u20138 vCPUs, 16\u201332 GB RAM \u2013 MySQL\/MariaDB or PostgreSQL, tuned for large buffer pools.<\/li>\n<\/ul>\n<p>Advantages:<\/p>\n<ul>\n<li>Database no longer competes with PHP for RAM and CPU.<\/li>\n<li>Each tier can be scaled independently (for example, upgrade only the DB VPS when reports slow down).<\/li>\n<li>Maintenance windows can be managed separately.<\/li>\n<\/ul>\n<p>We discuss the decision of moving to a dedicated database server in more depth in our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/veritabani-sunucusunu-uygulama-sunucusundan-ayirmak-ne-zaman-mantikli\/\">when to separate database and application servers for MySQL and PostgreSQL<\/a>.<\/p>\n<h3><span id=\"Stage_3_HighAvailability_and_Scaling_Out\">Stage 3: High\u2011Availability and Scaling Out<\/span><\/h3>\n<p>For university\u2011wide and mission\u2011critical LMS setups, you gradually move towards:<\/p>\n<ul>\n<li>Two or more application VPS nodes behind a load balancer.<\/li>\n<li>A primary database server with one or more replicas (for read traffic and failover).<\/li>\n<li>Dedicated caching and possibly a separate search server if you use advanced search plugins.<\/li>\n<\/ul>\n<p>Our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/trafik-patlamasindan-once-load-test-yapmak-k6-jmeter-ve-locust-ile-kapasite-olcme-rehberi\/\">load testing your hosting before traffic spikes<\/a> is particularly relevant here: you want to validate capacity and failover behaviour <em>before<\/em> exam week, not during it.<\/p>\n<h2><span id=\"Performance_Tuning_Tips_Specific_to_Moodle_and_LMS\">Performance Tuning Tips Specific to Moodle and LMS<\/span><\/h2>\n<p>Sizing is only half the story. Even a well\u2011sized VPS can feel slow if it\u2019s not tuned for the particular access patterns of an LMS.<\/p>\n<h3><span id=\"1_Use_PHP_8x_and_OPcache_Properly\">1. Use PHP 8.x and OPcache Properly<\/span><\/h3>\n<p>Modern Moodle versions benefit significantly from PHP 8.x performance improvements. Make sure:<\/p>\n<ul>\n<li>OPcache is enabled with enough memory to store compiled scripts.<\/li>\n<li><code>opcache.validate_timestamps<\/code> is configured for a balance of performance and development convenience.<\/li>\n<li>PHP memory limits are high enough for complex operations but not so high that a single runaway process can exhaust all RAM.<\/li>\n<\/ul>\n<h3><span id=\"2_Enable_and_Configure_Caching\">2. Enable and Configure Caching<\/span><\/h3>\n<p>Moodle has its own caching subsystem. Even on a single VPS, using Redis for session and application cache can reduce database load and improve response times, especially under spikes when many users are loading the same course or quiz.<\/p>\n<h3><span id=\"3_Keep_the_Database_Clean_and_Indexed\">3. Keep the Database Clean and Indexed<\/span><\/h3>\n<p>Over time, logs and temporary data can grow aggressively. Consider:<\/p>\n<ul>\n<li>Configuring log retention periods appropriate for your compliance needs.<\/li>\n<li>Regularly checking slow query logs and adding indexes where necessary.<\/li>\n<li>Vacuuming\/analyzing (PostgreSQL) or optimizing tables periodically for very large instances.<\/li>\n<\/ul>\n<p>On larger setups, database\u2011level replication (for read scaling and failover) becomes relevant. We cover the basics of setting this up in our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/mysql-ve-postgresql-replikasyon-kurulumu-ile-vps-uzerinde-yuksek-erisilebilirlik\/\">MySQL and PostgreSQL replication on VPS servers<\/a>.<\/p>\n<h3><span id=\"4_Watch_RAM_Swap_and_IOwait\">4. Watch RAM, Swap and IOwait<\/span><\/h3>\n<p>Even if CPU looks fine, high IOwait or aggressive swap usage will slow Moodle to a crawl. Monitor:<\/p>\n<ul>\n<li><strong>Actual RAM usage<\/strong> vs total and free.<\/li>\n<li><strong>Swap\u2011in \/ swap\u2011out rates<\/strong>, not just swap size.<\/li>\n<li><strong>IOwait<\/strong> as a percentage of CPU time \u2013 persistent values above a few percent under load warrant investigation.<\/li>\n<\/ul>\n<p>Again, our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/vpste-ram-swap-ve-oom-killer-yonetimi\/\">RAM, swap and the OOM killer on VPS servers<\/a> gives detailed techniques for diagnosing and fixing memory\u2011related slowdowns.<\/p>\n<h3><span id=\"5_Schedule_Heavy_Tasks_Outside_Peak_Hours\">5. Schedule Heavy Tasks Outside Peak Hours<\/span><\/h3>\n<p>Moodle cron tasks (backups, report generations, automated enrolments) can be resource\u2011intensive. On busy platforms, it\u2019s wise to:<\/p>\n<ul>\n<li>Run full site backups and heavy reports during off\u2011peak hours.<\/li>\n<li>Use incremental backups where possible.<\/li>\n<li>Stagger tasks so they don\u2019t all run at the same minute.<\/li>\n<\/ul>\n<h2><span id=\"Backups_Scalability_and_FutureProofing\">Backups, Scalability and Future\u2011Proofing<\/span><\/h2>\n<h3><span id=\"Backup_Strategy\">Backup Strategy<\/span><\/h3>\n<p>LMS data is usually business\u2011critical: grades, completion records, compliance training proof. Treat backups as non\u2011negotiable:<\/p>\n<ul>\n<li>Automated daily database backups, stored off\u2011server.<\/li>\n<li>Regular file backups (Moodledata, configuration files).<\/li>\n<li>Periodic restore tests to a staging VPS so you know your backups actually work.<\/li>\n<\/ul>\n<p>At dchost.com we often combine VPS snapshots with logical database dumps for a layered approach. This aligns with the 3\u20112\u20111 backup principles we discuss in more depth in our other backup\u2011focused articles.<\/p>\n<h3><span id=\"Vertical_vs_Horizontal_Scaling\">Vertical vs Horizontal Scaling<\/span><\/h3>\n<p>On VPS hosting, your first scaling moves will usually be vertical:<\/p>\n<ul>\n<li>Increase vCPU and RAM on the same VPS as concurrency grows from 20 \u2192 50 \u2192 100 users.<\/li>\n<li>Upgrade storage from SSD to NVMe or add more capacity as course content expands.<\/li>\n<\/ul>\n<p>Once you get into the 100\u2013300 concurrent user range, you\u2019ll start to see benefit from horizontal moves:<\/p>\n<ul>\n<li>Splitting the database onto a dedicated VPS.<\/li>\n<li>Adding a second application VPS behind a load balancer.<\/li>\n<\/ul>\n<p>Because we operate both VPS and dedicated server infrastructure at dchost.com, we regularly help Moodle clients move from a single node to a multi\u2011VPS or even hybrid architecture when the time is right.<\/p>\n<h2><span id=\"Putting_It_All_Together_A_Practical_Sizing_Checklist\">Putting It All Together: A Practical Sizing Checklist<\/span><\/h2>\n<p>When you plan or review Moodle\/LMS hosting on a VPS, walk through this checklist:<\/p>\n<ol>\n<li><strong>Estimate concurrency:<\/strong> realistic peak concurrent users during exams or deadlines.<\/li>\n<li><strong>Map concurrency to vCPU:<\/strong> start with 5\u201320 users per vCPU depending on workload; round up generously.<\/li>\n<li><strong>Plan RAM:<\/strong>\n<ul>\n<li>Reserve 1\u20132 GB for OS and file cache.<\/li>\n<li>Allocate enough for PHP workers (based on memory per process).<\/li>\n<li>Give database at least 40\u201350% of remaining RAM.<\/li>\n<\/ul>\n<\/li>\n<li><strong>Choose storage:<\/strong> SSD\/NVMe, with enough IOPS and headroom for content growth and backups.<\/li>\n<li><strong>Decide the architecture stage:<\/strong> all\u2011in\u2011one VPS vs split app\/DB vs multi\u2011VPS with replication.<\/li>\n<li><strong>Configure caching:<\/strong> OPcache, Moodle cache stores, optionally Redis for sessions\/data.<\/li>\n<li><strong>Set up monitoring and load testing:<\/strong> watch CPU, RAM, IOwait and run test loads before high\u2011stakes exams.<\/li>\n<li><strong>Implement backups:<\/strong> automated, off\u2011site, and tested restores.<\/li>\n<\/ol>\n<h2><span id=\"Conclusion_A_Calm_Path_to_Reliable_Moodle_VPS_Hosting\">Conclusion: A Calm Path to Reliable Moodle VPS Hosting<\/span><\/h2>\n<p>Hosting Moodle or any serious LMS on a VPS does not have to be a guessing game. When you break the problem down into CPU, RAM, database and storage needs \u2013 and tie those to realistic concurrent user numbers \u2013 a clear sizing picture emerges. Start small but not tiny, keep an eye on memory and database health, and be ready with a plan for when concurrency doubles. That\u2019s far easier than trying to rescue an overloaded server in the middle of exam week.<\/p>\n<p>As the dchost.com team, we see Moodle and LMS workloads every day across different industries and sizes. The patterns in this guide come directly from that experience. If you\u2019re planning a new platform, migrating from shared hosting, or wondering whether it\u2019s time to split your database onto its own VPS, we\u2019re happy to review your current metrics and help design a roadmap. When you pair sensible VPS sizing with good performance tuning and a solid backup strategy, your LMS becomes something everyone can rely on \u2013 quietly, in the background, exactly as it should be.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>Moodle and other LMS platforms can look lightweight from the outside: a few courses, some videos, a quiz here and there. But the moment real users start clicking \u201cStart quiz\u201d at the same time, CPU, RAM and database performance become the difference between a smooth learning experience and a support nightmare. In this guide, we\u2019ll [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":4492,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-4491","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-teknoloji"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/4491","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=4491"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/4491\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/4492"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=4491"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=4491"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=4491"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}