LawrenceLi Asked: 2016-07-03 18:34:14 +0800 CST2016-07-03 18:34:14 +0800 CST 2016-07-03 18:34:14 +0800 CST 20个mysqld进程只使用1个端口? 772 这些来自阿里云云数据库服务器,20个mysqld进程使用一个3306端口 有没有人见过这个 ? 任何人都可以解释如何做到这一点? 这有什么好处吗? mysql percona-server 4 个回答 Voted Michael - sqlbot 2016-07-04T06:36:12+08:002016-07-04T06:36:12+08:00 我们看到的是不可能的,所以合乎逻辑的假设是它是一种幻觉。 多个 MySQL 服务器实例无法侦听同一端口。它们也不能像它们那样共享同一个 pid 文件,也不能共享 InnoDB 的数据文件。 对此最明智的解释是,这些工具向您展示的是线程,而不是进程——无论出于何种原因。Linux 中的线程(如果是这样的话)共享相同的进程 ID,但它们也有自己的线程 ID,这个数字来自与 PID 相同的编号空间。 我怀疑最引人注目的是有 20 多个条目,每个条目消耗 10.9% 的可用内存。虽然如果 MySQL 服务器拥有相同数量的内存(尤其是繁忙的),多个相同实例的可能性极小,但您在此服务器上的内存使用率不可能超过 200%。 mysql> SHOW FULL PROCESSLIST;当由具有SUPERorPROCESS权限的用户执行时,应该向您显示活动的客户端线程,并且可能包含代表两个看起来特别忙的条目,这里。当然,输出中的数量会比此处显示的要少,因为并非所有线程都是客户端线程。 SELECT CONNECTION_ID(), UUID_SHORT();通过反复连接和断开连接和发出和/或同时在多个连接上执行此操作,向自己证明实际上只有一个实例在运行。这两个值都会增加很多(connection_id 会随着每个连接增加,但在连接时保持不变,uuid_short 会随着每个查询增加)并且永远不会更小。如果涉及多个 MySQL 服务器守护程序实例,这几乎是不可能的。 Philᵀᴹ 2016-07-04T18:32:46+08:002016-07-04T18:32:46+08:00 他们并不都使用相同的端口。 主 mysqld 进程将fork关闭其子进程(您可以在ps输出的第 2 列和第 3 列中看到 child<>parent 关系 - pid 26308 看起来是主“线程”。实际上只有一个进程会监听在TCP端口上。您可以使用lsof.forkargv[]fork()--port=3306 Best Answer RolandoMySQLDBA 2016-07-04T18:39:58+08:002016-07-04T18:39:58+08:00 您在操作系统中看到的所有这些进程都是源自 mysqld 的内核线程。 仔细看第一张图 Linux 进程 ID26101是 mysqld_safe Linux 进程 ID26307是线程 mysqld_safe 启动 mysqld Linux 进程 ID26308实际上是 mysqld 19 个 Linux 进程 ID 26309-26334是来自 mysqld ( 26308)的线程 我的猜测是它们只是数据库连接,但其他内部线程是可能的 如果要证实这一点,可以运行以下命令: 在 mysql 中,SELECT COUNT(1) FROM information_schema.processlist; 在操作系统中,运行netstat | grep -c 3306或netstat | grep mysql | grep -c ESTABLISHED 结果可能有利于操作系统 旧版本的 mysqld 倾向于在操作系统中执行此操作。例如,请看以下内容: Nov 28, 2013:Why do top and ps show different PIDs for the same processes? Apr 28, 2012:Is multiple mysqld processes for 1 mysql server is normal? May 29, 2007:mysql creating lots of processes (not threads, linux processes) 我一直怀疑当mysqld出现这种行为时,它可能是通过源码编译构建的,但没有适当的编译选项。mysqld 会在操作系统的眼中将其表现为多个连接。 从 2007 年起,施瓦茨男爵似乎就是这么认为的 斯科特坦纳似乎从 2007 年开始就这么认为 去年我刚刚提到过:太多的 mysql 实例。怎么杀? 4年前我对此发表了评论:innodb_buffer_pool_size没有改变 结论 你真的没什么好担心的。mysqld 仍将正常运行。这完全与创建 mysqld 二进制文件的环境与运行这些二进制文件的位置有关。 Rick James 2016-07-11T10:36:03+08:002016-07-11T10:36:03+08:00 根据操作系统,您可能会看到 mysqld 有 1 个进程,或者您可能会看到每个连接有 1 个。每个最初都连接在端口 3306 上。 如果您有连接池(在客户端)和/或高值thread_cache_size和高值wait_timeout,则可能有一堆“不会消失”的空闲连接。 正如罗兰多所说,“没什么好担心的”。 另一方面,39.6%CPU非常高。SHOW FULL PROCESSLIST;看看你能不能抓住它。然后考虑改进那个繁忙的查询。(这可能会或可能不会“担心”。)
我们看到的是不可能的,所以合乎逻辑的假设是它是一种幻觉。
多个 MySQL 服务器实例无法侦听同一端口。它们也不能像它们那样共享同一个 pid 文件,也不能共享 InnoDB 的数据文件。
对此最明智的解释是,这些工具向您展示的是线程,而不是进程——无论出于何种原因。Linux 中的线程(如果是这样的话)共享相同的进程 ID,但它们也有自己的线程 ID,这个数字来自与 PID 相同的编号空间。
我怀疑最引人注目的是有 20 多个条目,每个条目消耗 10.9% 的可用内存。虽然如果 MySQL 服务器拥有相同数量的内存(尤其是繁忙的),多个相同实例的可能性极小,但您在此服务器上的内存使用率不可能超过 200%。
mysql> SHOW FULL PROCESSLIST;
当由具有SUPER
orPROCESS
权限的用户执行时,应该向您显示活动的客户端线程,并且可能包含代表两个看起来特别忙的条目,这里。当然,输出中的数量会比此处显示的要少,因为并非所有线程都是客户端线程。SELECT CONNECTION_ID(), UUID_SHORT();
通过反复连接和断开连接和发出和/或同时在多个连接上执行此操作,向自己证明实际上只有一个实例在运行。这两个值都会增加很多(connection_id 会随着每个连接增加,但在连接时保持不变,uuid_short 会随着每个查询增加)并且永远不会更小。如果涉及多个 MySQL 服务器守护程序实例,这几乎是不可能的。他们并不都使用相同的端口。
主 mysqld 进程将
fork
关闭其子进程(您可以在ps
输出的第 2 列和第 3 列中看到 child<>parent 关系 - pid 26308 看起来是主“线程”。实际上只有一个进程会监听在TCP端口上。您可以使用lsof
.fork
argv[]
fork()
--port=3306
您在操作系统中看到的所有这些进程都是源自 mysqld 的内核线程。
仔细看第一张图
26101
是 mysqld_safe26307
是线程 mysqld_safe 启动 mysqld26308
实际上是 mysqld26309
-26334
是来自 mysqld (26308
)的线程我的猜测是它们只是数据库连接,但其他内部线程是可能的
如果要证实这一点,可以运行以下命令:
SELECT COUNT(1) FROM information_schema.processlist;
netstat | grep -c 3306
或netstat | grep mysql | grep -c ESTABLISHED
旧版本的 mysqld 倾向于在操作系统中执行此操作。例如,请看以下内容:
Nov 28, 2013
:Why do top and ps show different PIDs for the same processes?
Apr 28, 2012
:Is multiple mysqld processes for 1 mysql server is normal?
May 29, 2007
:mysql creating lots of processes (not threads, linux processes)
我一直怀疑当mysqld出现这种行为时,它可能是通过源码编译构建的,但没有适当的编译选项。mysqld 会在操作系统的眼中将其表现为多个连接。
结论
你真的没什么好担心的。mysqld 仍将正常运行。这完全与创建 mysqld 二进制文件的环境与运行这些二进制文件的位置有关。
根据操作系统,您可能会看到 mysqld 有 1 个进程,或者您可能会看到每个连接有 1 个。每个最初都连接在端口 3306 上。
如果您有连接池(在客户端)和/或高值
thread_cache_size
和高值wait_timeout
,则可能有一堆“不会消失”的空闲连接。正如罗兰多所说,“没什么好担心的”。
另一方面,
39.6%
CPU非常高。SHOW FULL PROCESSLIST;
看看你能不能抓住它。然后考虑改进那个繁忙的查询。(这可能会或可能不会“担心”。)