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):
(bts_tools)[email protected]:~$ free -m
total used free shared buffers cached
Mem: 2001 1926 74 0 2
buffers/cache: 1193-/+ 730 1270
Swap: 6143 0 6143
(bts_tools)[email protected]:~$ 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.