6 ms·

"PostgreSQL's model of one process per connection doesn't scale, so let's build a connection pooler that uses one process per connection." Certainly sounds lik

"PostgreSQL's model of one process per connection doesn't scale, so let's build a connection pooler that uses one process per connection." Certainly sounds like a strange concept. How well does it scale with thousands of connections?

jpgvm 5y ago
Not the author but PG connection scalability being blamed on per-process model is somewhat misunderstood. You can easily have many hundreds of thousands of processes, they are mostly equivalent to threads on Linux anyway (with some minor differences ofc). Instead the poor scalability stems from the amount of resources allocated to each connection. If postgres was to switch to threads without changing this architecture it's likely scalability wouldn't be majorly improved. By the same token a connection pooler that is fork based but only allocates a very small amount of resources per connection is still likely to a net win as it can do statement based pooling of a smaller number of postgres connections.
- kasey_junk 5y ago
  Pretty good discussion of Postgres’ process bottlenecks: https://www.citusdata.com/blog/2020/10/08/analyzing-connection-scalability/ https://www.citusdata.com/blog/2020/10/08/analyzing-connecti... Summary: The resource per process issue is isolated to just the transaction isolation mechanism and can likely be improved but you are never getting around the context switching and memory locality issues of the per process model.
- anarazel 5y ago
  > You can easily have many hundreds of thousands of processes, they are mostly equivalent to threads on Linux anyway (with some minor differences ofc). Not really. The page-table overhead of a 100k processes alone is going to a eat up a lot of memory - and you don't have that with threads. And with something like postgres the page tables aren't going to be tiny, even with explicit use of huge pages for applicable allocations. The decrease in TLB hit ratio also is very painful. In a lot of workloads postgres spends way too much time in TLB faults, and that's to a good degree caused by the process model (also caused by linux making it way too hard to map executables with huge pages, itlb faults are a significant issue). That's not to say that a 1 connection: 1 thread approach is the right thing for a pooler - threads area also don't scale great. I think there are good simplicity arguments to be made for a 1 connection: 1 thread model for a database server itself, but for poolers the benefits seem much smaller.
  - anarazel 5y ago
    (Although the sibling post pointing to my postgres connection scalability post is right - processes are not the major bottleneck at the moment, and certainly not with < PG 14)
    - jpgvm 5y ago
      Yeah I agree wholeheartedly. What I was trying to get across was that simply s/processes/threads isn't going to make a massive difference to postgres if that was the only change you were to make. Your analysis seems pretty on-point with what I expected, i.e snapshot scalability and other postgres specific arch being the major bottlenecks for higher connection counts.
      - anarazel 5y ago
        FWIW, a good chunk of the snapshot scalability changes are in PG 14, so the situation has gone a bit further towards s/processes/threads/ being the primary bottleneck. It depends quite a bit on whether you're write-mostly (bottlenecks almost completely unrelated to processes vs threads) or read-mostly. And in the latter case whether it's a context switch heavy workload (processes vs threads may be a significant factor), or not (processes vs threads can be a significant factor, but less likely).
api 5y ago
The popularity and mindshare of Postgres really puzzles me. It’s so arcane and full of weird failure modes and gotchas. It feels like something from a 1980s mainframe that would come with a bound “field manual.” We can have file systems like zfs that for all but maybe the largest and most exotic use cases are bulletproof and relatively easy to administrate. Why can’t we have SQL like this? I guess we do in the form of CockroachDB or Yugabyte, but Postgres has been so aggressively evangelized try selling someone on those. I know of one or two companies that use them but it’s a tough sell. There are tons of overpriced Postgres managed cloud offerings and consultancies, so my guess is that there is a heavy financially motivated astroturf campaign.
- gmac 5y ago
  First: have you used Postgres, and at what scale? Because that hasn't been my experience of it. Second: do you know something that's comparable but better?
  - api 5y ago
    I should have been more detailed. Postgres works really well in single node configurations as long as you read up a bit on the weirdness around vacuuming. Usually you don't have to worry unless you are running write-heavy loads at large scale. HA Postgres is where things get frustrating and hairy. It's 2021. I should be able to set up a master-master multi-node database by running a second node and telling it where the first node is, and then you're done. Master with read-only backup should be similarly easy. If I shut down the "lead" node a backup should become leader automatically. I should be able to set this up in a day and not worry that it will fail to fail over properly in a real scenario because there are algorithms now like Raft consensus that are provably correct (provided you meet their requirements). IMHO this kind of easy clustering is a table stakes feature for anything billing itself as an "enterprise capable" database. The fact that HA Postgres requires me to think in 2021 is what makes me hate the thing. As near as I can tell this problem exists to make me buy managed HA Postgres at 1000% markup over compute/storage. I can't complain too much because it's free and it is very good for the things it does well. It's just puzzling to me that there is no canonical turn-key solution for this after so many years of so many people requiring it. Implementing Raft is far far easier than a lot of the other stuff that has been implemented in Postgres.

jpgvm 5y ago

Not the author but PG connection scalability being blamed on per-process model is somewhat misunderstood. You can easily have many hundreds of thousands of processes, they are mostly equivalent to threads on Linux anyway (with some minor differences ofc). Instead the poor scalability stems from the amount of resources allocated to each connection. If postgres was to switch to threads without changing this architecture it's likely scalability wouldn't be majorly improved. By the same token a connection pooler that is fork based but only allocates a very small amount of resources per connection is still likely to a net win as it can do statement based pooling of a smaller number of postgres connections.

kasey_junk 5y ago
Pretty good discussion of Postgres’ process bottlenecks: https://www.citusdata.com/blog/2020/10/08/analyzing-connection-scalability/ https://www.citusdata.com/blog/2020/10/08/analyzing-connecti... Summary: The resource per process issue is isolated to just the transaction isolation mechanism and can likely be improved but you are never getting around the context switching and memory locality issues of the per process model.
anarazel 5y ago
> You can easily have many hundreds of thousands of processes, they are mostly equivalent to threads on Linux anyway (with some minor differences ofc). Not really. The page-table overhead of a 100k processes alone is going to a eat up a lot of memory - and you don't have that with threads. And with something like postgres the page tables aren't going to be tiny, even with explicit use of huge pages for applicable allocations. The decrease in TLB hit ratio also is very painful. In a lot of workloads postgres spends way too much time in TLB faults, and that's to a good degree caused by the process model (also caused by linux making it way too hard to map executables with huge pages, itlb faults are a significant issue). That's not to say that a 1 connection: 1 thread approach is the right thing for a pooler - threads area also don't scale great. I think there are good simplicity arguments to be made for a 1 connection: 1 thread model for a database server itself, but for poolers the benefits seem much smaller.
- anarazel 5y ago
  (Although the sibling post pointing to my postgres connection scalability post is right - processes are not the major bottleneck at the moment, and certainly not with < PG 14)
  - jpgvm 5y ago
    Yeah I agree wholeheartedly. What I was trying to get across was that simply s/processes/threads isn't going to make a massive difference to postgres if that was the only change you were to make. Your analysis seems pretty on-point with what I expected, i.e snapshot scalability and other postgres specific arch being the major bottlenecks for higher connection counts.
    - anarazel 5y ago
      FWIW, a good chunk of the snapshot scalability changes are in PG 14, so the situation has gone a bit further towards s/processes/threads/ being the primary bottleneck. It depends quite a bit on whether you're write-mostly (bottlenecks almost completely unrelated to processes vs threads) or read-mostly. And in the latter case whether it's a context switch heavy workload (processes vs threads may be a significant factor), or not (processes vs threads can be a significant factor, but less likely).

api 5y ago

The popularity and mindshare of Postgres really puzzles me. It’s so arcane and full of weird failure modes and gotchas. It feels like something from a 1980s mainframe that would come with a bound “field manual.” We can have file systems like zfs that for all but maybe the largest and most exotic use cases are bulletproof and relatively easy to administrate. Why can’t we have SQL like this? I guess we do in the form of CockroachDB or Yugabyte, but Postgres has been so aggressively evangelized try selling someone on those. I know of one or two companies that use them but it’s a tough sell. There are tons of overpriced Postgres managed cloud offerings and consultancies, so my guess is that there is a heavy financially motivated astroturf campaign.

gmac 5y ago
First: have you used Postgres, and at what scale? Because that hasn't been my experience of it. Second: do you know something that's comparable but better?
- api 5y ago
  I should have been more detailed. Postgres works really well in single node configurations as long as you read up a bit on the weirdness around vacuuming. Usually you don't have to worry unless you are running write-heavy loads at large scale. HA Postgres is where things get frustrating and hairy. It's 2021. I should be able to set up a master-master multi-node database by running a second node and telling it where the first node is, and then you're done. Master with read-only backup should be similarly easy. If I shut down the "lead" node a backup should become leader automatically. I should be able to set this up in a day and not worry that it will fail to fail over properly in a real scenario because there are algorithms now like Raft consensus that are provably correct (provided you meet their requirements). IMHO this kind of easy clustering is a table stakes feature for anything billing itself as an "enterprise capable" database. The fact that HA Postgres requires me to think in 2021 is what makes me hate the thing. As near as I can tell this problem exists to make me buy managed HA Postgres at 1000% markup over compute/storage. I can't complain too much because it's free and it is very good for the things it does well. It's just puzzling to me that there is no canonical turn-key solution for this after so many years of so many people requiring it. Implementing Raft is far far easier than a lot of the other stuff that has been implemented in Postgres.