kill相关知识
-
linux kill 命令用法kill 命令的用途kill 命令很容易让人产生误解,以为它仅仅就是用来杀死进程的。我们来看一下 man page 对它的解释:kill - send a signal to a process.从官方的解释不难看出,kill 是向进程发送信号的命令。当然我们可以向进程发送一个终止运行的信号,此时的 kill 命令才是名至实归。事实上如果我们不给 kill 命令传递信号参数,它默认传递终止进程运行的信号给进程!这是 kill 命令最主要的用法,也是本文要介绍的内容。一般情况下,终止一个前台进程使用 Ctrl + C 就可以了。对于一个后台进程就须用 kill 命令来终止。我们会先使用 ps、top 等命令获得进程的 PID,然后使用 kill 命令来杀掉该进程。kill 命令格式kill [options] <pid> [...] <pid> […] : 把信号发送给列出的所有进程。 options : &n
-
percona-toolkit之pt-killpt-kill 是一个非常简单的 杀mysql线程和查询的 工具。 主要是为了防止一些长的查询 长时间占用 系统资源,而对线上业务造成影响的情况。主要作用:从show processlist 中获取满足条件的连接或者从包含show processlist的文件中读取满足条件的连接并打印或者杀掉或者执行其他操作。我们这里主要用来防止某些select操作时间过长,从而影响其他线上SQL。安装:安装percona-toolkit即可使用范例:pt-kill --log-dsn D=testdb,t=kill_log --create-log-table --host=host2 --user=root --password=root --port=3306 --busy-time=10 --print --kill-query --match-info "SELECT|select" --victims all也可使用--config写配置文件:pt-kill --config t
-
使用pt-kill根据一定的规则来kill连接的方法pt-kill 是一个优秀的kill MySQL连接的一个工具,是percona toolkit的一部分,在因为空闲连接较多导致超过最大连接数、某个有问题的sql导致mysql负载很高时,都需要将一些连接kill掉,这个工具主要就是这个用途。参数–busy-time运行时间–idle-time空闲时间–victims所有匹配的连接,对应有最久的连接–interval间隔时间,默认30s,有点长,可以根据实际情况来调节–print打印出来kill掉的连接–match-command匹配当前连接的命令QuerySleepBinlog DumpConnectDelayed insertExecuteFetchInit DBKillPrepareProcesslistQuitReset stmtTable Dump–match-state匹配当前连接的状态Lockedlogincopy to tmp tableCopying to tmp tableCopying to tmp table on diskCreat
-
pt-kill 常用杀进程参数介绍pt-kill 是一个优秀的kill MySQL连接的一个工具,是percona toolkit的一部分,在因为空闲连接较多导致超过最大连接数、某个有问题的sql导致mysql负载很高时,都需要将一些连接kill掉,这个工具主要就是这个用途。1. 按user kill/usr/bin/pt-kill --busy-time 15 --match-user="dbUSER1 | dbUSER2,..." --victim all --interval 1 --kill --daemonize --pid=/tmp/ptkill.pid --print --log=/home/pt-kill.log 注:测试通过按用户来杀线程,注意--match-user多个用户之间用 | 分隔。 2. 按query来源 host kill/usr/bin/pt-kill --busy-time 15 --match-host="
kill相关课程
kill相关教程
- 4. kill 结束进程 前面查找到进程的 PID 之后,可以使用 kill 命令杀死进程,命令如下:kill -9 12471ps -ef | grep nginx执行结果如下图:Tips:从图中可以看到,使用 kill -9 命令之后,可以杀掉 PID = 12471 这个进程,12472 属于 12471 的子进程,所以也会被一起杀掉,从前面的表中可以看到 -9 表示无条件终止。
- 6. 小结 本小节介绍了进程通信信号描述,介绍了如何使用 ps 命令查看进程的 PID,还介绍了如何使用 kill 和 killall 结束进程,其中 kill 是通过进程的 PID 来结束掉进程的,killall 可以通过进程名称来结束掉进程,另外还介绍了如何使用 PID 去查找该应用程序占用的端口号。
- 2.1 语法 连接到设备adb connect device_ip_address查询设备adb devices -l安装应用adb install path_to_apk将文件复制到设备adb push local remote从设备复制文件adb pull remote local发出 shell 命令adb shell shell_command停止 adb 服务器adb kill-server
- 2.2 信号 信号(Signal)是 Unix 系统中就已有的 IPC 方式,继承于 Unix 的 Linux 系统和 MacOS 系统也具有相同的通信方式。信号的工作原理是向某个进程发送特定的消息,目标进程在收到消息之后,就知道特定事件已经发生,此时进程可以忽略消息即不做处理,或者是处理消息调用固定的函数。以 MacOS 为例,在 shell 终端输入 kill -l 可以列出支出的全部信号名称:HUP INT QUIT ILL TRAP ABRT EMT FPE KILL BUS SEGV SYS PIPE ALRM TERM URG STOP。MacOS 支持的信号列表
- Linux 结束进程 前面小节介绍了如何启动一个程序进程,还介绍了如何查看系统进程信息,本小节来介绍如何通过 kill 命令结束进程。
- 3.1 Nginx 进程模型实验 按照前面的讲解,我们测试给 Nginx 的 Master 进程直接发送信号,并观察进程情况:# 确认没有 Nginx 进程[root@server sbin]# ps -ef | grep nginxroot 10603 10137 0 14:23 pts/2 00:00:00 grep --color=auto nginx# 启动 Nginx [root@server sbin]# ./nginx# 可以看到 Nginx 启动的进程[root@server sbin]# ps -ef | grep nginxroot 10640 1 0 14:23 ? 00:00:00 nginx: master process ./nginxroot 10642 10640 0 14:23 ? 00:00:00 nginx: worker processroot 10643 10640 0 14:23 ? 00:00:00 nginx: worker processroot 10644 10640 0 14:23 ? 00:00:00 nginx: cache manager processroot 10645 10640 0 14:23 ? 00:00:00 nginx: cache loader process可以看到 Nginx 启动了 Master 进程(pid=10640),后由 Master 进程 fork 除了两个 Worker 进程和两个 Cache 进程,他们的父进程 id 均为10640。现在做如下几个操作:关闭进程号等于10642的 Worker 进程[root@server sbin]# sudo kill -SIGTERM 10642[root@server sbin]# ps -ef | grep nginxroot 10640 1 0 14:23 ? 00:00:00 nginx: master process ./nginxroot 10643 10640 0 14:23 ? 00:00:00 nginx: worker processroot 10644 10640 0 14:23 ? 00:00:00 nginx: cache manager processroot 10869 10640 0 14:32 ? 00:00:00 nginx: worker processroot 10939 10137 0 14:32 pts/2 00:00:00 grep --color=auto nginx可以看到原先的 Worker 进程被杀死后,Nginx 的主进程又立马拉起来一个新的 Worker 进程提供服务。这说明 Nginx 是非常可靠的,只要 Master 进程还在就会保证 Worker 进程持续存在并提供服务。向主进程发送 SIGHUP 信号,等价于 -s reload 操作。可以看到除了 Master 进程外,所有其他进程已经是新启动的进程了。[root@server sbin]# sudo kill -SIGHUP 10640[root@server sbin]# ps -ef | grep nginxroot 10640 1 0 14:23 ? 00:00:00 nginx: master process ./nginxroot 11059 10640 0 14:37 ? 00:00:00 nginx: worker processroot 11060 10640 0 14:37 ? 00:00:00 nginx: worker processroot 11061 10640 0 14:37 ? 00:00:00 nginx: cache manager processroot 11098 10137 0 14:37 pts/2 00:00:00 grep --color=auto nginx向主进程发生 SIGTERM 信号,等价于 -s stop 操作,即停止 Nginx 服务,关闭所有进程[root@server sbin]# sudo kill -SIGTERM 10640[root@server sbin]# ps -ef | grep nginxroot 11267 10137 0 14:43 pts/2 00:00:00 grep --color=auto nginx向主进程发生 USR1 信号,等价于 -s repoen 操作,即重新打开日志文件[root@server sbin]# ./nginx[root@server sbin]# ps -ef | grep nginxroot 11408 1 0 14:48 ? 00:00:00 nginx: master process ./nginxroot 11410 11408 0 14:48 ? 00:00:00 nginx: worker processroot 11411 11408 0 14:48 ? 00:00:00 nginx: worker processroot 11412 11408 0 14:48 ? 00:00:00 nginx: cache manager processroot 11413 11408 0 14:48 ? 00:00:00 nginx: cache loader processroot 11484 10137 0 14:49 pts/2 00:00:00 grep --color=auto nginx[root@server sbin]# ll ../logs/access.log -rw-r--r-- 1 root root 384349 Feb 11 14:26 ../logs/access.log[root@server sbin]# rm -rf ../logs/access.log [root@server sbin]# ll ../logs/access.log ls: cannot access ../logs/access.log: No such file or directory[root@server sbin]# kill -USR1 11408[root@server sbin]# ll ../logs/access.log -rw-r--r-- 1 root root 0 Feb 11 14:50 ../logs/access.log可以看到,在移除 Nginx 的 access.log 日志后,在向 Nginx 主进程发送 USR1 信号,Nginx 会重新生成一个新的 access.log 日志。
kill相关搜索
-
kafka
key
keygen
keypress
keys
kickstart
kill
kotlin
kotlin android
kotlin 教程
kotlin教程
kotlin中文文档
开发工具
开发管理
开方函数
开源代码
客户端开发
空格的代码
空格符号怎么打
控制器