[mbell]

The connection comments are a bit dubious. MySQL will use less memory for 1000 connections but performance will still drop due to contention and context switching. In both systems you want a small number of connections to the actual database, something on the order of 1-2x cpu cores usually, and something on top pooling client connections if you need a lot of them, pgbouncer or the equivalent for MySQL.

[nvivo]

I had some real issues with mysql handling more than 2000 connections. Once past that limit, cpu usage increases exponentially with few connections due to context switching. At 3000 connections, 80% of thr cpu was used gor context switching and it got unusable. That was a 64 core/256gb ram server.

[stevenwoo]

What did you do to address the mysql connection problem?

[nvivo]

I ended up reducing the number of clients. In my case I had a thousand servers, and I was able to change the application structure and merge them into a dozen big application servers. Now with connection pooling each server has less than 100 connections.

As a more permanent solution for scaling, I'm moving out of mysql into something more distributed.

[kolzeq]

Or you can have move to mariadb, using configuration "thread_handling=pool-of-threads" to enable threadpool that is exactly the solution.

(MySQL have that only for "entreprise" version)

[ngrilly]

Something more distributed like what?