Git基本概念及工作流介绍

未分类

git介绍

Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。Torvalds 开始着手开发 Git 来替代 BitKeeper,后者之前一直是 Linux 内核开发人员在全球使用的主要源代码工具。尽管最初 Git 的开发是为了辅助 Linux 内核开发的过程,但是我们已经发现在很多其他自由软件项目中也使用了 Git。例如 很多 Freedesktop 的项目迁移到了 Git 上。

Git基础

Git首先需要掌握的概念

  • 工作区:就是在电脑里能看到的目录
  • 版本库:工作区有一个隐藏目录.git,这个不算工作区,而是Git的版本库,版本库里面存了很多东西,其中最重要的就是暂存区(stage或index),Git为我们自动创建的第一个分支master,以及指向master分支的一个指针叫做HEAD
  • 远程库(中央仓库)

结构如下所示:

未分类

工作区内修改的代码提交到远程库需要三步:

  • git add把代码文件添加到暂存区
  • git commit把暂存区的内容提交到当前分支
  • git push把代码推到远程库

Git工作流

掌握工作流能更好的实现团队间通过远程库进行协作。

中心化的工作流

中心化的工作流需要远程库存在一个master分支即可

未分类

A和B同时对项目修改,A和B的本地都有了各自的历史,A先提交代码到远程库,不会发生问题,B再提交的时候就会产生冲突
远程库在这里作为中央仓库代表官方项目,因此它的提交历史应该被视作神圣不可更改的。如果开发者的本地提交和中央仓库分叉,Git会拒绝将他们的修改推送上去,因为这会覆盖官方提交
冲突解决办法:先将代码拉到本地,再执行rebase操作

完整命令

git pull --rebase origin master

合并过程如有冲突,需手动进行修改,可以用git status查看当前工作区状态
合并完成后

git push origin master

Feature分支的工作流

未分类

团队成员在不同的分支上修改不同功能,等待功能模块完成后再合并到主分支。隔离功能开发后,通过pull request合并代码,也可以和其他成员沟通,其他成员对代码查看和提问。

我们项目组中使用这种工作流

GitFlow工作流

GitFlow工作流围绕项目发布定义了一个严格的分支模型,方便管理大型项目。和功能分支相比,这种工作流没有增加任何新的概念或命令。除了功能分支之外,它还为准备发布、维护发布、记录发布分别是用了单独的分支。
它有两个分支来记录项目历史。master分支存储官方发布历史,develop分支整合功能分支,这两个分支不直接交互。
开发分支:如果develop分支的新功能足够发布,可以从develop分支fork一个发布分支,只有和发布相关的任务应该在这个分支进行,如修复bug、生成文档等。完成发布后,发布分支合并会master和develop分支

维护分支,通常有以下约定:

  • 从develop创建
  • 合并进master分支
  • 命名规范release-*

Fork工作流

未分类

Fork工作流与其他工作流不同的是,每个开发者都有一个远程代码库和本地代码库,Fork工作流的主要优点在于贡献可以轻易地整合进项目,而不需要每个人都推送到单一的远程库,开发者将代码推到个人仓库后在告知中央仓库需要合并代码
项目管理员执行合并操作时可以有两步:

直接检查PullRequest中检查代码
将代码拉取到本地仓库然后手动合并

以上对Git使用做了大致总结,欢迎补充。

鲁大师问:Git最常用和最不常用的5个命令分别是什么?
我答:
最常用的

git status
git log --oneline
git commit
git fetch
git merge

最不常用的

git pull
git add
git rebase
git clone
git reflog

Ansible安装配置zabbix-agent

Ansible Role: zabbix-agent

安装zabbix客户端

介绍

zabbix(音同 z?bix)是一个基于WEB界面的提供分布式系统监视以及网络监视功能的企业级的开源解决方案。
zabbix agent需要安装在被监视的目标服务器上,它主要完成对硬件信息或与操作系统有关的内存,CPU等信息的收集。zabbix agent可以运行在Linux,Solaris,HP-UX,AIX,Free BSD,Open BSD, OS X, Tru64/OSF1, Windows NT4.0, Windows (2000/2003/XP/Vista)等系统之上。

官方地址: https://www.zabbix.com
官方文档地址:https://www.zabbix.com/documentation/3.2/manual

要求

此角色仅在RHEL及其衍生产品上运行。

测试环境

ansible 2.3.0.0
os Centos 6.7 X64
python 2.6.6

角色变量

software_files_path: "/opt/software"
software_install_path: "/usr/local"

zabbix_agent_version: "3.2.6"

zabbix_agent_file: "zabbix-{{ zabbix_agent_version }}.tar.gz"
zabbix_agent_file_path: "{{ software_files_path }}/{{ zabbix_agent_file }}"
zabbix_agent_file_url: "https://jaist.dl.sourceforge.net/project/zabbix/ZABBIX%20Latest%20Stable/{{ zabbix_agent_version }}/{{ zabbix_agent_file }}"

zabbix_agent_repo_url: "http://repo.zabbix.com/zabbix/3.2/rhel/6/x86_64/zabbix-release-3.2-1.el6.noarch.rpm"
zabbix_agent_packages:
  - "zabbix-agent-{{ zabbix_agent_version }}-1.el6"

zabbix_agent_user: zabbix
zabbix_agent_group: zabbix

zabbix_agent_install_from_source: false

zabbix_agent_source_dir: "/tmp/{{ zabbix_agent_file | replace('.tar.gz','') }}"
zabbix_agent_source_configure_command: >
  ./configure
  --prefix={{ software_install_path }}/zabbix-{{ zabbix_agent_version }}
  --enable-agent

zabbix_agent_conf_path: "/etc/zabbix" 
zabbix_agent_logs_path: "/var/log/zabbix"

zabbix_agent_hostname: "{{ ansible_hostname | d() }}"
zabbix_agent_server_host: "127.0.0.1"

依赖

None

github地址

https://github.com/kuailemy123/Ansible-roles/tree/master/zabbix-agent

Example Playbook

---
# 源码安装
- hosts: node2
  roles:
   - { role: zabbix-agent, zabbix_agent_install_from_source: true, zabbix_agent_server_host: "192.168.77.130" }

# rpm包安装
- hosts: node3
  roles:
   - { role: zabbix-agent, zabbix_agent_server_host: "192.168.77.130" }

使用

~]# /etc/init.d/zabbix-agent 
Usage: /etc/init.d/zabbix-agent {start|stop|status|restart|help}

    start        - start zabbix_agentd
    stop        - stop zabbix_agentd
    status        - show current status of zabbix_agentd
    restart        - restart zabbix_agentd if running by sending a SIGHUP or start if not running
    help        - this screen

配置WordPress上传图片/附件文件同步到UPYUN又拍云存储

这几天笔者一直在折腾UPYUN又拍云存储相关的问题且整理到不少的基础文章,昨天已经创建且绑定域名,并且又拍云还支持一键快速配置SSL证书。对于一般的站长而言,我们希望网站速度打开快一些,这样用户体验会比较好,如果在本身的服务器资源比较固定限制的时候,我们就要寻求细微的改善,比如将静态资源与网站分离,一般会使用到第三方云存储+CDN加速。

因为考虑到UPYUN又拍云免费空间支持HTTPS流量,所以暂时就准备将占用资源较大的图片资源单独存放到又拍云存储中,这样就减低页面的加载资源提高速度。我们可以实现的方法有很多种,比如可以手工将图片传到云存储空间中,然后编辑文章的时候调用图片,或者采用W3 Total Cache缓存插件结合FTP同步上传图片。

在这篇文章中,我准备使用hacklog remote attachment upyun插件,实现WordPress附件图片文件上传到又拍云存储中,然后直接从又拍云存储调用图片,一来可以降低服务器的存储空间,二来可以提高网站打开速度,毕竟这类第三方存储空间具备CDN加速,应该是比自己服务器速度快。

未分类

第一、 WordPress同步又拍云插件

插件地址:https://github.com/ihacklog/hacklog-remote-attachment-upyun

目前这款插件并没有在WordPress官方平台中,以前有一款老版本在的,这款比较新的插件提交在GITHUN上,我们下载后安装到当前WordPress网站中。

第二、 配置同步又拍云插件准备工作

1、如果我们直接看到这篇文章的,那需要创建一个又拍云存储空间,如果我们域名有BA过的,可以设定绑定自己的域名,这样觉得更加专业一点点,也可以选择启动SSL证书,具体可以参考这篇文章。

2、开启表单API

未分类

因为我们上传的图片、附件文件会直接上传到又拍云存储中,所以需要开启API,这样不经过本地服务器,直接传到又拍云存储空间中。

3、开启防盗链

未分类

如果我们附件文件较大,或者希望启动防盗链,可以直接开启Token 防盗链,设置一个密钥,记下来,等会设置需要,如果不希望启动那就不管了。

第三、 又拍云同步WordPress插件设置

1、管理员、表单API设置

未分类

根据我们创建的云存储空间设置空间名称、操作员用户名和密码。以及我们开启的API密钥,其他参数默认。如果防盗链设置密钥后,就填写,没设置启动就留空。

2、设置URL和路径

未分类

上面几行的参数都默认即可,主要是最后这三行,远程URL是我们自定义的域名,以及在服务器和存储空间保存文件的路径。

第四、 WordPress站点文件的路径定向

因为我们即将图片和附件都采用又拍云存储空间上的,如果我们是新网站那就不用管,但是已经本地有存储图片的,我们需要全部转移拷贝一份到远程空间中。这里我们直接用FTP链接到又拍云,然后对应路径传上去。

未分类

理论上我们需要将全站本地地址的目录替换成又拍云的绑定空间的地址,但是这个插件提供一键转移,点击后直接就替换掉了。刷新页面,我们可以看到当前的全部使用的又拍云空间存储地址文件。

第五、 小结

1、这个hacklog remote attachment upyun插件能够和又拍云完美结合,将WordPress附件文件传到存储中,使得静态文件完全调用又拍云存储的,提高网站速度降低资源占用。

2、唯一不足的是上传文件完全到又拍云存储中,本地没有同步一份,如果能给用户选择本地也保存一份这样对于数据的安全会更好一些。这样完全是在又拍云,如果,我们定期也需要将又拍云存储文件备份到本地,确保数据的安全。

解决WordPress的Fatal Error: Out of Memory

WordPress 偶尔出现 502 Bad Gateway 错误,通过查看日志,发现是 Fatal Error: Out of Memory 错误,也就是内存不足导致的,最好的解决方法就是直接升级服务器配置啦,如果你是VPS 或者 是共享主机,可以尝试下面的方法来解决:

方法一:You can even consider adding a line in .htaccess file which will resolve the issue.

php_value memory_limit 256M

就是在 .htaccess 文件中加上红色的那行字

方法二:Add this to your wp-config.php file:

define (‘WP_MEMORY_LIMIT’, ‘256M’ );

在你的 wp-config.php 文件中加上红色的那行字

方法三:wp-settings.php,编辑这个文件,修改define(‘WP_MEMORY_LIMIT’, ’32M’);为

define(‘WP_MEMORY_LIMIT’, ‘256M’);

方法四:在你的博客目录中添加一个 php.ini 文件,并且写入下面那行

memory_limit=256M

方法五:其实是方法四升级版:在你的博客目录中添加一个 php.ini 文件,并且写入下面的内容

register_globals=Off
safe_mode=off
magic_quotes_gpc=On
allow_url_include=Off
file_uploads=on
memory_limit=256M
max_executi alt=90
post_max_size=10M
upload_max_filesize=10M
max_input_time=300

如果以上加大内存的方法,还是不能够解决 Fatal Error: Out of Memory ,那你的WordPress可能某个插件 或 个功能,真的很耗内存,可以尝试用「WordPress插件:P3,找出拖慢网站的插件」排查。

CentOS LNMP WordPress自动更新需填写FTP解决方法

无论是使用阿里云还是其他云 VPS 下的 Linux + LNMP 一键安装包环境,安装 WordPress 后,遇上提示更新升级的时候,都会出现需要填写 FTP 相关信息的情况,相当不方便。不过,根据 LNMP 作者军哥的博客提示,只需要在服务器内做一些文件权限的修改变可以。

这个问题的产生,主要是网站目录的权限执行身份非文件属主身份。

解决方法如下:

假设你的 WordPress 安装目录为 /home/wwwroot/lnmp.org

用 Putty 登录 Linux VPS ,执行:chown -R www /home/wwwroot/lnmp.org

执行上面的命令就可以将 /home/wwwroot/lnmp.org 下所有文件的属主改为 www ,这样就可以解决自动更新必须填FTP的问题。

基本上按以上方法就可以解决问题,如果还不能正常成功更新,可以尝试修改 wp-config.php 文件

在 wp-config.php 中加入一行代码

define('FS_METHOD', "direct");

如此就能可以在后台点击更新升级。

使用docker-compose来部署WordPress

很早的时候想维护一个个人Blog,一开始通过 github home page + jekyll,奈何没精力再去把ruby玩溜,自己也不是个擅长改写前端页面的人,无疾而终。今天终于鼓起勇气,买了服务器和域名,部署了wordpress,毕竟wordpress易用易上手,模板也多,也就懒得自己改了。既然本Blog是运行在Docker之上的,那第一篇文章也就来说说这个吧。

部署方式介绍

  • 我的服务器安装的是Arch Linux,自己也是比较喜欢这个极简的Linux发行版。
  • 我使用了docker-compose来做镜像编排工具,nginx,mysql(mairadb),wordpress分别运行于不同的容器。
  • 托上面两个先决条件的福,下面的内容大家根据自己的实际环境,酌情选择。

准备工作

安装Docker

托Arch Linux的福,安装Docker非常简单。

pacman -S docker

安装docker-compose

同样是托Arch的福,安装依旧简单粗暴。

pacman -S docker-compose

准备配置

首先我们需要做的是准备好docker wordpress运行的用户,执行以下命令,添加一个叫wordpress的新用户,将它添加到docker用户组,并为它设置密码

useradd -m -s /bin/zsh wordpress
usermod -a -G docker wordpress
passwd wordpress

紧接着,创建一些目录,保存docker-compose配置文件,存储运行产生的文件,让数据库落地到本机而不是容器,执行以下命令

su - wordpress
cd
mkdir wordpress-compose
touch docker-compose.yml
mkdir -p wordpress-compose/db-data
mkdir -p wordpress-compose/logs/nginx
mkdir -p wordpress-compose/nginx
mkdir -p wordpress-compose/wordpress

这些目录和文件的功能分别如下:

目录或文件 含义

  • wordpress-compose 容器相关根目录
  • wordpress-compose/db-data 数据库数据存储目录
  • wordpress-compose/logs/nginx nginx存储目录
  • wordpress-compose/nginx nginx配置文件
  • wordpress-compose/wordpress wordpress本体,因为安装插件等会改变php文件

接下来我们编写必要的nginx配置文件。在wordpress-compose/nginx下新建wordpress.conf文件,文件中写入下面这些配置,一个很经典的php-fpm的nginx配置文件。

server {
    listen 80;
    server_name www.gsgtzq.com;

    root /var/www/html;
    index index.php;

    access_log /var/log/nginx/wordpress-access.log;
    error_log /var/log/nginx/wordpress-error.log;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ .php$ {
        try_files $uri =404;
        fastcgi_split_path_info ^(.+.php)(/.+)$;
        fastcgi_pass wordpress:9000;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO $fastcgi_path_info;
    }
}

接下来就是docker-compose配置文件的编写了,首先将工作目录切换至刚刚创建的wordpress-compose目录,用自己熟悉的编辑器打开docker-compose.yml文件。

vim docker-compose.yml

先是nginx部分,我使用最新的nginx镜像,暴露80端口给本机,挂载conf.d、log、/var/www/html目录到本机,连接nginx和wordpress容器。

nginx:
        image: nginx:latest
        ports:
                - '80:80'
        volumes:
                - ./nginx:/etc/nginx/conf.d
                - ./logs/nginx:/var/log/nginx
                - ./wordpress:/var/www/html
        links:
                - wordpress
        restart: always

然后是mysql部分,我使用了mairadb的最新镜像,挂载mysql数据存储点到本机,链接mysql和wordpress容器,通过环境变量设置mysql的默认root密码。

mysql:
        image: mariadb:latest
        volumes:
                - ./db-data:/var/lib/mysql
        environment:
                - MYSQL_ROOT_PASSWORD=123345
        restart: always

最后是wordpress本体,我使用wordpress:php7.1-fpm的镜像,挂载/var/www/html目录到本机,链接连接mysql容器和wordpress,并且使用环境变量,指定mysql主机名,表前缀,和库名。

wordpress:
        image: wordpress:php7.1-fpm
        volumes:
                - ./wordpress:/var/www/html
        environment:
                - WORDPRESS_DB_NAME=wpdb
                - WORDPRESS_TABLE_PREFIX=wp_
                - WORDPRESS_DB_HOST=mysql
        links:
                - mysql
        restart: always

到此位置,docker-compose的配置文件全部编写完毕。

启动容器

编排文件已写完,接下来启动容器即可。

docker-compose up -d

当收到三个done以后,编排好的容器就正式启动了,我们现在可以访问本机的IP或域名来访问wordpress了。
我还可以使用下面这些命令来检查容器的运行情况,注意,docker-compose命令只有在刚才写好配置文件的目录下执行才有效果。

命令 含义

  • docker ps -a 查看当前所有运行的docker容器
  • docker-compose logs wordpress 查看wordpress容器的日志
  • docker-compose ps 查看当前编排好的应用的所有容器状态
  • docker-compose top 查看当前编排好的应用中各容器中的进程情况

具体还有一些其他的办法,可以通过查阅docker手册和docker-compose文档来进行使用。

结束语

到此为止,使用docker来运行wordpress已经完成,从开始折腾Docker到现在少说1个半月过去了,也是学习到了非常多的东西,目前而言公司的项目想用起docker来还是有不少难度,我思考了很多使用docker对传统部署和开发带来冲击的问题,例如对开发人员的要求其实高了很多,尤其是在运维这块,基础环境部署等等……但很希望自己能把它用好了,开发受益,运维也受益。

WordPress迁移网站目录时如何修改数据库信息

当我们搭建好网站后,如果需要给网站更换主机空间和迁移网站目录,也就是站长常说的“网站搬家”,对于新手站长来说可能会比较复杂,最近很多用户咨询:主机上的网站目录如何迁移,下面为大家详细介绍Wordpress迁移网站目录数据库信息的修改方法!

1、登陆数据库修改下配置然后移动到站点根目录

未分类

WordPress迁移网站目录数据库信息的修改方法

2、修改两个字段siteurlhome

未分类

修改两个字段siteurlhome

3、点击执行操作即可

未分类

点击执行操作

Ubuntu 16.04使用Docker部署WordPress

未分类

介绍

WordPress是基于PHP和MySQL的著名内容管理系统,根据GNU GPLv2(或更高版本)的规定分发。通常它安装在像Apache这样的Web服务器上,但也可以在使用Docker容器构建的隔离环境中运行它,特别是使用Docker Compose。本教程的主题时使用Ubuntu 16.04作为操作系统。

入门

首先,有必要安装Docker和Docker Compose。 在Ubuntu 16.04中,这可以通过两种不同的方式完成:

  • 设置存储库并从中安装,方便安装和升级任务
  • 下载DEB包并手动安装; 还允许您完全手动管理升级

在本教程中,Docker将使用存储库方法进行安装。 因此,您需要安装软件包以允许apt通过HTTPS使用存储库:

# apt install -y --no-install-recommends apt-transport-https ca-certificates curl software-properties-common

接下来,添加Docker的官方GPG密钥:

$ curl -fsSL https://apt.dockerproject.org/gpg | sudo apt-key add -

密钥ID应为58118E89F3A912897C070ADBF76221572C52609D,因此验证:

$ apt-key fingerprint 58118E89F3A912897C070ADBF76221572C52609D

使用以下命令设置稳定存储库:

# add-apt-repository 
       "deb https://apt.dockerproject.org/repo/ 
       ubuntu-$(lsb_release -cs) 
       main"

现在可以安装Docker了。

首先,更新apt包索引:

# apt update

然后:

# apt install docker-engine
This will install docker and its daemon should start automatically.

安装 Docker Compose

安装Docker后,下一步是安装Compose,这是此过程所必需的。 只需执行命令:

# curl -L https://github.com/docker/compose/releases/download/1.11.1/docker-compose-`uname -s`-`uname -m` > /usr/local/bin/docker-compose

更改docker-compose binary的权限:

# chmod +x /usr/local/bin/docker-compose

测试:

$ docker-compose --version

现在Docker和Docker Compose已安装并可以使用。

安装 MariaDB

创建一个空目录,例如docker_wordpress。
然后改成:

$ cd docker_wordpress

创建一个docker-compose.yml文件,该文件将启动您的WordPress博客和一个单独的MySQL实例与卷挂载数据持久性。
在此文件中,输入以下文本:

version: '2'

services:
   db:
     image: mysql:5.7
     volumes:
       - db_data:/var/lib/mysql
     restart: always
     environment:
       MYSQL_ROOT_PASSWORD: wordpress
       MYSQL_DATABASE: wordpress
       MYSQL_USER: wordpress
       MYSQL_PASSWORD: wordpress

   wordpress:
     depends_on:
       - db
     image: wordpress:latest
     ports:
       - "8000:80"
     restart: always
     environment:
       WORDPRESS_DB_HOST: db:3306
       WORDPRESS_DB_PASSWORD: wordpress
volumes:
    db_data:

接下来,在docker_wordpress文件夹中,使用以下命令启动容器:

# docker-compose up -d

这很简单,因为Docker团队确保一切都配置良好。 事实上,WordPress Docker容器中有一个脚本,它从wordpress容器中读取MYSQL_ROOT_PASSWORD变量,并使用它来连接到WordPress。

安装 PHPMyAdmin

添加PHPMyAdmin与添加数据库没有什么不同。在docker-compose.yml文件中,只需在“services”部分添加以下行:

phpmyadmin:
image: corbinu/docker-phpmyadmin
  links:
    - wordpress_db:mysql
  ports:
    - 8181:80
  environment:
    MYSQL_USERNAME: root
    MYSQL_ROOT_PASSWORD: wordpress

保存这些配置并运行docker-compose命令来创建和启动容器:

# docker-compose up -d

配置几乎完成! 使用Web浏览器,转到URL:http://SERVER_IP:8181。 它将显示PhpMyAdmin的登录屏幕。 使用在docker-compose.yml文件中配置的相同凭据进行登录。

总结

就这样!现在服务器正在运行WordPress安全和隔离的容器。虽然Docker是“开发人员工具”,但它可以用于各种项目,就像这里所示。 当然,配置文件可以通过更细致的细节进行编辑和定制,例如DNS部分和一些硬件限制,如CPU和内存使用。 祝你玩得开心!

wordpress启用memcached加速访问

Memcached 是什么?

Memcached 是一种高性能的分布式内存对象缓存系统。在动态应用,Memcached 既能提高访问的速度,同时还减低了数据库的负载。

Danga Interactive 为提升 LiveJournal.com 的速度研发了 Memcached。目前,LiveJournal.com 每天已经在向一百万用户提供多达两千万次的页面访问。而这些,是由一个由 Web 服务器和数据库服务器组成的集群完成的。Memcached 几乎完全放弃了任何数据都从数据库读取的方式,同时,它还缩短了用户查看页面的速度、更好的资源分配方式,以及 Memcache 失效时对数据库的访问速度。

WordPress 和 Memcached

由于 WordPress 默认支持 Object Cache,所以在 WordPress 实现 Memcached 就是使用 Memcached 把 WordPress 的 Object Cache 写到内存中去,下次直接从内存中读取。相比直接从数据库去读取数据,或者从 Object Cache 数据存到文件,然后从硬盘中读取,Memcached 有很大的速度优势。

WordPress 如何启用 Memcached 缓存

  1. 需要你的服务器支持,就是你的 PHP 需要安装上 Memcached 相关的扩展,注意 PHP 有两个扩展:PHP Memcache 扩展 和 PHP Memcached 扩展,两者仅仅相差一个字母 D,你可以通过 phpinfo() 这个 PHP 函数来检测,你安装的是哪个扩展。
  2. 下载object-cache.php ,点击这里下载
  3. 把下载的:object-cache.php 复制到 wordpress的wp-content目录,这里值得注意不是 wp-content/plugins/

WordPress 会自动检查在 wp-content 目录下是否有 object-cache.php 文件,如果有,直接调用它作为 WordPress 对象缓存机制。查询数据次数明显减少

开启了之前 0.201 秒内总共 30次查询

开启之后 0.205 秒内总共 9 次查询

varnishstat – 查看varnish统计信息命令

varnishstat是一个查看当前varnish实例的实时运行状态信息。命令以及参数如下:

varnishstat [-1] [-f <glob>] [-h] [-j] [-l] [-n <dir>] [-N <filename>] [-t <seconds | off>] [-V ] [-X]

以下选项可用:

  • -1 不再显示不断更新的显示,而是将统计信息打印到stdout。
  • -f Field inclusion glob. Use backslash to escape characters. If the argument starts with ‘^’ it is used as an exclusion glob. Multiple -f arguments may be given, and they will be applied in order.
  • -h 显示帮助信息
  • -j 统计信息为JSON格式输出到stdout。
  • -l 列出与-f选项一起使用的可用字段。
  • -n 指定varnishd工作目录(也称为实例名称)以获取日志。如果未指定-n,则使用主机名。
  • -N 指定一个陈旧的VSM实例的文件名。使用此选项时,放弃检查被禁用。
  • -t
    在初始VSM连接返回错误之前超时。如果设置VSM连接在0.5秒钟内重试这段时间。如果为零,则仅尝试连接一次,如果不成功,将立即失败。如果设置为“关闭”,连接将不会失败,允许该实用程序启动并等待不明确地显示该Varnish实例。默认为5秒。
  • -V 打印版本信息
  • -x 输出xml格式到stdout

在服务端使用varnishstat命令之后,会出现如下输出,并且每秒刷新一次。

21+20:34:26
Hitrate ratio:        9        9        9
Hitrate avg:     0.6641   0.6641   0.6641

   636637687       499.06   337.12 client_conn - Client connections accepted
   637516286       511.04   337.58 client_req - Client requests received
   384410700       345.35   203.56 cache_hit - Cache hits
      397324         1.00         0.21 cache_hitpass - Cache hits for pass
   239345712       158.70   126.74 cache_miss - Cache misses
     4835741         0.00         2.56 backend_conn - Backend conn. success
   248259966       154.71   131.46 backend_reuse - Backend conn. reuses
      242608         0.00         0.13 backend_toolate - Backend conn. was closed
   248512413       160.70   131.59 backend_recycle - Backend conn. recycles
        1530         0.00         0.00 backend_retry - Backend conn. retry
       23931         0.00         0.01 fetch_length - Fetch with Length
   249781348       162.69   132.27 fetch_chunked - Fetch chunked
       15614         0.00         0.01 fetch_close - Fetch wanted close
         589          .            .   n_sess_mem - N struct sess_mem
          39          .            .   n_sess - N struct sess
       34325          .            .   n_object - N struct object
       34492          .            .   n_objectcore - N struct objectcore
       84074          .            .   n_objecthead - N struct objecthead
         216          .            .   n_waitinglist - N struct waitinglist
          77          .            .   n_vbc - N struct vbc
         219          .            .   n_wrk - N worker threads
      120362         0.00         0.06 n_wrk_create - N worker threads created
      576844         0.00         0.31 n_wrk_queued - N queued work requests
           1          .            .   n_backend - N backends
   239311376          .            .   n_expired - N expired objects
   213406425          .            .   n_lru_moved - N LRU moved objects
         194         0.00         0.00 losthdr - HTTP header overflows
   632853774       503.05   335.12 n_objwrite - Objects sent with write
   636660065       512.04   337.13 s_sess - Total Sessions
   637516287       511.04   337.58 s_req - Total Requests
     3283172         2.99         1.74 s_pipe - Total pipe
    10476261         3.99         5.55 s_pass - Total pass
   249820893       162.69   132.29 s_fetch - Total fetch
210331163670    169330.83    111376.73 s_hdrbytes - Total header bytes
1121952708903    992663.81    594107.97 s_bodybytes - Total body bytes
   636390701       511.04   336.99 sess_closed - Session Closed
     1746856         0.00         0.93 sess_linger - Session Linger
     5168683         2.00         2.74 sess_herd - Session herd
 38768640297     30143.36     20529.17 shm_records - SHM records
  3367627420      2570.17      1783.26 shm_writes - SHM writes
      487720         4.99         0.26 shm_flushes - SHM flushes due to overflow
    10953952        30.94         5.80 shm_cont - SHM MTX contention

第一行表示的是varnish的运行时常,上面显示是21天。

  • Hitrate ratio和Hitrate avg表示的则是在多少秒内的命中率。有几个比较重要的统计数据

  • cache-hit:缓存命中次数

  • miss-hit:未命中次数

  • worker threads:当前工作线程的数量

  • expired objects:代表过期对象的个数

  • LRU nuked objects:代表缓存可使用的内存以达上线而不得不移除的对象个数

  • LRU moved objects:代表LRU策略被移动的对象个数

  • Total header bytes:代表缓存的请求头对象的大小

  • Total body bytes:代表缓存的请求体对象大小