精华内容
下载资源
问答
  • 系统设计目标(3):池化技术:如何减少频繁创建数据库连接的性能损耗?用连接池预先建立数据库连接用线程池预先创建线程总结 假设公司的领导,把我们叫到会议室,告诉我们公司有一个新的商业机会,希望我们可以迅速...

    池化技术:如何减少频繁创建数据库连接的性能损耗?

    假设公司的领导,把我们叫到会议室,告诉我们公司有一个新的商业机会,希望我们可以迅速研发出一套面向某个垂直领域的电商系统。

    在人手紧张,时间不足的情况下,为了能够完成任务,我们毫不犹豫地采用了最简单的架构:前端一台 Web 服务器运行业务代码,后端一台数据库服务器存储业务数据。

    在这里插入图片描述
    这个架构图是我们每个人最熟悉的,最简单的架构原型,很多系统在一开始都是长这样的,只是随着业务复杂度的提高,架构做了叠加,然后看起来就越来越复杂了。

    再说回我们的垂直电商系统,系统一开始上线之后,虽然用户量不大,但运行平稳,我们很有成就感,不过领导觉得用户量太少了,所以紧急调动运营同学做了一次全网的流量推广。

    这一推广很快带来了一大波流量,但这时,系统的访问速度开始变慢

    分析程序的日志之后,我们发现系统慢的原因出现在和数据库的交互上。因为我们数据库的调用方式是先获取数据库的连接,然后依靠这条连接从数据库中查询数据,最后关闭连接释放数据库资源。这种调用方式下,每次执行 SQL 都需要重新建立连接,所以我们怀疑,是不是频繁地建立数据库连接耗费时间长导致了访问慢的问题。

    通过 “tcpdump -i eth0 -nn -tttt port 3306” 命令抓取了MySQL建立连接的网络包来做分析,从抓包结果来看,整个MySQL的连接过程可以分为两部分:

    • 第一部分是前三个数据包。第一个数据包是客户端向服务端发送的一个“SYN”包,第二个包是服务端回给客户端的“ACK”包以及一个“SYN”包,第三个包是客户端回给服务端 的“ACK”包,熟悉 TCP 协议的同学可以看出这是一个 TCP 的三次握手过程。
    • 第二部分是 MySQL 服务端校验客户端密码的过程。其中第一个包是服务端发给客户端要 求认证的报文,第二和第三个包是客户端将加密后的密码发送给服务端的包,最后两个包是 服务端回给客户端认证 OK 的报文。
      在这里插入图片描述
      那么单条 SQL 执行时间是多少呢?我们统计了一段时间的 SQL 执行时间,发现 SQL 的平均执行时间大概是 1ms,也就是说相比于 SQL 的执行,MySQL 建立连接的过程是比较耗 时的。这在请求量小的时候其实影响不大,因为无论是建立连接还是执行 SQL,耗时都是毫秒级别的。可是请求量上来之后,如果按照原来的方式建立一次连接只执行一条 SQL 的话,1s 只能执行 200 次数据库的查询,而数据库建立连接的时间占了其中 4/5。

    那这时你要怎么做呢?一番谷歌搜索之后,我们发现解决方案也很简单,只要使用连接池将数据库连接预先建立好, 这样在使用的时候就不需要频繁地创建连接了。调整之后,发现 1s 就可以执行 1000 次 的数据库查询,查询性能大大的提升了。

    用连接池预先建立数据库连接

    其实,在开发过程中我们会用到很多的连接池,像是数据库连接池、HTTP 连接池、Redis 连接池等等。而连接池的管理是连接池设计的核心,就以数据库连接池为例,来说明一下连接池管理的关键点。

    数据库连接池有两个最重要的配置:最小连接数和最大连接数,它们控制着从连接池中获取连接的流程:

    • 如果当前连接数小于最小连接数,则创建新的连接处理数据库请求;
    • 如果连接池中有空闲连接则复用空闲连接;
    • 如果空闲池中没有连接并且当前连接数小于最大连接数,则创建新的连接处理请求;
    • 如果当前连接数已经大于等于最大连接数,则按照配置中设定的时间(C3P0 的连接池配置是 checkoutTimeout)等待旧的连接可用;
    • 如果等待超过了这个设定时间则向用户抛出错误;

    对于数据库连接池,一般在线上建议最小连接数控制在 10 左右,最大连接数控制在 20~30 左右即可。

    在这里,你需要注意池子中连接的维护问题。一般情况下,产生故障的原因可能有以下几种:

    1. 数据库的域名对应的 IP 发生了变更,池子的连接还是使用旧的 IP,当旧的 IP 下的数据库服务关闭后,再使用这个连接查询就会发生错误;
    2. MySQL 有个参数是“wait_timeout”,控制着当数据库连接闲置多长时间后,数据库会主动的关闭这条连接。这个机制对于数据库使用方是无感知的,所以当我们使用这个被关闭 的连接时就会发生错误。

    那么,怎么保证启动的数据库连接池一定是可用的呢?

    1. 启动一个线程来定期检测连接池中的连接是否可用,比如使用连接发送“select 1”的命令给数据库看是否会抛出异常,如果抛出异常则将这个连接从连接池中移除,并且尝试关闭。目前 C3P0 连接池可以采用这种方式来检测连接是否可用,也是比较推荐的方式。
    2. 在获取到连接之后,先校验连接是否可用,如果可用才会执行 SQL 语句。比如 DBCP 连接池的 testOnBorrow 配置项,就是控制是否开启这个验证。这种方式在获取连接时会引入多余的开销,在线上系统中还是尽量不要开启,在测试服务上可以使用。

    用线程池预先创建线程

    在JDK 1.5 中引入的 ThreadPoolExecutor 就是一种线程池的实现,它有两个重要的参数:coreThreadCount 和 maxThreadCount,这两个参数控制着线程池的执行过程。

    • 如果线程池中的线程数少于 coreThreadCount 时,处理新的任务时会创建新的线程;
    • 如果线程数大于 coreThreadCount 则把任务丢到一个队列里面,由当前空闲的线程执行;
    • 当队列中的任务堆积满了的时候,则继续创建线程,直到达到 maxThreadCount;
    • 当线程数达到 maxTheadCount 时还有新的任务提交,那么我们就不得不将它们丢弃了;

    在这里插入图片描述
    这个任务处理流程看似简单,实际上有很多坑,你在使用的时候一定要注意。

    首先, JDK 实现的这个线程池优先把任务放入队列暂存起来,而不是创建更多的线程,它比较适用于执行 CPU 密集型的任务,也就是需要执行大量 CPU 运算的任务。这是为什么呢?因为执行 CPU 密集型的任务时 CPU 比较繁忙,因此只需要创建和 CPU 核数相当的线程就好了,多了反而会造成线程上下文切换,降低任务执行效率。所以当当前线程数超过核 心线程数时,线程池不会增加线程,而是放在队列里等待核心线程空闲下来。

    但是,我们平时开发的 Web 系统通常都有大量的 IO 操作,例如说查询数据库、查询缓存等等。任务在执行 IO 操作的时候 CPU 就空闲了下来,这时如果增加执行任务的线程数而不是把任务暂存在队列中,就可以在单位时间内执行更多的任务,大大提高了任务执行的吞吐量。所以你看 Tomcat 使用的线程池就不是 JDK 原生的线程池,而是做了一些改造,当线程数超过 coreThreadCount 之后会优先创建线程,直到线程数到达 maxThreadCount,这样就比较适合于 Web 系统大量 IO 操作的场景了,你在实际运用过程中也可以参考借鉴。

    其次,线程池中使用的队列的堆积量也是我们需要监控的重要指标,对于实时性要求比较高的任务来说,这个指标尤为关键。

    最后,如果你使用线程池请一定记住不要使用无界队列(即没有设置固定大小的队列)。也许你会觉得使用了无界队列后,任务就永远不会被丢弃,只要任务对实时性要求不高,反正早晚有消费完的一天。但是,大量的任务堆积会占用大量的内存空间,一旦内存空间被占满 就会频繁地触发 Full GC,造成服务不可用。

    这是一种常见的软件设计思想,叫做池化技术,它的核心思想是空间换时间,期望使用预先创建好的对象来减少频繁创建对象的性能开销,同时还可以对对象进行统一的管理,降低了对象的使用的成本,总之是好处多多。

    不过,池化技术也存在一些缺陷,例如说存储池子中的对象肯定需要消耗多余的内存,如果对象没有被频繁使用,就会造成内存上的浪费。再比方说,池子中的对象需要在系统启动的时候就预先创建完成,这在一定程度上增加了系统启动时间。

    可这些缺陷相比池化技术的优势来说就比较微不足道了,只要我们确认要使用的对象在创建时确实比较耗时或者消耗资源,并且这些对象也确实会被频繁地创建和销毁,我们就可以使用池化技术来优化。

    总结

    其实,连接池和线程池我们并不陌生,不过可能对它们的原理和使用方式上还存在困惑或者误区。池化技术强调的重点是:

    • 池子的最大值和最小值的设置很重要,初期可以依据经验来设置,后面还是需要根据实际运行情况做调整。
    • 池子中的对象需要在使用之前预先初始化完成,这叫做池子的预热,比方说使用线程池时就需要预先初始化所有的核心线程。如果池子未经过预热可能会导致系统重启后产生比较多的慢请求。
    • 池化技术核心是一种空间换时间优化方法的实践,所以要关注空间占用情况,避免出现空间过度使用出现内存泄露或者频繁垃圾回收等问题。

    现在我们用池化技术解决了数据库连接复用的问题,这时,我们的垂直电商系统虽然整体架构上没有变化,但是和数据库交互的过程有了变化,在我们的 Web 工程和数据库之间增加了数据库连接池,减少了频繁创建连接的成本。现在的架构图如下所示:
    在这里插入图片描述

    展开全文
  • 如图:当我访问控制器,控制器调用mybatis的dao层时一直在建立连接下面是从数据库查询出已经建立的连接 ,居然有20002个这是调用的方法这是dao层 mybatis相关 ,只有两个简单的方法这是数据库连接信息这是我的...

    如图:当我访问控制器,控制器调用mybatis的dao层时一直在建立连接

    8b09f9a2b7e462b26b7def40cbf9d0ad.gif

    下面是从数据库查询出已经建立的连接 ,居然有20002个

    900ee9461bcc3bdabb4e369171ac33d5.png

    这是调用的方法

    caf55140bc56d3aa8005a23da7716c73.png

    这是dao层 mybatis相关 ,只有两个简单的方法

    68f34e9239a06865fa1a720daec5a219.png

    这是数据库连接信息

    b02a47d25dde4d9e8525cd94c3ba6e5a.png

    这是我的applicationContext.xml配置

    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

    xmlns:context="http://www.springframework.org/schema/context"

    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd">

    这是部分错误 控制台一致在闪烁,估计有2000多这样的错误

    com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: Data source rejected establishment of connection, message from server: "Too many connections"

    at sun.reflect.GeneratedConstructorAccessor28.newInstance(Unknown Source)

    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)

    at java.lang.reflect.Constructor.newInstance(Constructor.java:423)

    at com.mysql.jdbc.Util.handleNewInstance(Util.java:406)

    at com.mysql.jdbc.Util.getInstance(Util.java:381)

    at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:984)

    at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:956)

    at com.mysql.jdbc.MysqlIO.doHandshake(MysqlIO.java:1095)

    at com.mysql.jdbc.ConnectionImpl.createNewIO(ConnectionImpl.java:2031)

    at com.mysql.jdbc.ConnectionImpl.(ConnectionImpl.java:718)

    at com.mysql.jdbc.JDBC4Connection.(JDBC4Connection.java:46)

    at sun.reflect.GeneratedConstructorAccessor24.newInstance(Unknown Source)

    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)

    at java.lang.reflect.Constructor.newInstance(Constructor.java:423)

    at com.mysql.jdbc.Util.handleNewInstance(Util.java:406)

    at com.mysql.jdbc.ConnectionImpl.getInstance(ConnectionImpl.java:302)

    at com.mysql.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:282)

    at com.alibaba.druid.pool.DruidAbstractDataSource.createPhysicalConnection(DruidAbstractDataSource.java:1375)

    at com.alibaba.druid.pool.DruidAbstractDataSource.createPhysicalConnection(DruidAbstractDataSource.java:1431)

    at com.alibaba.druid.pool.DruidDataSource$CreateConnectionThread.run(DruidDataSource.java:1844)

    展开全文
  • mysql数据库频繁连接的问题ENVOS Platform: CentOS 7.4 64bit (阿里云的 ECS 云服务器)Node.js Version: 8.11.4ThinkJS Version: 2.2.24PM2 Version: 3.1.2 (没有启用 Cluster)MySQL Version: 5.7 (阿里云的 RDS 云...

    mysql数据库频繁连接的问题

    ENV

    OS Platform: CentOS 7.4 64bit (阿里云的 ECS 云服务器)

    Node.js Version: 8.11.4

    ThinkJS Version: 2.2.24

    PM2 Version: 3.1.2 (没有启用 Cluster)

    MySQL Version: 5.7 (阿里云的 RDS 云数据库,300个连接数限制,非本地安装的实例)

    mysql 参数

    connect_timeout: 10

    interactive_timeout: 7200

    wait_timeout: 86400

    mysql 内存 1.2G ,占用始终低于 10%

    error message

    2018-11-14 09:42:28 +08:00: [2018-11-14 09:42:28] [SOCKET] Connect mysql with mysql://

    2018-11-14 09:43:08 +08:00: [2018-11-14 09:43:08] [SOCKET] Connect mysql with mysql://

    2018-11-14 09:43:08 +08:00: [2018-11-14 09:43:08] [SOCKET] Connect mysql with mysql://

    2018-11-14 09:43:11 +08:00: [2018-11-14 09:43:11] [SOCKET] Connect mysql with mysql://

    2018-11-14 09:43:31 +08:00: [2018-11-14 09:43:31] [SOCKET] Connect mysql with mysql://

    2018-11-14 09:43:33 +08:00: [2018-11-14 09:43:33] [SOCKET] Connect mysql with mysql://

    2018-11-14 09:43:36 +08:00: [2018-11-14 09:43:36] [SOCKET] Connect mysql with mysql://

    2018-11-14 09:43:39 +08:00: [2018-11-14 09:43:39] [SOCKET] Connect mysql with mysql://

    2018-11-14 09:43:47 +08:00: [2018-11-14 09:43:47] [SOCKET] Connect mysql with mysql://

    2018-11-14 09:43:48 +08:00: [2018-11-14 09:43:48] [SOCKET] Connect mysql with mysql://

    2018-11-14 09:44:03 +08:00: [2018-11-14 09:44:03] [SOCKET] Connect mysql with mysql://

    2018-11-14 09:45:00 +08:00: [2018-11-14 09:45:00] [SOCKET] Connect mysql with mysql://

    2018-11-14 09:49:29 +08:00: [2018-11-14 09:49:29] [SOCKET] Connect mysql with mysql://

    2018-11-14 09:49:40 +08:00: [2018-11-14 09:49:40] [SOCKET] Connect mysql with mysql://

    2018-11-14 09:52:38 +08:00: [2018-11-14 09:52:38] [SOCKET] Connect mysql with mysql://

    2018-11-14 09:52:41 +08:00: [2018-11-14 09:52:41] [SOCKET] Connect mysql with mysql://

    2018-11-14 09:53:10 +08:00: [2018-11-14 09:53:10] [SOCKET] Connect mysql with mysql://

    2018-11-14 09:54:07 +08:00: [2018-11-14 09:54:07] [SOCKET] Connect mysql with mysql://

    2018-11-14 09:54:17 +08:00: [2018-11-14 09:54:17] [SOCKET] Connect mysql with mysql://

    2018-11-14 09:54:18 +08:00: [2018-11-14 09:54:18] [SOCKET] Connect mysql with mysql://

    2018-11-14 09:54:19 +08:00: [2018-11-14 09:54:19] [SOCKET] Connect mysql with mysql://

    2018-11-14 09:54:20 +08:00: [2018-11-14 09:54:20] [SOCKET] Connect mysql with mysql://

    2018-11-14 09:55:01 +08:00: [2018-11-14 09:55:01] [SOCKET] Connect mysql with mysql://

    2018-11-14 09:55:59 +08:00: [2018-11-14 09:55:59] [SOCKET] Connect mysql with mysql://

    2018-11-14 09:56:03 +08:00: [2018-11-14 09:56:03] [SOCKET] Connect mysql with mysql://

    2018-11-14 09:56:05 +08:00: [2018-11-14 09:56:05] [SOCKET] Connect mysql with mysql://

    2018-11-14 09:57:09 +08:00: [2018-11-14 09:57:09] [SOCKET] Connect mysql with mysql://

    2018-11-14 09:57:14 +08:00: [2018-11-14 09:57:14] [SOCKET] Connect mysql with mysql://

    2018-11-14 09:57:17 +08:00: [2018-11-14 09:57:17] [SOCKET] Connect mysql with mysql://

    2018-11-14 09:57:19 +08:00: [2018-11-14 09:57:19] [SOCKET] Connect mysql with mysql://

    2018-11-14 09:58:40 +08:00: [2018-11-14 09:58:40] [SOCKET] Connect mysql with mysql://

    不知道开发组还会不会回复 v2 版本的询问,谢谢!

    本人转 node 时间不长,使用 thinkjs v2 版本做了应用系统,在访问量大一些的时候(其实并不大,1000个 UV 左右,3000个PV 左右),会造成 mysql 连接数用尽(300个连接数限制)的问题。

    下面错误信息里面贴的是 pm2 输出日志的信息,可以看到创建连接的次数还是非常频繁的。

    无论是否在配置里面启用 connectionLimit 参数(无论是长连接还是池连接),都是会频繁建立连接。

    看 thinkjs 源码,可以看到创建长连接和池连接都 log 了 [SOCKET] Connect mysql with... 这个日志,我是据此判断是频繁创建新的连接,而旧的连接一直等待超时导致连接数用尽。

    我归纳了几个频繁创建新的连接的原因:

    mysql 参数设置问题(但是单纯看 wait_timeout 参数值是应该支持长连接不断开的)

    因为 mysql 实例是远程地址,连接会被网络断开

    业务系统中使用了事务,并发时会新增连接

    业务代码应该显式关闭连接(但是这是短连接的思维模式,且 thinkjs 文档中也不建议使用 model.close() 方法)

    实际上就是业务系统的高并发问题,mysql 连接数不够用

    请教该如何排查和处理这个问题呢?谢谢

    展开全文
  • 至于为什么使用连接池,大家都知道,就是为了避免频繁与数据库建立连接, 因为建立连接是一个比较耗时的操作。而连接池的配置基本差不多,都会设置一个最大连接数。 现在就有一个疑问,为什么最大连接数要设置成多...

    一般程序在访问数据库的时候,都是使用数据库连接池,比如:DBCP,C3P0等等。至于为什么使用连接池,大家都知道,就是为了避免频繁的与数据库建立连接, 因为建立连接是一个比较耗时的操作。而连接池的配置基本差不多,都会设置一个最大连接数。 现在就有一个疑问,为什么最大连接数要设置成多个?只建立1个连接,一直都不关闭可以吗?1个的话岂不是占用系统资源更少吗(排除掉使用transaction的情况,因为transaction的提交和回滚是在Connection上的)?难道说java.sql.Connection不是线程安全的? http://docs.oracle.com/javase/1.3/docs/guide/jdbc/spec/jdbc-spec.frame9.html 9.2     Multi-threading We require that all operations on all the java.sql objects be multi-thread safe and  able to cope correctly with having several threads simultaneously calling the same object. Some drivers may allow more concurrent execution than others.  Developers can assume fully concurrent execution;  if the driver requires some form of synchronization, it will provide it.  The only difference visible to the developer will be that applications will run with reduced concurrency. For example, two Statements on the same Connection can be executed concurrently and their ResultSets can be processed concurrently  (from the perspective of the developer). Some drivers will provide this full concurrency. Others may execute one statement and wait until it completes before sending the next. One specific use of multi-threading is to cancel a long running statement. This is done by using one thread to execute the statement and another to cancel it with its Statement.cancel() method. In practice we expect that most of the JDBC objects will only be accessed in a single threaded way. However some multi-thread support is necessary,  and our attempts in previous drafts to specify some classes as MT safe and some as MT unsafe appeared to be adding more confusion than light.  也就是说,java.sql.Connection是线程安全的,应用程序可以并发的使用同一个Connection来访问数据库,问题是,数据库的驱动可能会是并发的处理请求,也可能是串行的处理,这取决于数据库厂商。同时也说了,实际开发中最好还是单线程方式使用。 http://docs.oracle.com/cd/B14117_01/java.101/b10979/tips.htm#i1005436 The Oracle JDBC drivers provide full support for programs that use Java multithreading.  The following example creates a specified number of threads and lets you determine whether or not the threads will share a connection.  If you choose to share the connection, then the same JDBC connection object will be used by all threads (each thread will have its own statement object, however). Because all Oracle JDBC API methods are synchronized, if two threads try to use the connection object simultaneously,  then one will be forced to wait until the other one finishes its use. Oracle的JDBC API都是synchronized的,因此,对数据库的操作肯定是串行的。 http://forums.mysql.com/read.php?39,171022,171195#msg-171195 While you _can_ share a connection across threads (especially if each thread has its own Statement), it's usually not a good idea.  The JDBC API is not really designed to be used in a thread-safe way, and most JDBC connections (including MySQL's) can only process a single query at a time. You'll be adding _more_ contention in your system rather than concurrency compared to just giving each thread a "private" connection.  MySQL的Connection也是串行的执行数据库操作的。 http://stackoverflow.com/questions/9428573/is-it-safe-to-use-a-static-java-sql-connection-instance-in-a-multithreaded-syste This way the connection going to be shared among all requests sent by all users and thus all queries will interfere with each other.  But threadsafety is not your only problem, resource leaking is also your other problem.  You're keeping a single connection open during the entire application's lifetime.  The average database will reclaim the connection whenever it's been open for too long which is usually between 30 minutes and 8 hours, depending on DB's configuration.  So if your web application runs longer than that, the connection is lost and you won't be able to execute queries anymore. 这个就是说,用1个连接可能会出现长时间不用试导致连接被回收的情况。一般连接的最大不活动时间在30分钟到8个小时之间,取决于数据库服务器的配置。 设置Mysql的连接超时参数 http://blog.chinaunix.net/uid-26758020-id-3307042.html 在Mysql的默认设置中,如果一个数据库连接超过8小时没有使用(闲置8小时,即28800s),mysql server将主动断开这条连接,后续在该连接上进行的查询操作都将失败, 将出现:error 2006 (MySQL server has gone away)!。 查看mysql server超时时间: msyql> show global variables like '%timeout%'; 设置mysql server超时时间(以秒为单位):  msyql> set global wait_timeout=10; msyql> set global interactive_timeout=10; ps:我们的线上服务器设置的是2个小时。 MySQL中的配置参数interactive_timeout和wait_timeout(可能导致过多sleep进程的两个参数) http://www.cnblogs.com/jiunadianshi/articles/2475475.html 1)interactive_timeout: 参数含义:服务器关闭“交互式连接”前等待活动的秒数。交互式客户端定义为在mysql_real_connect()中使用CLIENT_INTERACTIVE选项的客户端。 参数默认值:28800秒(8小时) (2)wait_timeout: 参数含义:服务器关闭“非交互连接”之前等待活动的秒数。 在线程启动时,根据全局wait_timeout值或全局interactive_timeout值初始化会话wait_timeout值,取决于客户端类型(由mysql_real_connect()的连接选项CLIENT_INTERACTIVE定义)。 参数默认值:28800秒(8小时) MySQL服务器所支持的最大连接数是有上限的,因为每个连接的建立都会消耗内存,因此我们希望客户端在连接到MySQL Server处理完相应的操作后,应该断开连接并释放占用的内存。如果你的MySQL Server有大量的闲置连接,他们不仅会白白消耗内存,而且如果连接一直在累加而不断开,最终肯定会达到MySQL Server的连接上限数,这会报'too many connections'的错误。对于wait_timeout的值设定,应该根据系统的运行情况来判断。在系统运行一段时间后,可以通过show processlist命令查看当前系统的连接状态,如果发现有大量的sleep状态的连接进程,则说明该参数设置的过大,可以进行适当的调整小些。 问题: 如果在配置文件my.cnf中只设置参数wait_timeout=100,则重启服务器后进入,执行: Mysql> show variables like “%timeout%”; 会发现参数设置并未生效,仍然为28800(即默认的8个小时)。 查询资料后,要同时设置interactive_timeout和wait_timeout才会生效。 【mysqld】 wait_timeout=100 interactive_timeout=100 重启MySQL Server进入后,查看设置已经生效。 http://blog.csdn.net/z1988316/article/details/7976038 问题1:这里为什么要同时设置interactive_timeout,wait_timeout的设置才会生效? 答:    不设置interactive_timeout,wait_timeout也会生效。 问题2:interactive的值如果设置的和wait_timeout不同,为什么Interactive_timeout会覆盖wait_timeout? 答:在交互模式下(CLIENT_INTERACTIVE),interactive_timeout才生效,非交互模式下,不生效。 问题3:在进行MySQL优化时,因为interactive_timeout决定的是交互连接的时间长短,而wait_timeout决定的是非交互连接的时间长短。如果在进行连接配置时mysql_real_connect()最后一个参数client_flag不设置为CLIENT_INTERACTIVE,是不是interactive_timeout的值不会覆盖wait_timeout? 答:可以做实验试试。 问题4:为了减少长连接的数量,在设置优化时是不是可以将interactive_timeout的值设置的大些,而wait_timeout的值设置的小些?但是问题2的描述好像又不允许这样。。。 答:如2所述,在交互模式下,interactive_timeout取代wait_timeout。这样,如果有的客户端是交互模式方式连接mysql server。那么客户端的timeout受制于interactive_timeout。如果有的客户端是非交互模式,长连接mysql server。那么客户端的timeout受制于wait_timeout。(是否是交互模式的连接,由客户端决定) 总结一下: (1)jdk的规范里面说了,对于客户端来说Connection是线程安全的,允许多线程并发的使用,但是,数据库驱动可能是并行的执行,也可能是串行的执行SQL。 (2)同一个connection,Oracle和MySQL的驱动都是串行的执行操作,因此公用一个Connection与使用多个Connection相比会降低并发度,这应该才是最主要的原因。 (3)数据库一般都会有一个最大不活动时间,超过这个时间就会把连接关闭掉,因此,只有一个Connection的话,会出现连接已关闭,需要重建的情况。(其实这个倒不是啥大问题,启动一个后台线程,隔一段时间就执行一次查询,保持住连接不关闭就可以了。) (4)到底多少个连接合适,这是个问题。如果连接数过多,显然是浪费,而且,数据库对每个user支持的连接数都是有限制的。如果连接数少,考虑突发访问量变大的情况,肯定就会出现有的线程取不到连接的情况,这个请求就会失败。如果多个请求可以共用连接,这个时候至少不会出现获取不到连接直接失败,顶多是处理的时间变长了。

    展开全文
  • 数据库连接

    2021-02-08 12:49:25
    这时可以简单在需要访问数据库时,就新创建一个连接,用完后就关闭它,这样做也不会带来什么明显的性能上的开销。但是对于一个复杂的数据库应用,情况就完全不同了。频繁建立、关闭连接,会极大的减低系统的性能...
  • 文章目录[隐藏]起因论证解决方案操作步骤先贴阿里云服务器的配置:这是一个困扰我很久的问题,之前不管是搭在CentOS还是Ubuntu上,Wordpress都会定期出现“建立数据库连接时错误”,最近一周更是每天早上网站都无法...
  • 第一次Java程序要在MySQL中执行一条语句,那么就必须建立一个Connection对象,代表了MySQL数据库连接通过直接发送你要执行的SQL语句之后,就会调用Connection.close()来关闭和销毁与数据库连接。为什么要立即...
  • 自动连接数据库

    2021-01-28 03:24:32
    描述FineReport连接多维数据库,首先要通过数据连接将多维数据库与FineReport连接起来,然后在数据连接的基础上新建多维数据库XMLA数据集,用于模板设计。2.XMLA数据连接2.1描述多维数据库(Multi Dimensional ...
  • oracle数据库空闲连接

    2021-01-11 19:41:15
    RMAN-04006: error from auxiliary database: ORA-01034: ORACLE not available在使用rman duplicate复制standby数据库的时候,由于standby数据库实例必须处于非mount状态,所以主数据库直接连接是会报错的,需要在...
  • 数据库事务与连接

    千次阅读 2021-12-03 09:51:29
    修改就永久保存下来;要么数据库管理系统将放弃所作的所有修改,整个事务回滚(rollback)到最 初状态。 3. 为确保数据库中数据的一致性,数据的操纵应当是离散的成组的逻辑单元:当它全部完成时,数 据的一致性...
  • 随着信息技术的高速发展广泛应用,数据库技术在信息技术领域中的位置越来越重要,尤其是网络应用和电子商务的迅速发展,都需要数据库技术支持动态Web站点的运行,而传统的开发模式是:首先在主程序(如Servlet、...
  • 展开全部tomcat连接池的62616964757a686964616fe58685e5aeb931333264626630方法1:连接池所要解决的问题:应用程序每一次与数据库连接都会由于网络传输和执行数据库查询而严重降低了程序的执行效率,因此我们需要...
  • 大家可能会有这样疑问:连接池类似于线程池或者对象池,就是一个放连接的池子,使用的时候从里面拿一个,用完了再...同时也会介绍唯品会自研数据库连接池产品(代号:Caelus)为什么要有连接池先看一下连接池所处的位...
  • 前段时间在一个老项目中经历过一个问题:一个 Dubbo 服务,启动的时候慢的要死,后来看日志查原因整个过程一直在初始化数据库连接。一看数据库连接参数,连接池大小:1024。 很多入行晚的同学没有经历过手写 JDBC ...
  • 这时可以简单在需要访问数据库时,就新创建一个连接,用完后就关闭它,这样做也不会带来什么明显的性能上的开销。但是对于一个复杂的数据库应用,情况就完全不同了。频繁建立、关闭连接,会极大的减低系统的性能...
  • 数据库连接池是负责分配、管理和释放数据库连接,它允许应用程序重复使用一个现有的数据库连接,而不是再重新建立一个。 2.为什么要使用连接池? 数据库连接是一种关键的有限的昂贵的资源,这一点在多用户的网页应用...
  • Java数据库连接

    2021-01-27 01:21:47
    频繁创建连接和关闭连接,浪费数据库资源,影响服务器性能。什么是数据库连接池?顾名思义,就是一个池子,里面放着数据库连接,应用服务需要的时候就去池子里面拿,用完之后归还给池子。数据库连接池负责分配...
  • 解决数据库连接连接mysql时,每隔8小时mysql自动断开所有连接的问题最近有个问题非常讨厌,我们的工程中使用自己的连接连接mysql数据库,可mysql数据库每隔8小时就会自动断开所有链接,连接池就失效,需要重新...
  • 而所有数据有关的操作,基本上都是后端的范畴,所以掌握好对数据库的操作,是后端的必修课之一。数据库的内容很庞大,真的要学起来还挺复杂的,我懂得也不多,就先挑简单的来吧,以后有机会的话再去学习、记录。...
  • 们经常会遇到这样那样的连接未关闭的问题,连接没有...大家也经常听到连接池、线程池之类的线程、池的概念,那么究竟这些概念我们的连接有什么关系呢?下面我就想就上面的问题谈谈我的一点浅见,请大家批评指正...
  • java配置数据库连接

    2021-03-04 01:58:09
    数据库连接作为对象存储在一个Vector对象中,一旦数据库连接建立后,不同的数据库访问请求就可以共享这些连接,这样,通过复用这些已经建立数据库连接,可以克服上述缺点,极大节省系统资源和时间。...
  • SpringBoot笔记 —— 数据库连接

    千次阅读 2021-11-12 23:48:48
    首先写一个测试类,来看一下连接池的运行过程 package com.demo.spring.test; import org.apache.commons.dbcp2.BasicDataSource; import java.sql.Connection; import java.sql.PreparedStatement; import java....
  • 1.程序员认知中的数据库...在Java系统中去访问一个MySQL数据库,必须得在系统的依赖中加入一个MySQL驱动,有了这个MySQL驱动才能跟MySQL数据库建立连接,然后执行各种各样的SQL语句。 上图就是引入到Maven配置中的My
  • 应用程序直接获取数据库连接缺点用户每次请求都会建立一次数据库连接,并且数据库创建连接会消耗相对大的资源和时间。如果针对于个别的工具或者是大量的代码测试甚至系统运行,对数据库操作次数频繁,极大的占用...
  • 数据库常用连接池总结一、为什么需要连接池...数据库连接池的解决方案是在应用程序启动时建立足够的数据库连接,并讲这些连接组成一个连接池,由应用程序动态对池中的连接进行申请、使用和释放。对于多于连接池...
  • 一、概念 数据库连接池(Connection pooling)是程序启动时建立足够的数据库连接,并将这些连接组成一个连接池,由程序动态对池中的连接进行申请,使用,释放。 简单的说:创建数据库连接是一... 1.TCP建立连接的三
  • (2)当程序请求一个连接时,连接池会为该请求分配一个空闲的连接,为不是重新建立一个连接,当使用完连接后,该连接会重新回到连接池中,而不是直接释放 (3)当连接池中空闲的连接数低于下限时,连接池的管理机制...
  • 如果你在开线程请求数据库中如果你觉得所用时间太长的话,你就可以通过python数据库连接池去改善一下在此方面的不足之处,以下是文章的具体介绍,你可以通过我们的文章对python数据库连接池有一个更好的了解。...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 110,500
精华内容 44,200
关键字:

频繁地与数据库建立连接