Jak se počítá využití RAM pro účtování

Poradna při řešení nejrůznějších problémů spojených s provozem virtuálních serverů.

Jak se počítá využití RAM pro účtování

Příspěvekod megi » pát 19. kvě 2017 16:36:12

Dobrý den,

Před 3 měsíci mi náklady na server narostly o 60% a i přes snahu o optimalizaci dále rostou. Zdá se, že rozdíl se týká účtování využití RAM.

Je obtížné dohledat co se stalo, protože statistiky v administraci vps jsou prakticky nepoužitelné, resp. trvá velmi dlouho než se načtou ty denní. Na načtení každého dne čekám > 2 minuty. Jinde není účtování rozdělitelné na jednotlivé položky (HDD, RAM, atd.).

Na 4smart.cz se mi líbil přístup, že optimalizací a vlastním přičiněním se dalo dosáhnout úspor. Tak to tedy alespoň fungovalo dříve. Tak jsem před pár měsíci optimalizoval svůj poštovní server aby neotvíral cca 8-10 persistentních spojení do DB, ale jen maximálně dvě, které ještě po pár sekundách zavírá. Jediný výsledek je, že i přes to náklady dál na první pohled nesmyslně rostou, i když využití prostředků je objektivně nižší, alespoň podle toho co jsem schopný naměřit přímo ve virtuálu.

Mám tedy několik dotazů:

1) Jak se aktuálně účtuje využití RAM? Co se do toho započítává? Změnilo se něco kolem 9.3.?

Když se podívám na minutové vyúčtování RAM pro dvě časová období, tak tam je typicky:

Leden (a zhruba podobně i celý minulý rok): cca -0.00164 za 5 minut při ceně 0,001041667 za minutu a 100MB, to odpovídá cca 160 MB ram, což cca byla asi celkem odpovídající moje spotřeba paměti běžícími programy tehdy. (3.3. jsem postfix přesunul na využívání DB, náklady skokově vzrostly 9.3. a od té doby rostou a klesají podle toho jak mám nastavený limit)
Začátek května: -0.007 za 5 min, tedy cca za 700MB (měl jsem nastaven limit 1GB ram - náklady najednou 5x vyšší)
Dnes: cca -0.00428 za 5 min, tedy cca za 420MB (stáhnul jsem limit na 640MB), kdežto v ten samý okamžik měřím ve virtuálu:

Kód: Vybrat vše
             total       used       free     shared    buffers     cached
Mem:           640        393        246         55          0        141
-/+ buffers/cache:        252        387


Což působí, že to měří spotřebu RAM nově včetně využití diskové cache (!). Podle free je využití paměti programy 252 MB ale účtuje se mi ve stejný okamžik podle statistik cca za 450MB.

2) Neustále mi chodí každých pár minut notifikace o nedostatku RAM, přestože na serveru "free -m" ukazuje toto:

Kód: Vybrat vše
             total       used       free     shared    buffers     cached
Mem:           640        397        242         55          0        140
-/+ buffers/cache:        257        382


Tj. 382 MB volné paměti. Když se započte využitá disková cache, tak 242MB volné paměti, ale to by mělo být irelevantní. Dal jsem free do sekundové smyčky, abych ověřil zda tam něco skokově nevyužívá paměť moc a zdá se že ne. Tu a tam to skočí o 100MB, ale to je prakticky nezachytitelné v sekundových intervalech (zachytil jsem to tak 3x za cca 15 minut měření).

Buď úplně vypnu notifikace o problémech, kvůli nesmyslným hlášením o nedostatku RAM, pak se ale nedozvím ani o jiných problémech. Nebo zvýším limit RAM, ale to stojí peníze i když by nemělo. Dá se s tím něco dělat, aby to bylo rozumnější?

3) Je nové měření paměti zamýšlený a trvalý stav? Pokud ano, pak přejdu jinam, protože 4smart pro mě ztratilo výše uvedenou hlavní výhodu. RAM je největší nákladová položka a s tímhle způsobem účtování včetně systémové cache nemám žádný způsob jak ovlivnit její využití svými programy. Defakto platím za nastavený limit jako jinde a ne za skutečné využití jak se 4smart prezentuje.

Diskovou cache neovlivním a systém se jí snaží vždy vyplnit, takže se většinou blíží limitu využití RAM. Taky nevím proč bych za ní měl platit, když to je něco co nezabírá paměť mým ani cizím programům a je uvolněná okamžitě kdykoliv jiný program paměť potřebuje. Jediné co mohu a co jsem zkusil bylo stáhnout horní limit nastavení RAM, ale pak mi neustále chodí maily o tom jak mám nedostatek ram i když je volných cca 400MB. Jen dnes mám těchhle mailů ve schránce 110.
megi
 
Příspěvky: 4
Registrován: pon 03. dub 2017 9:43:46

Re: Jak se počítá využití RAM pro účtování

Příspěvekod admin » sob 20. kvě 2017 7:46:38

Dobrý den,

z pohledu měření statistik využití systémových prostředků na 4smart.cz nedošlo k žádným změnám.
Veškerá implementace je původní a roky nezměněná. Rovněž od 1.1.2017 nedošlo ke změnám cen.
Veškeré měření využití operační paměti probíhá v 5-min. intervalech a je založen na paprsrování /proc/user_beancounters.

Tento problém se tedy týká výhradně Vašeho VPS. V takovém případě je nutné provést inspekci serveru
a zjistit, kde problém začíná. Míra využití operační paměti záleží na vytížení serveru (platí pro variantu PROFI).

Zvýšená alokace RAM může být způsobena provozováním serveru pod větší zátěží, zvýšenými oprávněnými nároky, které plynou z konfigurace
prostředí serveru, intenzity provozu, ale také může být spojená s aktivitami havěti (botů), nebo obecně se snahami třetí strany prolomit Váš VPS, uhádnou hesla
např. k IMAP/POP3 účtům, nebo využít Váš poštovní server k rozesílání SPAMu.

Může také jít o chybu v kódu nějaké aplikace ve Vašem serveru, která vede k paměťovým únikům.

V poslední řadě může být Váš server kompromitován škodlivým kódem, může být využíván k rozesílání SPAMu, nebo jako součást nějakého botnetu
ve smyslu jiných nežádoucích aktivit.


Pokud máte zájem, můžeme se domluvit na inspekci Vašeho serveru. V takovém případě mě kontaktujte prosím na email
podpora[zv]4smart.cz. Uveďte prosím svůj login, heslo zákaznické podpory (nikoliv přihlašovací heslo) a ID problémového serveru.
Jsem si jist, že nalezneme řešení Vašeho problému.

J.M.
admin
Administrátor
 
Příspěvky: 1356
Registrován: úte 12. říj 2010 9:16:11

Re: Jak se počítá využití RAM pro účtování

Příspěvekod megi » ned 21. kvě 2017 1:24:26

Díky za odpověď. Jakým způsobem se spotřeba počítá z výstupu /proc/user_beancounters?

Kód: Vybrat vše
Version: 2.5
       uid  resource                     held              maxheld              barrier                limit              failcnt
      772:  kmemsize                 16561903             20283392             57000000             67000000                    0
            lockedpages                     0                  122                  256                  256                    6
            privvmpages                 85133               162400               163840               163840                    0
            shmpages                    14173                46941               130000               130000                    0
            dummy                           0                    0  9223372036854775807  9223372036854775807                    0
            numproc                        67                  111                  500                  500                    0
            physpages                   50564                62189                    0  9223372036854775807                    0
            vmguarpages                     0                    0                16384  9223372036854775807                    0
            oomguarpages                10471                23875                65536  9223372036854775807                    0
            numtcpsock                     24                   67                 1000                 1000                    0
            numflock                        3                   10                  188                  206                    0
            numpty                          2                    5                   30                   30                    0
            numsiginfo                      0                   27                  256                  256                    0
            tcpsndbuf                  863544              6215312             18000000             24000000                    0
            tcprcvbuf                  393216              2222272             18000000             24000000                    0
            othersockbuf               268952               570464             15000000             19000000                    0
            dgramrcvbuf                     0                13080             11048576             12048576                    0
            numothersock                  157                  216                 1200                 1200                    0
            dcachesize                7663769              7700000              7600000              7700000                    0
            numfile                       982                 1585                 5000                 5000                    0
            dummy                           0                    0  9223372036854775807  9223372036854775807                    0
            dummy                           0                    0  9223372036854775807  9223372036854775807                    0
            dummy                           0                    0  9223372036854775807  9223372036854775807                    0
            numiptent                      36                   36                  128                  128                    0


V mé VPS problém není (nic z té množiny věcí, které popisujete). Jediná metrika která se změnila je účtovaná částka za RAM, vše ostatní je přibližně podobné.

Je možné že se i dříve měřilo využití RAM i s diskovou keší, jen se tolik nevyužívala, protože jsem měl limit paměti kolem 320MB, možná i méně. Limit jsem měnil někdy v březnu - jedna knihovna v mém programu vyžaduje mmap 128MB virtuální paměti, které pak ale nevyužívá, takže není ve výsledku fyzicky alokovaná, ale virtualizační řešení to blokuje). Každopádně systém účtování zdá se funguje tak, že stačí změnit limit pro RAM a projeví se to na vyúčtování, i když se vůbec nic nezmění ve VPS samotné (krom vyššího využití diskové cache). Což není vyloženě očekávané chování. Stejně jako když bych změnil limit pro místo na HDD, tak by systém měl účtovat jen skutečně využité místo (a taky to dělá u disku, u RAM ne).
megi
 
Příspěvky: 4
Registrován: pon 03. dub 2017 9:43:46

Re: Jak se počítá využití RAM pro účtování

Příspěvekod megi » ned 21. kvě 2017 2:10:08

Nedá se asi nic dělat. Už se mi to nechce dál řešit. Tohle účtování RAM mi nevyhovuje. Za ty ceny, které bych platil, za něco co nevyužívám už si trochu připlatím za plnou virtualizaci, kde budu moci i používat systemd, wireguard, nftables a další moderní technologie, jako na jiných svých strojích. Dík za 4smart. Za ty čtyři roky mi docela ušetřil. 60-70Kč/měs. za VPSku bylo docela nepřekonatelné.
megi
 
Příspěvky: 4
Registrován: pon 03. dub 2017 9:43:46

Re: Jak se počítá využití RAM pro účtování

Příspěvekod admin » ned 21. kvě 2017 8:07:04

Dobrý den,

musím se opakovat, na 4smart.cz nedošlo ke změnám z pohledu způsobu účtování a cen. Tento problém vzniká ve Vašem VPS.
Způsob účtování týkající se paměti je založen na atributu privvmpages. Vy systému nyní k dnešnímu ránu vidím, že limit množství paměti v nedávné době nedostačoval,
čítač failcnt je u tohoto atributu nastaven na nenulovou hodnotu. Nicméně současné využití paměti je pod nastaveným limitem, takže aktuálně paměť s přehledem dostačuje.

Kód: Vybrat vše
 privvmpages                 83111               162480               163840               163840                    1


Na 4smart.cz se účtuje za skutečně využité systémové prostředky, nikoliv za nastavený limit (hodnota 83111 - první sloupec za názvem atributu).
Kdyby se ve Vašem případě mělo účtovat za nastavený limit, který máte pro VPS 772 nastaven na 4 GB RAM, platil byste jen za paměť cca 368 Kč měsíčně místo současných cca 109 Kč, které platíte za provoz celého serveru.
Myslím, že k tomu, aby se zde dělal závěr v podobě že se na 4smart.cz účtuje za nastavený limit nikoliv za skutečnou spotřebu je nutné nejprve z něčeho vycházet - v tomto případě jednoduchý výpočet.

Vypadá to, že zde dochází k nějaké nárazové alokaci paměti. Otázkou je, jak Vaše aplikace zareaguje pokud narazí na tento limit.
Může se jednat o chybu v nějaké knihovně, která na základě určitých spouštěcích okolností alokuje paměť kam až to jde a následně dojde k ukončení příslušného procesu a případně následně k jeho respawnu.
Tohle je v současné době stanovisko ze kterého vycházím já. Ostatně nebyl byste první a nejspíš nejste ani poslední. K těmto situacím na 4smart.cz velmi zřídka dochází. Příčinou neobvyklých chování serveru bývá 1) kompromitace, 2) siťový útok, 3) chyba v konfiguraci 4) implementační chyba

O atributu privvmpages se dočtete zde (pokud Vás to zajímá):
https://openvz.org/UBC_secondary_parameters

Vaše nespokojenost v tomto případě logicky pramení pouze z nějaké změny, která ve Vašem VPS nastala a dále se děje.
Problém je třeba analyzovat a vyřešit tam. Možná tento stav způsobil nějaký update, změna v konfiguraci nebo něco z toho co jsem zde již včera uvedl.

Zde je pro úplnost přehled Vašich měsíčních nákladů na provoz serveru:
Kód: Vybrat vše
+--------+------------+------------------------+-----------------------+--------------+
| vps_id | date       | system_resources_costs | other_resources_costs | fee          |
+--------+------------+------------------------+-----------------------+--------------+
|    772 | 2015-12-01 |           -54.68020400 |           -0.79684553 |   0.00000000 |
|    772 | 2016-01-01 |           -64.15792900 |           -0.01048856 |   0.00000000 |
|    772 | 2016-02-01 |           -57.93046300 |           -0.23800652 |   0.00000000 |
|    772 | 2016-03-01 |           -61.31662900 |           -0.45314991 |   0.00000000 |
|    772 | 2016-04-01 |           -60.75248300 |           -0.43950603 |   0.00000000 |
|    772 | 2016-05-01 |           -65.85206100 |           -0.62974200 |   0.00000000 |
|    772 | 2016-06-01 |           -64.78098300 |           -0.77308192 |   0.00000000 |
|    772 | 2016-07-01 |           -65.77378600 |           -0.79914388 |   0.00000000 |
|    772 | 2016-08-01 |           -66.88639900 |           -0.79941256 |   0.00000000 |
|    772 | 2016-09-01 |           -66.01357100 |           -0.77299236 |   0.00000000 |
|    772 | 2016-10-01 |           -67.68902200 |           -0.80003948 |   0.00000000 |
|    772 | 2016-11-01 |           -66.31624000 |           -0.78141237 |   0.00000000 |
|    772 | 2016-12-01 |           -67.30818000 |           -0.74085302 |   0.00000000 |
|    772 | 2017-01-01 |           -61.82196900 |           -1.33858725 | -10.32853900 |
|    772 | 2017-02-01 |           -59.91081400 |           -1.14118099 |  -9.33004800 |
|    772 | 2017-03-01 |           -90.01495000 |           -1.51712768 | -10.31465500 |
|    772 | 2017-04-01 |           -98.18653300 |           -1.55803709 |  -9.99763700 |
|    772 | 2017-05-01 |           -67.54553100 |           -0.99014779 |  -6.77886300 |
+--------+------------+------------------------+-----------------------+--------------+


system_resources_costs - náklady spojené s provozem serveru (základní služba)
other_resources_costs - náklady spojené se zálohováním (doplňková služba)
fee - paušální poplatek za server (10 Kč/30 dní dle ceníku pro variantu PROFI)

Dále přikládám přehled jednotlivých systémových prostředků (nákladů) vyúčtovaných za poslední měsíce:

leden 2017
Kód: Vybrat vše
+-------------+--------------+--------------+-------------+-----------------------+---------------+
| SUM(cpu)    | SUM(ram)     | SUM(hdd_spc) | SUM(hdd_io) | SUM(net_in + net_out) | SUM(ipv4_pub) |
+-------------+--------------+--------------+-------------+-----------------------+---------------+
| -0.34102600 | -15.40150200 |  -3.65969500 | -0.95588300 |           -3.23844900 |  -38.22541400 |
+-------------+--------------+--------------+-------------+-----------------------+---------------+


únor 2017
Kód: Vybrat vše
+-------------+--------------+--------------+-------------+-----------------------+---------------+
| SUM(cpu)    | SUM(ram)     | SUM(hdd_spc) | SUM(hdd_io) | SUM(net_in + net_out) | SUM(ipv4_pub) |
+-------------+--------------+--------------+-------------+-----------------------+---------------+
| -0.29975300 | -17.99136400 |  -3.57303300 | -0.79837700 |           -2.71823900 |  -34.53004800 |
+-------------+--------------+--------------+-------------+-----------------------+---------------+


březen 2017
Kód: Vybrat vše
+-------------+--------------+--------------+-------------+-----------------------+---------------+
| SUM(cpu)    | SUM(ram)     | SUM(hdd_spc) | SUM(hdd_io) | SUM(net_in + net_out) | SUM(ipv4_pub) |
+-------------+--------------+--------------+-------------+-----------------------+---------------+
| -0.87915600 | -41.61744700 |  -3.22706000 | -2.27843400 |           -3.83882300 |  -38.17403000 |
+-------------+--------------+--------------+-------------+-----------------------+---------------+


duben 2017
Kód: Vybrat vše
+-------------+--------------+--------------+-------------+-----------------------+---------------+
| SUM(cpu)    | SUM(ram)     | SUM(hdd_spc) | SUM(hdd_io) | SUM(net_in + net_out) | SUM(ipv4_pub) |
+-------------+--------------+--------------+-------------+-----------------------+---------------+
| -1.34580700 | -47.69819500 |  -3.29472900 | -2.85288200 |           -5.99415800 |  -37.00076200 |
+-------------+--------------+--------------+-------------+-----------------------+---------------+


dosud neukončený květen 2017
Kód: Vybrat vše
+-------------+--------------+--------------+-------------+-----------------------+---------------+
| SUM(cpu)    | SUM(ram)     | SUM(hdd_spc) | SUM(hdd_io) | SUM(net_in + net_out) | SUM(ipv4_pub) |
+-------------+--------------+--------------+-------------+-----------------------+---------------+
| -0.77087300 | -31.60511600 |  -2.28013000 | -1.24248100 |           -6.60497600 |  -25.12677600 |
+-------------+--------------+--------------+-------------+-----------------------+---------------+


Kromě nákaldů za operační paměť se vám zvyšují také náklady za datové přenosy (vyšší zátěž nebo kompromitace/síťový útok ?)

J.M.
admin
Administrátor
 
Příspěvky: 1356
Registrován: úte 12. říj 2010 9:16:11

Re: Jak se počítá využití RAM pro účtování

Příspěvekod megi » pon 22. kvě 2017 15:12:39

Způsob účtování týkající se paměti je založen na atributu privvmpages. Vy systému nyní k dnešnímu ránu vidím, že limit množství paměti v nedávné době nedostačoval,


Ano, experimentoval jsem s tím, jak nízký limit server snese, proto je failcount > 0.

Myslím, že k tomu, aby se zde dělal závěr v podobě že se na 4smart.cz účtuje za nastavený limit nikoliv za skutečnou spotřebu je nutné nejprve z něčeho vycházet - v tomto případě jednoduchý výpočet.


Měl by jste si znovu přečíst co tvrdím. 4smart účtoval z pohledu mé bývalé VPS to co bylo ve výstupu free ukázané jako včetně diskové cache a bufferů. (což efektivně s časem vede k tomu že účtuje nastavený limit - něco málo, třeba 20-30% - když jsem měl limit 1GB, účtovalo se 700MB, když jsem to stáhnul na 640MB, účtovalo se 400MB) Moje VPS nikdy v průměru reálně nevyužívala 700MB fyzické RAM (což je něco co mě bylo účtované někdy v březnu), to je naprosto absudrdní hodnota. Ty max 2 PHP-FPM procesy, nginx, postfix ani extrémně sestříhaný postgresql to opravdu nemohli dohromady trvale dát. Všechno mělo nastavené přísné limity.

Identická konfigurace virtuálu (s jedniným rozdílem, že jsem se nenamáhal ořezávat php-fpm a nechal výchozí nastavení) pod plnou virtualizací spotřebovává po jednom dni běhu 120MB.

Předpokládám, že se prostě něco změnilo ve virtualizaci. Třeba během aktualizace, úpravou nastavení vm, jako třeba změnou swappiness, netuším. Také htop a free dříve chvílemi ukazovali z části hausnumera (myslím, že vůbec neukazovali diskovou cache (proužek v htopu byl vždy jednobarevný) a i suma využité paměťi byla chvílemi podezřele malá - třeba 30MB) a od nějaké doby to ukazovalo správněji. Neřešil jsem to, protože účtované částky odpovídaly zhruba běžícím procesům a přisuzoval jsem to nějaké specifické vlastnosti virtualizačního řešení.

Dělal jsem si i statistiky zátěže nginx a postfixu z logů a vyplynulo z nich, že některé dny bylo např. 500 pokusů o připojení k postfixu a některé dny 20000, což už je v průměru připojení každých pár sekund - mezi těmi dny nebyl žádný praktický rozdíl v účtované RAM ani CPU. Tj. ani 20000 připojení/s (většinou odmítaných) není zátěž která by měla mít zásadní vliv na využití RAM a podle statistik ani neměla.

O napadení také pochybuji, mám stažené zálohy z období před problémy a po nich. Dělal jsem diff a nenašel nic podezřelého. Mimo to, některé části souborového systému co 4 hodiny synchronizuji na lokál a ukládám do gitu, takže mám k dispozici kompletní historii změn na serveru za několik let s docela jemnou granularitou. Není to nemožné, ale nenašel jsem žádné znaky napadení.

Rostoucí síťové vytížení je očekávané. Webserver je celkem populární s 5000 unikátními přístupy měsíčně a stabilním růstem. Ale to nemá vliv na využití RAM. Zátěž byla podobná minulý rok a nastavení nginx je identické.

Upřímně, o server se starám a mám o něm přehled. Na fórum jsem šel až po tom co jsem vyčerpal nápady na to co může být špatně z mé strany. Kdyby mě účtování RAM dávalo po 9.3. smysl, tak sem nic nepíšu. Přistupujte si k tomu jak chcete. Zatím hledáte problém v mé VPS. Fajn. Proč ne.

Ale také by jste si mohl udělat experiment a sečíst kolik účtujete za využití RAM na jednom stroji v jeden okamžik pro všechny VPS. Může vám vyjít vtipné číslo větší než velikost RAM na serveru, protože - z vámi odkazované stránky:

Since the memory accounted into privvmpages may not be actually used, the sum of current privvmpages values for all containers may exceed the RAM and swap size of the computer.


Nicméně pro mě už je to pasé. Migroval jsem jinam.
megi
 
Příspěvky: 4
Registrován: pon 03. dub 2017 9:43:46


Zpět na Řešení problémů

Kdo je online

Uživatelé procházející toto fórum: Žádní registrovaní uživatelé a 1 návštěvník