linux查看apache进程，以及类unix上开启，关闭，重启

linux查看apache进程，以及类unix上开启，关闭，重启

（文档暂存）
在linux下如何查看apache的请求进程数:
要想在 Linux系统下查看 Apache的负载状况，最简单有效的方法就是查看Apache Server Status，在没有开启Apache Server Status的状况下，或安装的是其余的Web Server，好比Nginx的时候，可使用下面的命令查看。
#ps -ef|grep httpd|wc -l
1388
统计httpd进程数，这个请求会启动一个进程，使用于Apache服务器。
表示Apache可以处理1388个并发请求，这个值Apache可根据负载状况 自动调整
#netstat -nat|grep -i "80"|wc -l
4342
netstat -an会打印系统当前网络连接状态，而grep -i “80″是用来提取与80端口有关的链接的, wc -l进行链接数统计。
最终返回的数字就是当前全部80端口的请求总数。#netstat -na|grep ESTABLISHED|wc -l
376
netstat -an会打印系统当前网络连接状态，而grep ESTABLISHED 提取出已创建链接的信息。 而后wc -l统计。
最终返回的数字就是当前全部80端口的已创建链接的总数。
#netstat -n | awk ‘/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}’
FIN_WAIT_1 286
FIN_WAIT_2 960
SYN_SENT 3
LAST_ACK 32
CLOSING 1
CLOSED 36
SYN_RCVD 144
TIME_WAIT 2520
ESTABLISHED 352
返回参数的说明以下：
SYN_RECV表示正在等待处理的请求数；
ESTABLISHED表示正常数据传输状态；
TIME_WAIT表示处理完毕，等待超时结束的请求数。

在类Unix系统上如何中止和重启Apache 。
Windows NT/2000/XP/2003的用户请参见以服务方式运行Apache ，Windows 9x/ME用户则参见在控制台中运行Apache 。

简介
为了中止或者从新启动Apache ，你必须向正在运行的httpd进程发送信号。有两种发送信号的方法。第一种方法是直接使用UNIX的kill命令向运行中的进程发送信号。你也许你会 注意到 你的系统里运行着不少httpd进程。但你不该该直接对它们中的任何一个发送信号，而只要对已经在PidFile中记载下了自身PID的父进程发送信号。 也就是说，你没必要对父进程之外的任何进程发送信号。你能够向父进程发送三种信号：TERM、HUP、USR1 ，咱们过一下子再进行详细的说明。

你能够用下面这样的命令来向父进程发送信号：

kill -TERM `cat /usr/local/apache2/logs/httpd.pid`

第二种方法是使用下面将要描述的httpd二进制可执行文件的 -k 命令行选项：stop、restart、graceful、graceful-stop 。不过咱们推荐你使用apachectl控制脚原本向httpd二进制可执行文件传递这些选项。

当你向httpd发送信号后，你能够这样来读取它的进行过程：

tail -f /usr/local/apache2/logs/error_log

你能够修改这些示例以适应你的ServerRoot和PidFile 设置。
当即中止
信号：TERM
apachectl -k stop
发送TERM或stop信号到父进程可使它马上杀死全部子进程。这将花费一些时间来杀死全部子进程。而后父进程本身也退出。全部进行中的请求将被强行停止，并且再也不接受其它请求。
优雅重启
信号：USR1
apachectl -k graceful
USR1或graceful信号使得父进程建议子进程在完成它们如今的请求后退出(若是他们没有进行服务，将会马上退出)。父进程从新读入配置文件并从新打开日志文件。每当一个子进程死掉，父进程马上用新的配置文件产生一个新的子进程并马上开始伺服新的请求。

重启代码的设计可以确保MPM进程控制指令的正常运做，也就是在重启过程当中确保有适当数量的进程和线程以响应客户端的请求。它是这样 StartServers的：若是在一秒钟之后尚未新建立StartServers个子进程，则建立出足够完成如今任务的子进程个数。所以，代码除了保 有可以维持服务器的现有负载数量的子进程外，也确保StartServers按你的意愿运做。

使用mod_status的用户会注意到在USR1信号发出后，服务器的统计信息没有被清零。代码被写成既能将你服务器没法伺服新请求的时间降至最少(这些请求将被操做系统放到队列里，使得它们不会丢失)，又能听从你的参数 优化。为了作到这一点，它将在从新生成子进程的过程当中，在scoreboard上保存全部子进程的状态。 mod_status还会将那些在优雅重启前就已经开始而没有结束伺服请求的子进程用一个"G"来标志。 目前，日志滚动脚本还没法使用USR1来肯定全部写入预重启日志的子进程都已结束。咱们建议你在发出了USR1信号后等待一个适当的时间，而后再对旧的日 志作处理。好比说若是对于一个窄带用户来讲，大部分的点击处理将在10分钟以内完成，那么你应该在处理旧的日志前等待15分钟。 如 果Apache重启时发现配置文件有误，那么父进程将不会重启，而是报错并退出。在优雅重启的状况下，它将在处理中的子进程存在的状况下维持它的存在(就 是那些被要求在处理完它们的请求后"优雅退出"的子进程)。若是你要重启服务器，这将致使一些问题：它将不能绑定到它的监听端口。在执行重启以前，你能够 用 -t 命令行参数来检查配置文件语法的正确性(参见httpd)。但这仍然不能保证服务器必定能够正确的重启。为了从语法和语义两方面检查配置文件，你能够用一 个非root用户来启动httpd。若是没有错误，它将尝试去打开套接字和日志文件，继而因没有root权限而失败(或是由于如今运行的httpd已经绑 定了这些端口)。若是是由于其余缘由那么就多是一个配置文件产生的错误，你就应当在进行优雅重启以前改正这个错误。当即重启 信号：HUP apachectl -k restart 向父进程发送HUP或restart信号会使它象收到TERM信号同样杀掉全部的子进程，不一样之处在于父进程自己并不退出。它从新读入配置文件、从新打开日志文件。而后产生一系列新的子进程来继续服务。 使用mod_status的用户会注意到在HUP信号发出后，服务器统计信息会被清零。 若是你重启时配置文件有误，那么父进程将不会重启，而是报错并退出。参见上文中避免的方法。优雅中止 信号：WINCH apachectl -k graceful-stop WINCH或graceful-stop信号使得父进程建议子进程在完成它们如今的请求后退出(若是他们没有进行服务，将会马上退出)。而后父进程删除 PidFile并中止在全部端口上的监听。父进程仍然继续运行并监视正在处理请求的子进程，一旦全部子进程完成任务并退出或者超过由 GracefulShutdownTimeout指令规定的时间，父进程将会退出。在超时的状况下，全部子进程都将接收到TERM信号并被强制退出。 在"优雅"状态下，TERM信号将会当即停止父进程和全部子进程。因为PidFile已经被删除，你将没法使用apachectl或httpd发送该信号。 graceful-stop容许你同时运行多个相同配置的httpd实例。这在对Apache进行平滑升级的时候是一个很是有用的特性。不过它在某些配置的状况下一样可能会致使死锁和竞争条件。 必须注意确保诸如Lockfile和ScriptSock之类的磁盘文件包含服务器的PID ，而且可以安全的共存。然而若是一个配置指令、第三方模块或持久CGI使用任何磁盘锁或状态文件，必须注意确保多个httpd运行实例之间不会争抢文件。 你还必须防止潜在的竞争条件，好比使用rotatelogs风格的管道日志。运行中的多个rotatelogs实例企图同时滚动同一个日志文件可能会致使互相破坏对方的日志文件。 附录：信号和竞争条件 在Apache 1.2b9 以前，有不少关于重启和死亡信号的竞争条件。关 于竞争条件的一个简单描述是：一个时间敏感的问题，若是一些事情在不适当的时间或以不恰当的顺序发生，它将做出你不指望的反应；若是一样的事情在恰当的时 间发生，则不会出现异常。凭借那些拥有"正确"特性设置的体系结构，咱们尽可能避免了它们的出现。但值得注意的是，仍然有一些竞争条件存在于这样的体系结构 中。 使用物理磁盘的ScoreBoardFile就有损坏ScoreBoard的潜在危险。这将发生在"bind: Address already in use"(HUP以后)或"long lost child came home!"(USR1以后)时。前者是一个致命错误，然后者则会使服务器丢失ScoreBoard的一个记录。因此咱们建议多使用优雅重启，偶尔使用硬 重启。这些问题很难解决，但幸运的是大多数结构并不须要ScoreBoard文件。而若是你须要这样的结构，你能够参考ScoreBoardFile文 档。 当 每一个子进程在一个HTTP的持续链接(KeepAlive)中涉及到第二个并发的请求时，全部的结构都会或多或少存在竞争状态的问题。它将在读取了请求而 没有读取任何请求头以后马上退出。这个修复对于1.2来讲来得太晚了。但由于持续链接的客户端已经考虑到网络延时和服务器超时会形成相似的状况，因此理论 上说，这不是一个太大的问题。而实际上彷佛也没有任何影响：在一个测试案例中服务器在一秒以内被重启了20次，而客户端却成功的浏览了网站，并且没有任何 破损的图片或空文档。