Atmiņa visbiežāk nosaka servera izmēru: tā beidzas pirmā, un, kad tās pietrūkst, serveris nevis palēninās, bet aptur pakalpojumus. Šajā ceļvedī ir aprēķina noteikums, tas, ko patērē katra lietojumprogrammas sastāvdaļa, tipiski profili un veids, kā izmērīt jau strādājošu serveri.
free -h kolonnu available, nevis kolonnu free.Serveris nepatērē atmiņu «vispār»: katra strādājoša programma aizņem savu daļu, kamēr vien darbojas. Tāpēc aprēķins sākas ar pastāvīgi strādājošo procesu sarakstu, un pēc tam pieskaita slodzes maksimumu un rezervi:
Paredzamā atmiņa = (sistēma + pastāvīgie pakalpojumi + epizodisko uzdevumu maksimums) × 1,25
Tālāk norādītie lielumi attiecas uz parasta izmēra lietojumprogrammu un ir mērīti produkcijā. Tie ir sākumpunkts; pēdējais vārds vienmēr pieder mērījumam jūsu pašu lietojumprogrammā, kā aprakstīts tālāk.
| Sastāvdaļa | Tipiskā atmiņa | No kā tā mainās |
|---|---|---|
| Nginx, Caddy (tīmekļa serveris, starpniekserveris) | 10 līdz 50 MB | Gandrīz nemainīga: savienojumu skaits to ietekmē maz. |
| PHP-FPM (WordPress, Laravel, Symfony) | 40 līdz 80 MB uz procesu | Procesu skaits, ko ierobežo pm.max_children: 10 procesi ir 400 līdz 800 MB. |
| Node.js (API, Next.js, NestJS) | 60 līdz 300 MB uz procesu | Procesu skaits (klastera režīms, PM2) un kaudzes (heap) izmērs, ko ierobežo --max-old-space-size. |
| Python (Django, FastAPI, Flask) | 80 līdz 200 MB uz procesu | Gunicorn vai Uvicorn darba procesu (workers) skaits un ielādētās bibliotēkas: pandas vai mašīnmācīšanās modelis pieliek simtiem MB. |
| Java (Spring Boot) | No 300 MB līdz 1 GB uz lietojumprogrammu | Maksimālais kaudzes izmērs: pēc noklusējuma JVM paņem ceturtdaļu no atmiņas, ko tā redz. |
| Go, Rust | 10 līdz 100 MB | Dati, ko lietojumprogramma pati glabā atmiņā. |
| PostgreSQL | 25 % atmiņas parametram shared_buffers, plus daži MB uz katru savienojumu | Bieži lasīto datu apjoms, savienojumu skaits, work_mem. |
| MySQL, MariaDB | innodb_buffer_pool_size, pēc noklusējuma 128 MB | Serverī, kas veltīts tikai datubāzei, šis buferis parasti aizņem līdz 80 % atmiņas. |
| Redis | Datu apjoms plus to struktūras | Saglabājot datus diskā, mainītās lapas tiek dublētas: sliktākajā gadījumā līdz divkāršam apjomam. |
| Elasticsearch, OpenSearch | Vismaz 2 GB kaudzei | Kaudze nepārsniedz pusi atmiņas: pārējais kalpo failu kešatmiņai. |
JavaScript lietojumprogrammās bieži atkārtojas viens maksimums: kompilēšana (build). npm run build Next.js, Nuxt vai Angular projektā pati par sevi uz dažām minūtēm parasti prasa 1 līdz 2 GB, papildus tam, kas jau darbojas. Kompilēt serverī nozīmē dimensionēt šim maksimumam; kompilēt savā datorā vai nepārtrauktās integrācijas (CI) vidē un augšupielādēt tikai rezultātu nozīmē no tā izvairīties.
Tāds pats spriedums attiecas uz Docker konteineriem: katrs konteiners ir procesu kopums kā jebkurš cits, un Docker dēmons pieliek savu patēriņu. docker stats parāda, cik aizņem katrs no tiem.
Šie profili saskaita iepriekšējās sastāvdaļas, ieskaitot maksimumu un rezervi. Tie pieņem parasta izmēra lietojumprogrammu un palaišanas brīža datplūsmu; apjomīga datubāze vai pastāvīgi liela datplūsma bīda skaitli uz augšu.
| Kas darbojas serverī | Paredzamā atmiņa |
|---|---|
| Statiska vietne, starpniekserveris, neliels bots vai ieplānots skripts | 1 līdz 2 GB |
| Viena WordPress vietne ar MariaDB un lapu kešatmiņu | 2 GB |
| WooCommerce veikals vai vairākas WordPress vietnes | 4 GB |
| Node.js vai Python API ar PostgreSQL, pirmie lietotāji | 4 GB |
| Next.js lietojumprogramma, kompilēta serverī, ar savu API un PostgreSQL datubāzi | 6 līdz 8 GB |
| Vairākas lietojumprogrammas konteineros, testa un produkcijas vide | 8 GB |
| Vairākus desmitus GB liela datubāze ar intensīvu lasīšanu | 16 GB un vairāk |
| Valodas modelis ar 7 līdz 8 miljardiem parametru, kas darbojas pašā serverī | 16 GB |
Lietojumprogramma, kas izsauc mākslīgā intelekta modeli caur API (OpenAI, Anthropic, Mistral), tiek dimensionēta kā jebkura tīmekļa lietojumprogramma: modelis darbojas pie sava izstrādātāja, un jūsu serveris gaida tā atbildi. Mērogu maina tieši modeļa darbināšana pašā serverī.
Strādājošā serverī mērījums aizstāj aplēsi. Trīs komandas parāda, kāda ir situācija:
free -h
ps aux --sort=-rss | head -n 15
vmstat 5 5free -h: skatieties kolonnu available, atmiņu, kas patiešām pieejama jaunu programmu palaišanai. Kolonnā free skaitlis gandrīz vienmēr ir mazs, un tas ir normāli: Linux aizpilda neizmantoto atmiņu ar failu kešatmiņu (buff/cache) un atdod to, tiklīdz kādai programmai tā vajadzīga.ps aux --sort=-rss: procesi, sakārtoti pēc aizņemtās atmiņas (kolonna RSS, kilobaitos). Šeit redzams, cik sver katrs PHP vai Node.js darba process.vmstat 5 5: pieci mērījumi ar piecu sekunžu intervālu. Nenulles vērtības kolonnās si un so mērījumu pēc mērījuma nozīmē, ka serveris aktīvi izmanto swap: tam trūkst atmiņas.Mēriet dienas noslogotākajā brīdī un epizodisko uzdevumu laikā: kompilēšanas, rezerves kopēšanas, importa. Izšķirošs ir maksimums.
Serveris, kuram beidzas atmiņa, nepalēninās pakāpeniski. Kad vairs nav ko atbrīvot, Linux kodols iedarbina OOM killer (out of memory): tas izvēlas procesu, parasti to, kas aizņem visvairāk atmiņas, un aptur to uz vietas. Lietojumprogrammu serverī tā bieži ir datubāze.
Simptomi: brīžiem kļūdas 502 vai 503, pakalpojums, kas restartējas bez redzama iemesla, kompilēšana, kas pārtrūkst ar Killed. Žurnāli to apstiprina:
journalctl -k | grep -i "out of memory"
systemctl status pakalpojuma-nosaukumsKomandas systemctl status izvadē ieraksts Failed with result 'oom-kill' norāda uz pakalpojumu, kas apturēts atmiņas trūkuma dēļ.
Swap (mijmaiņas apgabals diskā), ja serverim tāds ir, šo brīdi attālina, pārvietojot uz disku vismazāk izmantoto atmiņu. Tas ir drošības tīkls, nevis jauda: serveris, kas pastāvīgi balstās uz swap, atbild vairākas reizes lēnāk, pat uz NVMe SSD.
Risinājumi, no vienkāršākā līdz ilgtspējīgākajam: samazināt lietojumprogrammas procesu skaitu (pm.max_children, Gunicorn darba procesi), kompilēt ārpus servera, ierobežot datubāzes atmiņu, pēc tam pāriet uz lielāku izmēru.
Atmiņa nav vienīgais resurss: procesors ir svarīgs visam, kas skaitļo (kompilēšana, attēlu apstrāde, mākslīgā intelekta modeļa darbināšana), disks ir svarīgs datubāzei un failiem. Tomēr tīmekļa lietojumprogrammai izmēru gandrīz vienmēr nosaka tieši atmiņa.
VPS Pro ir pieejams sešos izmēros uz Intel Xeon procesoriem, ECC atmiņas un spoguļotiem NVMe SSD, un jebkurā brīdī pāriet uz lielāku izmēru bez pārinstalēšanas. Visaptverošais atbalsts ir iekļauts: aprakstiet, ko darbinās jūsu serveris, un mēs ieteiksim izmēru, pēc tam katrā jautājumā diagnosticēsim un pateiksim, kas jādara, no sistēmas līdz pat jūsu lietojumprogrammas kodam.
Statiska vietne, starpniekserveris vai neliels skripts darbojas ar 1 līdz 2 GB. Tiklīdz serveri dala datubāze un lietojumprogramma (PHP, Node.js, Python), rēķinieties ar 2 GB WordPress vietnei un 4 GB pēc pasūtījuma izstrādātai lietojumprogrammai ar PostgreSQL.
2 GB vietnei ar MariaDB un lapu kešatmiņu, 4 GB WooCommerce veikalam vai vairākām vietnēm. Pirmais iestatījums ir PHP-FPM procesu skaits: katrs aizņem 40 līdz 80 MB.
Nē. Swap novērš pēkšņu apstāšanos, kad atmiņa ir pilna, bet serveris, kas to izmanto pastāvīgi, atbild vairākas reizes lēnāk, pat uz NVMe SSD. Tas ir drošības tīkls; izmēru izvēlas pēc atmiņas.
Tāpēc, ka Linux neizmantoto atmiņu izmanto kā failu kešatmiņu. Šī kešatmiņa atbrīvojas, tiklīdz kādai programmai vajadzīga atmiņa. Jāskatās kolonna available, kas rāda patiešām pieejamo atmiņu.
Rēķinieties ar 1 līdz 2 GB tikai kompilēšanai, papildus tam, kas serverī jau darbojas. Kompilējot savā datorā vai nepārtrauktās integrācijas vidē un augšupielādējot tikai rezultātu, no šī maksimuma var izvairīties.
Simafri
Parunāsim par jūsu ieceri
Pasakiet mums dažos vārdos, kas jums vajadzīgs: mēs jums ātri atbildam.
Paldies! Jūsu pieprasījums ir nosūtīts. Drīzumā ar jums sazināsimies.
Labāk e-pastu? Rakstiet mums uz support@simafri.com.