Skip to main content

Hardware selection

29.12.2022

Introduction​

How to run 200+ cameras on a server for 300 euro?

grafana_node

We're often asked how many cameras can be added to Yucca on a server with a given set of hardware resources. The question is always individual, and there's no one-size-fits-all answer. A lot depends on the type of cameras, bitrate, processor, and other variables. So we decided to gather some statistics from one of our clients' servers, with screenshots and detailed explanations, so that everyone can get an idea of how many resources are needed for their particular case...

We've published similar statistics about running on Raspberry Pi 4

Our installation​

So, this is Yucca version 0.7.2, with 154 cameras connected, an archive depth of almost 4 years, and a stream bitrate from the cameras of around 1M (megabits per second). Besides Yucca, this same server also runs postgresql, as the database.

ycc_main ycc_admin grafana_ycc (If you want the same dashboard, the instructions are available at this link)

So what resources are used for all of this, and how much of them is being utilized?

Motherboard​

Z8NR-D12 is a very old chassis, and you can buy one on the secondary market for about 200 euro.

motherboard a screenshot from a marketplace we know

This particular option is perhaps missing a second power supply, but you could look for a similar chassis, for example from Supermicro.

Processor (CPU)​

Intel(R) Xeon(R) CPU X5690 @ 3.47GHz - 2 processors with 12 threads each, giving 24 in total. On the secondhand market you can find one for about 30 euro apiece.

CPU is one of the most important resources – it's always what you'll end up bottlenecked on as the number of streams grows. The more streams there are, the more processes, and the more CPU time we need. So the most important thing to watch is not so much utilization, as in the 1st screenshot, but LA, or Load Average (if you don't know what that is, read about it here) – see the 2nd screenshot.

So let's look at utilization over 24 hours; there are peaks here, but average utilization is around 30% cpu_util

The LA chart for the day shows a similar picture, around 30% - 40% cpu_la

Keep in mind that this is the reading for 150 cameras, which means the server is roughly half full, and in theory the same number of cameras could be added again, provided the cameras have a similar bitrate.

We don't recommend adding cameras to servers where the LA is already above one. LA > 1 means the queue will keep growing and service problems and degradation are almost inevitable – you need either more CPU or another Yucca server. So with a large number of clients and cameras, always visualize your installations in monitoring first and keep an eye on the metrics.

RAM​

9965447-034.A00LF - server ECC memory, about 10 euro per board on the secondhand market.

In our case, 16 gigabytes (8 per processor socket) is more than enough with a 3x margin, and utilization is around 4 gigabytes.

grafana_ram

Disk​

Disk arrays are a topic that deserves a separate note on how to do it right and how not to, and I'll explain how to roughly calculate the projected volume by hand, but you can always find an online calculator for your bitrate and array type.

On this particular setup, our client only hosts public cameras, and an unexpected loss of archive from these cameras is not critical for them. So if your archive has significant value, don't do it this way, as described here.

ST10000VN0004-1Z - Seagate IronWolf 10Tb NAS.
4 units in a Raid0 configuration give 37 terabytes, at a cost of around 200 euro per unit.

$ df -h | grep yucca
/dev/md0            37T          15T   20T           43% /opt/yucca/data/alloc

$ cat /etc/mdadm/mdadm.conf 
DEVICE partitions
ARRAY /dev/md0 level=raid0 num-devices=4 metadata=1.2 name=yucca:0 UUID=xxx

Of course, since this is Raid0, we don't experience any performance issues at all when writing the archive from 150 cameras in parallel, and there wouldn't be any with 300 either, but fault tolerance is zero, so everyone has to choose the right solution for themselves.

How to calculate how much space you need for the archive​

Suppose we have 150 identical cameras with a stream bitrate of 2M, and we want to write an archive with a depth of 14 days:

  • 2 megabits per second, that's 2/8 = 0.25 megabytes
  • 0.25 * 60 * 60 = 900 megabytes per hour
  • 900 * 24 = 21600 megabytes => 21.6 gigabytes per day per camera
  • 21.6 * 14(days) = 302.4 gigabytes in 14 days per camera
  • 302.4 * 150 = 45360 gigabytes => 45.36 terabytes

This simple calculation lets you roughly estimate how much space our archive will take up. It's also worth noting that arrays shouldn't be filled up to 99% capacity, and it's better to keep at least 5-10% free.

Conclusions​

So, we have a chassis + processors + RAM for about 300 euro and a disk array for 400 euro. In total, about 700 euro for a full-fledged working solution, with the ability to sell services to clients with a capacity of up to 300 cameras.

Let's dream a bit...
A Yucca license costs 40 euro a month, and we don't have any camera limits – if you have a modern chassis and 10,000 cameras, we won't hold you back :) The average tariff for a camera with a 14-day archive currently charged by providers is about ~5-7 euro a month, meaning you could earn 1500 euro a month on such a server with barely any expenses, paying it off in 1 month – though that assumes you already have 300 clients ready to go 🙂

Thanks to everyone who read this to the end!
You can ask a question through the contact form on our website, by writing to info@yucca.app or in the community Telegram chat.