I’m having a problem with MySQL 5.7 with « too many connections » causing services crashes. The max_connections system variable is set at 1000 and on average there are +/- 250 sessions/thread, so it’s odd that the max connections are being reached. The issue appears mostly at night between 10 and 11 pm at certain weeknights. The machine is a Windows 2008 R2 Enterprise Server with 32 Gb RAM and Dual Xeon CPUs. Here's some more environmental information: Variable | Max Connection Memory ------------------------------------------------- join_buffer_size | 250.00 MB read_buffer_size | 62.50 MB read_rnd_buffer_size | 250.00 MB sort_buffer_size | 250.00 MB max_connections = 1000 | 812.50 MB Timeouts | VALUE ------------------------------------------- connect_timeout | 10 delayed_insert_timeout | 300 have_statement_timeout | YES innodb_flush_log_at_timeout | 1 innodb_lock_wait_timeout | 50 innodb_rollback_on_timeout | OFF interactive_timeout | 28800 lock_wait_timeout | 31536000 net_read_timeout | 30 net_write_timeout | 60 rpl_stop_slave_timeout | 31536000 slave_net_timeout | 60 wait_timeout | 28800 ------------------------------------------- max_allowed_packet | 33554432 slave_max_allowed_packet | 1073741824 Here's my sample log file: Aborted connection 27933 to db: 'wms_mysql' user: 'mysql' host: 'eifprdrds01.domain.com' (Got an error reading communication packets) Aborted connection 26736 to db: 'wms_mysql' user: 'mysql' host: 'eifprdrds01.domain.com' (Got an error reading communication packets) Aborted connection 27200 to db: 'wms_mysql' user: 'mysql' host: 'eifprdrds01.domain.com' (Got an error reading communication packets) Aborted connection 27356 to db: 'wms_mysql' user: 'mysql' host: 'eifprdrds01.domain.com' (Got an error reading communication packets) Aborted connection 29119 to db: 'wms_mysql' user: 'mysql' host: 'pc286.domain.com' (Got an error reading communication packets) Aborted connection 16274 to db: 'wms_mysql' user: 'mysql' host: 'pc828.domain.com' (Got timeout reading communication packets) Aborted connection 24916 to db: 'wms_mysql' user: 'mysql' host: 'pc830.domain.com' (Got an error reading communication packets) Aborted connection 19357 to db: 'wms_mysql' user: 'mysql' host: 'pc830.domain.com' (Got an error reading communication packets) Aborted connection 19343 to db: 'wms_mysql' user: 'mysql' host: 'pc830.domain.com' (Got an error reading communication packets) Here are some additional environmental parameters (global status): Variable_name | Value Aborted_clients | 579 Aborted_connects | 1 Binlog_cache_disk_use | 0 Binlog_cache_use | 0 Binlog_stmt_cache_disk_use | 0 Binlog_stmt_cache_use | 0 Bytes_received | 112705860256 Bytes_sent | 1320858513743 Com_admin_commands | 6343 Com_assign_to_keycache | 0 Com_alter_db | 0 Com_alter_db_upgrade | 0 Com_alter_event | 0 Com_alter_function | 0 Com_alter_instance | 0 Com_alter_procedure | 0 Com_alter_server | 0 Com_alter_table | 0 Com_alter_tablespace | 0 Com_alter_user | 0 Com_analyze | 0 Com_begin | 368010 Com_binlog | 0 Com_call_procedure | 0 Com_change_db | 14 Com_change_master | 0 Com_change_repl_filter | 0 Com_check | 0 Com_checksum | 0 Com_commit | 367880 Com_create_db | 0 Com_create_event | 0 Com_create_function | 0 Com_create_index | 0 Com_create_procedure | 0 Com_create_server | 0 Com_create_table | 0 Com_create_trigger | 0 Com_create_udf | 0 Com_create_user | 0 Com_create_view | 0 Com_dealloc_sql | 0 Com_delete | 1899441 Com_delete_multi | 0 Com_do | 0 Com_drop_db | 0 Com_drop_event | 0 Com_drop_function | 0 Com_drop_index | 0 Com_drop_procedure | 0 Com_drop_server | 0 Com_drop_table | 0 Com_drop_trigger | 0 Com_drop_user | 0 Com_drop_view | 0 Com_empty_query | 0 Com_execute_sql | 0 Com_explain_other | 0 Com_flush | 0 Com_get_diagnostics | 0 Com_grant | 0 Com_ha_close | 0 Com_ha_open | 0 Com_ha_read | 0 Com_help | 0 Com_insert | 5932889 Com_insert_select | 0 Com_install_plugin | 0 Com_kill | 1 Com_load | 0 Com_lock_tables | 0 Com_optimize | 0 Com_preload_keys | 0 Com_prepare_sql | 0 Com_purge | 0 Com_purge_before_date | 0 Com_release_savepoint | 0 Com_rename_table | 0 Com_rename_user | 0 Com_repair | 0 Com_replace | 0 Com_replace_select | 0 Com_reset | 0 Com_resignal | 0 Com_revoke | 0 Com_revoke_all | 0 Com_rollback | 107 Com_rollback_to_savepoint | 0 Com_savepoint | 0 Com_select | 305377361 Com_set_option | 412902 Com_signal | 0 Com_show_binlog_events | 0 Com_show_binlogs | 0 Com_show_charsets | 9 Com_show_collations | 9 Com_show_create_db | 0 Com_show_create_event | 0 Com_show_create_func | 0 Com_show_create_proc | 0 Com_show_create_table | 0 Com_show_create_trigger | 0 Com_show_databases | 20 Com_show_engine_logs | 0 Com_show_engine_mutex | 0 Com_show_engine_status | 0 Com_show_events | 0 Com_show_errors | 0 Com_show_fields | 33672455 Com_show_function_code | 0 Com_show_function_status | 8 Com_show_grants | 2 Com_show_keys | 34409046 Com_show_master_status | 0 Com_show_open_tables | 0 Com_show_plugins | 19 Com_show_privileges | 0 Com_show_procedure_code | 0 Com_show_procedure_status | 8 Com_show_processlist | 2 Com_show_profile | 0 Com_show_profiles | 0 Com_show_relaylog_events | 0 Com_show_slave_hosts | 0 Com_show_slave_status | 6 Com_show_status | 337719 Com_show_storage_engines | 9 Com_show_table_status | 0 Com_show_tables | 11 Com_show_triggers | 634 Com_show_variables | 221 Com_show_warnings | 0 Com_show_create_user | 0 Com_shutdown | 0 Com_slave_start | 0 Com_slave_stop | 0 Com_group_replication_start | 0 Com_group_replication_stop | 0 Com_stmt_execute | 2 Com_stmt_close | 2 Com_stmt_fetch | 0 Com_stmt_prepare | 2 Com_stmt_reset | 0 Com_stmt_send_long_data | 0 Com_truncate | 0 Com_uninstall_plugin | 0 Com_unlock_tables | 0 Com_update | 3160289 Com_update_multi | 0 Com_xa_commit | 0 Com_xa_end | 0 Com_xa_prepare | 0 Com_xa_recover | 0 Com_xa_rollback | 0 Com_xa_start | 0 Com_stmt_reprepare | 0 Compression | OFF Connection_errors_accept | 0 Connection_errors_internal | 0 Connection_errors_max_connections | 94 Connection_errors_peer_address | 0 Connection_errors_select | 0 Connection_errors_tcpwrap | 0 Connections | 412961 Created_tmp_disk_tables | 34412942 Created_tmp_files | 53367 Created_tmp_tables | 71692427 Delayed_errors | 0 Delayed_insert_threads | 0 Delayed_writes | 0 Flush_commands | 1 Handler_commit | 315946909 Handler_delete | 5540520 Handler_discover | 0 Handler_external_lock | 688867588 Handler_mrr_init | 0 Handler_prepare | 0 Handler_read_first | 34976935 Handler_read_key | 2188865194 Handler_read_last | 17485 Handler_read_next | 54290082542 Handler_read_prev | 19085786 Handler_read_rnd | 1186807611 Handler_read_rnd_next | 2955796362 Handler_rollback | 148 Handler_savepoint | 0 Handler_savepoint_rollback | 0 Handler_update | 428611514 Handler_write | 646923649 Innodb_buffer_pool_dump_status | Dumping of buffer pool not started Innodb_buffer_pool_load_status | Buffer pool(s) load completed at 181219 19:56:57 Innodb_buffer_pool_resize_status | Innodb_buffer_pool_pages_data | 966720 Innodb_buffer_pool_bytes_data | 2953838592 Innodb_buffer_pool_pages_dirty | 0 Innodb_buffer_pool_bytes_dirty | 0 Innodb_buffer_pool_pages_flushed | 5329236 Innodb_buffer_pool_pages_free | 8197 Innodb_buffer_pool_pages_misc | 73659 Innodb_buffer_pool_pages_total | 1048576 Innodb_buffer_pool_read_ahead_rnd | 0 Innodb_buffer_pool_read_ahead | 34382 Innodb_buffer_pool_read_ahead_evicted | 0 Innodb_buffer_pool_read_requests | 3904592079 Innodb_buffer_pool_reads | 747465 Innodb_buffer_pool_wait_free | 0 Innodb_buffer_pool_write_requests | 1045142981 Innodb_data_fsyncs | 1695449 Innodb_data_pending_fsyncs | 0 Innodb_data_pending_reads | 0 Innodb_data_pending_writes | 0 Innodb_data_read | 644895232 Innodb_data_reads | 1088377 Innodb_data_writes | 14566224 Innodb_data_written | 3881918464 Innodb_dblwr_pages_written | 4497979 Innodb_dblwr_writes | 398532 Innodb_log_waits | 0 Innodb_log_write_requests | 22692404 Innodb_log_writes | 8771102 Innodb_os_log_fsyncs | 322535 Innodb_os_log_pending_fsyncs | 0 Innodb_os_log_pending_writes | 0 Innodb_os_log_written | 18935997952 Innodb_page_size | 16384 Innodb_pages_created | 134590 Innodb_pages_read | 1087932 Innodb_pages_written | 5329236 Innodb_row_lock_current_waits | 0 Innodb_row_lock_time | 3466511 Innodb_row_lock_time_avg | 35015 Innodb_row_lock_time_max | 51754 Innodb_row_lock_waits | 99 Innodb_rows_deleted | 5540520 Innodb_rows_inserted | 564189585 Innodb_rows_read | 2017392003 Innodb_rows_updated | 3601631 Innodb_num_open_files | 300 Innodb_truncated_status_writes | 0 Innodb_available_undo_logs | 128 Key_blocks_not_flushed | 0 Key_blocks_unused | 6698 Key_blocks_used | 4 Key_read_requests | 124 Key_reads | 29 Key_write_requests | 0 Key_writes | 0 Last_query_cost | 0 Last_query_partial_plans | 0 Locked_connects | 0 Max_execution_time_exceeded | 0 Max_execution_time_set | 0 Max_execution_time_set_failed | 0 Max_used_connections | 701 Max_used_connections_time | 12/19/2018 23:27 Not_flushed_delayed_rows | 0 Ongoing_anonymous_transaction_count | 0 Open_files | 1 Open_streams | 0 Open_table_definitions | 876 Open_tables | 2000 Opened_files | 57710 Opened_table_definitions | 876 Opened_tables | 24810492 Performance_schema_accounts_lost | 0 Performance_schema_cond_classes_lost | 0 Performance_schema_cond_instances_lost | 0 Performance_schema_digest_lost | 0 Performance_schema_file_classes_lost | 0 Performance_schema_file_handles_lost | 0 Performance_schema_file_instances_lost | 0 Performance_schema_hosts_lost | 0 Performance_schema_index_stat_lost | 0 Performance_schema_locker_lost | 0 Performance_schema_memory_classes_lost | 0 Performance_schema_metadata_lock_lost | 0 Performance_schema_mutex_classes_lost | 0 Performance_schema_mutex_instances_lost | 0 Performance_schema_nested_statement_lost | 0 Performance_schema_prepared_statements_lost | 0 Performance_schema_program_lost | 0 Performance_schema_rwlock_classes_lost | 0 Performance_schema_rwlock_instances_lost | 0 Performance_schema_session_connect_attrs_lost | 0 Performance_schema_socket_classes_lost | 0 Performance_schema_socket_instances_lost | 0 Performance_schema_stage_classes_lost | 0 Performance_schema_statement_classes_lost | 0 Performance_schema_table_handles_lost | 0 Performance_schema_table_instances_lost | 0 Performance_schema_table_lock_stat_lost | 0 Performance_schema_thread_classes_lost | 0 Performance_schema_thread_instances_lost | 0 Performance_schema_users_lost | 0 Prepared_stmt_count | 0 Qcache_free_blocks | 0 Qcache_free_memory | 0 Qcache_hits | 0 Qcache_inserts | 0 Qcache_lowmem_prunes | 0 Qcache_not_cached | 0 Qcache_queries_in_cache | 0 Qcache_total_blocks | 0 Queries | 386369511 Questions | 386351756 Select_full_join | 8242 Select_full_range_join | 97092 Select_range | 57964836 Select_range_check | 4 Select_scan | 69826287 Slave_heartbeat_period | 0 Slave_last_heartbeat | Slave_open_temp_tables | 0 Slave_received_heartbeats | 0 Slave_retried_transactions | 0 Slave_running | OFF Slow_launch_threads | 0 Slow_queries | 44 Sort_merge_passes | 34863 Sort_range | 1764316 Sort_rows | 299335094 Sort_scan | 2888984 Ssl_accept_renegotiates | 0 Ssl_accepts | 0 Ssl_callback_cache_hits | 0 Ssl_cipher | Ssl_cipher_list | Ssl_client_connects | 0 Ssl_connect_renegotiates | 0 Ssl_ctx_verify_depth | 0 Ssl_ctx_verify_mode | 0 Ssl_default_timeout | 0 Ssl_finished_accepts | 0 Ssl_finished_connects | 0 Ssl_server_not_after | Ssl_server_not_before | Ssl_session_cache_hits | 0 Ssl_session_cache_misses | 0 Ssl_session_cache_mode | NONE Ssl_session_cache_overflows | 0 Ssl_session_cache_size | 0 Ssl_session_cache_timeouts | 0 Ssl_sessions_reused | 0 Ssl_used_session_cache_entries | 0 Ssl_verify_depth | 0 Ssl_verify_mode | 0 Ssl_version | Table_locks_immediate | 67608 Table_locks_waited | 0 Table_open_cache_hits | 386002409 Table_open_cache_misses | 24810492 Table_open_cache_overflows | 24808485 Tc_log_max_pages_used | 0 Tc_log_page_size | 0 Tc_log_page_waits | 0 Threads_cached | 8 Threads_connected | 10 Threads_created | 1388 Threads_running | 1 Uptime | 1018391 Uptime_since_flush_status | 1018391 I'm somewhat at a loss as to what's happening. Any advice would be very useful!

I support an ERP system named Epicor Prophet 21 at a mid-sized company. Every few months we experience a system outage and it is due to SQL Server no longer accepting connections. The connection attempts all time out. The Windows Server host CPU, RAM, Network levels all look quite normal. We have found that the only way to resolve this is to reboot the Windows Server host. We're running Microsoft SQL Server 2019 (RTM-CU30) (KB5049235) - 15.0.4415.2 (X64). It is hosted in a VMWare environment. VMWare Admins insist that there is nothing wrong in the hypervisor and I believe that is the case. Before rebooting, I reviewed logs in the Windows Event Viewer. There are hundreds of instances of, "A time out occurred while waiting to optimize the query. Rerun the query." What can I investigate within the SQL engine to learn more about what causes this condition that leaves the SQL engine unable to accept new connections? My first thought is that we must be exceeding the number of max connections and the only way I can think of for that to happen is if connections are created and never destroyed.

MySQL 5.1.x | Windows Server 2003 Can someone please clarify why max_connections in my.ini is much larger than the manual value I specify in the Concurrent Connections Dialogue ? For example, if I set concurrent connections to 800 in the dialogue window, I see max_connections=1023 in my.ini. Why? Is this normal?

We have an AWS RDS PostgreSQL (v14.10) instance running on a db.t3.micro instance. Randomly throughout the day (some days more than others), our .NET Core application starts failing with the following exceptions: An exception occurred while iterating over the results of a query for context type 'App.Server.Database.DbContext'. System.InvalidOperationException: An exception has been raised that is likely due to a transient failure. ---> Npgsql.PostgresException (0x80004005): 53300: sorry, too many clients already System.InvalidOperationException: An exception has been raised that is likely due to a transient failure. ---> Npgsql.NpgsqlException (0x80004005): Exception while reading from stream ---> System.TimeoutException: Timeout during reading attempt We haven't been able to track down the root cause yet, thinking we have an application side connection leak somewhere, but that hasn't yielded any results. With the t3.micro instance type, our max_connections is set to 81 (using this query select * from pg_settings where name='max_connections';), but we never see the DatabaseConnection metric in RDS monitoring get above 25-30. See the following screenshot of our metrics. We started throwing these errors just after 12:30 (see red arrow on right) Has anyone see this issue before, or is there something else I should be looking into? Can anyone explain why the DatabaseConnections metric shows a count much lower than our max?

I have seeing a strange behaviour with PostgreSQL13 pg_settings system view. I tried updating max_connections using SET command and left without a restart. But if I query from the same session or any new session the pending_restart column in pg_settings is not showing true for this parameter. However if I issue a statement like I attached in the screenshot then pending_restart column shows correctly as `true. What's this behaviour related to?

So I have read this a few times about these two metrics: ConnectionAttempts and DatabaseConnections. Based on the above, is RDS rejecting lots of connections? Here are the graphs of these two metrics. Or perhaps I have miss-understood? The max-connections parameter is set to 1609 for each instance.

For the last two days one of our query causing parallel workers related errors as below, 2024-01-04 13:58:45.988 CST,"user_a","testdb",108428,"10.0.0.1:46480",6596490c.1a78c,150,"SELECT",2024-01-04 13:58:36 CST,398/8937486,0,ERROR,53300,"remaining connection slots are reserved for non-replication superuser connections",,,,,"parallel worker","SELECT count(*) AS ""count"" FROM ""view_a"" AS ""vi_a"" WHERE ""vi_a"".""status"" = 1 AND ""vi_a"".""id"" IN (select ab_id from tab1 where status=2 group by ab_id);",,,"","client backend" 2024-01-04 13:58:45.989 CST,,,108647,,65964915.1a867,1,,2024-01-04 13:58:45 CST,,0,ERROR,55000,"could not map dynamic shared memory segment",,,,,,,,,"","parallel worker" 2024-01-04 13:58:45.990 CST,,,88206,,62b0ea26.1588e,17270,,2022-06-21 05:44:06 CST,,0,LOG,00000,"background worker ""parallel worker"" (PID 108646) exited with exit code 1",,,,,,,,,"","postmaster" SELECT count(*) AS "count" FROM "view_a" AS "vi_a" WHERE "vi_a"."status" = 1 AND "vi_a"."id" IN (select ab_id from tab1 where status=2 group by ab_id) I have checked the execution plan of this query but only take 180-200ms with two parallel workers. I have tried the same query by disabling parallelism still the same execution time. Can it be something wrong with the query? OR Is this something related to max_parallel_workers as it running out of parallel workers?

I am using PostgreSQL 9.5 and we have max_connections set to 200 in our postgresql.conf file. We have 2 apps server running java apps which are load balanced. When we run our tests via JMETER, I run pg_stat_activity and I can see there is a lot of IDLE connections with most of the queries called COMMIT. ### Questions 1. Do I need to be concerned with the IDLE connections and will this affect any new tests I run? 2. Could this be an issue with my Java apps not auto_committing? My assumption is that the connections will be re-used, but I am concerned if we run more tests that new connections will spin up and the max_connections of **200** will be hit.

I have a client who's insisting in a SaaS application to have one table for all users, and then for each user to have a separate database on which we perform CRUD operations based on an authentication token that contains permission only for that database. This will be done with python using psycopg2, from what I've read is that PostgreSQL has a max_connections option and this would mean that at one point in future we're going to reach a bottleneck and will no longer be able to serve our application for an x simultaneous number of clients. What other arguments can I provide to make my client change his mind and avoid such mistake that might cost him too much as he's also had some amount of app development experience?

The question was asked previously, "how do I calculate MySQL max_connections" and this was the answer: > max_connections = (Available RAM - Global Buffers) / Thread Buffers Since I don't have enough reputation to add a comment to the existing question I had to ask a brand new question. I can get the buffer values by executing : SHOW VARIABLES LIKE '%buffer%'; but what is the available RAM part of this equation exactly? Is this value in bytes, kilobytes, megabytes? Something else? Also, do I use the available RAM shown in the resource monitor while my site is being used, or do I need to use the total amount of RAM installed on the machine?

On Db2 v11.5.8.0 Linux x86_64 database every few months some application opens up a lot of connections and it free them up pretty quickly like in 10 mins. I assume it has to be fat client application from Windows, because for WAS applications number of connections are restricted at application server level. Checking high water mark I get: db2 get snapshot for dbm | grep "High water mark for agents registered" > High water mark for agents registered = 4296 What is the best way to limit number of connections by (unknown) IP address? For example I want to restrict maximum number of connection from particular IP address to 100 connections. Bear in mind that I don't know the IP address, it can be any.

From time to time, I'm getting an error "

(): (HY000/1203): User already has more than 'max_user_connections' active connections.

" I checked the MySQL max_connection variable, and it's at 150. What's odd is that when I check for Max_used_connections, it says 41, which (I think) implies that MySql never reached 150 simultaneous connections. The per-user Max_user_connections variable is 0, so it should effectively be the same as max_connections. Am I misunderstanding what these variables mean, or is something odd going on with MySql? I use PHP to connect to MySql. The MySql version is 5.7.40 Here are the results of

status like '%connec%';

and

variables like '%connections%';

+-----------------------------------------------+---------------------+
| Variable_name                                 | Value               |
+-----------------------------------------------+---------------------+
| Aborted_connects                              | 776                 |
| Connection_errors_accept                      | 0                   |
| Connection_errors_internal                    | 0                   |
| Connection_errors_max_connections             | 0                   |
| Connection_errors_peer_address                | 0                   |
| Connection_errors_select                      | 0                   |
| Connection_errors_tcpwrap                     | 0                   |
| Connections                                   | 8899838             |
| Locked_connects                               | 0                   |
| Max_used_connections                          | 41                  |
| Max_used_connections_time                     | 2022-10-25 13:57:07 |
| Performance_schema_session_connect_attrs_lost | 0                   |
| Ssl_client_connects                           | 0                   |
| Ssl_connect_renegotiates                      | 0                   |
| Ssl_finished_connects                         | 0                   |
| Threads_connected                             | 1                   |
+-----------------------------------------------+---------------------+

+----------------------+------------+
| Variable_name        | Value      |
+----------------------+------------+
| max_connections      | 150        |
| max_user_connections | 2147483647 |
+----------------------+------------+

Also, I doubt I'm using up all connections by serving web pages; I'm not doing complicated queries, and the data sets are relatively small. Can someone point me to how to find what process/user maxes out these resources?

We are using Oracle Cloud's Ampere A1 instance consisting of 4 OCPUs (equivalent to 4 vCPUs) and 24GB of usable memory on Oracle Linux 7.9. On the server is running an java game server and a web server, both are used with MySQL 5.x. With the game server written in Java, we are using proxool , targeting up to 250 concurrent users. And with web server (currently using Apache) can be up to 1000 concurrent users. If based on the formula : connections = ((core_count * 2) + effective_spindle_count) But the boot volume that the instance uses is now no longer HDD, so the value of the parameter effective_spindle_count is still a mystery on SSD. So with the properties maximum-connection-count , minimum-connection-count , simultaneous-build-throttle , prototype-count which formula should be used? And what is the recommended value of these properties? This is the current my.cnf configuration. Based on the above information and current configuration files, what is the calculation formula and the recommended value for the max_connections system variable?

I've run into the following problem. From time to time, my app receives remaining connection slots are reserved for non-replication superuser connections from postgres. It lasts for quite noticeable periods of time, from several seconds to couple of minutes. I've checked pg_stat_activity at this very period, and it showed about five application backend connections, several pgAdmin connections, and some postgres-specific processes like replication, autovaccuum, wal-writing, etc -- about 20 processes in total, nothing peculiar. Then I checked SHOW max_connections; -- it was still 200. I've no pooling, nothing except just postgres and a backend application. How come?

In mariaDB, is it possible to do something like this? - limit the number of connections (like in mysql, as explained in this SO answer ) - set up a queue for all the other connection attempts, and avoid triggering User ** already has more than 'max_user_connections' active connections If something like this is possible, is it even **advisable** to set things up in this way? Real case scenario is that something is causing one of our servers to clog up, with mariaDB taking up as much as 80% of CPU and about the same percentage of RAM. SHOW FULL PROCESSLIST returns a ridiculous amount of connections from one user (+50), while the other users have 3-5 simultaneous connections. If the offending user is temporarily blocked, everything returns to normal.

As per https://devcenter.heroku.com/articles/heroku-postgres-legacy-plans the connection limit is 500 As per https://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server "Generally, PostgreSQL on good hardware can support a few hundred connections" What are the determining factors in this limit? #CPU cores? RAM? OS?

I am using MySQLi for my webapp but whenever I want to visit some particular page, I get mysqli_connect() [function.mysqli-connect]: (42000/1203): User ***_user already has more than 'max_user_connections' active connections. I tried already to close all connections but this does not improve the situation. Is there a way to know exactly what connections are open at any particular moment or any other useful data that can help me resolve this issue ? BTW, I'm using PHP 5.2.17 and MySQL 5.1.

I am suddenly getting this error when either trying to access the website that uses the postgresql database, or even when using the psql utility or pgadmin3. My database is set to handle 150 maximum connections: # SHOW max_connections; max_connections ----------------- 150 (1 row) After rebooting the ubuntu server which my website is on (which is really the only thing using connections), I see the current amount of connections is 140: # select count(*) from pg_stat_activity; count ------- 140 (1 row) I don't understand how suddenly so many connections after rebooting my server. So I check the postgresql activity: # SELECT * FROM pg_stat_activity; And I see over a 100 columns with the same exact query that looks like this: SELECT "reports".* FROM "reports" WHERE (("reports"."time" | f | | 2014-06-29 00:05:06.735249-04 | 2014-06-27 16:34:39.307312-04 | 192.111.11.111 | 52759 464875 | mydb | 5054 | 16387 | myuser | SELECT "reports".* FROM "reports" WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1 | f | 2014-06-28 22:46:59.52573-04 | 2014-06-28 22:46:59.52573-04 | 2014-06-28 22:46:52.285867-04 | 192.111.11.111 | 37371 464875 | mydb | 5055 | 16387 | myuser | SELECT "reports".* FROM "reports" WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1 | f | 2014-06-28 22:46:59.530804-04 | 2014-06-28 22:46:59.530804-04 | 2014-06-28 22:46:52.303562-04 | 192.111.11.111 | 37372 464875 | mydb | 5056 | 16387 | myuser | SELECT "reports".* FROM "reports" WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1 | f | 2014-06-28 22:46:59.572198-04 | 2014-06-28 22:46:59.572198-04 | 2014-06-28 22:46:52.31447-04 | 192.111.11.111 | 37373 464875 | mydb | 5057 | 16387 | myuser | SELECT "reports".* FROM "reports" WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1 | f | 2014-06-28 22:46:59.872037-04 | 2014-06-28 22:46:59.872037-04 | 2014-06-28 22:46:52.323721-04 | 192.111.11.111 | 37374 464875 | mydb | 5058 | 16387 | myuser | SELECT "reports".* FROM "reports" WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1 | f | 2014-06-28 22:46:59.961803-04 | 2014-06-28 22:46:59.961803-04 | 2014-06-28 22:46:52.334238-04 | 192.111.11.111 | 37375 464875 | mydb | 5059 | 16387 | myuser | SELECT "reports".* FROM "reports" WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1 | f | 2014-06-28 22:46:59.53713-04 | 2014-06-28 22:46:59.53713-04 | 2014-06-28 22:46:52.347227-04 | 192.111.11.111 | 37376 464875 | mydb | 5060 | 16387 | myuser | SELECT "reports".* FROM "reports" WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1 | f | 2014-06-28 22:47:00.208948-04 | 2014-06-28 22:47:00.208948-04 | 2014-06-28 22:46:52.360008-04 | 192.111.11.111 | 37377 464875 | mydb | 5061 | 16387 | myuser | SELECT "reports".* FROM "reports" WHERE (("reports"."time" < '2014-06-28 13:30:42.000000' AND "reports"."unit_id" = 3192)) ORDER BY "reports"."id" DESC LIMIT 1 | f | 2014-06-28 22:46:59.938983-04 | 2014-06-28 22:46:59.938983-04 | 2014-06-28 22:46:52.369496-04 | 192.111.11.111 | 37378

In SQL Server 2012 Standard edition, I know that the max number of user connections is 32,767. What should I do as a DBA if I am heading towards this number? Currently there are 30,000 user connections, and this number is expected to increase.

I have this set in the mysql config file, rebooted, seems to be correct. SHOW VARIABLES LIKE "max_connections"; +-----------------+-------+ | Variable_name | Value | +-----------------+-------+ | max_connections | 500 | +-----------------+-------+ I have a load test against my server. This never get's above 151, server just gets real slow until the testing is done. mysql> SHOW STATUS LIKE 'max_used_connections'; +----------------------+-------+ | Variable_name | Value | +----------------------+-------+ | Max_used_connections | 151 | +----------------------+-------+ I have already put in every config option that supposedly will fix this. Will Max_used_connections ever go above 151? ubuntu 16 mysql Ver 14.14 Distrib 5.7.33, for Linux (x86_64) using EditLine wrapper been dinking around with this all day, thanks for any advice.