Running a Delegate on a 2GB vps

[xeroc]

also, in general: empty ram is useless ram

[wackou]

The tools report the memory usage as returned by the psutil python package: https://pythonhosted.org/psutil/

Memory usage on linux is a very complex thing:
- what you see from free does not mean anything, really, as if your kernel caches a lot of things, free will show them as used memory, even though it is in effect not used, as linux will reclaim it and evict its caches as soon as you need it
- top is not 100% reliable either, but gives a little bit more information. The important value, and the one I believe psutil reports, is the resident ram amount, ie: the amount of ram used exclusively by your process, that is, excluding shared libraries and things that are swapped out.

to sum up: it's really hard to know exactly how much memory your program is using. You can monitor an increase in ram usage, and detect something is happening, but getting an exact value requires a lot of work and is usually not that helpful either. See for instance:

- http://www.darkcoding.net/software/resident-and-virtual-memory-on-linux-a-short-example/
- http://unix.stackexchange.com/questions/35129/need-explanation-on-resident-set-size-virtual-size
- etc...

[xeroc]

my delegates run on 2gb ram, too. Had the same issues but in general do not miss my blocks when swapping.

My machine missed block due to heavy exceptions logging until disk was full

[jsidhu]

6 gb swap on 2 gb is a bad idea you will get alot of missed blocks once you are in swap mem mode.. I did.. In general 50% is usually max for swap to double your memory.. It should only be needed in emergency.. I agree the client uses too much memory but i think it will be fixed with the recent fc changes

[Thom]

delegate.verbaltech is running on an 8 core, 2GB vps (linux OS) with a 6GB swap file. I updated the client to v0.8.1 within a couple of hours of Vikram's announcement that it was available, however it managed to get off on the wrong fork.

Getting it back up & running on the correct fork took a lot of time & effort. It was harder than when I updated the client b/c it was only obtaining info from liondani's chainserver rather than 30 - 40 peers. I started by removing the exceptions, logs and peer.leveldb folders to insure data was coming only from the chainserver.

As swap utilization approached the limit (twice) I stopped the client and decided to reboot the vps to make sure all memory was freed, then resumed the sync process immediately after the reboot was complete.

Once synced I rebooted one last time. Before starting the client after rebooting the vps there was 1880MB out of 2GB free. The OS uses very little as it's configured. After starting the bitshares_client, tmux, 2 bash sessions with bts_tools (python virtualenv, one for the client the other for the monitor processes which are very lightweight):

Code: [Select]

tmux client:

(bts_tools)mike@vps:~$ free -m
total                used       free     shared    buffers     cached
Mem:                 2001       1926         74          0          2
buffers/cache:       1193-/+     730       1270
Swap:                6143          0       6143

tmux monitor:

(bts_tools)mike@vps:~$ uwsgi --ini ~/.bts_tools/uwsgi/bts_tools.ini >> ~/.bts_tools/monitor.log 2>&1

Almost no change was observed.
A screen shot of the status info from the monitor shows only a little more than 700MB of memory consumption, but I'm not sure what that is reflecting. It sure doesn't reflect overall system memory utilization. If I'm not mistaken, I seem to recall the info for the status tab comes from the ps command obtained by the python code. Perhaps wackou might enlighten us about this.