this post was submitted on 05 Jun 2023
86 points (98.9% liked)
Lemmy
13104 readers
2 users here now
Everything about Lemmy; bugs, gripes, praises, and advocacy.
For discussion about the lemmy.ml instance, go to !meta@lemmy.ml.
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
The site currently runs on the biggest VPS which is available on OVH. Upgrading further would probably require migrating to a dedicated server, which would mean some downtime. Im not sure if its worth the trouble, anyway the site will go down sooner or later if millions of Reddit users try to join.
There will either be an hour of downtime to migrate and grow or days of downtime to fizzle.
I love that there's an influx of volunteers, including SQL experts, to mitigate scaling issues for the entire fediverse but those improvements won't be ready in time. Things are overloading already and there's less than a week before things increase 1,000-fold, maybe more.
😬
2 follow-ups:
We need Self hosted team and team networking to represent. Would be amazing to see some community support in scaling Lemmy up.
Maybe some dns fail-over for lemmy.ml to point to join-lemmy.org might be cool indeed 🤔
Yeah, was thinking of a DNS based solution as well. Probably the easiest and most effective way to do it?
I dont think so, when the site is overloaded then clients cant reach it at all.
It should be compatible if someone sets it up.
You could configure something like a Cloudflare worker to throw up a page directing users elsewhere whenever healthchecks failed.
Then cloudflare would be able to spy on all the traffic so thats not an option.
That's...not how things work. Everyone has their philosophical opinions so I won't attempt to argue the point, but if you want to handle scale and distribution, you're going to have to start thinking differently, otherwise you're going to fail when load starts to really increase.
Cloudflare does have the ability to spy on traffic though, they hold SSL keys.
You could run an interstitial proxy yourself with a little health checking. The server itself doesn't die, just the webapp/db. nginx could be stuck on there (if it's not already there) with a temp redirect if the site is timing out.
A better option for a simple usecase like that is using something from your DNS provider. Depending on who you use they may have a health check service that has no access to user data that can simply ping a URL, and if it fails hard enough, start redirecting traffic to join-lemmy.org
I think Constellix has it, though I'm not necessarily recommending them specifically
How about https://deflect.ca/ they could still spy but probably less bad?
I'm sure you know this, but getting progressively larger servers is not the only way, why not scale horizontally?
I say this as someone with next to no idea how Lemmy works.
Its better to optimize the code so that all instances benefit.
Is it possible to make Lemmy (the system as a whole) able to be compatible with horizontally scaling instances? I don't see why an instance has to be confined to one server, and this would allow for very large instances that can scale to meet demand.
Edit: just seen your other comment https://lemmy.ml/comment/453391
It should be easy once websocket is removed. Sharded postgres and multiple instances of frontend/backend. Though I don't have any experience with this myself.
I think that is unavoidable, Look at the most popular subreddits , they can get something like 80 million upvotes and 66K comments per day, do you think a single server can handle that?
Splitting communities just so that it will be easier technically is not good UX.
@nutomic @Lobstronomosity In one of the comments I thought I saw that the biggest CPU load was due to image resizing.
I think it might be easier to split the image resizer off to its own worker that can run independently on one (or more) external instances. Example: client uses API to get a temporary access token for upload, client uploads to one of many image resizers instead of the main API, image resizer sends output back the main API.
Then your main instance never sees the original image
There is already a docker image so that should not be too hard. I'd be happy to set something up, but (as others have said) the DB will hit a bottleneck relatively quickly.
I like the idea of splitting off the image processing.
Image processing isnt causing any noticable cpu load.
I saw someone say it was, obviously I have no access to data.
Maybe on another instance but not on lemmy.ml
What's the current bottleneck?
SQL. We desperately need SQL experts. It's been just me for yeRs, and my SQL skills are pretty terrible.
Put the whole DB in RAM :-)
Makes me remember optimization, lots of EXPLAIN and JOIN pain, on my old MySQL multiplayer game server lol. A shame I'm not an expert ...
There are some SQL database optimisations being discussed right now and apparently the picture resizing on upload can be quite CPU heavy.
SQL dev here. Happy to help if you can point me in the direction of said conversation. My expertise is more in ETL processes for building DWs and migrating systems, but maybe I can help?
https://github.com/LemmyNet/lemmy/issues/2877
this seems to be the relevant issue: https://github.com/LemmyNet/lemmy/issues/2877
I've been helping on the SQL github issue. And I think the biggest performance boost would be to separate the application and postgresql onto different servers. Maybe even use a hosted postgresql temporarily, so you can scale the db at the press of a button. The app itself appears to be negligible in terms of requirements (except the picture resizing - which can also be offloaded).
But running a dedicated db on a dedicated server - as close to the bare metal as possible give by far the best performance. And increase it for more connections. Our production database at my data analytics startup runs a postgresql instance on an i9 server with 16 cores, 128GB RAM, and a fast SSD. We have 50 connections set up, and the run pgbouncer to allow up to 500 connections to share those 50. And it seamlessly runs heavy reporting and dashboards for more than 500 business customers with billions of rows of data. And costs us less than US$200pm at https://www.tailormadeservers.com/.
I think hexbear.net (an older lemmy fork-ed site) is working on this in conjunction with moving back to a modern lemmy version
This suggestion probably won't help with hosted VPS, but lib nvJPEG pushes crazy theoretical numbers for image resizing.
Maybe this could be worth investigating?
Probably not, but it does mention a more general CUDA based solution that might be interesting to add to Pictrs. I could for example move my Pictrs instance onto a server that does have an older Nvidia GPU to accelerate stuff (to use for Libretranslate and some other less demanding ML stuff).
Edit: Ok looks like the resizing is anyways only supported on Pictrs 0.4.x which most Lemmy instances are not using yet. However this seems to use regular ImageMagick in the background, so chances are quite high that it can be made to work with OpenCL: https://imagemagick.org/script/opencl.php
And may be the bandwidth. Serve thousands and thousands need at minimum 1gbps.
Its mostly text so bandwidth shouldnt be a problem.
So reading this correctly, it's currently a hosting bill of 30 Euro a month?
No, thats the 8 GB memory option... if its the biggest, it should be around 112 €. Meanwhile i keep wondering if i should let Lemmy stay on the current KVM (which is similarely specked but with dedicated cores and stuff) or if it is better to move it to one of my dedis just in case... well... will see xD
Its the one for 30 euros, Im not seeing any vps for 112. Maybe thats a different type of vps?
Is it running in a single docker container or is it spread out across multiple containers? Maybe with
docker-machineor kubernetes with horizontal scaling, it could absorb users without issue - well, except maybe cost. OVH has managed kubernetes.