Колко RAM е нужна за VPS: правилото, според всяка употреба

Правилото: съберете това, което остава в паметта

Сървърът не консумира памет „изобщо“: всяка работеща програма заема своя дял, докато работи. Затова изчислението започва от списъка на процесите, които присъстват постоянно, след което добавя пика и резерв:

Памет за предвиждане = (система + постоянни услуги + пик на еднократните задачи) × 1,25

• Системата: минимална Linux дистрибуция (Debian, Ubuntu) заема от порядъка на 150 до 300 MB след стартиране, включително SSH достъпа и журналите.
• Постоянните услуги: уеб сървър, процеси на приложението, база данни, кеш, опашка от задачи. Консумацията им зависи от технологията, описана подробно в следващия раздел.
• Пикът: това, което се добавя от време на време, като компилиране на приложението, резервно копие, импорт, тежка планирана задача. Сървър, оразмерен по средната си консумация, пада точно в тези моменти.
• Резервът: 25 % над общата сума, за растежа на данните и на трафика. Той не стои без работа: Linux използва свободната памет като кеш за файловете, което ускорява базата данни.

Колко консумира всеки компонент

Порядъците по-долу важат за приложение с обичаен размер, измерено в продукция. Те дават отправна точка; измерването на собственото ви приложение, описано по-долу, винаги има последната дума.

Един пик се връща често при JavaScript приложенията: компилирането. npm run build на проект с Next.js, Nuxt или Angular обикновено изисква само по себе си 1 до 2 GB за няколко минути, в допълнение към всичко, което вече работи. Да компилирате на сървъра означава да го оразмерите за този пик; да компилирате на своя компютър или в непрекъснатата интеграция (CI) и да качвате само резултата означава да го избегнете.

Същото разсъждение важи за Docker контейнерите: всеки контейнер е набор от процеси като всички останали, а Docker демонът добавя собствена консумация. docker stats показва колко заема всеки от тях.

Типични профили

Тези профили събират компонентите от предишния раздел, с включени пик и резерв. Те предполагат приложение с обичаен размер и трафика при старта; обемна база данни или постоянно висок трафик изместват стойността нагоре.

Приложение, което извиква AI модел през API (OpenAI, Anthropic, Mistral), се оразмерява като всяко уеб приложение: моделът работи при своя създател, а вашият сървър чака отговора му. Изпълнението на модела на самия сървър е това, което променя мащаба.

Измерване на работещ сървър

На сървър в експлоатация измерването заменя оценката. Три команди показват текущото състояние:

free -h
ps aux --sort=-rss | head -n 15
vmstat 5 5

• free -h: четете колоната available, паметта, реално достъпна за стартиране на нови програми. Колоната free почти винаги е ниска и това е нормално: Linux запълва неизползваната памет с кеш на файловете (buff/cache), който освобождава веднага щом някоя програма има нужда от него.
• ps aux --sort=-rss: процесите, подредени по заета памет (колоната RSS, в килобайти). Тук се вижда колко тежи всеки PHP или Node.js worker.
• vmstat 5 5: пет измервания през пет секунди. Ненулеви стойности в колоните si и so, измерване след измерване, показват сървър, който използва swap: паметта му не стига.

Измервайте в най-натоварения момент от деня и по време на еднократните задачи: компилиране, резервно копие, импорт. Решаващ е пикът.

Когато паметта не стига

Сървър, на който паметта не стига, не се забавя постепенно. Когато вече няма какво да освободи, ядрото на Linux задейства OOM killer (out of memory): избира процес, обикновено този, който заема най-много памет, и го спира рязко. На сървър с приложение това често е базата данни.

Симптомите: грешки 502 или 503 от време на време, услуга, която се рестартира без видима причина, компилиране, което прекъсва с Killed. Журналите го потвърждават:

journalctl -k | grep -i "out of memory"
systemctl status ime-na-uslugata

В изхода на systemctl status записът Failed with result 'oom-kill' означава услуга, спряна поради липса на памет.

Swap, когато сървърът разполага с такъв, отлага този момент, като премества на диска най-малко използваната памет. Той е предпазна мрежа, а не капацитет: сървър, който постоянно разчита на swap, отговаря няколко пъти по-бавно, дори на NVMe SSD.

Решенията, от най-простото към най-трайното: намалете броя на процесите на приложението (pm.max_children, worker процесите на Gunicorn), компилирайте извън сървъра, ограничете паметта на базата данни, след това преминете към по-голям размер.

Изборът на размер и следващите стъпки

1. Избройте какво ще работи: уеб сървър, приложение и брой процеси, база данни, кеш, планирани задачи.
2. Съберете стойностите с таблицата на компонентите, добавете най-тежкия пик (често компилирането), след това 25 % резерв.
3. Изберете размера, който покрива тази сума. Между два съседни размера по-малкият е подходящ, стига преминаването към по-голям размер да става без преинсталиране.
4. Измервайте след пускането онлайн, в пика на деня, и след това при всеки етап от растежа на приложението.

Паметта не е единственият ресурс: процесорът има значение за всичко, което изчислява (компилиране, обработка на изображения, изпълнение на AI модел), а дискът за базата данни и файловете. За едно уеб приложение обаче почти винаги паметта определя размера.