Nginx教程(三) Nginx日志管理 1 日志管理 1.1 Nginx日志描述 通过访问日志,你可以得到用户地域来源.跳转来源.使用终端.某个URL访问量等相关信息:通过错误日志,你可以得到系统某个服务或server的性能瓶颈等.因此,将日志好好利用,你可以得到很多有价值的信息. 1.2 Nginx日志格式 打开nginx.conf配置文件:vim /usr/local/nginx/conf/nginx.conf 日志部分内容: #access_log  logs/access.log  m

[1]Nginx重新打开日志文件 向 Nginx 主进程发送 USR1 信号.USR1 信号是重新打开日志文件: 方式一: kill -USR1 $(cat /usr/local/lib/ubcsrvd/logs/nginx.pid) 方式二(推荐方式): kill -USR1 $(ps aux | grep nginx | grep master | awk '{print $2}') 思考:为什么推荐方式二? 因为,方式一利用的是读取nginx.pid文件保存的进程nginx master的

先移动日志文件 mv /usr/local/openresty/nginx/logs/access.log /usr/local/openresty/nginx/logs/access.log.20161024 发送信号重新打开日志文件 kill -USR1 $(cat /usr/local/openresty/nginx/logs/nginx.pid) 简单说明一下: 1.在没有执行kill -USR1 `cat ${pid_path}`之前,即便已经对文件执行了mv命令也只是改变了文件的名称

linux命令 — lsof 查看进程打开那些文件 或者 查看文件给那个进程使用 lsof命令是什么? 可以列出被进程所打开的文件的信息.被打开的文件可以是 1.普通的文件,2.目录  3.网络文件系统的文件,4.字符设备文件  5.(函数)共享库  6.管道,命名管道 7.符号链接 8.底层的socket字流,网络socket,unix域名socket 9.在linux里面,大部分的东西都是被当做文件的…..还有其他很多 怎样使用lsof 这里主要用案例的形式来介绍lsof 命令的使用 1.列

前言: 无意间使用 kill -9 命令杀掉了nginx的主进程,当我再次使用 ./nginx -s reload 重新刷新nginx的时候,一直出现了下面的错误信息: nginx: [alert] kill(27905, 1) failed (3: No such process) 同时,执行命令 ./nginx -t 返回的结果如下: nginx: the configuration file /opt/nginx-1.4.7/conf/nginx.conf syntax is ok ngi

Nginx 是一个非常轻量的 Web 服务器,体积小.性能高.速度快等诸多优点.但不足的是也存在缺点,比如其产生的访问日志文件一直就是一个,不会自动地进行切割,如果访问量很大的话,将 导致日志文件容量非常大,不便于管理.当然了,我们也不希望看到这么庞大的一个访问日志文件,那需要手动对这个文件进行切割. 在 Linux 平台上 Shell 脚本丰富,使用 Shell 脚本加 crontab 命令能非常方便地进行切割,但在 Windows 平台上就麻烦一些了,刚才弄了好长时间,就在这里记录整理一下.

http://www.cnblogs.com/benio/archive/2010/10/13/1849935.html 偶然发现access.log有21G大,所以将其切割. Nginx 是一个非常轻量的 Web 服务器,体积小.性能高.速度快等诸多优点.但不足的是也存在缺点,比如其产生的访问日志文件一直就是一个,不会自动地进行切割,如果访问量很大的话,将 导致日志文件容量非常大,不便于管理.当然了,我们也不希望看到这么庞大的一个访问日志文件,那需要手动对这个文件进行切割. 在 Linux 平

Nginx命令 Nginx命令帮助如下 nginx -h nginx version: nginx/0.8.45 Usage: nginx [-?hvVt] [-s signal] [-c filename] [-p prefix] [-g directives] Options: -?,-h         : this help   // 帮助 -v            : show version and exit // 显示版本 -V            : show version

问题 nginx日志默认记录在一个文件access.log中,时间长了会导致日志文件特别大,甚至磁盘占满. 解决方案 使用以下方法,将access.log文件每天一个,然后清过15天以前的文件. 方法 创建clearNginxLog.sh文件 #!/bin/bash LOG_PATH="/data/nginx/log/" save_days=1 YESTERDAY=$(date -d "yesterday" +%Y%m%d) echo "---------

Nginx日志的指令主要有两条: log_format,设置日志的格式 access_log,指定日志文件的存放路径.格式和缓存大小 两条指令在Nginx配置文件中的位置可以在http{……..}之间,也可以在虚拟主机之间,即server(…….)两个大括号之间. log_format 语法如下: log_format name format [format …] name表示定义的格式名称(name名称在Nginx配置文件中是不能重复的) format表示定义的格式样式.log_format有

应用环境:生产环境中的Nginx服务器,由于访问日志文件增长速度非常快,日志太大会严重影响服务器效率.同时,为了 方便对日志进行分析计算,须要对日志文件进行定时切割.定时切割的方式有按月切割.按天切割.按小时切割等, 最常用的是按天切割. 切割原理:Nginx不支持像Apache 一样使用cronolog来轮循日志,但是可以用以下方案来实现: ①更改文件名: mv  /data/logs/access.log /data/logs/access_2017-12-20.log ②重建access.

1. 信号 Nginx 在管理 master 进程和 worker 进程时大量使用了信号.Linux 定义的前 31 个信号是最常用的,Nginx 则通过重定义其中一些信号的处理方法来使用吸纳后,如接收到 SIGUSR1 信号就意味着需要重新打开文件. 使用信号时 Nginx 定义了一个 ngx_signal_t 结构体用于描述接收到的信号时的行为: typedef struct { // 需要处理的信号 int signo; // 信号对应的字符串名称 char *signame; // 这个

 1.启动nginx的方式: cd /usr/local/nginx ls ./nginx -c nginx.conf 2.查看nginx的进程方式: [root@localhost nginx]# ps –ef | grep nginx [root@localhost nginx]# ps -ef | grep nginx root     21094     1  0 07:52 ?        00:00:00 nginx: master process ./nginx -c ngi

参考资料: Nginx中文文档: http://www.nginx.cn/nginxchscommandline Nginx的启动.停止.平滑重启.信号控制和平滑升级:http://zachary-guo.iteye.com/blog/1358312 命令行参数: 常用命令: -c filename:设置配置文件. -t :不运行,而仅仅测试配置文件.nginx 将检查配置文件的语法的正确性,并尝试打开配置文件中所引用到的文件. -s :传递一个信号,stop快速关闭,quit从容关闭,reop

五.Nginx服务.架构及其信号 (1)Nginx服务的查看 1.netstat -antp 查看Nginx是否在80端口运行: 2.ps aux|grep nginx 查看nginx相关进程: 发现如图Nginx开启了2个或以上的进程,分别是一个主进程(Master process)和一个或多个子进程(Worker process). 由此可知,Nginx有一个主进程文件,用于管理和影响(如关闭) 4 ~ 8个子进程,浏览器请求则由子进程来负责. Nginx worker模型如下: 主进程负责

nginx命令行参数 [user@host dir]$ /usr/local/nginx/sbin/nginx -hnginx version: nginx/1.8.0Usage: nginx [-?hvVtq] [-s signal] [-c filename] [-p prefix] [-g directives] Options: -?,-h : this help  查看帮助信息 -v : show version and exit 显示 nginx 的版本 -V : show vers

进程模型 Nginx分为Single和Master两种进程模型.Single模型即为单进程方式工作,具有较差的容错能力,不适合生产之用.Master模型即为一个master进程+N个worker进程的工作方式. 生产环境都是用master-worker模型来工作. master进程 我们知道在main函数中完毕了Nginx启动初始化过程,启动初始化过程中的一个重要环节就是解析配置文件.回调各个配置指令的回调函数.因此完毕了各个模块的配置及相互关联.在全部的这些重要及不重要的初始化完毕后.main

目录 进程结构图 信号量管理 Linux的信号量管理机制 利用信号量管理Nginx进程 配置文件重载原理 进程结构图 Nginx是多进程结构,多进程结构设计是为了保证Nginx的高可用高可靠,包含: master进程:父进程,负责worker进程的管理 worker进程:子进程,worker进程一般配置与服务器CPU核数相同,worker进程用来处理具体请求. cache进程:也是子进程,包括cache manager和cache loader进程,主要是反向代理做缓存使用. 注:多进程相对于多

kill 中的USR信号解释 USR1亦通常被用来告知应用程序重载配置文件:例如,向Apache HTTP服务器发送一个USR1信号将导致以下步骤的发生:停止接受新的连接,等待当前连接停止,重新载入配置文件,重新打开日志文件,重启服务器,从而实现相对平滑的不关机的更改. 在POSIX兼容的平台上,SIGUSR1和SIGUSR2是发送给一个进程的信号,它表示了用户定义的情况.它们的符号常量在头文件signal.h中定义.在不同的平台上,信号的编号可能发生变化,因此需要使用符号名称. kill -H

转自:网易博客 服务器的并发模型设计是网络编程中很关键的一个部分,服务器的并发量取决于两个因素,一个是提供服务的进程数量,另外一个是每个进程可同时处理的并发连接数量.相应的,服务器的并发模型也由两个部分构成:进程模型和连接处理机制.进程模型主要有以下3种模型: (1)单进程模式:这种模式的服务器称为迭代服务器,实现最简单,也没有进程控制的开销,cpu利用率最高,但是所有的客户连接请求排队等待处理,如果有一条连接时长过大,则其他请求就会被阻塞甚至被丢弃,这种模型也很容易被攻击,一般很少使用这种模型