连接数

一、正常情况下的服务演化之路 让我们从最初开始。 单体应用 每个创业公司基本都是从类似SSM和SSH这种架构起来的，没什么好讲的，基本每个程序员都经历过。 RPC应用 当业务越来越大，我们需要对服务进行水平扩容，扩容很简单，只要保证服务是无状态的就可以了。 当业务又越来越大，我们的服务关系错综复杂，同时，有很多服务访问都是不需要连接DB的，只需要连接缓存即可，那么就可以做成分离的，减少DB宝贵的连接。 我相信大部分公司都是在这个阶段。Dubbo就是为了解决这个问题而生的。 分库分表 如果你的公司产品很受欢迎，业务继续高速发展，数据越来越多，SQL操作越来越慢，那么数据库就会成为瓶颈，那么你肯定会想到分库分表，不论通过ID hash或者range的方式都可以。 这下应该没问题了吧。任凭你用户再多，并发再高，我只要无限扩容数据库，无限扩容应用，就可以了。 这也是本文的标题，分库分表就能解决无限扩容吗？ 实际上，像上面的架构，并不能解决。 其实，这个问题和RPC的问题有点类似：数据库连接过多！ 通常，我们的RPC应用由于是使用中间件进行访问数据库，应用实际上是不知道到底要访问哪个数据库的，访问数据库的规则由中间件决定，例如Sharding JDBC。 这就导致，这个应用必须和所有的数据库连接，就像我们上面的架构图一样，一个RPC应用需要和3个MySQL连接，如果是30个RPC应用

一、正常情况下的服务演化之路 让我们从最初开始。 单体应用 每个创业公司基本都是从类似SSM和SSH这种架构起来的，没什么好讲的，基本每个程序员都经历过。 RPC应用 当业务越来越大，我们需要对服务进行水平扩容，扩容很简单，只要保证服务是无状态的就可以了。 当业务又越来越大，我们的服务关系错综复杂，同时，有很多服务访问都是不需要连接DB的，只需要连接缓存即可，那么就可以做成分离的，减少DB宝贵的连接。 我相信大部分公司都是在这个阶段。Dubbo就是为了解决这个问题而生的。 分库分表 如果你的公司产品很受欢迎，业务继续高速发展，数据越来越多，SQL操作越来越慢，那么数据库就会成为瓶颈，那么你肯定会想到分库分表，不论通过ID hash或者range的方式都可以。 这下应该没问题了吧。任凭你用户再多，并发再高，我只要无限扩容数据库，无限扩容应用，就可以了。 这也是本文的标题，分库分表就能解决无限扩容吗？ 实际上，像上面的架构，并不能解决。 其实，这个问题和RPC的问题有点类似：数据库连接过多！ 通常，我们的RPC应用由于是使用中间件进行访问数据库，应用实际上是不知道到底要访问哪个数据库的，访问数据库的规则由中间件决定，例如Sharding JDBC。 这就导致，这个应用必须和所有的数据库连接，就像我们上面的架构图一样，一个RPC应用需要和3个MySQL连接，如果是30个RPC应用

刚开始工作的菜鸟，总会有各种疑问，刚开始是对 JDK API 的疑问，对 NIO 的疑问，对 JVM 的疑问，当工作几年后，对服务的可用性，可扩展性也有了新的疑问，什么疑问呢？其实是老生常谈的话题：服务的扩容问题。 正常情况下的服务演化之路 让我们从最初开始。 1、单体应用 每个创业公司基本都是从类似 SSM 和 SSH 这种架构起来的，没什么好讲的，基本每个程序员都经历过。 2、RPC 应用 当业务越来越大，我们需要对服务进行水平扩容，扩容很简单，只要保证服务是无状态的就可以了，如下图： 当业务又越来越大，我们的服务关系错综复杂，同时，有很多服务访问都是不需要连接 DB 的，只需要连接缓存即可，那么就可以做成分离的，减少 DB 宝贵的连接。如下图： 我相信大部分公司都是在这个阶段。Dubbo 就是为了解决这个问题而生的。 3、分库分表 如果你的公司产品很受欢迎，业务继续高速发展，数据越来越多，SQL 操作越来越慢，那么数据库就会成为瓶颈，那么你肯定会想到分库分表，不论通过 ID hash 或者 range 的方式都可以。如下图： 这下应该没问题了吧。任凭你用户再多，并发再高，我只要无限扩容数据库，无限扩容应用，就可以了。 这也是本文的标题，分库分表就能解决无限扩容吗？ 实际上，像上面的架构，并不能解决。 其实，这个问题和 RPC 的问题有点类似：数据库连接过多！！！ 通常，我们的

前言 像我这样的菜鸟，总会有各种疑问，刚开始是对 JDK API 的疑问，对 NIO 的疑问，对 JVM 的疑问，当工作几年后，对服务的可用性，可扩展性也有了新的疑问，什么疑问呢？其实是老生常谈的话题：服务的扩容问题。 正常情况下的服务演化之路 让我们从最初开始。 单体应用 每个创业公司基本都是从类似 SSM 和 SSH 这种架构起来的，没什么好讲的，基本每个程序员都经历过。 RPC 应用 当业务越来越大，我们需要对服务进行水平扩容，扩容很简单，只要保证服务是无状态的就可以了，如下图： 当业务又越来越大，我们的服务关系错综复杂，同时，有很多服务访问都是不需要连接 DB 的，只需要连接缓存即可，那么就可以做成分离的，减少 DB 宝贵的连接。如下图： 我相信大部分公司都是在这个阶段。Dubbo 就是为了解决这个问题而生的。 分库分表 如果你的公司产品很受欢迎，业务继续高速发展，数据越来越多，SQL 操作越来越慢，那么数据库就会成为瓶颈，那么你肯定会想到分库分表，不论通过 ID hash 或者 range 的方式都可以。如下图： 这下应该没问题了吧。任凭你用户再多，并发再高，我只要无限扩容数据库，无限扩容应用，就可以了。 这也是本文的标题，分库分表就能解决无限扩容吗？ 实际上，像上面的架构，并不能解决。 其实，这个问题和 RPC 的问题有点类似：数据库连接过多！！！ 通常，我们的 RPC

一、 文件数限制修改 1、用户级别 查看Linux系统用户最大打开文件限制： ulimit -n 1024 (1) vi /etc/security/limits.conf mysql soft nofile 10240 mysql hard nofile 10240 其中mysql指定了要修改哪个用户的打开文件数限制。 可用'*'号表示修改所有用户的限制；soft或hard指定要修改软限制还是硬限制；10240则指定了想要修改的新的限制值，即最大打开文件数(请注意软限制值要小于或等于硬限制)。 (2) vi /etc/pam.d/login session required /lib/security/pam_limits.so 这是告诉Linux在用户完成系统登录后，应该调用pam_limits.so模块来设置系统对该用户可使用的各种资源数量的最大限制(包括用户可打开的最大文件数限制)。 而pam_limits.so模块就会从/etc/security/limits.conf文件中读取配置来设置这些限制值。 2、Linux系统级别 查看Linux系统对同时打开文件数的硬限制： sysctl -a|grep file-max fs.file-max = 65535 这表明这台Linux系统最多允许同时打开(即包含所有用户打开文件数总和)65535个文件，是Linux系统级硬限制

目录 一 问题描述 二 问题分析 三 问题解决 四 问题扩展 4.1 time wait 连接过高有什么影响？ 4.2 如何减少 time wait 连接数？ 一 问题描述 工作中的一台数据库打印如下日志： 二 问题分析 查看当时 TCP 连接数状态： netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}' 从图中可以看到 time wait 数据是20143，而机器配置是： 得出结论：处于 time wait 状态的 TCP 套接字，超过 net.ipv4.tcp_max_tw_buckets 限制。 三 问题解决 适当加大 net.ipv4.tcp_max_tw_buckets 参数值。 四 问题扩展 4.1 time wait 连接过高有什么影响？ 处于 time wait 状态的连接过高时会占用大量连接，可能导致无法创建新的连接，进而影响系统的负载能力。这时需要调整参数，以尽快地释放TIME_WAIT。 4.2 如何减少 time wait 连接数？ 一般 TCP 相关的内核参数都在 /etc/sysct1.conf 文件中。为了能够尽快释放 TIME_WAIT 状态的连接，可以做以下配置。 net.ipv4.tcp_syncookies=1 ，表示开启 SYN Cookies。当出现 SYN

临时设置（重启mysql后失效）show variables like 'max_connections';(查可以看当前的最大连接数) set global max_connections=1000;(设置最大连接数为1000，可以再次show查看是否设置成功)永久设置：修改mysql配置文件my.ini 或 my.cnf的参数max_connections文件位置：　　windows：一般在C:/ProgramData/MySQL/MySQL Server.../ 下　　Linux:我得是在/etc/mysql/my.cnf　　　　　　如果找不到可以使用命令查找：find / -name my.cnf添加下面的属性： max_connections = 1000重启mysql生效，再使用show命令查看https://promotion.aliyun.com/ntms/yunparter/invite.html?userCode=f5v2mcse 来源： https://www.cnblogs.com/mangolw/p/11398804.html

查看连接数变化 CPU利用率到达100%，首先怀疑，是不是业务高峰活跃连接陡增，而数据库预留的资源不足造成的结果。我们需要查看下，问题发生时，活跃的连接数是否比平时多很多。对于RDS for PG，数据库上的连接数变化，可以从控制台的监控信息中看到。而当前活跃的连接数>可以直接连接数据库，使用下列查询语句得到： select count( * ) from pg_stat_activity where state not like '%idle'; 追踪慢SQL 如果活跃连接数的变化处于正常范围，则很大概率可能是当时有性能很差的SQL被大量执行导致。由于RDS有慢SQL日志，我们可以通过这个日志，定位到当时比较耗时的SQL来进一步做分析。但通常问题发生时，整个系统都处于停滞状态，所有SQL都慢下来，当时记录的>慢SQL可能非常多，并不容易排查罪魁祸首。这里我们介绍几种在问题发生时，即介入追查慢SQL的方法。 1、第一种方法是使用pg_stat_statements插件定位慢SQL，步骤如下。 1.1 如果没有创建这个插件，需要手动创建。我们要利用插件和数据库系统里面的计数信息（如SQL执行时间累积等），而这些信息是不断累积的，包含了历史信息。为了更方便的排查当前的CPU满问题，我们要先重置计数器。 create extension pg_stat_statements;

不用数据库连接池的写法： import MySQLdb conn= MySQLdb.connect(host='localhost',user='root',passwd='pwd',db='myDB',port=3306) cur=conn.cursor() SQL="select * from table1" r=cur.execute(SQL) r=cur.fetchall() cur.close() conn.close() 使用 PooledDB from DBUtils.PooledDB import PooledDB import pymysql import xlwt import os import threading import zipfile class CreateExcel(object): """ 查询数据库，并生成excel 文档 """ def __init__(self, mysql_info): self.mysql_info = mysql_info self.pool = PooledDB(pymysql, 5, host=self.mysql_info['host'], user=self.mysql_info['user'], password=self.mysql_info['password'], db=self.mysql

1、 SSH到oracle数据库服务器 2、 通过命令：sqlplus / as sysdba登录到oracle命令管理界面 3、 查看processes和sessions参数 SQL> show parameter processes NAME TYPE VALUE db_writer_processes integer 1 gcs_server_processes integer 0 job_queue_processes integer 10 log_archive_max_processes integer 2 processes integer 50 SQL> show parameter sessions NAME TYPE VALUE license_max_sessions integer 0 license_sessions_warning integer 0 logmnr_max_persistent_sessions integer 1 sessions integer 60 shared_server_sessions integer 4、 修改processes和sessions值 SQL> alter system set processes=300 scope=spfile;　　 SQL> alter system set sessions=335