Increase the RAM of the demo machine

[hivib26208]

Only 4GB? Is that a joke? Since it is a public instance, a lot of users can install things and it quickly runs out of memory and becomes unresponsive. Just look at the memory usage graph. It goes beyond 4GB at least half of the time. I know that this is only a demo, not for production, but at least it should be usable for testing.

[nebulon]

@hivib26208 I guess you are right, generally no matter what we add as memory, it may overload the demo if too many apps are installed, however since some apps like Gitlab alone take so much memory, I think it is good increase the demo instance. This is anyways positive, since it shows that the demo is used more and more.

[robi]

@nebulon perhaps a time to consider using one of the large memory instances from SSD Nodes or Contabo for the same pricing.

[nebulon]

For a start as the simpler option I just doubled the memory

[girish]

@robi Wow, 48GB RAM for 127/yr. Seems like a no brainer. I will sync with @nebulon to move the demo server there.

[robi]

@girish feel free to use my referral code if you do: trimurl.co/ssd

[girish]

@robi will do, thanks

[girish]

We got a server on ssdnodes (48GB RAM) but looks like CPU is like very very very slow. It takes forever to unzip docker images. Let's see if the situation improves.

[robi]

@girish sometimes you get on an overprovisioned box, just ask to have it moved to a less busy node.

[girish]

@robi moved demo cloudron to ssdnodes! they also kindly moved our VM to another node.

[girish]

So far, the performance on ssdnodes has been super flaky. I won't use it for anything production related because it seems to become really really slow every other day. And one can request a change of host only so many times...

[jdaviescoates]

@girish said in Increase the RAM of the demo machine:

the performance on ssdnodes has been super flaky.

Given their too good to be true pricing (and lots of others out there giving similar negative reviews) this doesn't surprise me one bit.

[robi]

After some back and forth with their support, they can be coaxed into letting you know that the machine you've moved to is locked, ie won't be getting new customers.

They do have some issues figuring out IO starvation issues, which are obvious. Higher quality support would do them good.

My system was fine for a long while until recently due to IO starvation.

Frankly I had forgotten about this, since it's been ok for so long. Had to relearn that lesson.

# dd if=/dev/zero of=/tmp/test1.img bs=1G count=1 oflag=dsync ; rm /tmp/test1.img
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 5.93197 s, 181 MB/s

As long as there's IO, it'll do.

[jdaviescoates]

@robi said in Increase the RAM of the demo machine:

they can be coaxed

To me this is just proof that their standard service is rubbish and they should be avoided.

If you have to coax them into providing the service they claim to be providing they evidently are not providing said service.

Each to their own I guess but I wouldn't touch them with a barge pole.

[girish]

@girish said in Increase the RAM of the demo machine:

@robi moved demo cloudron to ssdnodes! they also kindly moved our VM to another node.

as a follow up, we moved it to Linode now. SSDNodes is a bit too flaky for our needs.

[LoudLemur]

@robi I love you for this post!

https://contabo.com/en/
https://www.ssdnodes.com/

[nebulon]

@LoudLemur and @robi just to add here the option to run hdparm -Tt /dev/<youdisk>, which will measure a few things for disk I/O.

[robi]

@nebulon said in Increase the RAM of the demo machine:

@LoudLemur and @robi just to add here the option to run hdparm -Tt /dev/<youdisk>, which will measure a few things for disk I/O.

That requires root and for hdparm to actually be available and installed.

Hence I use:
dd if=/dev/zero of=/tmp/test1.img bs=1G count=1 oflag=dsync ; rm /tmp/test1.img