Making use of added storage volumes

hosting
1

For most VPS providers I’ve seen, if you need more storage space you either:

  • Upgrade your whole VPS plan.
  • Buy additional storage volumes.

Now if you are running out of disk space, but your CPU/RAM resources are plenty, the additional storage volumes are likely the more cost efficient option. But these appear as a new volume on your server, while Discourse keeps running on the original volume where you installed it in the first place.

I could not find a guide or documentation on best practices how to either move Discourse to the newly added larger volume or what is the best way to make use of the added capacity?

For example on Digital Ocean if you upgrade your VPS plan you generally get 2x CPU and RAM, but only 10/20GB increments in disk space.

2 Likes
2

Storage space for what? The database of users, posts, and replies? Or uploads and attachments?

3

Well, personally I always offload images/attachements to S3,so in my case we would be talking about base system and database. Low cost VPSs tend to come with tiny SSDs.

4

At least on Digital Ocean that would be a 3x performance penalty

3 Likes
5

Coming back to this topic. I benchmarked ScaleWay’s 9.99€ plan…

https://meta.discourse.org/t/the-cheapest-solution-for-hosting/24060/35?u=ljpp

…and noticed that their nice 200GB storage capacity is actually delivered in two volumes:

  • 50GB volume, where the OS is
  • Additional 150GB

So what is the best practice to make use of the secondary 150GB volume?

2 Likes
6

This question remains. I benchmarked ScaleWays new intensive workload server, and seems like a viable option for Discourse hosting.

But again, theiy deliver the SSD storage as 50+150GB, so how to make use of the additional 150GB volume? By default Discourse-setup will install to the 50GB system volume.

This should be a trivial issue, but I’d need some practical guidance on best the approach? Installing Discourse to the additional volume would be the most straight forward way, even though it leaves some of the 50GB system volume unutilized.

@mpalmer?

7
1 Like
8

I usually offload uploads to S3 anyway. But how to install the base system to other than default location?

Symlink might be an idea, but for a reason unknown @sam adviced against them.

9

You can:

  • Clone discourse_docker (usually /var/discourse) anywhere

  • Point the shared folders to another file system (like on the linked topics)

  • Change docker configs so /var/docker/aufs lands elsewhere.

This are the 3 changes that can be made to better use your disk space.

4 Likes
10

Warning, we have found that the add-on DO storage volumes are half the speed of the base disk:

root@vol:/# dd bs=1M count=512 if=/dev/zero of=test conv=fdatasync
536870912 bytes (537 MB) copied, 1.72333 s, 312 MB/s

root@server:/var/discourse# dd bs=1M count=512 if=/dev/zero of=test conv=fdatasync
536870912 bytes (537 MB) copied, 3.03458 s, 177 MB/s

For reference a here are numbers from a modern consumer M.2 PCI SSD drive:

536870912 bytes (537 MB) copied, 0.564705 s, 951 MB/s

And a plain old consumer SATA SSD, but a good one, like the Samsung 950 pro… though to be fair most name brand-ish SATA SSDs are close to this as it is a mature market:

536870912 bytes (537 MB) copied, 1.20895 s, 444 MB/s

I looked up old results, and ye olde spinning rust hard drives deliver anywhere from 50 MB/sec to 110 MB/sec.

7 Likes
11

The difference is much worse. dd is not a good tool to measure performance if you want the results to be anything near what is happening in real life. dd performs a long sequential write, and that is not what your Discourse server is doing.

We use fio for benchmarking stuff like this.
See this article: How to benchmark disk I/O : BinaryLane

The base SSD disk is around 9 times faster than the add-on volume.

Base disk:

Jobs: 1 (f=1): [m] [-.-% done] [115.8M/39880K /s] [29.7K/9970  iops] [eta 00m:00s]
   READ: io=307668KB, aggrb=127346KB/s, minb=127346KB/s, maxb=127346KB/s, mint=2416msec, maxt=2416msec
  WRITE: io=101932KB, aggrb=42190KB/s, minb=42190KB/s, maxb=42190KB/s, mint=2416msec, maxt=2416msec

Add-on volume:

Jobs: 1 (f=1): [m] [100.0% done] [11484K/3904K /s] [2871 /976  iops] [eta 00m:00s]
READ: io=306676KB, aggrb=14174KB/s, minb=14174KB/s, maxb=14174KB/s, mint=21635msec, maxt=21635msec
WRITE: io=102924KB, aggrb=4757KB/s, minb=4757KB/s, maxb=4757KB/s, mint=21635msec, maxt=21635msec

On the other hand, don’t overestimate the impact of a not so fast disk: if you use the add on disk only for files (public/uploads ) then nginx caching and kernel filesystem caching will save your day and you’ll still have a pretty decent performance.

8 Likes
12

That would definitely be my recommendation.

13

I would also recommend keeping docker images and containers on the volume, it seems to be holding up fine. (also, clearly backups)

Its pretty simple you symlink /var/lib/docker to /mnt/volume/whatever

6 Likes