189 8069 5689
首先介绍下 pt-stalk，它是 Percona-Toolkit 工具包中的一个工具，说起 PT 工具包大家都不陌生，平时常用的 pt-query-digest、 pt-online-schema-change 等工具都是出自于这个工具包，这里就不多介绍了。
成都创新互联专注于清河网站建设服务及定制，我们拥有丰富的企业做网站经验。 热诚为您提供清河营销型网站建设，清河网站制作、清河网页设计、清河网站官网定制、微信小程序服务，打造清河网络公司原创品牌,更为您提供清河网站排名全网营销落地服务。
pt-stalk 的主要功能是在出现问题时收集 OS 及 MySQL 的诊断信息，这其中包括：
1. OS 层面的 CPU、IO、内存、磁盘、网络等信息；
2. MySQL 层面的行锁等待、会话连接、主从复制，状态参数等信息。
而且 pt-stalk 是一个 Shell脚本，对于我这种看不懂 perl 的人来说比较友好，脚本里面的监控逻辑与监控命令也可以拿来参考，用于构建自己的监控体系。
三、使用
接着我们来看下如何使用这个工具。
pt-stalk 通常以后台服务形式监控 MySQL 并等待触发条件，当触发条件时收集相关诊断数据。
触发条件相关的参数有以下几个：
function：
∘ 默认为 status，代表监控 SHOW GLOBAL STATUS 的输出；
∘ 也可以设置为 processlist，代表监控 show processlist 的输出；
variable：
∘ 默认为 Threads_running，代表 监控参数，根据上述监控输出指定具体的监控项；
threshold：
∘ 默认为 25，代表 监控阈值，监控参数超过阈值，则满足触发条件；
∘ 监控参数的值非数字时，需要配合 match 参数一起使用，如 processlist 的 state 列；
cycles：
∘ 默认为 5，表示连续观察到五次满足触发条件时，才触发收集；
连接参数：host、password、port、socket。
其他一些重要参数：
iterations：该参数指定 pt-stalk 在触发收集几次后退出，默认会一直运行。
run-time：触发收集后，该参数指定收集多长时间的数据，默认 30 秒。
sleep：该参数指定在触发收集后，sleep 多久后继续监控，默认 300 秒。
interval：指定状态参数的检查频率，判断是否需要触发收集，默认 1 秒。
dest：监控数据存放路径，默认为 /var/lib/pt-stalk。
retention-time ：监控数据保留时长，默认 30 天。
daemonize：以后台服务运行，默认不开启。
log：后台运行日志，默认为 /var/log/pt-stalk.log。
collect：触发发生时收集诊断数据，默认开启。
∘ collect-gdb：收集 GDB 堆栈跟踪，需要 gdb 工具。
∘ collect-strace：收集跟踪数据，需要 strace 工具。
∘ collect-tcpdump：收集 tcpdump 数据，需要 tcpdump 工具。
ps -ef 的意思显示系统执行进程
-e 显示所有终端机下执行的进程
-f 指的是显示UID,PPIP,C与STIME栏位
grep 是搜索过滤
ps -ef | grep mysql的含义就是显示系统执行进程，从显示的全部进程信息中搜索包含mysql字符串的信息，并显示出来
查询死锁进程
采用如下存储过程来查询数据中当前造成死锁的进程。
drop procedure sp_who_lock
go
CREATE procedure sp_who_lock
as
begin
declare @spid int
declare @blk int
declare @count int
declare @index int
declare @lock tinyint
set @lock=0
create table #temp_who_lock
(
id int identity(1,1),
spid int,
blk int
)
if @@error0 return @@error
insert into #temp_who_lock(spid,blk)
select 0 ,blocked
from (select * from master..sysprocesses where blocked0)a
where not exists(select * from master..sysprocesses where a.blocked =spid and blocked0)
union select spid,blocked from master..sysprocesses where blocked0
if @@error0 return @@error
select @count=count(*),@index=1 from #temp_who_lock
if @@error0 return @@error
if @count=0
begin
select '没有阻塞和死锁信息'
return 0
end
while @indexA href="mailto:=@count"=@count
begin
if exists(select 1 from #temp_who_lock a where id@index and exists(select 1 from #temp_who_lock where idA href="mailto:=@index"=@index and a.blk=spid))
begin
set @lock=1
select @spid=spid,@blk=blk from #temp_who_lock where id=@index
select '引起数据库死锁的是: '+ CAST(@spid AS VARCHAR(10)) + '进程号,其执行的SQL语法如下'
select @spid, @blk
dbcc inputbuffer(@spid)
dbcc inputbuffer(@blk)
end
set @index=@index+1
end
if @lock=0
begin
set @index=1
while @indexA href="mailto:=@count"=@count
begin
select @spid=spid,@blk=blk from #temp_who_lock where id=@index
if @spid=0
select '引起阻塞的是:'+cast(@blk as varchar(10))+ '进程号,其执行的SQL语法如下'
else
select '进程号SPID：'+ CAST(@spid AS VARCHAR(10))+ '被' + '进程号SPID：'+ CAST(@blk AS VARCHAR(10)) +'阻塞,其当前进程执行的SQL语法如下'
dbcc inputbuffer(@spid)
dbcc inputbuffer(@blk)
set @index=@index+1
end
end
drop table #temp_who_lock
return 0
end
GO
--执行该存储过程
exec sp_who_lock
补充：
一、产生死锁的原因
在SQL Server中，阻塞更多的是产生于实现并发之间的隔离性。为了使得并发连接所做的操作之间的影响到达某一期望值而对资源人为的进行加锁(锁本质其实可以看作是一个标志位)。当一个连接对特定的资源进行操作时，另一个连接同时对同样的资源进行操作就会被阻塞，阻塞是死锁产生的必要条件。
二、如何避免死锁
1.使用事务时，尽量缩短事务的逻辑处理过程，及早提交或回滚事务；
2.设置死锁超时参数为合理范围，如：3分钟-10分种；超过时间，自动放弃本次操作，避免进程悬挂；
3.优化程序，检查并避免死锁现象出现；
4.对所有的脚本和SP都要仔细测试，在正是版本之前；
5.所有的SP都要有错误处理（通过@error）；
6.一般不要修改SQL SERVER事务的默认级别。不推荐强行加锁。
三、处理死锁
1、最简单的处理死锁的方法就是重启服务。
2、根据指定的死锁进程ID进行处理
根据第二步查询到的死锁进行，大致分析造成死锁的原因，并通过如下语句释放该死锁进程
kill pid --pid为查询出来的死锁进程号
3、通过存储过程杀掉某个库下面的所有死锁进程和锁
if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[sp_killspid]') and OBJECTPROPERTY(id, N'IsProcedure') = 1)
drop procedure [dbo].[sp_killspid]
GO
create proc sp_killspid
@dbname varchar(200) --要关闭进程的数据库名
as
declare @sql nvarchar(500)
declare @spid nvarchar(20)
declare #tb cursor for
select spid=cast(spid as varchar(20)) from master..sysprocesses where dbid=db_id(@dbname)
open #tb
fetch next from #tb into @spid
while @@fetch_status=0
begin
exec('kill '+@spid)
fetch next from #tb into @spid
end
close #tb
deallocate #tb
go
--使用方法，“db_name”为处理的数据库名称
exec sp_killspid 'db_name'
系统mysql的进程数
查看 mysql buffer pool hit
ps -ef | grep "mysql" | grep -v "grep" | wc –l
2.Slave_running
mysql show status like 'Slave_running';
如果系统有一个从复***务器，这个值指明了从服务器的健康度
3.Threads_connected
mysql show status like 'Threads_connected';
当前客户端已连接的数量。这个值会少于预设的值，但你也能监视到这个值较大，这可保证客户端是处在活跃状态。
4.Threads_running
mysql show status like 'Threads_running';
如果数据库超负荷了，你将会得到一个正在（查询的语句持续）增长的数值。这个值也可以少于预先设定的值。这个值在很短的时间内超过限定值是没问题的。当Threads_running值超过预设值时并且该值在5秒内没有回落时， 要同时监视其他的一些值。
5.Aborted_clients
mysql show status like 'Aborted_clients';
客户端被异常中断的数值，即连接到mysql服务器的客户端没有正常地断开或关闭。对于一些应用程序是没有影响的，但对于另一些应用程序可能你要跟踪该值，因为异常中断连接可能表明了一些应用程序有问题。
6.Questions
mysql show status like 'Questions';
每秒钟获得的查询数量，也可以是全部查询的数量，根据你输入不同的命令会得到你想要的不同的值。
7.Handler_*
mysql show status like 'Handler_%';
如果你想监视底层（low-level）数据库负载，这些值是值得去跟踪的。
如果Handler_read_rnd_next值相对于你认为是正常值相差悬殊，可能会告诉你需要优化或索引出问题了。Handler_rollback表明事务被回滚的查询数量。你可能想调查一下原因。
8.Opened_tables
mysql show status like 'Opened_tables';
表缓存没有命中的数量。如果该值很大，你可能需要增加table_cache的数值。典型地，你可能想要这个值每秒打开的表数量少于1或2。
9.Select_full_join
mysql show status like 'Select_full_join';
没有主键（key）联合（Join）的执行。该值可能是零。这是捕获开发错误的好方法，因为一些这样的查询可能降低系统的性能。
10.Select_scan
mysql show status like 'Select_scan';
执行全表搜索查询的数量。在某些情况下是没问题的，但占总查询数量该比值应该是常量（即Select_scan/总查询数量商应该是常数）。如果你发现该值持续增长，说明需要优化，缺乏必要的索引或其他问题。
11.Slow_queries
mysql show status like 'Slow_queries';
超过该值（--long-query-time）的查询数量，或没有使用索引查询数量。对于全部查询会有小的冲突。如果该值增长，表明系统有性能问题。
12.Threads_created
mysql show status like 'Threads_created';
该值应该是低的。较高的值可能意味着你需要增加thread_cache的数值，或你遇到了持续增加的连接，表明了潜在的问题。
13.客户端连接进程数
shell mysqladmin processlist
mysql show processlist;
你可以通过使用其他的统计信息得到已连接线程数量和正在运行线程的数量，检查正在运行的查询花了多长时间是一个好主意。如果有一些长时间的查询，管理员可以被通知。你可能也想了解多少个查询是在"Locked"的状态—---该值作为正在运行的查询不被计算在内而是作为非活跃的。一个用户正在等待一个数据库响应。
14.innodb状态
mysql show engine innodb status\G;
该语句产生很多信息，从中你可以得到你感兴趣的。首先你要检查的就是“从最近的XX秒计算出来的每秒的平均负载”。
(1)Pending normal aio reads: 该值是innodb io请求查询的大小（size）。如果该值大到超过了10—20，你可能有一些瓶颈。
(2)reads/s, avg bytes/read, writes/s, fsyncs/s:这些值是io统计。对于reads/writes大值意味着io子系统正在被装载。适当的值取决于你系统的配置。
(3)Buffer pool hit rate:这个命中率非常依赖于你的应用程序。当你觉得有问题时请检查你的命中率
(4)inserts/s, updates/s, deletes/s, reads/s:有一些Innodb的底层操作。你可以用这些值检查你的负载情况查看是否是期待的数值范围。