RAM Memory Cache a Buffer

[hazardrok]

Ahoj, provozuju dva servery s ubuntu. Jeden mám fyzicky a druhej používá VPS. Na obou serverech jede stejnej software. Ten fyzizkej používám pro ladění a vývoj a na tom VPS provozuju finální aplikaci. Jen poznámka, že vše provozuju dost amatérsky a nejsem úplně IT odborník.

Poslední dobou se mi na tom VPS začlo dít, že mi začla růst hodnota buff/cache z výpisu htop. Roste v podstatě až do maxima než server spadne. Na tom fyzickém stroji se to neděje což je pro mě záhada, ale to mi zas tak nevadí.

Chtěl bych se tedy zeptat co to vlastně to buff/cache je? Zkoušel jsem porovnávat dva různé záznamy z výstupu htop před a po nárůstu buff/cache a snažil se najít v které aplikaci paměť je, ale došel jsem k závěru že žádná spuštěná aplikace tuto paměť nepoužívá. Nebo jsem to nenašel.

Pak jsem narazil na tento odkaz:
https://www.geeksforgeeks.org/how-to-clear-ram-memory-cache-buffer-and-swap-space-on-linux/

Když jsem provedl to co tam popisujou paměť se skutečně uvolnila a serveru se ulehčilo. Píšou tam také, že se to provádí každé tři hodiny. Chci se tedy ještě zeptat, jestli návod v tomto odkazu je správná cesta ke stabilitě serveru.
Dík

[Reklama]

[František Ryšánek]

Palec nahoru za dotaz a za používání šedé kůry :-)
Ano správně, to téma je kontroverzní.

Vedle hodnot Buffers/Cached jsou zajímavé také hodnoty MemTotal/MemFree/MemAvailable, Dirty/Writeback, SwapTotal/SwapFree a další. V zásadě je zajímavá velká část obsahu /proc/meminfo, a jeho vývoj v čase.

Odpojit swapáč za jízdy na serveru, který začíná drhnout, mi přijde jako poněkud kaskadérský nápad :-) Zejména bez mrknutí do /proc/meminfo, kolik je naswapováno.

Free_caches způsobí:

- zahození obsahu stránek, který zůstal v ramce ve smyslu "čtecí cache". Tzn pokud něco z toho bude zanedlouho potřeba, vyvolá to nějaký ten přístup k disku navíc = zdržení.

- nejsem si jistý (nepoužívám to) zda způsobí také flushnutí dirty stránek (write-back cache). Pokud to navíc provede "bariérovou operaci", může to způsobit dost dlouhé zdržení. Záleží jaký objem stránek je ve stavu dirty/writeback, kolik je to transakcí, jak rychlé jsou disky a jakou další zátěž ten storage táhne (pokud je sdílený více hostitelskými stroji).

Objem Cached/Buffers sám o sobě mnoho neříká. Stránky "buffered" (čtecí cache) jsou teoreticky "obratem k dispozici" (téměř free), prostě se jenom vyřadí z cache. Tzn. "uvolnit je násilím" by samo o sobě nemělo mít velký přínos. Je možné, že to má vedlejší efekty a konotace. Četl jsem něco o interakci NFS a vespod ZFS, kde free_caches řeší reálný problém. Nebo že konkrétně ve virtualizovaných prostředích to má taky svůj dobrý smysl - cca aby guesti zbytečně nedrželi hostiteli alokovanou fyzickou RAM na nějaké svoje poviderní čtecí cache, "jenom proto že je ta RAMka k dispozici". Protože ve virtualizaci se fyzická RAMka přiděluje vlastně "nadvakrát" - probíhá memory management v rámci hostitele a následně v rámci jednotlivých guestů, tato dvě patra mohou spolupracovat. Padla v této souvislosti taky na okraj zmínka o ballooning driveru (asi jakožto o alternativním způsobu, jak nutit guestův kernel ke střídmému zacházení s využíváním RAMky).

Téma do jisté míry souvisí s fragmentací RAM - té se dá bránit explicitním spuštěním "defragmentace RAM":
echo 1 > /proc/sys/vm/compact_memory
...což ale zřejmě neřeší konkrétně otázky specifické pro virtualizované prostředí.

Odkazy = rychlým dotazem do Googlu jsem našel k tématu několik výživných debat - řazeno cca sestupně podle relevance:
https://serverfault.com/questions/597115/why-drop-caches-in-linux
https://savvinov.com/2019/10/14/memory-fragmentation-the-silent-performance-killer/
https://www.unix.com/unix-for-advanced-and-expert-users/248922-memory-fragmentation-linux-settop-box.html
https://lwn.net/Articles/368869/

[hazardrok]

Díky za reakci a za odkazy. Kontroverzní to asi je, soudě podle jednoho jediného komentáře k problému. Snažil jsem se odkazy pročíst a trochu tomu porozumět, jedno z toho se mi povedlo, ale o úspěšnosti toho druhého dost pochybuji :-D

Po načerpání nových teoretických poznatků mi došlo, že jsem možná zapomněl napsat parametry toho VPS:
2GB RAM, 20GB SSD DISK, 1 CPU Core

Také jsem napsal špatně, že ten server se po vyčerpání paměti zhroutí. To vlastně není pravda, stane se to, že výkon CPU jde na 100%. Provozovatel VPS v mém případě neumožňuje dlouhodobé vytížení VPS a tak ho vypne.

Pokud to správně chápu tak problém je v tom, že se jedná o VPS o jehož konfiguraci nic nevím a asi s ní nic neudělám viz citace od savvinov:

In many cases, memory fragmentation can be reduced by tweaking VM parameters. Of course, as with any low-level change, you really need to know what you are doing, so it’s best to get a consult from a Linux expert, or from Oracle support in an SR (and do some good testing).

Třeba to nikam nepovede, ale budu pokračovat v laborování...
Provedl jsem opakovaně:

Kód: [Vybrat]

free -h

Kód: [Vybrat]

               total        used        free      shared  buff/cache   available
Mem:          1.9Gi       201Mi       994Mi       2.0Mi       791Mi       1.6Gi
Swap:         2.3Gi          0B       2.3Gi

1. Hodnota Swap je stále na nule a nikdy jsem neviděl, že by se pohnula. Zdá se, že tento prostor se vůbec nepoužívá.
2. buff/cache postupně pomalu v čase roste.

Snažím se stále pochopit jak bych tomu mohl pomoci jinak než nějakým násilným způsobem za jaký je možná považováno

Kód: [Vybrat]

echo 3 > /proc/sys/vm/drop_caches

, ale nic jiného mě v tuhle chvíli nenapadá, protože mi to příjde, že to není věcí programů, které používám, ale věcí systému který rozhodně nemám plně pod svou kontrolou.

[Jan Fikar]

drop_caches asi moc nevadí, jedině to může trochu škodit diskovému výkonu. Pokud se to bude dělat jednou za 3 hodiny, tak to nebude tak strašné. Možná by stačilo ještě míň často? Taky jde místo nejdrsnějšího 3 zapsat do drop_caches jen 2 nebo 1, což by možná účel také splnilo, ale negativní efekt by byl menší.

Taky je možnost snížit prioritu cache pomocí velké hodnoty vfs_cache_pressure, defaultní je 100, ale funguje to jen ve spojitosti se swapem, tak bych asi zároveň zvýšil swappiness a asi by se vyplatilo snížit a zafixovat vm.dirty_bytes a vm.dirty_background_bytes. Defaultně je to hodně, nějaké procento celkové paměti.

něco jako toto v /etc/sysctl.conf

Kód: [Vybrat]

vm.vfs_cache_pressure=500
vm.swappiness=100
vm.dirty_bytes=16638608
vm.dirty_background_bytes=8319304

Ještě mě napadlo, jestli nemáte nějaké hugepages? je z výstupu něco nenulové?

Kód: [Vybrat]

cat /sys/kernel/mm/hugepages/hugepages-*/nr_hugepages

[Jan Fikar]

Dafaultně je dirty_bytes 20% a dirty_background_bytes 10% RAM, tedy ve vašem případě 410GB a 205GB. Já to zmenšil na 16GB a 8GB.

[Reklama]

[RDa]

V tomto kontextu je VM configuration konfigurace virtualni pameti. Ne virtualniho stroje.

[hazardrok]

vm.vfs_cache_pressure=500
vm.swappiness=100
vm.dirty_bytes=16638608
vm.dirty_background_bytes=8319304

Našel jsem ještě tenhle odkaz kde se ty parametry vysvětlujou takže aspoň člověk má trochu povědomí co nastavuje: https://letsfoss.com/managing-swap-memory-in-ubuntu/

Tam jsou ty hodnoty trošku v rozporu s tím co píšeš. Takže s těmi hodnotami budu experimentovat.
Zjistil jsem, že jak vm.dirty_bytes, tak vm.dirty_background_bytes jsou v mé konfiguraci nulové takže je nechám na nule.

Kód: [Vybrat]

cat /sys/kernel/mm/hugepages/hugepages-*/nr_hugepages

se provedlo s nulovým výsledkem.

Teď nezbývá než čekat...trvá to cca týden než to zbuchne.

[František Ryšánek]

Dokud je nějaká paměť "available", tak by neměl být problém. Možná to s pamětí vůbec nesouvisí.
V momentě kdy ten stroj sežere 100% CPU, dá se zjistit, čím je procesor konkrétně vytížený?
Mimochodem popis problému mi cosi připomněl, ale asi je to podobnost čistě náhodná.

[hazardrok]

V momentě kdy ten stroj sežere 100% CPU, dá se zjistit, čím je procesor konkrétně vytížený?

Na tomhle teď pracuju, takže bych to snad měl vědět příští cyklus zhroucení pokud se to povede zachytit. Napsal jsem si pro to krásnej a asi dost úchylnej script kterej se spouští každou minutu :-)

#!/bin/bash
for i in {1..19}
do
  currentDate=`date +"%Y-%m-%d_%T"`
  currentMoon=`date +"%m"`
  currentDay=`date +"%d"`

  mkdir -p /home/irma/MONITOR/$currentMoon/$currentDay

  #echo $currentTime
  top -b -n 1 > /home/irma/MONITOR/$currentMoon/$currentDay/$currentDate
  gzip /home/irma/MONITOR/$currentMoon/$currentDay/$currentDate
  sleep 3
done

Možná to nebude fungovat, ale nic lepšího co mi nezabralo moc času na napsání mě nenapadlo.

[Jose D]

Napsal jsem si pro to krásnej a asi dost úchylnej script

→ sysstat aka sar?

> currentMoon=`date +"%m"`

mhmmmmmm

[Jan Fikar]

Našel jsem ještě tenhle odkaz kde se ty parametry vysvětlujou takže aspoň člověk má trochu povědomí co nastavuje: https://letsfoss.com/managing-swap-memory-in-ubuntu/

Tam jsou ty hodnoty trošku v rozporu s tím co píšeš. Takže s těmi hodnotami budu experimentovat.

ano, protože většina uživatelů chce malý swap a velký cache, což pomáhá IO výkonu a na desktopu jsou malé zádrhy kvůli disku dost poznat

Zjistil jsem, že jak vm.dirty_bytes, tak vm.dirty_background_bytes jsou v mé konfiguraci nulové takže je nechám na nule.

To tak je, protože vm.drity_ratio=20 a vm.dirty_background_ratio=10. Když se zapíše do _bytes, tak se zase vynuluje _ratio

Jinak je možné, že to opravdu s cache nesouvisí. To, že cache naroste na celou dostupnou RAM se prostě časem stane, ale není to nic špatného. Cache se může lehce zapsat a zahodit. Leda by opravdu drop_cache dlouhodobě problém řešil.

Jinak špinavým řešením by také mohl být restart každé třeba 4 dny. Pokud problém nastane za týdden.

[redustin]

Co žere to 100%CPU? Ve virtualboxu s Win10 běžícím nad Mintem se mi při něčem větším ve Win rozjede kernelí vlákno kcompactd0 na 100% jádra a virtuál se takřka zastaví. Někdy to trvá minuty, někdy musím rebootnout a pustit vmware jako první, než na linuxu spustím něco většího (něco jako aby měl vmware souvislou paměť). Win10 10GB, hostitel celkem 16GB. Řekl bych, že to dřív nedělalo.

[hazardrok]

Ahoj, nabízím pokračování toho co se tu už řešilo, neboť po několika týdnech mám konečně výsledky co se na tom VPS děje. Závěr je to, že ten VPS podle mě pracuje špatně a nevidím chybu u sebe (samozřejmě připouštím, že jsem něco přehlédnul, něčemu neporozumněl, nebo nemám dostatečné znalosti a zkušenosti). Došel jsem k tomu tak, že jsem si každé tři sekundy logoval výsledek z příkazu top. Najednou se ale stane to, že z ničeho nic ten příkaz top přestane pracovat a vrací nulové hodnoty, po několika sekundách chcípne úplně celý systém. Poslední log (ani logy předtím) neukazuje na nic neobvyklého.
Neměl by ještě někdo nějaký nápad na základě těchto nových skutečností?

Výpis posledního top před zhroucením:

Kód: [Vybrat]

top - 09:00:52 up 2 days, 19:35,  0 users,  load average: 0.12, 0.08, 0.08
Tasks: 103 total,   1 running, 102 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.0 us,  6.2 sy,  0.0 ni, 87.5 id,  0.0 wa,  0.0 hi,  6.2 si,  0.0 st
MiB Mem :   1983.4 total,    160.4 free,    216.1 used,   1606.9 buff/cache
MiB Swap:   2355.0 total,   2353.7 free,      1.3 used.   1584.3 avail Mem 

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 585042 root      20   0       0      0      0 I   6.7   0.0   0:28.97 kworker+
 677495 root      20   0    9120   3584   3140 R   6.7   0.2   0:00.01 top
      1 root      20   0  168848  12648   8168 S   0.0   0.6   0:20.57 systemd
      2 root      20   0       0      0      0 S   0.0   0.0   0:00.04 kthreadd
      3 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 rcu_gp
      4 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 rcu_par+
      6 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 kworker+
      8 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 mm_perc+
      9 root      20   0       0      0      0 S   0.0   0.0   3:30.42 ksoftir+
     10 root      20   0       0      0      0 I   0.0   0.0   7:57.32 rcu_sch+
     11 root      rt   0       0      0      0 S   0.0   0.0   0:00.55 migrati+
     12 root     -51   0       0      0      0 S   0.0   0.0   0:00.00 idle_in+
     14 root      20   0       0      0      0 S   0.0   0.0   0:00.00 cpuhp/0
     15 root      20   0       0      0      0 S   0.0   0.0   0:00.00 kdevtmp+
     16 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 netns
     17 root      20   0       0      0      0 S   0.0   0.0   0:00.00 rcu_tas+
     18 root      20   0       0      0      0 S   0.0   0.0   0:00.00 kauditd
     19 root      20   0       0      0      0 S   0.0   0.0   0:00.07 khungta+
     20 root      20   0       0      0      0 S   0.0   0.0   0:00.00 oom_rea+
     21 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 writeba+
     22 root      20   0       0      0      0 S   0.0   0.0   0:00.00 kcompac+
     23 root      25   5       0      0      0 S   0.0   0.0   0:00.00 ksmd
     24 root      39  19       0      0      0 S   0.0   0.0   0:00.00 khugepa+
     70 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 kintegr+
     71 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 kblockd
     72 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 blkcg_p+
     73 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 tpm_dev+
     74 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 ata_sff
     75 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 md
     76 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 edac-po+
     77 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 devfreq+
     78 root      rt   0       0      0      0 S   0.0   0.0   0:00.00 watchdo+
     80 root      20   0       0      0      0 S   0.0   0.0   0:00.59 kswapd0
     81 root      20   0       0      0      0 S   0.0   0.0   0:00.00 ecryptf+
     83 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 kthrotld
     84 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 acpi_th+
     85 root      20   0       0      0      0 S   0.0   0.0   0:00.00 scsi_eh+
     86 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 scsi_tm+
     87 root      20   0       0      0      0 S   0.0   0.0   0:00.00 scsi_eh+
     88 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 scsi_tm+
     90 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 vfio-ir+
     92 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 ipv6_ad+
    101 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 kstrp
    104 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 kworker+
    118 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 charger+
    120 root       0 -20       0      0      0 I   0.0   0.0   0:09.47 kworker+
    201 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 raid5wq
    252 root      20   0       0      0      0 S   0.0   0.0   0:18.92 jbd2/vd+
    253 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 ext4-rs+
    329 root      19  -1   96528  45216  43980 S   0.0   2.2   1:46.10 systemd+
    358 root      20   0    2488    584    516 S   0.0   0.0   0:00.00 none
    371 root      20   0   21288   5256   3932 S   0.0   0.3   0:01.95 systemd+
    540 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 kaluad
    541 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 kmpath_+
    542 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 kmpathd
    543 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 kmpath_+
    544 root      rt   0  280208  17992   8200 S   0.0   0.9   0:21.06 multipa+
    553 root       0 -20       0      0      0 S   0.0   0.0   0:00.00 loop0
    555 root       0 -20       0      0      0 S   0.0   0.0   0:00.00 loop1
    557 root       0 -20       0      0      0 S   0.0   0.0   0:00.00 loop2
    558 root       0 -20       0      0      0 S   0.0   0.0   0:00.00 loop3
    560 root       0 -20       0      0      0 S   0.0   0.0   0:00.00 loop4
    563 root       0 -20       0      0      0 S   0.0   0.0   0:00.00 loop5
    564 root       0 -20       0      0      0 S   0.0   0.0   0:00.00 loop6
    581 systemd+  20   0   90196   5924   5152 S   0.0   0.3   0:01.50 systemd+
    623 systemd+  20   0   18380   7388   6536 S   0.0   0.4   0:07.47 systemd+
    625 systemd+  20   0   23860  11892   7984 S   0.0   0.6   0:06.79 systemd+
    636 root      20   0  236084   7516   6328 S   0.0   0.4   0:24.36 account+
    639 root      20   0    6812   2784   2520 S   0.0   0.1   0:03.02 cron
    640 message+  20   0    7828   4632   3688 S   0.0   0.2   0:01.62 dbus-da+
    651 root      20   0   29340  15056   7304 S   0.0   0.7   0:01.98 network+
    653 root      20   0   10324   5900   4620 S   0.0   0.3   0:21.58 openvpn
    654 root      20   0    9692   5236   4532 S   0.0   0.3   0:05.18 openvpn
    656 syslog    20   0  224348   4748   3216 S   0.0   0.2   0:16.87 rsyslogd
    662 root      20   0   17256   7848   6684 S   0.0   0.4   0:00.78 systemd+
    664 daemon    20   0    3792   2100   1924 S   0.0   0.1   0:00.00 atd
    714 root      20   0   12176   6512   5584 S   0.0   0.3   0:19.87 sshd
    747 root      20   0    5828   1576   1464 S   0.0   0.1   0:00.00 agetty
    759 root      20   0  107908  15440   8072 S   0.0   0.8   0:00.12 unatten+
    766 irma      20   0   18392   9600   8048 S   0.0   0.5   0:00.16 systemd
    771 irma      20   0  103244   3292      0 S   0.0   0.2   0:00.00 (sd-pam)
    778 root      20   0  232716   6552   5856 S   0.0   0.3   0:00.05 polkitd
    913 irma      20   0    7084   2208   1820 S   0.0   0.1   0:17.21 screen
    915 irma      20   0    6952   2052   1792 S   0.0   0.1   0:00.00 screen
    917 irma      20   0    6892   2276   2044 S   0.0   0.1   0:00.00 start_b+
    918 irma      20   0    7024   2572   2124 S   0.0   0.1   0:00.00 start_m+
    919 irma      20   0   10352   2236   1768 S   0.0   0.1   1:44.96 main
 169967 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 xfsalloc
 169975 root       0 -20       0      0      0 I   0.0   0.0   0:00.00 xfs_mru+
 169981 root      20   0       0      0      0 S   0.0   0.0   0:00.00 jfsIO
 169982 root      20   0       0      0      0 S   0.0   0.0   0:00.00 jfsComm+
 169983 root      20   0       0      0      0 S   0.0   0.0   0:00.00 jfsSync
 316561 irma      20   0  333968  31272   7444 S   0.0   1.5  49:55.47 main
 416282 root      20   0  725792  42116  19368 S   0.0   2.1   0:07.49 snapd
 668599 grafana   20   0 1304764  81720  53960 S   0.0   4.0   0:10.34 grafana+
 668777 grafana   20   0 1306740  19128  11268 S   0.0   0.9   0:02.24 gpx_sql+
 670932 root      20   0       0      0      0 I   0.0   0.0   0:00.00 kworker+
 675275 root      20   0       0      0      0 I   0.0   0.0   0:00.12 kworker+
 676194 root      20   0       0      0      0 I   0.0   0.0   0:00.02 kworker+
 677044 root      20   0       0      0      0 I   0.0   0.0   0:00.00 kworker+
 677294 root      20   0    8352   3284   2612 S   0.0   0.2   0:00.00 cron
 677299 root      20   0    2608    612    540 S   0.0   0.0   0:00.00 sh
 677303 root      20   0    6892   3184   2940 S   0.0   0.2   0:00.03 system_+ 

Printscreen seznamu logů v příloze.

[kanoe22]

Mozno trepnem blbost, ale nie je tam nejak vela uspanych threadov a moc malo beziacich? aka 1 running, 102 sleeping.

Plus su tam nejake loop procesy:
    553 root       0 -20       0      0      0 S   0.0   0.0   0:00.00 loop0
    555 root       0 -20       0      0      0 S   0.0   0.0   0:00.00 loop1
    557 root       0 -20       0      0      0 S   0.0   0.0   0:00.00 loop2
    558 root       0 -20       0      0      0 S   0.0   0.0   0:00.00 loop3
    560 root       0 -20       0      0      0 S   0.0   0.0   0:00.00 loop4
    563 root       0 -20       0      0      0 S   0.0   0.0   0:00.00 loop5
    564 root       0 -20       0      0      0 S   0.0   0.0   0:00.00 loop6

Co su to za procesy? Nie su to nahodou nejake interne cykly z:

...

ktore sa vymkly kontrole?

[hazardrok]

Díky za reakci. Ta tvoje trepnutá blbost mě navedla akorád na to, že vůbec netuším co většina těch procesů znamená. Pokud bych se zabejval těma co se jmenujou loopx tak pokud správně rozumím číslům PID tak se spustí dřív než je vůbec předáno řízení auživatelským programům. Z toho bych si tedy myslel, že je to součástí systému. Na tom stroji není ani nic extra nainstalováno...jen SSH, VPN, grafana. Pak tam běží pár mých procesů kdy některé jen kopírují data a jiné komunikujou s TCP a ukládají do databáze (SQlite). Když to stejné běží na fyzickém stroji žádný problémy nejsou.

Ono je to ale ve finále všechno jedno, jediné co se děje že poskytovatel VPN odstaví ten virtuální stoj a pošle mail. Já ho nastartuju a jede se dál. Celej ten projekt je čistě amatérskej a stejně tak k tomu přistupujou všichni uživatelé, takže to nikoho neuráží....jen mě :-D