3 ms·

Use pgbouncer

by devit 3y ago

Use pgbouncer

ethbr0 3y ago
Was curious about this as an architectural solution as well. We're really talking about X-per-client as the primary reason to move away from processes, right? So if you can get most of the benefit via pooling... why inherit the pain of porting? Presumably latency jitter would be a difficult problem with pools, but it seems easier (and safer) than porting processes -> threads. Disclaimer: High performance / low latency DB code is pretty far outside my wheelhouse.
- ddorian43 3y ago
  > We're really talking about X-per-client as the primary reason to move away from processes, right? Many other things too. Like better sharing of caches. Lower overhead of thread instead of process. Etc. (read the thread)
- ilyt 3y ago
  The reasons are explained in article. Read the article
  - ethbr0 3y ago
    I appear to have missed them, then. Could you point out, aside from the large numbers of clients I mentioned (and the development overhead of implementing multi-process memory management code), what the article mentions is a primary drawback of using processes over threads?
    - ilyt 3y ago
      > The overhead of cross-process context switches is inherently higher than switching between threads in the same process - and my suspicion is that that overhead will continue to increase. Once you have a significant number of connections we end up spending a lot of time in TLB misses, and that's inherent to the process model, because you can't share the TLB across processes.
      - ethbr0 3y ago
        Yes, that's per-client performance scaling ("significant number of connections"), which indicates a pooled connection model might mitigate most of the performance impact while allowing some core code to remain process-oriented (and thus, not rewritten).
- anarazel 3y ago
  pgbouncer is not transparent, you loose features, particularly when using the pooling mode actually allowing a larger number of active concurrent connections. Solving those issues is a lot easier with threads than with processes.
treis 3y ago
That helps a lot but it's not a replacement for large number of persistent connections. If you had that you could simplify things in the application layer and do interesting things with the DB.

Use pgbouncer

by devit 3y ago

Use pgbouncer

Was curious about this as an architectural solution as well. We're really talking about X-per-client as the primary reason to move away from processes, right? So if you can get most of the benefit via pooling... why inherit the pain of porting? Presumably latency jitter would be a difficult problem with pools, but it seems easier (and safer) than porting processes -> threads. Disclaimer: High performance / low latency DB code is pretty far outside my wheelhouse.

ddorian43 3y ago
> We're really talking about X-per-client as the primary reason to move away from processes, right? Many other things too. Like better sharing of caches. Lower overhead of thread instead of process. Etc. (read the thread)
ilyt 3y ago
The reasons are explained in article. Read the article
- ethbr0 3y ago
  I appear to have missed them, then. Could you point out, aside from the large numbers of clients I mentioned (and the development overhead of implementing multi-process memory management code), what the article mentions is a primary drawback of using processes over threads?
  - ilyt 3y ago
    > The overhead of cross-process context switches is inherently higher than switching between threads in the same process - and my suspicion is that that overhead will continue to increase. Once you have a significant number of connections we end up spending a lot of time in TLB misses, and that's inherent to the process model, because you can't share the TLB across processes.
    - ethbr0 3y ago
      Yes, that's per-client performance scaling ("significant number of connections"), which indicates a pooled connection model might mitigate most of the performance impact while allowing some core code to remain process-oriented (and thus, not rewritten).
anarazel 3y ago
pgbouncer is not transparent, you loose features, particularly when using the pooling mode actually allowing a larger number of active concurrent connections. Solving those issues is a lot easier with threads than with processes.

treis 3y ago

That helps a lot but it's not a replacement for large number of persistent connections. If you had that you could simplify things in the application layer and do interesting things with the DB.