seang96

It's the one I'm using but it's not just running in a cluster. Even some applications recommend running separately like matrix. You can't run everything on the same.versiom all the time anyways.

How much RAM is postgres using? I'm running on i7 11th Gen and 16gb of RAM so your hardware is fine. This is the resource usage of my setup. First 6 are Lemmy itself broken up to scale and for redundancy. I have a node down right now normally using 3 http ones. Http ones receive federation from others and the lemmy-instance2s are the databases setup to be highly available too.

NAME CPU(cores) MEMORY(bytes)

lemmy-6b9fbd75f6-4q4n8 1m 5Mi

lemmy-fed-0 2m 18Mi

lemmy-fed-1 1m 18Mi

lemmy-fed-2 6m 17Mi

lemmy-http-57886f784f-5x9vb 4m 73Mi

lemmy-http-57886f784f-tpbtb 13m 121Mi

lemmy-instance2-czc6-0 47m 3362Mi

lemmy-instance2-jpw7-0 13m 1017Mi

Another note you want to have a round trip from federation in under 3 seconds. Those 499 are likely 10 second timeouts from Lemmy.worlds side. Mostly from a long query being the culprit. Lemmy federation in 0.19 processes changes in order per instance so lemmy.world won't sync newer stuff and keep sending the same large request. I believe there is a retry limit though.

Say what you want it's a recommendation and it's documented in quite a few deployment methods. The only benefit of centralizing it is if you are managing postres without other tools since it'd be a pain in the butt. You'll still run into apps that doesn't run on later versions and others that require later versions though.

An example of a very popular one:

How many databases should be hosted in a single PostgreSQL instance?

Our recommendation is to dedicate a single PostgreSQL cluster (intended as primary and multiple standby servers) to a single database, entirely managed by a single microservice application. However, by leveraging the "postgres" superuser, it is possible to create as many users and databases as desired (subject to the available resources).

The reason for this recommendation lies in the Cloud Native concept, based on microservices. In a pure microservice architecture, the microservice itself should own the data it manages exclusively. These could be flat files, queues, key-value stores, or, in our case, a PostgreSQL relational database containing both structured and unstructured data. The general idea is that only the microservice can access the database, including schema management and migrations.

CloudNativePG has been designed to work this way out of the box, by default creating an application user and an application database owned by the aforementioned application user.

Reserving a PostgreSQL instance to a single microservice owned database, enhances:

resource management: in PostgreSQL, CPU, and memory constrained resources are generally handled at the instance level, not the database level, making it easier to integrate it with Kubernetes resource management policies at the pod level
physical continuous backup and Point-In-Time-Recovery (PITR): given that PostgreSQL handles continuous backup and recovery at the instance level, having one database per instance simplifies PITR operations, differentiates retention policy management, and increases data protection of backups
application updates: enable each application to decide their update policies without impacting other databases owned by different applications
database updates: each application can decide which PostgreSQL version to use, and independently, when to upgrade to a different major version of PostgreSQL and at what conditions (e.g., cutover time)

This is what I'm doing but with a cluster of them and 12 TB in each node. One died in February and is coming back today for repairs. 3 year warranty came with it is insane.

It is recommended to run postgres for each service though since they may have completely different needs / configurations for the queries to be optimal. For self hosting Lemmy and matrix would be the big concerns here.

If your failing on Lemmy.world like others suggest, but federation is working with others, it's likely you are getting large queries that are timing out with lemmy.world. You can check for timeouts in your proxy's logs.

Troubleshooting tips

This guide is for tuning postgres if you find it is an issue. This has good tips and tips on how to analyze issues on postgres. It's oriented for matrix tuning though. work_mem and temp files likely will need constant tuning to meet your demands if you have limited memory for postgres.

Lastly I wanted to note that Lemmy does application connection pooling, so if you have a Pooler service behind postgres, dont, let Lemmy connect directly to postgres

Hope these help. I went from a recent 1 million federation backlog in lemmy.world to near none. I believe I am at a ram limit and a couple expensive queries (deleting posts for example) are creating temp files and taking too long.

Gotta have a firewall that closely resembles swiss cheese.

I'd say that depends. Some consumer routers may have guest network and client isolation on it though I doubt most do. Higher end routers support vlans can be configured that way and could be configured in many other wise such as talking to network 1 but not 2 or 3. For instance, I have IOT vlan allowed to connect to my server vlan for DNS since I self host DNS, but my general VLAN for personal trusted devices does can't be accessed by IOT.

Eh good point.. there needs to be a bit more regulation over all these industries so the government pays for actual proper disposal rather than dumped elsewhere for more $.

If they are wanting recycling materials with no cash transactions. Those dumps in other countries probably require payment to use their services, so I assume they wouldn't want it if they were paying to ship it across the world to throw it in another dump right?