早在Docker 1.6.0之际，Docker官方的工程师即宣称：1.7.0版本将会带来很大的变化，包括：Docker的bug修改以及功能添加；并且还体现在Docker的架构上，如网络模块等。

话不多说，赶紧让我们进入Docker 1.7.0的深度解析。从Docker的版本变更日志来看，Docker 1.7.0在四个方面会有或多或少的变动，分别是：Docker运行时（Runtime），Docker的代码变化，Docker的builder模块，以及Docker的bug修复。

本文主要涉及Docker 1.7.0的runtime。

1. 增添了一个仍然处于试验阶段的特性：支持out of process的数据卷插件。

何为试验性质的特性，换言之Docker的这部分特性还不支持在生产环境中采用，这些特性更多的希望用户仅仅在测试环境，以及沙箱环境中采用。试验性特性完全是Docker 1.7.0的一大亮点。

在以上的基础上理解out-of-process，就容易很多，插件本身与Docker Daemon无耦合，即插即用，在Docker Daemon范畴之外发挥作用。

目前Docker的试验性特性可以从两个方面来描述，首先Docker目前已经支持用户自定义第三方插件的使用；另外在这基础上，Docker自身支持了容器数据卷volume插件。此外，Docker还定义了一整套与插件相关的API，方便用户使用。当然，相信后续在该领域，不论是Docker官方，还是整个社区，都会不断有新的插件诞生。值得一提的，在数据卷volume插件方面，出现了Flocker的身影，这也意味着容器的数据存储问题，真正被提上台面，并由相应合理的解决方案。

2.从docker daemon的角度，添加了userland-proxy的起停开关。

首先介绍userland-proxy一直以来的作用。众所周知，在Docker的桥接bridge网络模式下，Docker容器时是通过宿主机上的NAT模式，建立与宿主机之外世界的通信。然而在宿主机上，一般情况下，进程可以通过三种方式访问容器，分别为：:, :,以及<0.0.0.0>:。实际上，最后一种方式的成功访问完全得益于userland-proxy，即Docker Daemon在启动一个Docker容器时，每为容器在宿主机上映射一个端口，都会启动一个docker-proxy进程，实现宿主机上0.0.0.0地址上对容器的访问代理。

当时引入userland-proxy时，也许是因为设计者意识到了0.0.0.0地址对容器访问上的功能缺陷。然而，在docker-proxy加入Docker之后相当长的一段时间内。Docker爱好者普遍感受到，很多场景下，docker-proxy并非必需，甚至会带来一些其他的弊端。

影响较大的场景主要有两种：

第一，单个容器需要和宿主机有多个端口的映射。此场景下，若容器需要映射1000个端口甚至更多，那么宿主机上就会创建1000个甚至更多的docker-proxy进程。据不完全测试，每一个docker-proxy占用的内存是4-10MB不等。如此一来，直接消耗至少4-10GB内存，以及至少1000个进程，无论是从系统内存，还是从系统CPU资源来分析，这都会是很大的负担。

第二，众多容器同时存在于宿主机的情况，单个容器映射端口极少。这种场景下，关于宿主机资源的消耗并没有如第一种场景下那样暴力，而且一种较为慢性的方式侵噬资源。

如今，Docker Daemon引入- -userland-proxy这个flag，将以上场景的控制权完全交给了用户，由用户决定是否开启，也为用户的场景的proxy代理提供了灵活性。

3. docker exec命令增加- -user参数，用户控制docker exec在容器中执行命令时所处的用户。

自从docker 1.3.0引入docker exec之后，用户对容器的操纵能力被大大释放，容器对用户而言不再是一个运行的黑盒。然而，docker exec带来巨大好处的同时，我们也能看到这其中的一些瑕疵，当然Docker社区也在不断地完善docker exec。

首先，docker exec在容器中运行的进程会以root权限运行，在权限方面缺乏灵活性的同时，容器的安全很有可能失控。参数- -user恰好弥补了这方面的不足。其次，docker exec的存在打破了容器内进程呈现树状关系的现状，而设计初期Docker容器的很多概念均以树的思想从init process入手，因此目前docker exec的进程并不能和原生态容器进程完全一样地被Docker Daemon管理。

4. 增强Docker容器网关地址的配置广度。

Docker 1.7.0发布之前，在bridge桥接模式下，Docker容器的网关地址是默认生成的，一般为Docker环境中的docker0网桥地址。从容器通信的角度而言，默认的方式已经可以满足需要。但是，我们依然可以发现，这种模式存在一些弊端，比如网络配置的灵活性以及网络安全性。

Docker容器的网络一直广受关注，缺乏可配置的特性，在如今的软件发展中，几乎就意味着封闭。 –default-gateway 以及–default-gateway-v6 这两个参数，很大程度上提高了用户自定义容器网络的灵活性，用户更多场景的覆盖，似乎从Docker的发展中若影若现。结合最近几次新版本，功能的增强与丰富，不难猜测，Docker的企业化以及生产化，已经更上一层楼。

默认网关的设置，为什么说会和容器的网络安全相关呢？过去很长一段时间内，docker0作为容器的网关地址，这种方式将容器与宿主机的耦合关系体现的很彻底。docker0作为宿主机上的网络接口，充当容器与宿主机的桥梁。然而，也正是桥梁的存在，使得容器内部进程很容易穿过网关，到达宿主机，此过程并非对用户透明。

5. 容器CFS quota的支持

完善Docker对内核cgoups的支持，指的是对于一个组内的进程组在一个周期内被内核CFS调度算法调度的时间限额，单位为微秒。该配置项在cgroups中相应的文件为/sys/fs/cgroup/cpu/cpu.cfs_quota_us。

6. 容器磁盘IO限制的支持

众所周知，容器将会为用户提供一个隔离的运行环境，容器内部的进程或者进程组使用资源时将受到限制，这样的资源，包括：内存资源（物理内存以及swap），CPU资源（CPU时间片以及CPU核等），磁盘空间资源等，以上这部分内容或多或少，Docker的新版本之前或多或少都可以实现，然而隔离维度依旧不够完美，这次Docker添加了—blkio-weight参数，实现对容器磁盘IO限制的支持。隔离更加完备，用户也不再需要担心容器间磁盘IO资源的竞争。

7. ZFS支持

Docker 1.7.0 正式宣布支持ZFS文件系统。此举也意味着Docker容器文件系统的支持从原先的5种增加到6种。此前，Docker支持aufs，devmapper，btrfs，ovelayfs，vfs（用于支持volume），如今添加对ZFS的支持。ZFS的支持，不禁让人联想到与Docker的数据卷volume插件的Flocker。错进错出，似乎关系较为微妙。

值得一提的是，除了支持ZFS之外，笔者发现在负责容器文件系统的graph模块中，添加了driver_windows.go,虽然内容极其简易，并非完全实现对windows的全盘支持，但是至少让大家看到Docker支持windows的步伐在不断迈进。

8. docker logs的功能扩展

查看容器日志，相信很多Docker爱好者都体验过，这也是用户查看容器运行状态的重要依据。

可以简单了解Docker容器日志的原理：对于每一个创建的Docker容器，Docker Daemon均会在内部创建一个goroutine来监听容器内部进程的标准输出stdout以及标准错误stderr，并将内容传递至日志文件中。每当用户发通过Docker Client发起查看容器日志的请求docker logs之后，Docker Daemon会将日志文件的内容传递至Docker Client显示。

docker logs的发展，几乎可以分为4个阶段：Docker诞生初期的原生态日志打印；允许用户follow容器的日志；开启容器容器的tail功能，以及容器日志的since功能，打印从某一个时间戳开始之后的容器日志。

虽然容器日志的功能在逐渐增强，但是不可否认的是，容器日志是容器本身与Docker Daemon耦合最大的模块之一，而这涉及Docker设计之初的计划，绝非完美，但的确是短时间内最易用的方案。

9. 容器与宿主机共享UTS命名空间的支持

不同的场景下，容器与宿主机可以完全隔离，容器也可能与宿主机存在共享信息的情况，Docker网络的host模式就是一个很好的例子，该模式下的容器共享宿主机的网络命名空间。

共享UTS命名空间的支持，意味着容器与宿主机的关系越来越微妙。也许目前很多Docker爱好者已经习惯容器与宿主机完全隔离的运行，当然也会有一些用户曾经抱怨完全隔离的运行环境并不能平滑的将传统遗留业务容器化。那么，目前Docker在兼顾两者的情况下，更多地在满足后者的需求，不久的将来，Docker容器的运用场景必将更加丰富，这也是Docker走向企业化以及生产化必须要趟的路。

总体而言，Docker 1.7.0给笔者的感受是：功能上逐渐向企业需求靠拢，在production-ready的路上不断优化，另外在安全方面在不涉及内核基础上也不断完善。

来源：http://dockone.io/article/451

我的一个朋友在参观一个办公室时发现其雇员都在使用 tmux 和 vim 工具来开发 Ruby 项目。他很好奇为什么人们宁可放弃鼠标输入的便利而选择使用控制台版本的 vim 进行工作。

最终我发现这个是一个非常好的工作方式。起初使用控制台 vim 强迫我去正确地学习 vim 快捷键（motion commands）。结合盲打后，vim 提供了在多文件以及多代码行跳转的强大指令，这无疑比使用鼠标更加高效。

我习惯于将终端工具与代码编辑器平铺在一起。在 web 开发工作通常需要一个控制台用于输入 ad-hoc 命令，一个控制台操作数据库，以及一个控制台查看日志。同时我的一些项目还会使用测试工具来对有修订的文件进行自动化测试，因此我也希望同时能看到这些测试执行的状态。

vim 提供了很多插件可以将上述功能集成在一起，但我更喜欢 vim/tmux 这个组合。这是个可视化的操作工具。

通用这种方式使用命令行工具，我们可以高效地打造一个轻量级、可定制化 IDE 。我还发现在 tmux 的多个控制台窗格（pane）中输入 Unix 命令的方式很好用，因为这种方式可以很容易地将命令结合起来从而提供复杂的脚本化操作，而不需要臃肿的IDE工具。

这种使用方法与使用传统的IDE的区别在于其提供的界面非常契合我当下的工作，且它仅受限于我所安装命令行工具以及脚本语言。我可以按需创建 tmux 窗格（pane）以及 vim 分割（split）窗口，而不要开发什么模板。尽管 Eclipse 和 Xocde 有提供一些以任务为中心（ task-foruce） 的界面，我还是觉得这些有些碍事。尤其是 Xcode，它所提供的快捷键感觉像是后面才补上去的，我还是得不停地使用鼠标进行操作。

支持任务间快速切换则是另一个优点。我是一个自由职业者，通常一天中我需要在 3、4 个项目间进行切换。在使用 tmux 之后， 我可以先断开（detach）一个会话稍后再切回来继续，这使我能够专注于当前工作。我觉得这个是控制台 vim 工具相比于 GUI vim 或是同时开一堆控制台工作而言的一个极大优势，因为 Eclipse 以及 Xcode 总是在关闭工程时尝试保存界面状态（不过最新的版本的 Xcode 在关闭工程貌似总是将我打开的分割窗口关闭掉）。

为什么使用 hjkl 键

这种操作方式看起来可能很别扭，不过如果你能够熟练地盲打，vim 和 tmux （配置成 vim 键风格）可以很容易让手指远离鼠标而只保持在键盘主键区（home row）进行操作。（译者注：home row 指的是键盘上的 “A、S、D、F、J、K、L、;” 这 8 个按键。）

这正是 hjkl 键的秘密：对于哪些盲打正确率高的人而言。 对于那些不习惯使用这些按键的人，可以先慢慢尝试几天。并先专注于打字的正确性，充分利用好你的十个手指。

使用 hjkl 键的道理让我想起说服游戏初学者去使用 wasd 键而不使用方向键情况。 起初 wasd 的确会觉得不太直观，但这使得同时使用键盘以及鼠标操作变得更加容易。当适应这种操作方式之后，其优点是显而易见的。

配置提示

我在 ~/.tmux.conf 文件中做了如下的配置:

set-window-option -g mode-keys vi
bind h select-pane -L
bind j select-pane -D
bind k select-pane -U
bind l select-pane -R

这个能让我在 tmux 中使用 vim 的快捷键。

如果你正在努力掌握 vim 的快捷键，请在 vim 的编辑模式下关闭方向键，具体可以参考：Vim: Making those Arrow Keys Work With You 。

如果你是个 vim 新手，这里值得一提的是 vim 支持 ctags。同时还有 TagHighlight 插件可以在 pane 中动态地显示当前文件编辑缓存区的多个标签（tags），这是个类似于 IDE 的功能。

Dotfiles文件

你的 IDE 配置文件是否能够在多台电脑间同步？

我有一个名为 dotfiles 的私个 git 库，专门用于存储 vim 和 ctags 配置以及插件。我写了一个安装脚本用于自动为本地 dotfiles 库创建配置文件的符号链接。一旦我使用一台新电脑时，我首先做的是检出（check out）这个 git 库。之后当我再开项目进行编辑时，vim 和 tmux 就已按我习惯的使用方式配置好了。

拷贝与粘贴

我经常需要使用 tmux 的拷贝与粘贴命令将控制台的输出拷贝到 vim 中。基于 tmux 的不同配置，快捷键有很大差异，因此非常值得去阅读一下 tmux 的手册并了解其工作原理。默认是使用 “ctrl-b [” 进入拷贝模式，使用空格键（space）开始内容选取，回车键（Enter）进行拷贝，然后使用 “ctrl-b ]” 进行粘贴。

快捷键

如果想要高效地使用 vim，对于重度依赖键盘的操作一定要思考是否有相关的快捷键。举个例子，当我第一次使用 ~ 快捷键时（用于大小写转换），我觉得“这个真是搞笑了，我肯定再不会使用它”。哈，实际上在我写这篇文章时，我已经使用三次了。

我之后找到了使用快捷键的窍门，因为我注意到一些有经验的 vim 使用者都在尽可能地避免使用编辑模式（insert mode）。因此一定要多看看 vim 的帮助手册，之后你就会发现居然有这么多好方法可以改进你的编辑技能。

来源：http://blog.jobbole.com/87585/

NGINX 能在 web 性能中取得领先地位，这是由于其软件设计所决定的。许多 web 服务器和应用程序服务器使用一个简单的基于线程或进程的架构，NGINX 立足于一个复杂的事件驱动的体系结构，使它能够在现代硬件上扩展到成千上万的并发连接。

下面这张深入 NGINX 的信息图从高层次的进程架构上深度挖掘说明了 NGINX 如何在单一进程里保持多个连接。这篇博客进一步详细地解释了这一切是如何工作的。

知识 – NGINX 进程模型

为了更好的理解这个设计，你需要理解 NGINX 如何运行的。NGINX 有一个主进程（它执行特权操作，如读取配置和绑定端口）和一些工作进程与辅助进程。

# service nginx restart
* Restarting nginx
# ps -ef --forest | grep nginx
root     32475     1  0 13:36 ?        00:00:00 nginx: master process /usr/sbin/nginx
                                                -c /etc/nginx/nginx.conf
nginx    32476 32475  0 13:36 ?        00:00:00  _ nginx: worker process
nginx    32477 32475  0 13:36 ?        00:00:00  _ nginx: worker process
nginx    32479 32475  0 13:36 ?        00:00:00  _ nginx: worker process
nginx    32480 32475  0 13:36 ?        00:00:00  _ nginx: worker process
nginx    32481 32475  0 13:36 ?        00:00:00  _ nginx: cache manager process
nginx    32482 32475  0 13:36 ?        00:00:00  _ nginx: cache loader process

在四核服务器，NGINX 主进程创建了4个工作进程和两个管理磁盘内容缓存的缓存辅助进程。

为什么架构很重要？

任何 Unix 应用程序的根本基础是线程或进程。（从 Linux 操作系统的角度来看，线程和进程大多是相同的，主要的区别是他们共享内存的程度。）一个线程或进程是一个自包含的指令集，操作系统可以在一个 CPU 核心上调度运行它们。大多数复杂的应用程序并行运行多个线程或进程有两个原因：

• 它们可以同时使用更多的计算核心。
• 线程或进程可以轻松实现并行操作。（例如，在同一时刻保持多连接）。

进程和线程消耗资源。他们每个都使用内存和其他系统资源，他们会在 CPU 核心中换入和换出（这个操作叫做上下文切换）。大多数现代服务器可以并行保持上百个小型的、活动的线程或进程，但是一旦内存耗尽或高 I/O 压力引起大量的上下文切换会导致性能严重下降。

网络应用程序设计的常用方法是为每个连接分配一个线程或进程。此体系结构简单、容易实现，但是当应用程序需要处理成千上万的并发连接时这种结构就不具备扩展性。

NGINX 如何工作？

NGINX 使用一种可预测的进程模式来分配可使用的硬件资源：

• 主进程（master）执行特权操作，如读取配置和绑定端口，然后创建少量的子进程（如下的三种类型）。
• 缓存加载器进程（cache loader）在加载磁盘缓存到内存中时开始运行，然后退出。适当的调度，所以其资源需求很低。
• 缓存管理器进程（cache manager）定期裁剪磁盘缓存中的记录来保持他们在配置的大小之内。
• 工作进程（worker）做所有的工作！他们保持网络连接、读写内容到磁盘，与上游服务器通信。

在大多数情况下 NGINX 的配置建议：每个 CPU 核心运行一个工作进程，这样最有效地利用硬件资源。你可以在配置中包含 worker_processes auto指令配置：

worker_processes auto;

当一个 NGINX 服务处于活动状态，只有工作进程在忙碌。每个工作进程以非阻塞方式保持多连接，以减少上下文交换。

每个工作进程是一个单一线程并且独立运行，它们会获取新连接并处理之。这些进程可以使用共享内存通信来共享缓存数据、会话持久性数据及其它共享资源。（在 NGINX 1.7.11 及其以后版本，还有一个可选的线程池，工作进程可以转让阻塞的操作给它。更多的细节，参见“NGINX 线程池可以爆增9倍性能！”。对于 NGINX Plus 用户，该功能计划在今年晚些时候加入到 R7 版本中。）

NGINX 工作进程内部

每个 NGINX 工作进程按照 NGINX 配置初始化，并由主进程提供一组监听端口。

NGINX 工作进程首先在监听套接字上等待事件（accept_mutex 和内核套接字分片）。事件被新进来的连接初始化。这些连接被分配到一个状态机 – HTTP 状态机是最常用的，但 NGINX 也实现了流式（原始 TCP ）状态机和几种邮件协议（SMTP、IMAP和POP3）的状态机。

状态机本质上是一组指令，告诉 NGINX 如何处理一个请求。大多数 web 服务器像 NGINX 一样使用类似的状态机来实现相同的功能 – 区别在于实现。

调度状态机

把状态机想象成国际象棋的规则。每个 HTTP 事务是一个象棋游戏。一方面棋盘是 web 服务器 —— 一位大师可以非常迅速地做出决定。另一方面是远程客户端 —— 在一个相对较慢的网络下 web 浏览器访问网站或应用程序。

不管怎样，这个游戏规则很复杂。例如，web 服务器可能需要与各方沟通（代理一个上游的应用程序）或与身份验证服务器对话。web 服务器的第三方模块甚至可以扩展游戏规则。

一个阻塞状态机

回忆我们之前的描述，一个进程或线程就像一套独立的指令集，操作系统可以在一个 CPU 核心上调度运行它。大多数 web 服务器和 web 应用使用每个连接一个进程或者每个连接一个线程的模式来玩这个“象棋游戏”。每个进程或线程都包含玩完“一个游戏”的指令。在服务器运行该进程的期间，其大部分的时间都是“阻塞的” —— 等待客户端完成它的下一步行动。

1. web 服务器进程在监听套接字上监听新连接（客户端发起新“游戏”）
2. 当它获得一个新游戏，就玩这个游戏，每走一步去等待客户端响应时就阻塞了。
3. 游戏完成后，web 服务器进程可能会等待是否有客户机想要开始一个新游戏（这里指的是一个“保持的”连接）。如果这个连接关闭了（客户端断开或者发生超时），web 服务器进程会返回并监听一个新“游戏”。

要记住最重要的一点是每个活动的 HTTP 连接（每局棋）需要一个专用的进程或线程（象棋高手）。这个结构简单容并且易扩展第三方模块（“新规则”）。然而，还是有巨大的不平衡：尤其是轻量级 HTTP 连接其实就是一个文件描述符和小块内存，映射到一个单独的线程或进程，这是一个非常重量级的系统对象。这种方式易于编程，但太过浪费。

NGINX是一个真正的象棋大师

也许你听过车轮表演赛游戏，有一个象棋大师同时对战许多对手？

列夫·吉奥吉夫在保加利亚的索非亚同时对阵360人。他的最终成绩是284胜70平6负。

这就是 NGINX 工作进程如何“下棋”的。每个工作进程（记住 – 通常每个CPU核心上有一个工作进程）是一个可同时对战上百人（事实是，成百上千）的象棋大师。

1. 工作进程在监听和连接套接字上等待事件。
2. 事件发生在套接字上，并且由工作进程处理它们：
   • 在监听套接字的事件意味着一个客户端已经开始了一局新棋局。工作进程创建了一个新连接套接字。
   • 在连接套接字的事件意味着客户端已经下了一步棋。工作进程及时响应。

一个工作进程在网络流量上从不阻塞，等待它的“对手”(客户端)做出反应。当它下了一步，工作进程立即继续其他的游戏，在那里工作进程正在处理下一步，或者在门口欢迎一个新玩家。

为什么这个比阻塞式多进程架构更快？

NGINX 每个工作进程很好的扩展支撑了成百上千的连接。每个连接在工作进程中创建另外一个文件描述符和消耗一小部分额外内存。每个连接有很少的额外开销。NGINX 进程可以固定在某个 CPU 上。上下文交换非常罕见，一般只发生在没有工作要做时。

在阻塞方式，每个进程一个连接的方法中，每个连接需要大量额外的资源和开销，并且上下文切换（从一个进程切换到另一个）非常频繁。

更详细的解释，看看这篇关于 NGINX 架构的文章，它由NGINX公司开发副总裁及共同创始人 Andrew Alexeev 写的。

通过适当的系统优化，NGINX 的每个工作进程可以扩展来处理成千上万的并发 HTTP 连接，并能脸不红心不跳的承受峰值流量(大量涌入的新“游戏”)。

更新配置和升级 NGINX

NGINX 的进程体系架构使用少量的工作进程，有助于有效的更新配置文件甚至 NGINX 程序本身。

更新 NGINX 配置文件是非常简单、轻量、可靠的操作。典型的就是运行命令 nginx –s reload，所做的就是检查磁盘上的配置并发送 SIGHUP 信号给主进程。

当主进程接收到一个 SIGHUP 信号，它会做两件事：

• 重载配置文件和分支出一组新的工作进程。这些新的工作进程立即开始接受连接和处理流量（使用新的配置设置）
• 通知旧的工作进程优雅的退出。工作进程停止接受新的连接。当前的 http 请求一旦完成，工作进程就彻底关闭这个连接（那就是，没有残存的“保持”连接）。一旦所有连接关闭，这个工作进程就退出。

这个重载过程能引发一个 CPU 和内存使用的小峰值，但是跟活动连接加载的资源相比它一般不易察觉。每秒钟你可以多次重载配置（很多 NGINX 用户都这么做）。非常罕见的情况下，有很多世代的工作进程等待关闭连接时会发生问题，但即使是那样也很快被解决了。

NGINX 的程序升级过程中拿到了高可用性圣杯 —— 你可以随时更新这个软件，不会丢失连接，停机，或者中断服务。

程序升级过程类似于平滑重载配置的方法。一个新的 NGINX 主进程与原主进程并行运行，然后他们共享监听套接字。两个进程都是活动的，并且各自的工作进程处理流量。然后你可以通知旧的主进程和它的工作进程优雅的退出。

整个过程的详细描述在 NGINX 管理。

结论

深入 NGINX 信息图提供一个 NGINX 功能实现的高层面概览，但在这简单的解释的背后是超过十年的创新和优化，使得 NGINX 在广泛的硬件上提供尽可能最好的性能同时保持了现代 Web 应用程序所需要的安全性和可靠性。

如果你想阅读更多关于NGINX的优化，查看这些优秀的资源：

• NGINX 安装和性能调优 (webinar; Speaker Deck 上的讲义)
• NGINX 性能调优
• 开源应用架构： NGINX 篇
• NGINX 1.9.1 中的套接字分片 (使用 SO_REUSEPORT 套接字选项)

via: http://nginx.com/blog/inside-nginx-how-we-designed-for-performance-scale/

作者：Owen Garrett 译者：wyangsun 校对：wxy

本文由 LCTT 原创翻译，Linux中国 荣誉推出

来源：https://linux.cn/article-5681-1.html

夏天到了，笔记本过热是最近一个常见的问题。监控硬件温度或许可以帮助你诊断笔记本为什么会过热。本篇中，我们会了解如何在Ubuntu中检查CPU的温度。

我们将使用一个GUI工具Psensor，它允许你在Linux中监控硬件温度。用Psensor你可以：

• 监控cpu和主板的温度
• 监控NVidia GPU的文档
• 监控硬盘的温度
• 监控风扇的速度
• 监控CPU的利用率

Psensor最新的版本同样提供了Ubuntu中的指示小程序，这样使得在Ubuntu中监控温度变得更加容易。你可以选择在面板的右上角显示温度。它还会在温度上过阈值后通知。

如何在Ubuntu 15.04 和 14.04中安装Psensor

在安装Psensor前，你需要安装和配置lm-sensors，这是一个用于硬件监控的命令行工具。如果你想要测量磁盘温度，你还需要安装hddtemp。要安装这些工具，运行下面的这些命令:

sudo apt-get install lm-sensors hddtemp

接着开始检测硬件传感器：

sudo sensors-detect

要确保已经工作，运行下面的命令：

sensors

它会给出下面这样的输出：

acpitz-virtual-0
Adapter: Virtual device
temp1: +43.0°C (crit = +98.0°C)
coretemp-isa-0000
Adapter: ISA adapter
Physical id 0: +44.0°C (high = +100.0°C, crit = +100.0°C)
Core 0: +41.0°C (high = +100.0°C, crit = +100.0°C)
Core 1: +40.0°C (high = +100.0°C, crit = +100.0°C)

如果一切看上去没问题，使用下面的命令安装Psensor：

sudo apt-get install psensor

安装完成后，在Unity Dash中运行程序。第一次运行时，你应该配置Psensor该监控什么状态。

在面板显示温度

如果你想要在面板中显示温度，进入Sensor Preferences:

在 Application Indicator 菜单下，选择你想要显示温度的组件并勾上 Display sensor in the label 选项。

每次启动启动Psensor

进入 Preferences->Startup 并选择 Launch on session startup 使每次启动时启动Psensor。

就是这样。你所要做的就是在这里监控CPU温度。你可以时刻注意并帮助你找出使计算机过热的进程。

via: http://itsfoss.com/check-laptop-cpu-temperature-ubuntu/

作者：Abhishek 译者：geekpi 校对：wxy

本文由 LCTT 原创翻译，Linux中国 荣誉推出

来源：https://linux.cn/article-5682-1.html

大家好，今天我们来了解如何使用Docker Machine在各种云服务提供商的平台上部署Docker。Docker Machine是一个可以帮助我们在自己的电脑、云服务提供商的平台以及我们数据中心的机器上创建Docker机器的应用程序。它为创建服务器、在服务器中安装Docker、根据用户需求配置Docker客户端提供了简单的解决方案。驱动API对本地机器、数据中心的虚拟机或者公用云机器都适用。Docker Machine支持Windows、OSX和Linux，并且提供一个独立的二进制文件，可以直接使用。它让我们可以充分利用支持Docker的基础设施的生态环境合作伙伴，并且使用相同的接口进行访问。它让人们可以使用一个命令来简单而迅速地在不同的云平台部署Docker容器。

1. 安装Docker Machine

Docker Machine可以很好地支持每一种Linux发行版。首先，我们需要从Github网站下载最新版本的。这里我们使用curl来下载目前最新0.2.0版本的Docker Machine。

在64位操作系统运行：

# curl -L https://github.com/docker/machine/releases/download/v0.2.0/docker-machine_linux-amd64 > /usr/local/bin/docker-machine

在32位操作系统运行：

# curl -L https://github.com/docker/machine/releases/download/v0.2.0/docker-machine_linux-i386 > /usr/local/bin/docker-machine

下载最新版本的Docker Machine并将docker-machine文件放到了/usr/local/bin/后，添加执行权限：

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

完成如上操作后，我们需要确认已经成功安装docker-machine了。可以运行如下命令检查，它会输出系统中docker-machine的版本：

# docker-machine -v

要在我们的机器上启用docker命令，需要使用如下命令安装Docker客户端：

    # curl -L https://get.docker.com/builds/linux/x86_64/docker-latest > /usr/local/bin/docker
    # chmod +x /usr/local/bin/docker

2. 创建机器

在自己的Linux机器上安装好了Docker Machine之后，我们想要将一个docker虚拟机部署到云服务器上。Docker Machine支持几个流行的云平台，如igital Ocean、Amazon Web Services（AWS）、Microsoft Azure、Google Cloud Computing及其它等等，所以我们可以在不同的平台使用相同的接口来部署Docker。本文中我们会使用digitalocean驱动在Digital Ocean的服务器上部署Docker，–driver选项指定digitalocean驱动，–digitalocean-access-token选项指定Digital Ocean Control Panel提供的API Token，命令最后的是我们创建的Docker虚拟机的机器名。运行如下命令：

# docker-machine create --driver digitalocean --digitalocean-access-token  linux-dev
# eval "$(docker-machine env linux-dev)"

注意： 这里linux-dev是我们将要创建的机器的名称。是一个安全key，可以在Digtal Ocean Control Panel生成。要找到这个key，我们只需要登录到我们的Digital Ocean Control Panel，然后点击API，再点击 Generate New Token，填写一个名称，选上Read和Write。然后我们就会得到一串十六进制的key，那就是，简单地替换到上边的命令中即可。

运行如上命令后，我们可以在Digital Ocean Droplet Panel中看到一个具有默认配置的droplet已经被创建出来了。

简便起见，docker-machine会使用默认配置来部署Droplet。我们可以通过增加选项来定制我们的Droplet。这里是一些digitalocean相关的选项，我们可以使用它们来覆盖Docker Machine所使用的默认配置。

• –digitalocean-image “ubuntu-14-04-x64” 用于选择Droplet的镜像
• –digitalocean-ipv6 enable 启用IPv6网络支持
• –digitalocean-private-networking enable 启用专用网络
• –digitalocean-region “nyc3” 选择部署Droplet的区域
• –digitalocean-size “512mb” 选择内存大小和部署的类型

如果你想在其他云服务使用docker-machine，并且想覆盖默认的配置，可以运行如下命令来获取Docker Mackine默认支持的对每种平台适用的参数。

# docker-machine create -h

3. 选择活跃主机

部署Droplet后，我们想马上运行一个Docker容器，但在那之前，我们需要检查下活跃主机是否是我们需要的机器。可以运行如下命令查看。

# docker-machine ls

ACTIVE一列有“*”标记的是活跃主机。

现在，如果我们想将活跃主机切换到需要的主机，运行如下命令：

# docker-machine active linux-dev

注意：这里，linux-dev是机器名，我们打算激活这个机器，并且在其上运行Docker容器。

4. 运行一个Docker容器

现在，我们已经选择了活跃主机，就可以运行Docker容器了。可以测试一下，运行一个busybox容器来执行echo hello word命令，这样就可以得到输出：

# docker run busybox echo hello world

注意：如果你试图在一个装有32位操作系统的宿主机部署Docker容器，使用SSH来运行docker是个好办法。这样你就可以简单跳过这一步，直接进入下一步。

5. SSH到Docker机器中

如果我们想在机器或者Droplet上控制之前部署的Docker机器，可以使用docker-machine ssh命令来SSH到机器上：

# docker-machine ssh

SSH到机器上之后，我们可以在上边运行任何Docker容器。这里我们运行一个nginx：

# docker run -itd -p 80:80 nginx

操作完毕后，我们需要运行exit命令来退出Droplet或者服务器。

# exit

5. 删除主机

删除在运行的主机以及它的所有镜像和容器，我们可以使用docker-machine rm命令：

# docker-machine rm linux-dev

使用docker-machine ls命令检查是否成功删除了：

# docker-machine ls

6. 在不使用驱动的情况新增一个主机

我们可以在不使用驱动的情况往Docker增加一台主机，只需要一个URL。它可以使用一个已有机器的别名，所以我们就不需要每次在运行docker命令时输入完整的URL了。

$ docker-machine create --url=tcp://104.131.50.36:2376 custombox

7. 管理主机

如果你已经让Docker运行起来了，可以使用简单的docker-machine stop命令来停止所有正在运行的主机，如果需要再启动的话可以运行docker-machine start：

# docker-machine stop
# docker-machine start

你也可以使用如下命令来使用机器名作为参数来将其停止或启动：

$ docker-machine stop linux-dev
$ docker-machine start linux-dev

总结

Docker Machine是一个非常棒的工具，可以使用Docker容器快速地部署服务。文中我们使用Digital Ocean Platform作演示，但Docker Machine还支持其他平台，如Amazon Web Service、Google Cloud Computing。使用Docker Machine，快速、安全地在几种不同平台部署Docker容器变得很简单了。因为Docker Machine还是Beta版本，不建议在生产环境使用。如果你有任何问题、建议、反馈，请在下方的评论框中写下来，我们会改进或者更新我们的内容。谢谢！享受吧 🙂

via: http://linoxide.com/linux-how-to/use-docker-machine-cloud-provider/

作者：Arun Pyasi 译者：goreliu 校对：wxy

本文由 LCTT 原创翻译，Linux中国 荣誉推出

来源：https://linux.cn/article-5683-1.html

【编者的话】开源渐成主流，越来越多的开发者想参与开源社区。而时下最火热的Docker也许就是开发者入手开源项目的最好选择，它不仅是目前最流行的开源项目之一，而且在提交Issue方面的文档和流程都是目前我见过的开源项目里最好的。本文主要介绍了如何入手开源项目，一些小经验和小工具，一起来学习。

成为一个流行开源项目（如Docker）的贡献者有如下好处：

• 你可以参与改进很多人都在使用的项目，以此来获得认同感；
• 你可以与开源社区中的那些聪明绝顶的人通力合作；
• 你可以通过参与理解和改进这个项目来使自己成为一名更加出色的程序员。

但是，从一个新的基准代码（codebase）入手绝对是一件恐怖的事情。目前，Docker已经有相当多的代码了，哪怕是修复一个小问题，都需要阅读大量的代码，并理解这些部分是如何组合在一起的。

不过，它们也并不如你想象的那么困难。你可以根据Docker的贡献者指南来完成环境的配置。然后按照如下5个简单的步骤，配合相关的代码片段来深入代码基。你所历练的这些技能，都将会在你的编程生涯的每个新项目中派上用场。那么还等什么，我们这就开始。

步骤1：从’func main()’开始

正如一句古话所述，从你知道的开始。如果你和大部分Docker用户一样，你可能主要使用Docker CLI。因此，让我们从程序的入口开始：‘main’函数。

此处为本文的提示，我们将会使用一个名为Sourcegraph的站点，Docker团队就使用它完成在线检索和代码浏览，和你使用智能IDE所做的差不多。建议在阅读本文时，打开Sourcegraph放在一边，以更好地跟上文章的进度。

在Sourcegraph站点，让我们搜索Docker仓库中的‘func main()’。

我们正在寻找对应‘docker’命令的‘main’函数，它是‘docker/docker/docker.go’中的一个文件。点击搜索结果，我们会跳到其定义(如下所示)。花一点时间浏览一下这个函数：

func main() {
	if reexec.Init() {
		return
	}
	// Set terminal emulation based on platform as required.
	stdin, stdout, stderr := term.StdStreams()
	initLogging(stderr)
	flag.Parse()
	// FIXME: validate daemon flags here
	if *flVersion {
		showVersion()
		return
	}
	if *flLogLevel != "" {
		lvl, err := logrus.ParseLevel(*flLogLevel)
		if err != nil {
			logrus.Fatalf("Unable to parse logging level: %s", *flLogLevel)
		}
		setLogLevel(lvl)
	} else {
		setLogLevel(logrus.InfoLevel)
	}
	// -D, --debug, -l/--log-level=debug processing
	// When/if -D is removed this block can be deleted
	if *flDebug {
		os.Setenv("DEBUG", "1")
		setLogLevel(logrus.DebugLevel)
	}
	if len(flHosts) == 0 {
		defaultHost := os.Getenv("DOCKER_HOST")
		if defaultHost == "" || *flDaemon {
			// If we do not have a host, default to unix socket
			defaultHost = fmt.Sprintf("unix://%s", api.DEFAULTUNIXSOCKET)
		}
		defaultHost, err := api.ValidateHost(defaultHost)
		if err != nil {
			logrus.Fatal(err)
		}
		flHosts = append(flHosts, defaultHost)
	}
	setDefaultConfFlag(flTrustKey, defaultTrustKeyFile)
	if *flDaemon {
		if *flHelp {
			flag.Usage()
			return
		}
		mainDaemon()
		return
	}
	if len(flHosts) > 1 {
		logrus.Fatal("Please specify only one -H")
	}
	protoAddrParts := strings.SplitN(flHosts[0], "://", 2)
	var (
		cli       *client.DockerCli
		tlsConfig tls.Config
	)
	tlsConfig.InsecureSkipVerify = true
	// Regardless of whether the user sets it to true or false, if they
	// specify --tlsverify at all then we need to turn on tls
	if flag.IsSet("-tlsverify") {
		*flTls = true
	}
	// If we should verify the server, we need to load a trusted ca
	if *flTlsVerify {
		certPool := x509.NewCertPool()
		file, err := ioutil.ReadFile(*flCa)
		if err != nil {
			logrus.Fatalf("Couldn't read ca cert %s: %s", *flCa, err)
		}
		certPool.AppendCertsFromPEM(file)
		tlsConfig.RootCAs = certPool
		tlsConfig.InsecureSkipVerify = false
	}
	// If tls is enabled, try to load and send client certificates
	if *flTls || *flTlsVerify {
		_, errCert := os.Stat(*flCert)
		_, errKey := os.Stat(*flKey)
		if errCert == nil && errKey == nil {
			*flTls = true
			cert, err := tls.LoadX509KeyPair(*flCert, *flKey)
			if err != nil {
				logrus.Fatalf("Couldn't load X509 key pair: %q. Make sure the key is encrypted", err)
			}
			tlsConfig.Certificates = []tls.Certificate{cert}
		}
		// Avoid fallback to SSL protocols < TLS1.0
		tlsConfig.MinVersion = tls.VersionTLS10
	}
	if *flTls || *flTlsVerify {
		cli = client.NewDockerCli(stdin, stdout, stderr, *flTrustKey, protoAddrParts[0], protoAddrParts[1], &tlsConfig)
	} else {
		cli = client.NewDockerCli(stdin, stdout, stderr, *flTrustKey, protoAddrParts[0], protoAddrParts[1], nil)
	}
	if err := cli.Cmd(flag.Args()...); err != nil {
		if sterr, ok := err.(*utils.StatusError); ok {
			if sterr.Status != "" {
				logrus.Println(sterr.Status)
			}
			os.Exit(sterr.StatusCode)
		}
		logrus.Fatal(err)
	}
}

在‘main’函数的顶部，我们看了许多与日志配置，命令标志读取以及默认初始化相关的代码。在底部，我们发现了对『client.NewDockerCli』的调用，它似乎是用来负责创建结构体的，而这个结构体的函数则会完成所有的实际工作。让我们来搜索『NewDockerCli』。

步骤2：找到核心部分

在很多的应用和程序库中，都有1到2个关键接口，它表述了核心功能或者本质。让我们尝试到达这个关键部分。

点击‘NewDockerCli’的搜索结果，我们会到达函数的定义。由于我们感兴趣的只是这个函数所返回的结构体——「DockerCli」，因此让我们点击返回类型来跳转到其定义。

func NewDockerCli(in io.ReadCloser, out, err io.Writer, keyFile string, proto, addr string, tlsConfig *tls.Config) *DockerCli {
	var (
		inFd          uintptr
		outFd         uintptr
		isTerminalIn  = false
		isTerminalOut = false
		scheme        = "http"
	)
	if tlsConfig != nil {
		scheme = "https"
	}
	if in != nil {
		inFd, isTerminalIn = term.GetFdInfo(in)
	}
	if out != nil {
		outFd, isTerminalOut = term.GetFdInfo(out)
	}
	if err == nil {
		err = out
	}
	// The transport is created here for reuse during the client session
	tr := &http.Transport{
		TLSClientConfig: tlsConfig,
	}
	// Why 32? See issue 8035
	timeout := 32 * time.Second
	if proto == "unix" {
		// no need in compressing for local communications
		tr.DisableCompression = true
		tr.Dial = func(_, _ string) (net.Conn, error) {
			return net.DialTimeout(proto, addr, timeout)
		}
	} else {
		tr.Proxy = http.ProxyFromEnvironment
		tr.Dial = (&net.Dialer{Timeout: timeout}).Dial
	}
	return &DockerCli{
		proto:         proto,
		addr:          addr,
		in:            in,
		out:           out,
		err:           err,
		keyFile:       keyFile,
		inFd:          inFd,
		outFd:         outFd,
		isTerminalIn:  isTerminalIn,
		isTerminalOut: isTerminalOut,
		tlsConfig:     tlsConfig,
		scheme:        scheme,
		transport:     tr,
	}
}

点击『DockerCli』将我们带到了它的定义。向下滚动这个文件，我们可以看到它的方法， ‘getMethod’，‘Cmd’，‘Subcmd’和‘LoadConfigFile’。其中，‘Cmd’值得留意。它是唯一一个包含docstring的方法，而docstring则表明它是执行每条Docker命令的核心方法。

步骤3：更进一步

既然我们已经找到了‘DockerCli’，这个Docker客户端的核心‘控制器’，接下来让我们继续深入，了解一条具体的Docker命令是如何工作的。让我们放大‘docker build’部分的代码。

type DockerCli struct {
	proto      string
	addr       string
	configFile *registry.ConfigFile
	in         io.ReadCloser
	out        io.Writer
	err        io.Writer
	keyFile    string
	tlsConfig  *tls.Config
	scheme     string
	// inFd holds file descriptor of the client's STDIN, if it's a valid file
	inFd uintptr
	// outFd holds file descriptor of the client's STDOUT, if it's a valid file
	outFd uintptr
	// isTerminalIn describes if client's STDIN is a TTY
	isTerminalIn bool
	// isTerminalOut describes if client's STDOUT is a TTY
	isTerminalOut bool
	transport     *http.Transport
}

阅读‘DockerCli.Cmd’的实现可以发现，它调用了‘DockerCli.getMethod’方法来执行每条Docker命令所对应的函数。

func (cli *DockerCli) Cmd(args ...string) error {
	if len(args) > 1 {
		method, exists := cli.getMethod(args[:2]...)
		if exists {
			return method(args[2:]...)
		}
	}
	if len(args) > 0 {
		method, exists := cli.getMethod(args[0])
		if !exists {
			fmt.Fprintf(cli.err, "docker: '%s' is not a docker command. See 'docker --help'.n", args[0])
			os.Exit(1)
		}
		return method(args[1:]...)
	}
	return cli.CmdHelp()
}

在‘DockerCli.getMethod’中，我们可以看到它是通过对一个函数的动态调用实现的，其中这个函数名的形式为在Docker命令前预置“Cmd”字符串。那么在‘docker build’这个情况下，我们寻找的是‘DockerCli.CmdBuild’。但在这个文件中并没有对应的方法，因此让我们需要搜索‘CmdBuild’。

func (cli *DockerCli) getMethod(args ...string) (func(...string) error, bool) {
	camelArgs := make([]string, len(args))
	for i, s := range args {
		if len(s) == 0 {
			return nil, false
		}
		camelArgs[i] = strings.ToUpper(s[:1]) + strings.ToLower(s[1:])
	}
	methodName := "Cmd" + strings.Join(camelArgs, "")
	method := reflect.ValueOf(cli).MethodByName(methodName)
	if !method.IsValid() {
		return nil, false
	}
	return method.Interface().(func(...string) error), true
}

搜索结果显示‘DockerCli’中确实有一个‘CmdBuild’方法，因此跳到它的定义部分。由于‘DockerCli.CmdBuild’的方法体过长，因此就不在本文中嵌入了，但是这里有它的链接。

这里有很多内容。在方法的顶部，我们可以看到代码会为Dockerfile和配置处理各种输入方法。通常，在阅读一个很长的方法时，倒过来读是一种很不错的策略。从底部开始，观察函数在最后做了什么。很多情况中，它们都是函数的本质，而之前的内容无非只是用来补全核心行为的。

在‘CmdBuild’的底部，我们可以看到通过‘cli.stream’构造的‘POST’请求。通过一些额外定义的跳转，我们到达了‘DockerCli.clientRequest’，它构造一个HTTP请求，这个请求包含你通过‘docker build’传递给Docker的信息。因此在这里，‘docker build所做的就是发出一个设想的’POST‘请求给Docker守护进程。如果你愿意，你也可以使用’curl‘来完成这个行为。

至此，我们已经彻底了解了一个单独的Docker客户端命令，或许你仍希望更进一步，找到守护进程接受请求的部分，并一路跟踪到它和LXC以及内核交互的部分。这当然是一条合理的路径，但是我们将其作为练习留给各位读者。接下来，让我们对客户端的关键组件有一个更加全面的认识。

步骤4：查看使用示例

更好地理解一段代码的方式是查看展示代码如何被应用的使用示例。让我们回到'DockerCli.clientRequest'方法。在右手边的Sourcegraph面板中，我们可以浏览这个方法的使用例子。结果显示，这个方法在多处被使用，因为大部分Docker客户端命令都会产生传到守护进程的HTTP请求。

为了完全理解一个代码片段，你需要同时知晓它是如何工作的以及是如何来使用的。通过阅读代码的定义部分让我们理解前者，而查看使用示例则是涵盖了后者。

请在更多的函数和方法上尝试，理解它们的内部联系。如果这有帮助，那么请就应用的不同模块如何交互，画一张图。

步骤5：选择一个问题并开始coding

既然你已经对Docker的代码基有了一个大概的认识，那么可以查阅一下issue跟踪系统，看看哪些问题亟待解决，并在遇到你自己无法回答的问题时，向Docker社区的成员申援。由于你已经花了时间来摸索并理解代码，那么你应该已经具备条件来提出“聪明”的问题，并知道问题大概出在哪里。

如果你觉得有必要，可以一路做好笔记，记录你的经历，并像本文一样作为博客发布。Docker团队会很乐意看到，你研究他们代码的经历。

有效地贡献

对一个巨大且陌生的基准代码的恐惧，俨然已经成为了一个阻止人们参与到项目中的误解。我们经常假设，对于程序员而言，工作的难点在于写代码，然而阅读并理解他人的代码却往往是最关键的一步。认识到这一切，并坚定地迎接任务，辅以优秀的工具，会帮助你克服心理防线，以更好地投入到代码中。

那么，开始动手吧，检查一下Docker今天的代码。一个充满活力的开源社区和基准代码正等着你！

来源：http://dockone.io/article/450

Jaromil在2002年设计了最为精简的一个Linux Fork炸弹,整个代码只有13个字符，在shell中运行后几秒后系统就会宕机：

:(){:|:&};:

这样看起来不是很好理解，我们可以更改下格式：

:()
{
	:|:&
};
:

更好理解一点的话就是这样:

bomb()
{
	bomb|bomb&
};
bomb

因为shell中函数可以省略function关键字，所以上面的十三个字符是功能是定义一个函数与调用这个函数，函数的名称为:,主要的核心代码是:|:&，可以看出这是一个函数本身的递归调用，通过&实现在后台开启新进程运行，通过管道实现进程呈几何形式增长，最后再通过:来调用函数引爆炸弹.因此，几秒钟系统就会因为处理不过来太多的进程而死机，解决的唯一办法就是重启。

Bomb一下

秉着不作不死的心态，我们也来运行一下，于是我将矛头指向云主机，，我使用了国内的一个2G内存的云主机，首先在本地开启两个终端，在一个终端连接云主机后运行炸弹，几秒后再尝试用另外一个终端登录，效果可以看下面Gif图：

看，运行一段时间后直接报出了-bash: fork: Cannot allocate memory，说明内存不足了。并且我在二号终端上尝试连接也没有任何反应。因为是虚拟的云主机，所以我只能通过主机服务商的后台来给主机断电重启。然后才能重新登录:

炸弹危害

Fork炸弹带来的后果就是耗尽服务器资源，使服务器不能正常的对外提供服务，也就是常说的DoS(Denial of Service)。与传统1v1、通过不断向服务器发送请求造成服务器崩溃不同，Fork炸弹有种坐山观虎斗，不费一兵一卒斩敌人于马下的感觉。更吓人的是这个函数是不需要root权限就可以运行的。看到网上有帖子说某些人将个性签名改为Fork炸弹，结果果真有好奇之人中枪，试想如果中枪的人是在公司服务器上运行的话，oh，！

预防方式

当然，Fork炸弹没有那么可怕，用其它语言也可以分分钟写出来一个，例如，python版：

import os
 	while True:
 	os.fork()

Fork炸弹的本质无非就是靠创建进程来抢占系统资源，在Linux中，我们可以通过ulimit命令来限制用户的某些行为，运行ulimit -a可以查看我们能做哪些限制：

ubuntu@10-10-57-151:~$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 7782
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 7782
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

可以看到，-u参数可以限制用户创建进程数，因此，我们可以使用ulimit -u 20来允许用户最多创建20个进程。这样就可以预防bomb炸弹。但这样是不彻底的，关闭终端后这个命令就失效了。我们可以通过修改/etc/security/limits.conf文件来进行更深层次的预防，在文件里添加如下一行（ubuntu需更换为你的用户名）：

ubuntu - nproc 20

这样，退出后重新登录，就会发现最大进程数已经更改为20了，

这个时候我们再次运行炸弹就不会报内存不足了，而是提示-bash: fork: retry: No child processes，说明Linux限制了炸弹创建线程。

参考

http://en.wikipedia.org/wiki/Fork_bomb

来源：http://blog.saymagic.cn/2015/03/25/fork-bomb.html

1. 引言

正如我们所知，NGINX采用了异步、事件驱动的方法来处理连接。这种处理方式无需（像使用传统架构的服务器一样）为每个请求创建额外的专用进程或者线程，而是在一个工作进程中处理多个连接和请求。为此，NGINX工作在非阻塞的socket模式下，并使用了epoll 和 kqueue这样有效的方法。

因为满负载进程的数量很少（通常每核CPU只有一个）而且恒定，所以任务切换只消耗很少的内存，而且不会浪费CPU周期。通过NGINX本身的实例，这种方法的优点已经为众人所知。NGINX可以非常好地处理百万级规模的并发请求。

每个进程都消耗额外的内存，而且每次进程间的切换都会消耗CPU周期并丢弃CPU高速缓存中的数据。

但是，异步、事件驱动方法仍然存在问题。或者，我喜欢将这一问题称为“敌兵”，这个敌兵的名字叫阻塞（blocking）。不幸的是，很多第三方模块使用了阻塞调用，然而用户（有时甚至是模块的开发者）并不知道阻塞的缺点。阻塞操作可以毁掉NGINX的性能，我们必须不惜一切代价避免使用阻塞。

即使在当前官方的NGINX代码中，依然无法在全部场景中避免使用阻塞，NGINX1.7.11中实现的线程池机制解决了这个问题。我们将在后面讲述这个线程池是什么以及该如何使用。现在，让我们先和我们的“敌兵”进行一次面对面的碰撞。

2. 问题

首先，为了更好地理解这一问题，我们用几句话说明下NGINX是如何工作的。

通常情况下，NGINX是一个事件处理器，即一个接收来自内核的所有连接事件的信息，然后向操作系统发出做什么指令的控制器。实际上，NGINX干了编排操作系统的全部脏活累活，而操作系统做的是读取和发送字节这样的日常工作。所以，对于NGINX来说，快速和及时的响应是非常重要的。

工作进程监听并处理来自内核的事件

事件可以是超时、socket读写就绪的通知，或者发生错误的通知。NGINX接收大量的事件，然后一个接一个地处理它们，并执行必要的操作。因此，所有的处理过程是通过一个线程中的队列，在一个简单循环中完成的。NGINX从队列中取出一个事件并对其做出响应，比如读写socket。在多数情况下，这种方式是非常快的（也许只需要几个CPU周期，将一些数据复制到内存中），NGINX可以在一瞬间处理掉队列中的所有事件。

所有处理过程是在一个简单的循环中，由一个线程完成

但是，如果NGINX要处理的操作是一些又长又重的操作，又会发生什么呢？整个事件处理循环将会卡住，等待这个操作执行完毕。

因此，所谓“阻塞操作”是指任何导致事件处理循环显著停止一段时间的操作。操作可以由于各种原因成为阻塞操作。例如，NGINX可能因长时间、CPU密集型处理，或者可能等待访问某个资源（比如硬盘，或者一个互斥体，亦或要从处于同步方式的数据库获得相应的库函数调用等）而繁忙。关键是在处理这样的操作期间，工作进程无法做其他事情或者处理其他事件，即使有更多的可用系统资源可以被队列中的一些事件所利用。

我们来打个比方，一个商店的营业员要接待他面前排起的一长队顾客。队伍中的第一位顾客想要的某件商品不在店里而在仓库中。这位营业员跑去仓库把东西拿来。现在整个队伍必须为这样的配货方式等待数个小时，队伍中的每个人都很不爽。你可以想见人们的反应吧？队伍中每个人的等待时间都要增加这些时间，除非他们要买的东西就在店里。

队伍中的每个人不得不等待第一个人的购买

在NGINX中会发生几乎同样的情况，比如当读取一个文件的时候，如果该文件没有缓存在内存中，就要从磁盘上读取。从磁盘（特别是旋转式的磁盘）读取是很慢的,而当队列中等待的其他请求可能不需要访问磁盘时，它们也得被迫等待。导致的结果是，延迟增加并且系统资源没有得到充分利用。

一个阻塞操作足以显著地延缓所有接下来的操作

一些操作系统为读写文件提供了异步接口，NGINX可以使用这样的接口（见AIO指令）。FreeBSD就是个很好的例子。不幸的是，我们不能在Linux上得到相同的福利。虽然Linux为读取文件提供了一种异步接口，但是存在明显的缺点。其中之一是要求文件访问和缓冲要对齐，但NGINX很好地处理了这个问题。但是，另一个缺点更糟糕。异步接口要求文件描述符中要设置O_DIRECT标记，就是说任何对文件的访问都将绕过内存中的缓存，这增加了磁盘的负载。在很多场景中，这都绝对不是最佳选择。

为了有针对性地解决这一问题，在NGINX 1.7.11中引入了线程池。默认情况下，NGINX+还没有包含线程池，但是如果你想试试的话，可以联系销售人员，NGINX+ R6是一个已经启用了线程池的构建版本。

现在，让我们走进线程池，看看它是什么以及如何工作的。

3. 线程池

让我们回到那个可怜的，要从大老远的仓库去配货的售货员那儿。这回，他已经变聪明了（或者也许是在一群愤怒的顾客教训了一番之后，他才变得聪明的？），雇用了一个配货服务团队。现在，当任何人要买的东西在大老远的仓库时，他不再亲自去仓库了，只需要将订单丢给配货服务，他们将处理订单，同时，我们的售货员依然可以继续为其他顾客服务。因此，只有那些要买仓库里东西的顾客需要等待配货，其他顾客可以得到即时服务。

传递订单给配货服务不会阻塞队伍

对NGINX而言，线程池执行的就是配货服务的功能。它由一个任务队列和一组处理这个队列的线程组成。当工作进程需要执行一个潜在的长操作时，工作进程不再自己执行这个操作，而是将任务放到线程池队列中，任何空闲的线程都可以从队列中获取并执行这个任务。

工作进程将阻塞操作卸给线程池

那么，这就像我们有了另外一个队列。是这样的，但是在这个场景中，队列受限于特殊的资源。磁盘的读取速度不能比磁盘产生数据的速度快。不管怎么说，至少现在磁盘不再延误其他事件，只有访问文件的请求需要等待。

“从磁盘读取”这个操作通常是阻塞操作最常见的示例，但是实际上，NGINX中实现的线程池可用于处理任何不适合在主循环中执行的任务。

目前，卸载到线程池中执行的两个基本操作是大多数操作系统中的read()系统调用和Linux中的sendfile()。接下来，我们将对线程池进行测试（test）和基准测试（benchmark），在未来的版本中，如果有明显的优势，我们可能会卸载其他操作到线程池中。

4. 基准测试

现在让我们从理论过度到实践。我们将进行一次模拟基准测试（synthetic benchmark），模拟在阻塞操作和非阻塞操作的最差混合条件下，使用线程池的效果。

另外，我们需要一个内存肯定放不下的数据集。在一台48GB内存的机器上，我们已经产生了每文件大小为4MB的随机数据，总共256GB，然后配置NGINX，版本为1.9.0。

配置很简单：

worker_processes 16;
events {
    accept_mutex off;
}
http {
    include mime.types;
    default_type application/octet-stream;
    access_log off;
    sendfile on;
    sendfile_max_chunk 512k;
    server {
        listen 8000;
        location / {
            root /storage;
        }
    }
}

如上所示，为了达到更好的性能，我们调整了几个参数：禁用了logging和accept_mutex，同时，启用了sendfile并设置了sendfile_max_chunk的大小。最后一个指令可以减少阻塞调用sendfile()所花费的最长时间，因为NGINX不会尝试一次将整个文件发送出去，而是每次发送大小为512KB的块数据。

这台测试服务器有2个Intel Xeon E5645处理器（共计：12核、24超线程）和10-Gbps的网络接口。磁盘子系统是由4块西部数据WD1003FBYX 磁盘组成的RAID10阵列。所有这些硬件由Ubuntu服务器14.04.1 LTS供电。

为基准测试配置负载生成器和NGINX

客户端有2台服务器，它们的规格相同。在其中一台上，在wrk中使用Lua脚本创建了负载程序。脚本使用200个并行连接向服务器请求文件，每个请求都可能未命中缓存而从磁盘阻塞读取。我们将这种负载称作随机负载。

在另一台客户端机器上，我们将运行wrk的另一个副本，使用50个并行连接多次请求同一个文件。因为这个文件将被频繁地访问，所以它会一直驻留在内存中。在正常情况下，NGINX能够非常快速地服务这些请求，但是如果工作进程被其他请求阻塞的话，性能将会下降。我们将这种负载称作恒定负载。

性能将由服务器上ifstat监测的吞吐率（throughput）和从第二台客户端获取的wrk结果来度量。

现在，没有使用线程池的第一次运行将不会带给我们非常振奋的结果：

% ifstat -bi eth2
eth2
Kbps in  Kbps out
5531.24  1.03e+06
4855.23  812922.7
5994.66  1.07e+06
5476.27  981529.3
6353.62  1.12e+06
5166.17  892770.3
5522.81  978540.8
6208.10  985466.7
6370.79  1.12e+06
6123.33  1.07e+06

如上所示，使用这种配置，服务器产生的总流量约为1Gbps。从下面所示的top输出，我们可以看到，工作进程的大部分时间花在阻塞I/O上（它们处于top的D状态）：

top - 10:40:47 up 11 days,  1:32,  1 user,  load average: 49.61, 45.77 62.89
Tasks: 375 total,  2 running, 373 sleeping,  0 stopped,  0 zombie
%Cpu(s):  0.0 us,  0.3 sy,  0.0 ni, 67.7 id, 31.9 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem:  49453440 total, 49149308 used,   304132 free,    98780 buffers
KiB Swap: 10474236 total,    20124 used, 10454112 free, 46903412 cached Mem
  PID USER     PR  NI    VIRT    RES     SHR S  %CPU %MEM    TIME+ COMMAND
 4639 vbart    20   0   47180  28152     496 D   0.7  0.1  0:00.17 nginx
 4632 vbart    20   0   47180  28196     536 D   0.3  0.1  0:00.11 nginx
 4633 vbart    20   0   47180  28324     540 D   0.3  0.1  0:00.11 nginx
 4635 vbart    20   0   47180  28136     480 D   0.3  0.1  0:00.12 nginx
 4636 vbart    20   0   47180  28208     536 D   0.3  0.1  0:00.14 nginx
 4637 vbart    20   0   47180  28208     536 D   0.3  0.1  0:00.10 nginx
 4638 vbart    20   0   47180  28204     536 D   0.3  0.1  0:00.12 nginx
 4640 vbart    20   0   47180  28324     540 D   0.3  0.1  0:00.13 nginx
 4641 vbart    20   0   47180  28324     540 D   0.3  0.1  0:00.13 nginx
 4642 vbart    20   0   47180  28208     536 D   0.3  0.1  0:00.11 nginx
 4643 vbart    20   0   47180  28276     536 D   0.3  0.1  0:00.29 nginx
 4644 vbart    20   0   47180  28204     536 D   0.3  0.1  0:00.11 nginx
 4645 vbart    20   0   47180  28204     536 D   0.3  0.1  0:00.17 nginx
 4646 vbart    20   0   47180  28204     536 D   0.3  0.1  0:00.12 nginx
 4647 vbart    20   0   47180  28208     532 D   0.3  0.1  0:00.17 nginx
 4631 vbart    20   0   47180    756     252 S   0.0  0.1  0:00.00 nginx
 4634 vbart    20   0   47180  28208     536 D   0.0  0.1  0:00.11 nginx
 4648 vbart    20   0   25232   1956    1160 R   0.0  0.0  0:00.08 top
25921 vbart    20   0  121956   2232    1056 S   0.0  0.0  0:01.97 sshd
25923 vbart    20   0   40304   4160    2208 S   0.0  0.0  0:00.53 zsh

在这种情况下，吞吐率受限于磁盘子系统，而CPU在大部分时间里是空闲的。从wrk获得的结果也非常低：

Running 1m test @ http://192.0.2.1:8000/1/1/1
  12 threads and 50 connections
  Thread Stats   Avg    Stdev     Max  +/- Stdev
    Latency     7.42s  5.31s   24.41s   74.73%
    Req/Sec     0.15    0.36     1.00    84.62%
  488 requests in 1.01m, 2.01GB read
Requests/sec:      8.08
Transfer/sec:     34.07MB

请记住，文件是从内存送达的！第一个客户端的200个连接创建的随机负载，使服务器端的全部的工作进程忙于从磁盘读取文件，因此产生了过大的延迟，并且无法在合理的时间内处理我们的请求。

现在，我们的线程池要登场了。为此，我们只需在location块中添加aio threads指令：

location / {
    root /storage;
    aio threads;
}

接着，执行NGINX reload重新加载配置。

然后，我们重复上述的测试：

% ifstat -bi eth2
eth2
Kbps in  Kbps out
60915.19  9.51e+06
59978.89  9.51e+06
60122.38  9.51e+06
61179.06  9.51e+06
61798.40  9.51e+06
57072.97  9.50e+06
56072.61  9.51e+06
61279.63  9.51e+06
61243.54  9.51e+06
59632.50  9.50e+06

现在，我们的服务器产生的流量是9.5Gbps，相比之下，没有使用线程池时只有约1Gbps！

理论上还可以产生更多的流量，但是这已经达到了机器的最大网络吞吐能力，所以在这次NGINX的测试中，NGINX受限于网络接口。工作进程的大部分时间只是休眠和等待新的时间（它们处于top的S状态）：

top - 10:43:17 up 11 days,  1:35,  1 user,  load average: 172.71, 93.84, 77.90
Tasks: 376 total,  1 running, 375 sleeping,  0 stopped,  0 zombie
%Cpu(s):  0.2 us,  1.2 sy,  0.0 ni, 34.8 id, 61.5 wa,  0.0 hi,  2.3 si,  0.0 st
KiB Mem:  49453440 total, 49096836 used,   356604 free,    97236 buffers
KiB Swap: 10474236 total,    22860 used, 10451376 free, 46836580 cached Mem
  PID USER     PR  NI    VIRT    RES     SHR S  %CPU %MEM    TIME+ COMMAND
 4654 vbart    20   0  309708  28844     596 S   9.0  0.1  0:08.65 nginx
 4660 vbart    20   0  309748  28920     596 S   6.6  0.1  0:14.82 nginx
 4658 vbart    20   0  309452  28424     520 S   4.3  0.1  0:01.40 nginx
 4663 vbart    20   0  309452  28476     572 S   4.3  0.1  0:01.32 nginx
 4667 vbart    20   0  309584  28712     588 S   3.7  0.1  0:05.19 nginx
 4656 vbart    20   0  309452  28476     572 S   3.3  0.1  0:01.84 nginx
 4664 vbart    20   0  309452  28428     524 S   3.3  0.1  0:01.29 nginx
 4652 vbart    20   0  309452  28476     572 S   3.0  0.1  0:01.46 nginx
 4662 vbart    20   0  309552  28700     596 S   2.7  0.1  0:05.92 nginx
 4661 vbart    20   0  309464  28636     596 S   2.3  0.1  0:01.59 nginx
 4653 vbart    20   0  309452  28476     572 S   1.7  0.1  0:01.70 nginx
 4666 vbart    20   0  309452  28428     524 S   1.3  0.1  0:01.63 nginx
 4657 vbart    20   0  309584  28696     592 S   1.0  0.1  0:00.64 nginx
 4655 vbart    20   0  30958   28476     572 S   0.7  0.1  0:02.81 nginx
 4659 vbart    20   0  309452  28468     564 S   0.3  0.1  0:01.20 nginx
 4665 vbart    20   0  309452  28476     572 S   0.3  0.1  0:00.71 nginx
 5180 vbart    20   0   25232   1952    1156 R   0.0  0.0  0:00.45 top
 4651 vbart    20   0   20032    752     252 S   0.0  0.0  0:00.00 nginx
25921 vbart    20   0  121956   2176    1000 S   0.0  0.0  0:01.98 sshd
25923 vbart    20   0   40304   3840    2208 S   0.0  0.0  0:00.54 zsh

如上所示，基准测试中还有大量的CPU资源剩余。

wrk的结果如下：

Running 1m test @ http://192.0.2.1:8000/1/1/1
  12 threads and 50 connections
  Thread Stats   Avg      Stdev     Max  +/- Stdev
    Latency   226.32ms  392.76ms   1.72s   93.48%
    Req/Sec    20.02     10.84    59.00    65.91%
  15045 requests in 1.00m, 58.86GB read
Requests/sec:    250.57
Transfer/sec:      0.98GB

服务器处理4MB文件的平均时间从7.42秒降到226.32毫秒（减少了33倍），每秒请求处理数提升了31倍（250 vs 8）！

对此，我们的解释是请求不再因为工作进程被阻塞在读文件，而滞留在事件队列中，等待处理，它们可以被空闲的进程处理掉。只要磁盘子系统能做到最好，就能服务好第一个客户端上的随机负载，NGINX可以使用剩余的CPU资源和网络容量，从内存中读取，以服务于上述的第二个客户端的请求。

5. 依然没有银弹

在抛出我们对阻塞操作的担忧并给出一些令人振奋的结果后，可能大部分人已经打算在你的服务器上配置线程池了。先别着急。

实际上，最幸运的情况是，读取和发送文件操作不去处理缓慢的硬盘驱动器。如果我们有足够多的内存来存储数据集，那么操作系统将会足够聪明地在被称作“页面缓存”的地方，缓存频繁使用的文件。

“页面缓存”的效果很好，可以让NGINX在几乎所有常见的用例中展示优异的性能。从页面缓存中读取比较快，没有人会说这种操作是“阻塞”。而另一方面，卸载任务到一个线程池是有一定开销的。

因此，如果内存有合理的大小并且待处理的数据集不是很大的话，那么无需使用线程池，NGINX已经工作在最优化的方式下。

卸载读操作到线程池是一种适用于非常特殊任务的技术。只有当经常请求的内容的大小，不适合操作系统的虚拟机缓存时，这种技术才是最有用的。至于可能适用的场景，比如，基于NGINX的高负载流媒体服务器。这正是我们已经模拟的基准测试的场景。

我们如果可以改进卸载读操作到线程池，将会非常有意义。我们只需要知道所需的文件数据是否在内存中，只有不在内存中时，读操作才应该卸载到一个单独的线程中。

再回到售货员那个比喻的场景中，这回，售货员不知道要买的商品是否在店里，他必须要么总是将所有的订单提交给配货服务，要么总是亲自处理它们。

人艰不拆，操作系统缺少这样的功能。第一次尝试是在2010年，人们试图将这一功能添加到Linux作为fincore()系统调用，但是没有成功。后来还有一些尝试，是使用RWF_NONBLOCK标记作为preadv2()系统调用来实现这一功能（详情见LWN.net上的非阻塞缓冲文件读取操作和异步缓冲读操作）。但所有这些补丁的命运目前还不明朗。悲催的是，这些补丁尚没有被内核接受的主要原因，貌似是因为旷日持久的撕逼大战（bikeshedding）。

另一方面，FreeBSD的用户完全不必担心。FreeBSD已经具备足够好的读文件取异步接口，我们应该用这个接口而不是线程池。

6. 配置线程池

所以，如果你确信在你的场景中使用线程池可以带来好处，那么现在是时候深入了解线程池的配置了。

线程池的配置非常简单、灵活。首先，获取NGINX 1.7.11或更高版本的源代码，使用--with-threads配置参数编译。在最简单的场景中，配置看起来很朴实。我们只需要在http、 server，或者location上下文中包含aio threads指令即可：

aio threads;

这是线程池的最简配置。实际上的精简版本示例如下：

thread_pool default threads=32 max_queue=65536;
aio threads=default;

这里定义了一个名为“default”，包含32个线程，任务队列最多支持65536个请求的线程池。如果任务队列过载，NGINX将输出如下错误日志并拒绝请求：

thread pool "NAME" queue overflow: N tasks waiting

错误输出意味着线程处理作业的速度有可能低于任务入队的速度了。你可以尝试增加队列的最大值，但是如果这无济于事，那么这说明你的系统没有能力处理如此多的请求了。

正如你已经注意到的，你可以使用thread_pool指令，配置线程的数量、队列的最大值，以及线程池的名称。最后要说明的是，可以配置多个独立的线程池，将它们置于不同的配置文件中，用做不同的目的：

http {
    thread_pool one threads=128 max_queue=0;
    thread_pool two threads=32;
    server {
        location /one {
            aio threads=one;
        }
        location /two {
            aio threads=two;
        }
    }
…
}

如果没有指定max_queue参数的值，默认使用的值是65536。如上所示，可以设置max_queue为0。在这种情况下，线程池将使用配置中全部数量的线程，尽可能地同时处理多个任务；队列中不会有等待的任务。

现在，假设我们有一台服务器，挂了3块硬盘，我们希望把该服务器用作“缓存代理”，缓存后端服务器的全部响应信息。预期的缓存数据量远大于可用的内存。它实际上是我们个人CDN的一个缓存节点。毫无疑问，在这种情况下，最重要的事情是发挥硬盘的最大性能。

我们的选择之一是配置一个RAID阵列。这种方法毁誉参半，现在，有了NGINX，我们可以有其他的选择：

# 我们假设每块硬盘挂载在相应的目录中：/mnt/disk1、/mnt/disk2、/mnt/disk3
proxy_cache_path /mnt/disk1 levels=1:2 keys_zone=cache_1:256m max_size=1024G
                 use_temp_path=off;
proxy_cache_path /mnt/disk2 levels=1:2 keys_zone=cache_2:256m max_size=1024G
                 use_temp_path=off;
proxy_cache_path /mnt/disk3 levels=1:2 keys_zone=cache_3:256m max_size=1024G
                 use_temp_path=off;
thread_pool pool_1 threads=16;
thread_pool pool_2 threads=16;
thread_pool pool_3 threads=16;
split_clients $request_uri $disk {
    33.3%     1;
    33.3%     2;
    *         3;
}
location / {
    proxy_pass http://backend;
    proxy_cache_key $request_uri;
    proxy_cache cache_$disk;
    aio threads=pool_$disk;
    sendfile on;
}

在这份配置中，使用了3个独立的缓存，每个缓存专用一块硬盘，另外，3个独立的线程池也各自专用一块硬盘。

缓存之间（其结果就是磁盘之间）的负载均衡使用split_clients模块，split_clients非常适用于这个任务。

在 proxy_cache_path指令中设置use_temp_path=off，表示NGINX会将临时文件保存在缓存数据的同一目录中。这是为了避免在更新缓存时，磁盘之间互相复制响应数据。

这些调优将带给我们磁盘子系统的最大性能，因为NGINX通过单独的线程池并行且独立地与每块磁盘交互。每块磁盘由16个独立线程和读取和发送文件专用任务队列提供服务。

我敢打赌，你的客户喜欢这种量身定制的方法。请确保你的磁盘也持有同样的观点。

这个示例很好地证明了NGINX可以为硬件专门调优的灵活性。这就像你给NGINX下了一道命令，让机器和数据用最佳姿势来搞基。而且，通过NGINX在用户空间中细粒度的调优，我们可以确保软件、操作系统和硬件工作在最优模式下，尽可能有效地利用系统资源。

7. 总结

综上所述，线程池是一个伟大的功能，将NGINX推向了新的性能水平，除掉了一个众所周知的长期危害——阻塞——尤其是当我们真正面对大量内容的时候。

甚至，还有更多的惊喜。正如前面提到的，这个全新的接口，有可能没有任何性能损失地卸载任何长期阻塞操作。NGINX在拥有大量的新模块和新功能方面，开辟了一方新天地。许多流行的库仍然没有提供异步非阻塞接口，此前，这使得它们无法与NGINX兼容。我们可以花大量的时间和资源，去开发我们自己的无阻塞原型库，但这么做始终都是值得的吗？现在，有了线程池，我们可以相对容易地使用这些库，而不会影响这些模块的性能。

来源：http://www.infoq.com/cn/articles/thread-pools-boost-performance-9x

提问: 我有一个USB盘包含了LVM分区。 我想要在Linux中访问这些LVM分区。我该如何在Linux中挂载LVM分区？

LVM是逻辑卷管理工具，它允许你使用逻辑卷和卷组的概念来管理磁盘空间。使用LVM相比传统分区最大的好处是弹性地为用户和程序分配空间而不用考虑每个物理磁盘的大小。

在LVM中，那些创建了逻辑分区的物理存储是传统的分区（比如：/dev/sda2，/dev/sdb1）。这些分区必须被初始化为“物理卷 PV”并加上卷标（如，“Linux LVM”）来使它们可以在LVM中使用。一旦分区被标记被LVM分区，你不能直接用mount命令挂载。

如果你尝试挂载一个LVM分区（比如/dev/sdb2）, 你会得到下面的错误。

$ mount /dev/sdb2 /mntmount: unknown filesystem type 'LVM2_member'

要正确地挂载LVM分区，你必须挂载分区中创建的“逻辑卷”。下面就是如何做的。

首先，用下面的命令检查可用的卷组：

$ sudo pvs PV         VG                           Fmt  Attr PSize   PFree/dev/sdb2  vg_ezsetupsystem40a8f02fadd0 lvm2 a--  237.60g    0 

物理卷的名字和卷组的名字分别在PV和VG列的下面。本例中，只有一个创建在dev/sdb2下的组“vg_ezsetupsystem40a8f02fadd0”。

接下来检查卷组中存在的逻辑卷，使用lvdisplay命令：

$ sudo lvdisplay 

使用lvdisplay显示了可用卷的信息（如：设备名、卷名、卷大小等等）。

$ sudo lvdisplay /dev/vg_ezsetupsystem40a8f02fadd0

  --- Logical volume ---
  LV Path                /dev/vg_ezsetupsystem40a8f02fadd0/lv_root
  LV Name                lv_root
  VG Name                vg_ezsetupsystem40a8f02fadd0
  LV UUID                imygta-P2rv-2SMU-5ugQ-g99D-A0Cb-m31eet
  LV Write Access        read/write
  LV Creation host, time livecd.centos, 2015-03-16 18:38:18 -0400
  LV Status              available
  # open                 0
  LV Size                50.00 GiB
  Current LE             12800
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           252:0

上图可以看到两个逻辑卷的名字：lv_root和lv_home

如果你想要挂载一个特定的逻辑卷，使用如下的“LV Path”的设备名（如：/dev/vg_ezsetupsystem40a8f02fadd0/lv_home）。

$ sudo mount /dev/vg_ezsetupsystem40a8f02fadd0/lv_home /mnt

你可以用mount命令不带任何参数检查挂载状态，这会显示所有已挂载的文件系统。

$ mount

如果你想在每次启动时自动挂载逻辑卷，在/etc/fstab中添加下面的行，你可以指定卷的文件系统类型（如 ext4），它可以从mount命令的输出中找。

/dev/vg_ezsetupsystem40a8f02fadd0/lv_home /mnt ext4 defaults 0 0

现在逻辑卷会在每次启动时挂载到/mnt。

via: http://ask.xmodulo.com/mount-lvm-partition-linux.html

作者：Dan Nanni 译者：geekpi 校对：wxy

本文由 LCTT 原创翻译，Linux中国 荣誉推出

来源：https://linux.cn/article-5693-1.html

本文我们介绍一个shell脚本，用来使用rsync命令将你本地Linux机器上的文件/目录备份到远程Linux服务器上。使用该脚本会以交互的方式实施备份，你需要提供远程备份服务器的主机名/ip地址和文件夹位置。我们使用一个单独的列表文件，在这个文件中你需要列出要备份的文件/目录。我们添加了两个脚本，第一个脚本在每次拷贝完一个文件后询问密码（如果你启用了ssh密钥验证，那么就不会询问密码），而第二个脚本中，则只会提示一次输入密码。

我们打算备份bckup.txt，dataconfig.txt，docs和orcledb。

[root@Fedora21 tmp]# ls -l
total 12
-rw-r--r--. 1 root root 0 May 15 10:43 bckrsync.sh
-rw-r--r--. 1 root root 0 May 15 10:44 bckup.txt
-rw-r--r--. 1 root root 0 May 15 10:46 dataconfig.txt
drwxr-xr-x. 2 root root 4096 May 15 10:45 docs
drwxr-xr-x. 2 root root 4096 May 15 10:44 oracledb

bckup.txt文件包含了需要备份的文件/目录的详情

[root@Fedora21 tmp]# cat /tmp/bckup.txt
/tmp/oracledb
/tmp/dataconfig.txt
/tmp/docs
[root@Fedora21 tmp]#

脚本 1：

#!/bin/bash
# 将备份列表文件的路径保存到变量中
backupf='/tmp/bckup.txt'
# 输入一个提示信息
echo "Shell Script Backup Your Files / Directories Using rsync"
# 检查是否输入了目标服务器，如果为空就再次提示用户输入
while [ x$desthost = "x" ]; do
# 提示用户输入目标服务器地址并保存到变量
read -p "Destination backup Server : " desthost
# 结束循环
done
# 检查是否输入了目标文件夹，如果为空就再次提示用户输入
while [ x$destpath = "x" ]; do
# 提示用户输入目标文件夹并保存到变量
read -p "Destination Folder : " destpath
# 结束循环
done
# 逐行读取备份列表文件
for line in `cat $backupf`
# 对每一行都进行处理
do
# 显示要被复制的文件/文件夹名称
echo "Copying $line ... "
# 通过 rsync 复制文件/文件夹到目标位置
rsync -ar "$line" "$desthost":"$destpath"
# 显示完成
echo "DONE"
# 结束
done

运行带有输出结果的脚本

[root@Fedora21 tmp]# ./bckrsync.sh
Shell Script Backup Your Files / Directories Using rsync
Destination backup Server : 104.*.*.41
Destination Folder : /tmp
Copying /tmp/oracledb ...
The authenticity of host '104.*.*.41 (104.*.*.41)' can't be established.
ECDSA key fingerprint is 96:11:61:17:7f:fa:......
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '104.*.*.41' (ECDSA) to the list of known hosts.
root@104.*.*.41's password:
DONE
Copying /tmp/dataconfig.txt ...
root@104.*.*.41's password:
DONE
Copying /tmp/docs ...
root@104.*.*.41's password:
DONE
[root@Fedora21 tmp]#

脚本 2：

#!/bin/bash
# 将备份列表文件的路径保存到变量中
backupf='/tmp/bckup.txt'
# 输入一个提示信息
echo "Shell Script Backup Your Files / Directories Using rsync"
# 检查是否输入了目标服务器，如果为空就再次提示用户输入
while [ x$desthost = "x" ]; do
# 提示用户输入目标服务器地址并保存到变量
read -p "Destination backup Server : " desthost
# 结束循环
done
# 检查是否输入了目标文件夹，如果为空就再次提示用户输入
while [ x$destpath = "x" ]; do
# 提示用户输入目标文件夹并保存到变量
read -p "Destination Folder : " destpath
# 结束循环
done
# 检查是否输入了目标服务器密码，如果为空就再次提示用户输入
while [ x$password = "x" ]; do
# 提示用户输入密码并保存到变量
# 使用 -s 选项不回显输入的密码
read -sp "Password : " password
# 结束循环
done
# 逐行读取备份列表文件
for line in `cat $backupf`
# 对每一行都进行处理
do
# 显示要被复制的文件/文件夹名称
echo "Copying $line ... "
# 使用 expect 来在脚本中输入密码
/usr/bin/expect << EOD
# 推荐设置超时为 -1
set timeout -1
# 通过 rsync 复制文件/文件夹到目标位置，使用 expect 的组成部分 spawn 命令
spawn rsync -ar ${line} ${desthost}:${destpath}
# 上一行命令会等待 “password” 提示
expect "*?assword:*"
# 在脚本中提供密码
send "${password}r"
# 等待文件结束符（远程服务器处理完了所有事情）
expect eof
# 结束 expect 脚本
EOD
# 显示结束
echo "DONE"
# 完成
done

运行第二个带有输出结果的脚本的屏幕截图

希望这些脚本对你备份会有帮助！！

via: http://linoxide.com/linux-shell-script/shell-script-backup-files-directories-rsync/

作者：Yevhen Duma 译者：GOLinux 校对：wxy

本文由 LCTT 原创翻译，Linux中国 荣誉推出

来源：https://linux.cn/article-5694-1.html

创建

复制一个已创建的仓库:

$ git clone ssh://user@domain.com/repo.git

创建一个新的本地仓库:

$ git init

本地修改

显示工作路径下已修改的文件：

$ git status

显示与上次提交版本文件的不同：

$ git diff

把当前所有修改添加到下次提交中：

$ git add

把对某个文件的修改添加到下次提交中：

$ git add -p 

提交本地的所有修改：

$ git commit -a

提交之前已标记的变化：

$ git commit

附加消息提交：

$ git commit -m 'message here'

提交，并将提交时间设置为之前的某个日期:

git commit --date="`date --date='n day ago'`" -am "Commit Message"

修改上次提交 _{请勿修改已发布的提交记录!}

$ git commit --amend

把当前分支中未提交的修改移动到其他分支

git stash
git checkout branch2
git stash pop

搜索

从当前目录的所有文件中查找文本内容：

$ git grep "Hello"

在某一版本中搜索文本：

$ git grep "Hello" v2.5

提交历史

从最新提交开始，显示所有的提交记录（显示hash， 作者信息，提交的标题和时间）：

$ git log

显示所有提交（仅显示提交的hash和message）：

$ git log --oneline

显示某个用户的所有提交：

$ git log --author="username"

显示某个文件的所有修改：

$ git log -p 

谁，在什么时间，修改了文件的什么内容：

$ git blame 

分支与标签

列出所有的分支：

$ git branch

切换分支：

$ git checkout 

创建并切换到新分支:

$ git checkout -b 

基于当前分支创建新分支：

$ git branch 

基于远程分支创建新的可追溯的分支：

$ git branch --track  

删除本地分支:

$ git branch -d 

给当前版本打标签：

$ git tag 

更新与发布

列出当前配置的远程端：

$ git remote -v

显示远程端的信息：

$ git remote show 

添加新的远程端：

$ git remote add  

下载远程端版本，但不合并到HEAD中：

$ git fetch 

下载远程端版本，并自动与HEAD版本合并：

$ git remote pull  

将远程端版本合并到本地版本中：

$ git pull origin master

将本地版本发布到远程端：

$ git push remote  

删除远程端分支：

$ git push  : (since Git v1.5.0)
或
git push  --delete  (since Git v1.7.0)

发布标签:

$ git push --tags

合并与重置

将分支合并到当前HEAD中：

$ git merge 

将当前HEAD版本重置到分支中: _{请勿重置已发布的提交!}

$ git rebase 

退出重置:

$ git rebase --abort

解决冲突后继续重置：

$ git rebase --continue

使用配置好的merge tool 解决冲突：

$ git mergetool

在编辑器中手动解决冲突后，标记文件为已解决冲突

$ git add 

$ git rm 

撤销

放弃工作目录下的所有修改：

$ git reset --hard HEAD

移除缓存区的所有文件（i.e. 撤销上次git add）:

$ git reset HEAD

放弃某个文件的所有本地修改：

$ git checkout HEAD 

重置一个提交（通过创建一个截然不同的新提交）

$ git revert 

将HEAD重置到指定的版本，并抛弃该版本之后的所有修改：

$ git reset --hard 

将HEAD重置到上一次提交的版本，并将之后的修改标记为未添加到缓存区的修改：

$ git reset 

将HEAD重置到上一次提交的版本，并保留未提交的本地修改：

$ git reset --keep 

来源：https://github.com/flyhigher139/Git-Cheat-Sheet/blob/master/Git%20Cheat%20Sheet-Zh.md

前言

通常一个网站数据库挂掉后，后果将是非常严重的。基本上整个网站基本不可用了。对于一些网站来说，当数据库挂掉后，如果能提供基本的浏览服务，也是不错的。本文将尝试使用 varnish + nginx + lua 搭建网站降级系统来实现整个目标。

降级目标

降级方案的目标是，当网站出现致命故障时（如出现500错误，不能提供服务），可以把缓存的页面数据展现给用户。从而提供基本的浏览服务。

1. 只提供基本的浏览服务
2. 浏览的数据都是非登录状态下的数据
3. 支持手动和自动降级。自动降级是当后端返回500错误次数在一段时间内达到一定阈值(不包含503)。手动降级是从控制界面操作。

降级方案

存储

使用varnish作为存储。有效的节约了物理内存，并保持了较好的性能。

更新

使用crond脚本从nginx的access日志中分析出请求url，然后向varnish发请求，从而更新varnish的缓存。缓存的异步更新，减少对nginx的压力。

降级

支持手动降级和自动降级。降级后，nginx自动从varnish中提取数据，并返回给用户。

流程图

流程描述

1. 用户请求到nginx时，nginx会判断当前是否是降级状态。如果属于降级状态，直接从varnish中获取数据。非降级状态，把请求转到php-fpm。
2. 当crond脚本请求varnish进行缓存数据更新时，如果当前varnish处于降级状态，则不进行缓存更新。如果没有处在降级状态，则把请求转到nginx，获取数据。然后把获取的数据缓存到varnish中。
3. varnish会自动监控后端nginx的状态。如果检测到nginx已经处于降级状态，则varnish也会自动进入降级状态。

安装部署

vanish安装到/home/varnish 目录下。安装步骤如下：

首先，安装libpcre。

sudo yum install pcre pcre-devel

其次，安装varnish。

./configure --prefix=/home/varnish
make
sudo -u admin make install
sudo -u admin mkdir -p /home/varnish/vcache/
sudo chown admin:admin -R /home/varnish
sudo -u admin touch /home/varnish/vcache/varnish_cache.data
sudo chmod 777 /home/varnish/vcache/varnish_cache.data

再次，修改varnish配置文件和部署相关脚本。点击下载文件压缩包。配置文件名为default.vcl。

最后，启动varnish。启动脚本也在压缩包中，名称为 varnishctl

sudo /home/admin/varnish/sbin/varnishctl start

注意：启动后可以通过varnishlog命令查看是否运行正常。如果出现以下字样，说明运行正常。http的返回状态为200

$ /home/varnish/bin/varnishlog
0 Backend_health - default Still healthy 4--X-RH 4 2 4 0.002698 0.001722 HTTP/1.1 200 OK

部署lua脚本

lua脚本在/home/admin/nginx/data/lua目录下。 确保目录下有如下几个个脚本。

pc_get_downgrade_data.lua
init.lua
pc_status_stat.lua
pc_get_status.lua
pc_set_satus.lua

这几个脚本在下载的压缩包中有。

修改nginx配置文件

首先，在http域增加

init_by_lua_file 'lua/init.lua';
lua_shared_dict pc_status 1m;
lua_shared_dict pc_auto_status 1m;
#varnish config
upstream varnish{
    server 127.0.0.1:8080 weight=1 max_fails=2 fail_timeout=5s;
}

最后，在server域宏增加如下配置。

location @php {
  include fastcgi_params;
}
location @var {
 proxy_pass http://varnish$str_params;
}
location ~* ^(.+.php)(.*)$ {
  #check downgrade status, then get data from varnish
  set $str_params $uri;
  content_by_lua_file lua/pc_get_downgrade_data.lua;
}
location /hl_get_auto_status {
           if ($white_ip = 0) {
               return 403;
           }
           content_by_lua_file lua/pc_get_auto_status.lua;
 }
location /hl_get_status {
     if ($white_ip = 0) {
         return 403;
     }
     content_by_lua_file lua/pc_get_status.lua;
}
location /hl_set_status {
           if ($white_ip = 0) {
               return 403;
           }
           content_by_lua_file lua/pc_set_status.lua;
}
log_by_lua_file  lua/pc_status_stat.lua;

部署crond脚本

脚本varnish_crond.php。在crond中增加执行命令。每分钟执行一次。

来自crond的请求，user-agent数据为varnish_crond。把user-agent为varnish_crond请求特殊处理。保证能正常请求，并返回相关数据。

降级管理

varnish降级

只要让varnish配置中指定的监控脚本check.php返回500错误即可。varnish监控到指定脚本不可用，自动会进入降级状态。当脚本返回200状态后，varnish自动又会恢复正常。

nginx降级

设置降级：

curl -H "Host:demo.bo56.com" -i http://127.0.0.1/hl_set_status?status=1

恢复正常：

curl -H "Host:demo.bo56.com" -i http://127.0.0.1/hl_set_status?status=0

查看降级状态：

curl -H "Host:demo.bo56.com" -i http://127.0.0.1/hl_get_status

如果返回的值为1表示降级。

来源：http://www.bo56.com/%E4%BD%BF%E7%94%A8varnish-nginx-lua%E6%90%AD%E5%BB%BA%E7%BD%91%E7%AB%99%E7%9A%84%E9%99%8D%E7%BA%A7%E7%B3%BB%E7%BB%9F/

location表达式类型

• ~ 表示执行一个正则匹配，区分大小写
• ~* 表示执行一个正则匹配，不区分大小写
• ^~ 表示普通字符匹配。使用前缀匹配。如果匹配成功，则不再匹配其他location。
• = 进行普通字符精确匹配。也就是完全匹配。
• @ 它定义一个命名的 location，使用在内部定向时，例如 error_page, try_files

location优先级说明

在nginx的location和配置中location的顺序没有太大关系。正location表达式的类型有关。相同类型的表达式，字符串长的会优先匹配。

以下是按优先级排列说明：

1. 等号类型（=）的优先级最高。一旦匹配成功，则不再查找其他匹配项。
2. ^~类型表达式。一旦匹配成功，则不再查找其他匹配项。
3. 正则表达式类型（~ ~*）的优先级次之。如果有多个location的正则能匹配的话，则使用正则表达式最长的那个。
4. 常规字符串匹配类型。按前缀匹配。

location优先级示例

配置项如下:

location = / {
    # 仅仅匹配请求 /
    [ configuration A ]
}
location / {
    # 匹配所有以 / 开头的请求。
    # 但是如果有更长的同类型的表达式，则选择更长的表达式。
    # 如果有正则表达式可以匹配，则优先匹配正则表达式。
    [ configuration B ]
}
location /documents/ {
    # 匹配所有以 /documents/ 开头的请求。
    # 但是如果有更长的同类型的表达式，则选择更长的表达式。
    # 如果有正则表达式可以匹配，则优先匹配正则表达式。
    [ configuration C ]
}
location ^~ /images/ {
    # 匹配所有以 /images/ 开头的表达式，如果匹配成功，则停止匹配查找。
    # 所以，即便有符合的正则表达式location，也不会被使用
    [ configuration D ]
}
location ~* .(gif|jpg|jpeg)$ {
    # 匹配所有以 gif jpg jpeg结尾的请求。
    # 但是 以 /images/开头的请求，将使用 Configuration D
    [ configuration E ]
}

请求匹配示例

/ -> configuration A
/index.html -> configuration B
/documents/document.html -> configuration C
/images/1.gif -> configuration D
/documents/1.jpg -> configuration E

注意，以上的匹配和在配置文件中定义的顺序无关。

来源：http://www.bo56.com/nginx-location%E5%9C%A8%E9%85%8D%E7%BD%AE%E4%B8%AD%E7%9A%84%E4%BC%98%E5%85%88%E7%BA%A7/

Docker自从诞生以来就一直备受追捧，学习Docker是一件很炫酷、很有意思的事情。我希望通过这篇文章能够让大家快速地入门Docker，并有一些学习成果来激发自己的学习兴趣。我也只是一个在Docker这条巨鲸上玩耍的小孩，全文如有不明确、不正确的地方，还请斧正。

Ubuntu上安装Docker

Docker的基础是Linux容器技术，因此学习Docker最好是使用Linux。这里推荐64位Ubuntu系统，因为在写此文(2015-05-28)时，Docker还不支持32位，尽管民间有些土办法可以象征性的解决，但还是推荐初学Docker的尽量按照标准的来。如果手边没有Ubuntu系统可以去Digitalocean、Ucloud等云服务商去租用一个Linux服务器。这样即使玩坏了也可以随时重新开始。

在Ubuntu中只需要运行一行命令即可实现Docker的安装：

sudo apt-get install docker.io

运行完后，可以在终端输入docker看到下面的界面证明我们安装成功了（注：提示权限问题就添加sudo，下文同）:

从上图可以看到，Docker的命令并不多，只有三十几个。例如我们可以输入docker info来查看我们安装的Docker信息:

运行容器

安装好之后，我们就可以来开始Docker之旅了，

我们现在的Docker还是一个”裸”Docker，上面没有容器，等一下，什么式容器？所谓容器就是Docker中用来运行应用的，Docker的容器很轻量级，但功能却强悍的很。也没有镜像。镜像？镜像简单理解就是容器的只读版本，用来方便存储与交流。此时，我们可以通过官方提供给我们的镜像来进行学习。比如我们想在Docker中运行一个Ubuntu系统，很简单，Docker中得pull命令是用来获取镜像的，执行下面的命令，就会从官方仓库里获取Ubuntu 14.04版本的系统:

docker pull ubuntu:14.04

images命令用来查看本机Docker中存在哪些镜像，运行 docker images就会看到我们刚才获取的Ubuntu14.04系统:

现在，我们把刚刚的镜像运行起来，运行起来的镜像就叫做容器了，容器是可读写的，这样我们就可以在容器里做很多有意思的事情了。run 命令就是将镜像运行起来的，运行:

docker run -it ubuntu:14.04

仔细看，你会发现终端交互的用户名变掉了，说明我们进入到了容器的内部，效果如下:

现在我们所做的任何操作都是针对于目前容器而言的，不会影响到原来的系统，例如，我们在里面安装下nginx服务器，运行如下命令:

sudo apt-get install -y nginx

完成后执行nginx -v就会发现我们已经将nginx安装成功:

将容器转化为镜像

在上一小节中，我们已经在容器里安装好了nginx，接下来我们希望将这个容器内容保存下来，这样我们下次就无需再次安装了。这就是Docker中将容器转换为镜像的技术。

如果您还在刚刚的安装了nginx的终端里，执行exit退出此终端，回到系统本身的终端:

ps命令可以查看我们当前都运行了哪些容器，加上-a参数后就表示运行过哪些容器，因为我们刚刚已经退出了安装nginx的容器，因此我现在想查看它的话，需要使用-a参数，执行如下命令:

docker ps -a

此时，就会显示出我们刚刚运行的容器，并且Docker会很贴心的随机给每个容器都起个Names方便标示。效果如下：

commit命令用来将容器转化为镜像，运行下面的命令，我们可以讲刚刚的容器转换为镜像:

sudo docker commit -m "Added nginx from ubuntu14.04"-a "saymagic"79c761f627f3 saymagic/ubuntu-nginx:v1

其中，-m参数用来来指定提交的说明信息；-a可以指定用户信息的；79c761f627f3代表的时容器的id；saymagic/ubuntu-nginx:v1指定目标镜像的用户名、仓库名和 tag 信息。创建成功后会返回这个镜像的 ID 信息。注意的是，你一定要将saymagic改为你自己的用户名。因为下文还会用到此用户名。

这是我们再次使用docker images命令就会发现此时多出了一个我们刚刚创建的镜像:

此时，如果运行docker run -it saymagic/ubuntu-nginx:v1就会是一个已经安装了nginx的容器:

存储镜像

我们刚刚已经创建了自己的第一个镜像，尽管它很简单，但这已经非常棒了，现在，我们希望它能够被更多的人使用到，此时，我们就需要将这个镜像上传到镜像仓库，Docker的官方Docker Hub应该是目前最大的Docker镜像中心，所以，我们就将我们的镜像上传到Docker Hub。

首先，我们需要成为Docker Hub的用户，前往https://hub.docker.com/进行注册。需要注意的是，为了方便下面的操作，你需要将你的用户名设为和我刚刚在上文提到的自定义用户名相同，例如我的刚刚将镜像的名字命名为是saymagic/ubuntu-nginx:v2,所以我的用户名为saymagic、注册完成后记住用户名、密码、邮箱。

login默认是用来登陆Docker Hub的，因此，输入如下命令来尝试登陆Docker Hub:

docker login

此时，就会输出交互，让我们输入Username、Password、Email,成功输入我们刚才注册的信息后就会返回Login Success提示:

运行命令:

docker push saymagic/ubuntu-nginx:v1

这就是我们为什么将刚刚的镜像命名为saymagic/ubuntu-nginx:v1的原因，如果你上面步骤都操作正确的正确的话，是会得到下面的内容:

此时，不出意外的话，我们的镜像已经被上传到Docker Hub上面了，去Docker Hub上面看看：

果然，我们在Docker Hub上有了我们的第一个镜像，此时，其它的用户就可以通过命令docker pull saymagic/ubuntu-nginx来直接获取一个安装了nginx的ubuntu系统了。不信？那就自己实践一下吧！

Dockerfile使用

通过上面的学习，我们掌握了如何创建镜像、获取镜像、上传镜像、运行容器等等内容。有了上面的知识，我们来次实战。

我们刚刚使用了commit命令创建了一个安装nginx的镜像，但其实Docker创建镜像的命令还有build,build命令可以通过指定一个Dockerfile文件来实现将镜像创建过程自动化。Dockerfile文件有着特定的编写规则，但语法都还比较容易理解。这次我们不仅使用Dockerfile文件来创建一个像上文一样安装nginx的ubuntu镜像，还要发挥nginx的老本行来运行一个网页吧！DockFile可以很轻松的完成这个问题。首先将新建一个名字为www的文件夹，文件夹下面可以放一些HTML网页，比如新建一个index.html文件，随便写点内容:

  
    Learn Docker
  
  
    
Enjoy Docker!
  

在www的同级目录下新建一个名为Dockerfile的文件，将DockerFile文件改写如下：

FROM ubuntu:14.04
MAINTAINER saymagic saymagic@163.com
RUN apt-get update
RUN apt-get install -y nginx
COPY ./www /usr/share/nginx/html
EXPOSE 80
CMD ["nginx","-g","daemon off;"]

我来整体的解释下这个Dockerfile文件，第一行是用来声明我们的镜像是基于什么构建的，这里我们指定为ubuntu14.04 ,第二行的作用在于告诉别人你的大名。第三行和第四行的RUN命令用来在容器内部的shell里执行命令。第五行将当前系统的www文件夹拷贝到容器的/usr/share/nginx/html目录下，第六行声明当前需要对外开放80端口，最后一行表示运行容器时开启nginx。不理解没关系，因为这都是固定的语法，感兴趣可以多看相关内容。此时我们通过build命令来构建镜像，运行：

docker build -t="saymagic/ubuntu-nginx:v2" .

注意，最后的.表示Dockerfile在当前目录，也可指定其它目录。此时，再次运行docker images就会看到刚刚生成的镜像：

现在我们就可以运行刚刚的镜像了，和前面运行稍有不同，此时我们需要对外指定80端口，该行为通过-p参数指定，运行:

docker run -p 80:80 saymagic/ubuntu-nginx:v2

此时，终端会卡住，这是正常的，因为Docker的思想是每个容器最好只开一个线程做一件事，此时我们打开了nginx服务器，所以终端卡住也没关系（当然是有办法来解决这个问题，但这里不做介绍）。现在我们可以通过浏览器访问localhost查看效果，如果是虚拟主机则需输入主机ip地址,然后就能看到了如下的页面:

DaoCloud实战

如果我们自己没有服务器，刚刚的网页我们只能在本地访问，好可惜。别急，现在我要隆重介绍一个Docker的好伙伴-DaoCloud，官网传送门：https://www.daocloud.io/

有了DaoCloud，我们只需要负责写Dockerfile，剩下的build、运行之类的东西都交给DaoCloud，我们只需要点一点按钮即可。

DaoCloud会将Github、GitCafe等git服务商作为代码源，这里我使用GitCafe，为了你下面的操作更加方便，你可以直接Fork我的项目，项目地址:https://gitcafe.com/saymagic/LearnDocker

接着，我们需要去Daocloud注册一个账号，完成后，进入个人主页后选择代码构建->创建新项目->给项目起一个响亮的名字->同步GitCafe代码源->选择GitCafe下的LearnDocker项目：

最后，点击开始创建按钮。Daoloud就会马不停蹄的运行起来。如果细心的话你会发现，DaoCloud的build会比本地快很多，很迅速就会完成镜像的构建：

仅仅是构建镜像没什么意思， DaoCloud还可以将这个镜像在云端运行起来。我们点击绿色的查看镜像按钮，跳转到如下页面：

在DaoCloud中镜像需要运行在容器中，因为当前我们只构建了一个版本，所以选择部署最新版本和下面的部署按钮效果相同，点击任意一个，来到了这里：

我们给容器起一个霸气的名字｀learndocker｀，然后点击页面最下面的立即部署按钮，秒秒钟，我们的应用就运行了起来：

此时，注意到你自己运行成功的url后面的链接，将其复制到浏览器打开，你会发现，网页的内容就是本篇博客：

写在最后

Docker能做的事情远不止这些，更多有意思的事情还请读者慢慢用心去发现。

来源：http://blog.saymagic.cn/2015/06/01/learning-docker.html

如果你一直关注新闻，那么就知道Ubuntu将会切换到带有Unity 8桌面的Mir显示服务器。然而，在尚未确定运行在 Mir 上的Unity 8是否会出现在Ubuntu 15.10 Willy Werewolf之前，有了一个Unity 8的预览版本可供你体验和测试。通过官方PPA，可以很容易地安装Unity 8到Ubuntu 14.04,14.10和15.04中。

到目前为止，开发者已经可以通过ISO（主要途径）获得该Unity 8预览来进行测试。不过Canonical也通过LXC容器发布了它。通过该方法，你可以使用Unity 8桌面会话，让它像其它桌面环境一样运行在Mir显示服务器上。就像你在Ubuntu中安装Mate桌面，然后从LightDm登录屏幕选择桌面会话一样。

想要试试Unity 8？让我们来看怎样安装它吧。

注意： 它是一个实验性预览，可能不是所有人都可以让它正确工作的。

安装Unity 8桌面到Ubuntu

下面是安装并使用Unity 8的步骤：

步骤 1： 安装Unity 8到Ubuntu 12.04和14.04

如果你正运行着Ubuntu 12.04和14.04，那么你必须使用官方PPA来安装Unity 8。使用以下命令进行安装：

sudo apt-add-repository ppa:unity8-desktop-session-team/unity8-preview-lxc
sudo apt-get update
sudo apt-get upgrade
sudo apt-get install unity8-lxc

步骤 1： 安装Unity 8到Ubuntu 14.10和15.04

如果你正运行着Ubuntu 14.10或15.04，那么Unity 8 LXC已经在源中准备好。你只需要运行以下命令：

sudo apt-get update
sudo apt-get install unity8-lxc

步骤 2： 设置Unity 8桌面预览LXC

安装Unity 8 LXC后，该对它进行设置，下面的命令就可达到目的：

sudo unity8-lxc-setup

它将花费一些时间来设置，所以，耐心点。它会下载ISO，然后解压缩，接着完成最后一些必要的设置来让它工作。它也会安装一个LightDM的轻度修改版本。这一切都搞定后，需要重启。

步骤 3： 选择Unity 8

重启后，在登录屏幕，点击你的登录旁边的Ubuntu图标：

你应该可以在这看到Unity 8的选项，选择它：

卸载Unity 8 LXC

如果你发现Unity 8毛病太多，或者你不喜欢它，那么你可以以相同的方式切换回默认Unity版本。此外，你也可以通过下面的命令移除Unity 8：

sudo apt-get remove unity8-lxc

该命令会将Unity 8选项从LightDM屏幕移除，但是配置仍然保留着。

以上就是你在Ubuntu中安装带有Mir的Unity 8的全部过程，试玩后请分享你关于Unity 8的想法哦！

via: http://itsfoss.com/install-unity-8-desktop-ubuntu/

作者：Abhishek 译者：GOLinux 校对：wxy

本文由 LCTT 原创翻译，Linux中国 荣誉推出

来源：https://linux.cn/article-5704-1.html

Nginx （engine-x）是一个开源的高性能 HTTP 服务器、反向代理和 IMAP/POP3 代理服务器。nginx 杰出的功能有：稳定、丰富的功能集、简单的配置和低资源消耗。nginx 被用于一些高性能网站并在站长之间变得越来越流行。本教程会从源码构建一个带有 google paespeed 模块的用于 Ubuntu 15.04 的 nginx .deb 安装包。

pagespeed 是一个由 google 开发的 web 服务器模块来加速网站响应时间、优化 html 和减少页面加载时间。ngx_pagespeed 的功能如下：

• 图像优化：去除元数据、动态缩放、重压缩。
• CSS 与 JavaScript 压缩、串联、内联、外联。
• 小资源内联
• 图像与 JavaScript 延迟加载
• HTML 重写
• 缓存生命期插件

更多请见 https://developers.google.com/speed/pagespeed/module/。

前置要求

• Ubuntu Server 15.04 64位
• root 权限

本篇我们将要：

• 安装必备软件包
• 安装带 ngx_pagespeed 的 nginx
• 测试

安装必备包

sudo apt-get install dpkg-dev build-essential zlib1g-dev libpcre3 libpcre3-dev

安装带 ngx_pagespeed 的 nginx

第一步 – 添加nginx仓库

vim /etc/apt/sources.list.d/nginx.list

加入下面的行：

deb http://nginx.org/packages/ubuntu/ trusty nginx
deb-src http://nginx.org/packages/ubuntu/ trusty nginx

更新仓库：

sudo apt-get update

注意：如果你看到信息：GPG error […] NO_PUBKEY […] 等等

请添加key：

sudo sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys KEYNUMBER
sudo apt-get update

第二步 – 从仓库下载 nginx 1.8

sudo su
cd ~
mkdir -p ~/new/nginx_source/
cd ~/new/nginx_source/
apt-get source nginx
apt-get build-dep nginx

第三步 – 下载 Pagespeed

cd ~
mkdir -p ~/new/ngx_pagespeed/
cd ~/new/ngx_pagespeed/
ngx_version=1.9.32.3
wget https://github.com/pagespeed/ngx_pagespeed/archive/release-${ngx_version}-beta.zip
unzip release-${ngx_version}-beta.zip
cd ngx_pagespeed-release-1.9.32.3-beta/
wget https://dl.google.com/dl/page-speed/psol/${ngx_version}.tar.gz
tar -xzf 1.9.32.3.tar.gz

第四步 – 配置 nginx 来编译 Pagespeed

cd ~/new/nginx_source/nginx-1.8.0/debin/
vim rules

在两处 CFLAGS .configure下添加模块：

--add-module=../../ngx_pagespeed/ngx_pagespeed-release-1.9.32.3-beta

第五步 – 打包 nginx 软件包并安装

cd ~/new/nginx_source/nginx-1.8.0/
dpkg-buildpackage -b

dpkg-buildpackage 会编译 ~/new/ngix_source/ 为 nginx.deb。打包完成后，看一下目录：

cd ~/new/ngix_source/
ls

接着安装 nginx。

dpkg -i nginx_1.8.0-1~trusty_amd64.deb

测试

运行 nginx -V 测试 nginx 是否已经自带 ngx_pagespeed。

nginx -V

总结

稳定、快速、开源的 nginx 支持许多不同的优化模块。这其中之一是 google 开发的‘pagespeed’。不像 apache，nginx 模块不是动态加载的，因此你必须在编译之前就选择好需要的模块。

via: https://www.howtoforge.com/tutorial/how-to-install-nginx-and-google-pagespeed-on-ubuntu-15-04/ 

作者：Muhammad Arul 译者：geekpi 校对：wxy

本文由 LCTT 原创翻译，Linux中国 荣誉推出

来源：https://linux.cn/article-5707-1.html

1. 安装nginx

1.1 选择稳定版本

我们编译安装nginx来定制自己的模块，机器CentOS 6.2 x86_64。首先安装缺少的依赖包：

# yum -y install gcc gcc-c++ make libtool zlib zlib-devel openssl openssl-devel pcre pcre-devel

这些软件包如果yum上没有的话可以下载源码来编译安装，只是要注意编译时默认安装的目录，确保下面在安装nginx时能够找到这些动态库文件（ldconfig）。

从 http://nginx.org/en/download.html 下载稳定版nginx-1.6.3.tar.gz到/usr/local/src下解压。

为了后续准备我们另外下载2个插件模块：nginx_upstream_check_module-0.3.0.tar.gz —— 检查后端服务器的状态，nginx-goodies-nginx-sticky-module-ng-bd312d586752.tar.gz（建议在/usr/local/src下解压后将目录重命名为nginx-sticky-module-ng-1.2.5） —— 后端做负载均衡解决session sticky问题（与upstream_check模块结合使用需要另外打补丁，请参考nginx负载均衡配置实战）。

请注意插件与nginx的版本兼容问题，一般插件越新越好，nginx不用追新，稳定第一。nginx-1.4.7，nginx-sticky-module-1.1，nginx_upstream_check_module-0.2.0，这个搭配也没问题。sticky-1.1与nginx-1.6版本由于更新没跟上编译出错。（可以直接使用Tengine，默认就包括了这些模块）

[root@cachets nginx-1.6.3]# pwd
/usr/local/src/nginx-1.6.3
[root@cachets nginx-1.6.3]# ./configure --prefix=/usr/local/nginx-1.6 --with-pcre
> --with-http_stub_status_module --with-http_ssl_module
> --with-http_gzip_static_module --with-http_realip_module
> --add-module=../nginx_upstream_check_module-0.3.0
[root@cachets nginx-1.6.3]# make && make install

1.2 常用编译选项说明

nginx大部分常用模块，编译时./configure --help以--without开头的都默认安装。

• --prefix=PATH ： 指定nginx的安装目录。默认 /usr/local/nginx
• --conf-path=PATH ： 设置nginx.conf配置文件的路径。nginx允许使用不同的配置文件启动，通过命令行中的-c选项。默认为prefix/conf/nginx.conf
• --user=name： 设置nginx工作进程的用户。安装完成后，可以随时在nginx.conf配置文件更改user指令。默认的用户名是nobody。--group=name类似
• --with-pcre ： 设置PCRE库的源码路径，如果已通过yum方式安装，使用--with-pcre自动找到库文件。使用--with-pcre=PATH时，需要从PCRE网站下载pcre库的源码（版本4.4 – 8.30）并解压，剩下的就交给Nginx的./configure和make来完成。perl正则表达式使用在location指令和 ngx_http_rewrite_module模块中。
• --with-zlib=PATH ： 指定 zlib（版本1.1.3 – 1.2.5）的源码解压目录。在默认就启用的网络传输压缩模块ngx_http_gzip_module时需要使用zlib 。
• --with-http_ssl_module ： 使用https协议模块。默认情况下，该模块没有被构建。前提是openssl与openssl-devel已安装
• --with-http_stub_status_module ： 用来监控 Nginx 的当前状态
• --with-http_realip_module ： 通过这个模块允许我们改变客户端请求头中客户端IP地址值(例如X-Real-IP 或 X-Forwarded-For)，意义在于能够使得后台服务器记录原始客户端的IP地址
• --add-module=PATH ： 添加第三方外部模块，如nginx-sticky-module-ng或缓存模块。每次添加新的模块都要重新编译（Tengine可以在新加入module时无需重新编译）

再提供一种编译方案：

./configure
> --prefix=/usr
> --sbin-path=/usr/sbin/nginx
> --conf-path=/etc/nginx/nginx.conf
> --error-log-path=/var/log/nginx/error.log
> --http-log-path=/var/log/nginx/access.log
> --pid-path=/var/run/nginx/nginx.pid
> --lock-path=/var/lock/nginx.lock
> --user=nginx
> --group=nginx
> --with-http_ssl_module
> --with-http_stub_status_module
> --with-http_gzip_static_module
> --http-client-body-temp-path=/var/tmp/nginx/client/
> --http-proxy-temp-path=/var/tmp/nginx/proxy/
> --http-fastcgi-temp-path=/var/tmp/nginx/fcgi/
> --http-uwsgi-temp-path=/var/tmp/nginx/uwsgi
> --with-pcre=../pcre-7.8
> --with-zlib=../zlib-1.2.3

1.3 启动关闭nginx

## 检查配置文件是否正确
# /usr/local/nginx-1.6/sbin/nginx -t
# ./sbin/nginx -V     # 可以看到编译选项
## 启动、关闭
# ./sbin/nginx        # 默认配置文件 conf/nginx.conf，-c 指定
# ./sbin/nginx -s stop
或 pkill nginx
## 重启，不会改变启动时指定的配置文件
# ./sbin/nginx -s reload
或 kill -HUP `cat /usr/local/nginx-1.6/logs/nginx.pid`

当然也可以将 nginx 作为系统服务管理，下载 nginx 到/etc/init.d/，修改里面的路径然后赋予可执行权限。

# service nginx {start|stop|status|restart|reload|configtest}

1.4 yum安装

yum安装rpm包会比编译安装简单很多，默认会安装许多模块，但缺点是如果你想以后安装第三方模块那就没办法了。

# vi /etc/yum.repo.d/nginx.repo
[nginx]
name=nginx repo
baseurl=http://nginx.org/packages/centos/$releasever/$basearch/
gpgcheck=0
enabled=1

剩下的就yum install nginx搞定，也可以yum install nginx-1.6.3安装指定版本（前提是你去packages里看到有对应的版本，默认是最新版稳定版）。

2. nginx.conf配置文件

Nginx配置文件主要分成四部分：main（全局设置）、server（主机设置）、upstream（上游服务器设置，主要为反向代理、负载均衡相关配置）和 location（URL匹配特定位置后的设置），每部分包含若干个指令。main部分设置的指令将影响其它所有部分的设置；server部分的指令主要用于指定虚拟主机域名、IP和端口；upstream的指令用于设置一系列的后端服务器，设置反向代理及后端服务器的负载均衡；location部分用于匹配网页位置（比如，根目录“/”,“/images”,等等）。他们之间的关系式：server继承main，location继承server；upstream既不会继承指令也不会被继承。它有自己的特殊指令，不需要在其他地方的应用。

当前nginx支持的几个指令上下文：

2.1 通用

下面的nginx.conf简单的实现nginx在前端做反向代理服务器的例子，处理js、png等静态文件，jsp等动态请求转发到其它服务器tomcat：

user  www www;
worker_processes  2;
error_log  logs/error.log;
#error_log  logs/error.log  notice;
#error_log  logs/error.log  info;
pid        logs/nginx.pid;
events {
    use epoll;
    worker_connections  2048;
}
http {
    include       mime.types;
    default_type  application/octet-stream;
    #log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
    #                  '$status $body_bytes_sent "$http_referer" '
    #                  '"$http_user_agent" "$http_x_forwarded_for"';
    #access_log  logs/access.log  main;
    sendfile        on;
    # tcp_nopush     on;
    keepalive_timeout  65;
  # gzip压缩功能设置
    gzip on;
    gzip_min_length 1k;
    gzip_buffers    4 16k;
    gzip_http_version 1.0;
    gzip_comp_level 6;
    gzip_types text/html text/plain text/css text/javascript application/json application/javascript application/x-javascript application/xml;
    gzip_vary on;
  # http_proxy 设置
    client_max_body_size   10m;
    client_body_buffer_size   128k;
    proxy_connect_timeout   75;
    proxy_send_timeout   75;
    proxy_read_timeout   75;
    proxy_buffer_size   4k;
    proxy_buffers   4 32k;
    proxy_busy_buffers_size   64k;
    proxy_temp_file_write_size  64k;
    proxy_temp_path   /usr/local/nginx/proxy_temp 1 2;
  # 设定负载均衡后台服务器列表
    upstream  backend  {
              #ip_hash;
              server   192.168.10.100:8080 max_fails=2 fail_timeout=30s ;
              server   192.168.10.101:8080 max_fails=2 fail_timeout=30s ;
    }
  # 很重要的虚拟主机配置
    server {
        listen       80;
        server_name  itoatest.example.com;
        root   /apps/oaapp;
        charset utf-8;
        access_log  logs/host.access.log  main;
        #对 / 所有做负载均衡+反向代理
        location / {
            root   /apps/oaapp;
            index  index.jsp index.html index.htm;
            proxy_pass        http://backend;
            proxy_redirect off;
            # 后端的Web服务器可以通过X-Forwarded-For获取用户真实IP
            proxy_set_header  Host  $host;
            proxy_set_header  X-Real-IP  $remote_addr;
            proxy_set_header  X-Forwarded-For  $proxy_add_x_forwarded_for;
            proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
        }
        #静态文件，nginx自己处理，不去backend请求tomcat
        location  ~* /download/ {
            root /apps/oa/fs;
        }
        location ~ .*.(gif|jpg|jpeg|bmp|png|ico|txt|js|css)$
        {
            root /apps/oaapp;
            expires      7d;
        }
       	location /nginx_status {
            stub_status on;
            access_log off;
            allow 192.168.10.0/24;
            deny all;
        }
        location ~ ^/(WEB-INF)/ {
            deny all;
        }
        #error_page  404              /404.html;
        # redirect server error pages to the static page /50x.html
        #
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }
    }
  ## 其它虚拟主机，server 指令开始
}

2.2 常用指令说明

2.2.1 main全局配置

nginx在运行时与具体业务功能（比如http服务或者email服务代理）无关的一些参数，比如工作进程数，运行的身份等。

• woker_processes 2在配置文件的顶级main部分，worker角色的工作进程的个数，master进程是接收并分配请求给worker处理。这个数值简单一点可以设置为cpu的核数grep ^processor /proc/cpuinfo | wc -l，也是 auto 值，如果开启了ssl和gzip更应该设置成与逻辑CPU数量一样甚至为2倍，可以减少I/O操作。如果nginx服务器还有其它服务，可以考虑适当减少。

• worker_cpu_affinity也是写在main部分。在高并发情况下，通过设置cpu粘性来降低由于多CPU核切换造成的寄存器等现场重建带来的性能损耗。如worker_cpu_affinity 0001 0010 0100 1000; （四核）。

• worker_connections 2048写在events部分。每一个worker进程能并发处理（发起）的最大连接数（包含与客户端或后端被代理服务器间等所有连接数）。nginx作为反向代理服务器，计算公式 最大连接数 = worker_processes * worker_connections/4，所以这里客户端最大连接数是1024，这个可以增到到8192都没关系，看情况而定，但不能超过后面的worker_rlimit_nofile。当nginx作为http服务器时，计算公式里面是除以2。

• worker_rlimit_nofile 10240写在main部分。默认是没有设置，可以限制为操作系统最大的限制65535。

• use epoll写在events部分。在Linux操作系统下，nginx默认使用epoll事件模型，得益于此，nginx在Linux操作系统下效率相当高。同时Nginx在OpenBSD或FreeBSD操作系统上采用类似于epoll的高效事件模型kqueue。在操作系统不支持这些高效模型时才使用select。

2.2.2 http服务器

与提供http服务相关的一些配置参数。例如：是否使用keepalive啊，是否使用gzip进行压缩等。

• sendfile on开启高效文件传输模式，sendfile指令指定nginx是否调用sendfile函数来输出文件，减少用户空间到内核空间的上下文切换。对于普通应用设为 on，如果用来进行下载等应用磁盘IO重负载应用，可设置为off，以平衡磁盘与网络I/O处理速度，降低系统的负载。

• keepalive_timeout 65 : 长连接超时时间，单位是秒，这个参数很敏感，涉及浏览器的种类、后端服务器的超时设置、操作系统的设置，可以另外起一片文章了。长连接请求大量小文件的时候，可以减少重建连接的开销，但假如有大文件上传，65s内没上传完成会导致失败。如果设置时间过长，用户又多，长时间保持连接会占用大量资源。

• send_timeout : 用于指定响应客户端的超时时间。这个超时仅限于两个连接活动之间的时间，如果超过这个时间，客户端没有任何活动，Nginx将会关闭连接。

• client_max_body_size 10m允许客户端请求的最大单文件字节数。如果有上传较大文件，请设置它的限制值

• client_body_buffer_size 128k缓冲区代理缓冲用户端请求的最大字节数

模块http_proxy：

这个模块实现的是nginx作为反向代理服务器的功能，包括缓存功能（另见文章）

• proxy_connect_timeout 60nginx跟后端服务器连接超时时间(代理连接超时)

• proxy_read_timeout 60连接成功后，与后端服务器两个成功的响应操作之间超时时间(代理接收超时)

• proxy_buffer_size 4k设置代理服务器（nginx）从后端realserver读取并保存用户头信息的缓冲区大小，默认与proxy_buffers大小相同，其实可以将这个指令值设的小一点

• proxy_buffers 4 32kproxy_buffers缓冲区，nginx针对单个连接缓存来自后端realserver的响应，网页平均在32k以下的话，这样设置

• proxy_busy_buffers_size 64k高负荷下缓冲大小（proxy_buffers*2）

• proxy_max_temp_file_size当 proxy_buffers 放不下后端服务器的响应内容时，会将一部分保存到硬盘的临时文件中，这个值用来设置最大临时文件大小，默认1024M，它与 proxy_cache 没有关系。大于这个值，将从upstream服务器传回。设置为0禁用。

• proxy_temp_file_write_size 64k当缓存被代理的服务器响应到临时文件时，这个选项限制每次写临时文件的大小。proxy_temp_path（可以在编译的时候）指定写到哪那个目录。

proxy_pass，proxy_redirect见 location 部分。

模块http_gzip：

• gzip on : 开启gzip压缩输出，减少网络传输。
  • gzip_min_length 1k ： 设置允许压缩的页面最小字节数，页面字节数从header头得content-length中进行获取。默认值是20。建议设置成大于1k的字节数，小于1k可能会越压越大。
  • gzip_buffers 4 16k ： 设置系统获取几个单位的缓存用于存储gzip的压缩结果数据流。4 16k代表以16k为单位，安装原始数据大小以16k为单位的4倍申请内存。
  • gzip_http_version 1.0 ： 用于识别 http 协议的版本，早期的浏览器不支持 Gzip 压缩，用户就会看到乱码，所以为了支持前期版本加上了这个选项，如果你用了 Nginx 的反向代理并期望也启用 Gzip 压缩的话，由于末端通信是 http/1.0，故请设置为 1.0。
  • gzip_comp_level 6 ： gzip压缩比，1压缩比最小处理速度最快，9压缩比最大但处理速度最慢(传输快但比较消耗cpu)
  • gzip_types ：匹配mime类型进行压缩，无论是否指定,”text/html”类型总是会被压缩的。
  • gzip_proxied any ： Nginx作为反向代理的时候启用，决定开启或者关闭后端服务器返回的结果是否压缩，匹配的前提是后端服务器必须要返回包含”Via”的 header头。
  • gzip_vary on ： 和http头有关系，会在响应头加个 Vary: Accept-Encoding ，可以让前端的缓存服务器缓存经过gzip压缩的页面，例如，用Squid缓存经过Nginx压缩的数据。。

2.2.3 server虚拟主机

http服务上支持若干虚拟主机。每个虚拟主机一个对应的server配置项，配置项里面包含该虚拟主机相关的配置。在提供mail服务的代理时，也可以建立若干server。每个server通过监听地址或端口来区分。

• listen监听端口，默认80，小于1024的要以root启动。可以为listen *:80、listen 127.0.0.1:80等形式。

• server_name服务器名，如localhost、www.example.com，可以通过正则匹配。

模块http_stream

这个模块通过一个简单的调度算法来实现客户端IP到后端服务器的负载均衡，upstream后接负载均衡器的名字，后端realserver以 host:port options; 方式组织在 {} 中。如果后端被代理的只有一台，也可以直接写在 proxy_pass 。

2.2.4 location

http服务中，某些特定的URL对应的一系列配置项。

• root /var/www/html定义服务器的默认网站根目录位置。如果locationURL匹配的是子目录或文件，root没什么作用，一般放在server指令里面或/下。

• index index.jsp index.html index.htm定义路径下默认访问的文件名，一般跟着root放

• proxy_pass http:/backend请求转向backend定义的服务器列表，即反向代理，对应upstream负载均衡器。也可以proxy_pass http://ip:port。

• proxy_redirect off;proxy_set_header Host $host;proxy_set_header X-Real-IP $remote_addr;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;这四个暂且这样设，如果深究的话，每一个都涉及到很复杂的内容，也将通过另一篇文章来解读。

关于location匹配规则的写法，可以说尤为关键且基础的，参考文章 nginx配置location总结及rewrite规则写法;

2.3 其它

2.3.1 访问控制 allow/deny

Nginx 的访问控制模块默认就会安装，而且写法也非常简单，可以分别有多个allow,deny，允许或禁止某个ip或ip段访问，依次满足任何一个规则就停止往下匹配。如：

location /nginx-status {
  stub_status on;
  access_log off;
#  auth_basic   "NginxStatus";
#  auth_basic_user_file   /usr/local/nginx-1.6/htpasswd;
  allow 192.168.10.100;
  allow 172.29.73.0/24;
  deny all;
}

我们也常用 httpd-devel 工具的 htpasswd 来为访问的路径设置登录密码：

# htpasswd -c htpasswd admin
New passwd:
Re-type new password:
Adding password for user admin
# htpasswd htpasswd admin    //修改admin密码
# htpasswd htpasswd sean    //多添加一个认证用户

这样就生成了默认使用CRYPT加密的密码文件。打开上面nginx-status的两行注释，重启nginx生效。

2.3.2 列出目录 autoindex

Nginx默认是不允许列出整个目录的。如需此功能，打开nginx.conf文件，在location，server 或 http段中加入autoindex on;，另外两个参数最好也加上去:

• autoindex_exact_size off; 默认为on，显示出文件的确切大小，单位是bytes。改为off后，显示出文件的大概大小，单位是kB或者MB或者GB
• autoindex_localtime on;默认为off，显示的文件时间为GMT时间。改为on后，显示的文件时间为文件的服务器时间

location /images {
  root   /var/www/nginx-default/images;
  autoindex on;
  autoindex_exact_size off;
  autoindex_localtime on;
}

参考

• http://liuqunying.blog.51cto.com/3984207/1420556
• http://nginx.org/en/docs/ngx_core_module.html#worker_cpu_affinity
• http://wiki.nginx.org/HttpCoreModule#sendfile

来源：http://seanlook.com/2015/05/17/nginx-install-and-config/

由于一切都迁移到了云上，作为提高职员生产力的一种方式，虚拟远程桌面在工业中越来越流行。尤其对于那些需要在多个地方和设备之间不停漫游的人，远程桌面可以让他们和工作环境保持无缝连接。远程桌面对于雇主同样有吸引力，可以在工作环境中提高敏捷性和灵活性，由于硬件整合、桌面安全加固等原因降低 IT 花费。

在 Linux 世界中，理所当然设置远程桌面有很多选择，支持许多协议（例如 RDP、RFB、NX） 和服务器/客户端实现（例如 TigerVNC、RealVNC、FreeNX、x2go、X11vnc、TeamViewer 等等）。

这当中有个出色的产品叫做 X2Go，它是一个基于 NX（译者注：通过计算机网络显示远程桌面环境的一种技术，可参考 Wiki）的远程桌面服务器和客户端的开源(GPLv2)实现。在这个教程中，我会介绍 如何为 Linux VPS 使用 X2Go 设置远程桌面环境。

X2Go 是什么？

X2Go 的历史要追溯到 NoMachine 的 NX 技术。NX 远程桌面协议的设计目的是通过利用主动压缩和缓存解决低带宽和高延迟的网络连接问题。后来，NX 转为闭源，但 NX 库还是采用 GPL 协议。这导致出现了多种基于 NX 的远程桌面解决方案开源实现，X2Go 就是其中之一。

和其它解决方案例如 VNC 相比，X2Go 有哪些好处呢？ X2Go 继承了 NX 技术的所有高级功能，很自然能在慢速网络连接上良好工作。另外，由于它内置的基于 SSH 的加密技术，X2Go 保持了确保安全的良好业绩记录。不再需要手动设置 SSH 隧道 。X2Go 默认支持音频，这意味着远程桌面的音乐播放可以通过网络传送，并进入本地扬声器。在易用性方面，远程桌面上运行的应用程序可以在你的本地桌面中以一个独立窗口无缝呈现，会给你造成一种应用程序实际上在你本地桌面运行的错觉。正如你看到的，这些都是一些基于 VNC 的解决方案所缺少的强大功能。

X2GO 的桌面环境兼容性

和其它远程桌面服务器一样，X2Go 服务器也有一些已知的兼容性问题。像 KDE 3/4、Xfce、MATE 和 LXDE 是对 X2Go 服务器最友好的桌面环境。但是，用其它桌面管理器效果可能有所不同。例如，已知 GNOME 3 之后的版本、KDE 5、Unity 和 X2Go 并不兼容。如果你的远程主机的桌面管理器和 X2Go 兼容，你可以继续以下的教程。

在 Linux 上安装 X2Go 服务器

X2Go 由远程桌面服务器和客户端组件组成。让我们首先安装 X2Go 服务器。我假设你已经有一个和 X2Go 兼容的桌面管理器并且在远程主机上运行，我们会安装 X2Go 服务器到该远程主机。

注意系统启动后 X2Go 服务器组件没有需要单独启动的服务。你只需要保证开启了 SSH 服务并在正常运行。

Ubuntu 或 Linux Mint：

配置 X2Go PPA 库。对于 Ubuntu 14.04 以及更高版本，有可用的 X2Go PPA。

$ sudo add-apt-repository ppa:x2go/stable
$ sudo apt-get update
$ sudo apt-get install x2goserver x2goserver-xsession

Debian (Wheezy)：

$ sudo apt-key adv --recv-keys --keyserver keys.gnupg.net E1F958385BFE2B6E
$ sudo sh -c "echo deb http://packages.x2go.org/debian wheezy main > /etc/apt/sources.list.d/x2go.list"
$ sudo sh -c "echo deb-src http://packages.x2go.org/debian wheezy main >> /etc/apt/sources.list.d/x2go.list"
$ sudo apt-get update
$ sudo apt-get install x2goserver x2goserver-xsession

Fedora：

$ sudo yum install x2goserver x2goserver-xsession

CentOS/RHEL：

首先启用 EPEL 库 然后运行：

$ sudo yum install x2goserver x2goserver-xsession

在 Linux 上安装 X2Go 客户端

在将会连接到远程桌面的本地主机上，安装以下命令安装 X2Go 客户端。

Ubuntu 或 Linux Mint：

配置 X2Go PPA 库。对于 Ubuntu 14.04 以及更高版本，有可用的 X2Go PPA。

$ sudo add-apt-repository ppa:x2go/stable
$ sudo apt-get update
$ sudo apt-get install x2goclient

Debian (Wheezy)：

$ sudo apt-key adv --recv-keys --keyserver keys.gnupg.net E1F958385BFE2B6E
$ sudo sh -c "echo deb http://packages.x2go.org/debian wheezy main > /etc/apt/sources.list.d/x2go.list"
$ sudo sh -c "echo deb-src http://packages.x2go.org/debian wheezy main >> /etc/apt/sources.list.d/x2go.list"
$ sudo apt-get update
$ sudo apt-get install x2goclient

Fedora：

$ sudo yum install x2goclient

CentOS/RHEL：

首先启用 EPEL 库 ，然后运行：

$ sudo yum install x2goclient

用 X2Go 客户端连接到远程桌面

现在可以连接到远程桌面了。在本地主机上，只需运行以下命令或者使用桌面启动器启动 X2Go 客户端。

$ x2goclient

输入远程主机的 IP 地址和 SSH 用户名称。同时，指定会话类型（例如，远程主机的桌面管理器）。

如果需要的话，你可以自定义其它东西（通过点击其它的标签），例如连接速度、压缩、屏幕分辨率等等。

当你初始化一个远程桌面连接的时候，会要求你登录。输入你的 SSH 登录名和密码。

成功登陆后，你会看到远程桌面屏幕。

如果你想测试 X2Go 的无缝窗口功能，选择 “Single application” 会话类型，然后指定远处主机上可执行文件的路径。在该例子中，我选择远程 KDE 主机上的 Dolphin 文件管理器。

你成功连接后，你会在本地桌面上看到一个远程应用窗口，而不是完整的远程桌面屏幕。

总结

在这篇教程中，我介绍了如何在 Linux VPS 实例上设置 X2Go 远程桌面。正如你所看到的，整个设置过程都非常简单（如果你使用一个合适的桌面环境的话）。尽管对于特定桌面仍有问题，X2Go 是一个安全、功能丰富、快速并且免费的远程桌面解决方案。

X2Go 的什么功能最吸引你？欢迎分享你的观点。

via: http://xmodulo.com/x2go-remote-desktop-linux.html

作者：Dan Nanni 译者：ictlyh 校对：wxy

本文由 LCTT 原创翻译，Linux中国 荣誉推出

来源：https://linux.cn/article-5708-1.html

流畅地使用命令行是一个常被忽略的技能，或被认为是神秘的奥义。但是，它会以明显而微妙的方式改善你作为工程师的灵活度和生产力。这是我在 Linux 上工作时发现的有用的命令行使用小窍门和笔记的精粹。有些小窍门是很基础的，而有些是相当地特别、复杂、或者晦涩难懂。这篇文章不长，但是如果你可以使用并记得这里的所有内容，那么你就懂得很多了。

其中大部分最初出现在Quora上，但是考虑到兴趣所在，似乎更应该放到 Github 上，这里的人比我更能提出改进建议。如果你看到一个错误，或者更好的某种东西，请提交问题或 PR！（当然，提交前请看看必读小节和已有的 PR/Issue。）

必读

范围：

• 本文是针对初学者和专业人员的，选题目标是覆盖面广（全都很重要）、有针对性（大多数情况下都给出具体实例）而简洁（避免不必要内容以及你能在其它地方轻松找到的离题的内容）。每个小窍门在某种情形下都很必需的，或者能比替代品大大节省时间。
• 这是为 Linux 写的。绝大部分条目都可以同样应用到 MacOS（或者甚至 Cygwin）。
• 主要针对交互式 Bash，尽管大多数小窍门也可以应用到其它 shell，以及常规 Bash 脚本。
• 包括了“标准的”UNIX 命令以及那些需要安装的软件包（它们很重要，值得安装）。

注意：

• 为了能在一篇文章内展示尽量多的东西，一些具体的信息会被放到引用页里。你可以使用 Google 来获得进一步的内容。（如果需要的话，）你可以使用 apt-get/yum/dnf/pacman/pip/brew来安装这些新的程序。
• 使用 Explainshell 来获取命令、参数、管道等内容的解释。

• 学习基本 Bash 技能。实际上，键入man bash，然后至少浏览一遍所有内容；它很容易理解，没那么长。其它 shell 也不错，但是 Bash 很强大，而且到处都可以找到（如果在你自己的笔记本上只学习 zsh、fish 之类，会在很多情形下受到限制，比如使用现存的服务器时）。

• 至少学好一种基于文本的编辑器。理想的一个是 Vim（vi），因为在终端中编辑时随时都能找到它（即使大多数时候你在使用 Emacs、一个大型的 IDE、或一个现代的时髦编辑器）。

• 学习怎样使用 man来阅读文档（好奇的话，用 man man来列出分区号，比如 1 是常规命令，5 是文件描述，8 用于管理员）。用 apropos找到帮助页。了解哪些命令不是可执行程序，而是 Bash 内置的，你可以用 help和 help -d得到帮助。

• 学习使用 >和 <来进行输出和输入重定向，以及使用 |来管道重定向，学习关于 stdout 和 stderr 的东西。

• 学习 *（也许还有 ?和 {…}）文件通配扩展和应用，以及双引号 "和单引号 '之间的区别。（更多内容请参看下面关于变量扩展部分）。

• 熟悉 Bash 作业管理：&， ctrl-z， ctrl-c， jobs， fg， bg， kill等等。

• 掌握ssh，以及通过 ssh-agent，ssh-add等进行无密码验证的基础技能。

• 基本的文件管理：ls和 ls -l（特别是，知道ls -l各个列的意义），less， head， tail和 tail -f（或者更好的less +F），ln和 ln -s（知道硬链接和软链接的区别，以及硬链接相对于软链接的优势），chown，chmod，du（用于查看磁盘使用率的快速摘要：du -sk *）。文件系统管理：df， mount，fdisk，mkfs，lsblk。

• 基本的网络管理： ip或 ifconfig，dig。

• 熟知正则表达式，以及各种使用grep/egrep的选项。-i，-o，-A和 -B选项值得掌握。

• 学会使用 apt-get，yum，dnf或 pacman（这取决于你的发行版）来查找并安装软件包。确保你可以用 pip来安装基于 Python 的命令行工具（下面的一些东西可以很容易地通过 pip安装）。

• 对于 Web 调试，curl和 curl -I很方便灵活，或者也可以使用它们的同行 wget，或者更现代的 httpie。

• 要了解磁盘、CPU、网络的状态，使用 iostat，netstat，top（或更好的 htop）和（特别是）dstat。它们对于快速获知系统中发生的状况很好用。

• 对于更深层次的系统总览，可以使用 glances。它会在一个终端窗口中为你呈现几个系统层次的统计数据，对于快速检查各个子系统很有帮助。

• 要了解内存状态，可以运行 free和 vmstat，看懂它们的输出结果吧。特别是，要知道“cached”值是Linux内核为文件缓存所占有的内存，因此，要有效地统计“free”值。

• Java 系统调试是一件截然不同的事，但是对于 Oracle 系统以及其它一些 JVM 而言，不过是一个简单的小把戏，你可以运行 kill -3 ，然后一个完整的堆栈追踪和内存堆的摘要（包括常规的垃圾收集细节，这很有用）将被转储到stderr/logs。

• 使用 mtr作路由追踪更好，可以识别网络问题。

• 对于查看磁盘满载的原因，ncdu会比常规命令如 du -sh *更节省时间。

• 要查找占用带宽的套接字和进程，试试 iftop或 nethogs吧。

• （Apache附带的）ab工具对于临时应急检查网络服务器性能很有帮助。对于更复杂的负载测试，可以试试 siege。

• 对于更仔细的网络调试，可以用 wireshark，tshark或 ngrep。

• 掌握 strace和 ltrace。如果某个程序失败、挂起或崩溃，而你又不知道原因，或者如果你想要获得性能的大概信息，这些工具会很有帮助。注意，分析选项（-c）和使用 -p关联运行进程。

• 掌握 ldd来查看共享库等。

• 知道如何使用 gdb来连接到一个运行着的进程并获取其堆栈追踪信息。

• 使用 /proc。当调试当前的问题时，它有时候出奇地有帮助。样例：/proc/cpuinfo，/proc/xxx/cwd，/proc/xxx/exe，/proc/xxx/fd/，/proc/xxx/smaps。

• 当调试过去某个东西为何出错时，sar会非常有帮助。它显示了 CPU、内存、网络等的历史统计数据。

• 对于更深层的系统和性能分析，看看 stap(SystemTap)，perf) 和 sysdig 吧。

• 确认是正在使用的 Linux 发行版版本（支持大多数发行版）：lsb_release -a。

• 每当某个东西的行为异常时（可能是硬件或者驱动器问题），使用dmesg。

• expr：实施算术或布林操作，或者求正则表达式的值

• m4：简单的宏处理器

• yes：大量打印一个字符串

• cal：漂亮的日历

• env：（以特定的环境变量设置）运行一个命令（脚本中很有用）

• look：查找以某个字符串开头的英文单词（或文件中的行）

• cut和 paste以及 join：数据处理

• fmt：格式化文本段落

• pr：格式化文本为页/列

• fold：文本折行

• column：格式化文本为列或表

• expand和 unexpand：在制表符和空格间转换

• nl：添加行号

• seq：打印数字

• bc：计算器

• factor：分解质因子

• gpg：加密并为文件签名

• toe：terminfo 条目表

• nc：网络调试和数据传输

• socat：套接字中继和 tcp 端口转发（类似 netcat）

• slurm：网络流量可视化

• dd：在文件或设备间移动数据

• file：识别文件类型

• tree：以树形显示目录及子目录；类似 ls，但是是递归的。

• stat：文件信息

• tac：逆序打印文件

• shuf：从文件中随机选择行

• comm：逐行对比分类排序的文件

• hd和bvi：转储或编辑二进制文件

• strings：从二进制文件提取文本

• tr：字符转译或处理

• iconv或uconv：文本编码转换

• split和csplit：分割文件

• units：单位转换和计算；将每双周（fortnigh）一浪（浪，furlong，长度单位，约201米）转换为每瞬（blink）一缇（缇，twip，一种和屏幕无关的长度单位）（参见： /usr/share/units/definitions.units）（LCTT 译注：这都是神马单位啊！）

• 7z：高比率文件压缩

• ldd：动态库信息

• nm：目标文件的符号

• ab：Web 服务器基准测试

• strace：系统调用调试

• mtr：用于网络调试的更好的路由追踪软件

• cssh：可视化并发 shell

• rsync：通过 SSH 同步文件和文件夹

• wireshark和 tshark：抓包和网络调试

• ngrep：从网络层摘取信息

• host和 dig：DNS查询

• lsof：处理文件描述符和套接字信息

• dstat：有用的系统统计数据

• glances：高级，多个子系统概览

• iostat：CPU和磁盘使用率统计

• htop：top的改进版

• last：登录历史

• w：谁登录进来了

• id：用户/组身份信息

• sar：历史系统统计数据

• iftop或nethogs：按套接口或进程的网络使用率

• ss：套接口统计数据

• dmesg：启动和系统错误信息

• hdparm：SATA/ATA 磁盘操作/改善性能

• lsb_release：Linux 发行版信息

• lsblk：列出块设备，以树形展示你的磁盘和分区

• lshw：硬件信息

• fortune，ddate和 sl：嗯，好吧，它取决于你是否认为蒸汽机车和 Zippy 引用“有用”

任何版本控制系统的一个最有的用特性就是“撤销 (undo)”你的错误操作的能力。在 Git 里，“撤销” 蕴含了不少略有差别的功能。

当你进行一次新的提交的时候，Git 会保存你代码库在那个特定时间点的快照；之后，你可以利用 Git 返回到你的项目的一个早期版本。

在本篇博文里，我会讲解某些你需要“撤销”已做出的修改的常见场景，以及利用 Git 进行这些操作的最佳方法。

撤销一个“已公开”的改变

场景: 你已经执行了 git push, 把你的修改发送到了 GitHub，现在你意识到这些 commit 的其中一个是有问题的，你需要撤销那一个 commit.

方法: git revert

原理: git revert 会产生一个新的 commit，它和指定 SHA 对应的 commit 是相反的（或者说是反转的）。如果原先的 commit 是“物质”，新的 commit 就是“反物质” — 任何从原先的 commit 里删除的内容会在新的 commit 里被加回去，任何在原先的 commit 里加入的内容会在新的 commit  里被删除。

这是 Git 最安全、最基本的撤销场景，因为它并不会改变历史 — 所以你现在可以  git push 新的“反转” commit 来抵消你错误提交的 commit。

修正最后一个 commit 消息

场景: 你在最后一条 commit 消息里有个笔误，已经执行了 git commit -m "Fxies bug #42"，但在 git push 之前你意识到消息应该是 “Fixes bug #42″。

方法: git commit --amend 或 git commit --amend -m "Fixes bug #42"

原理: git commit --amend 会用一个新的 commit 更新并替换最近的 commit ，这个新的 commit 会把任何修改内容和上一个 commit 的内容结合起来。如果当前没有提出任何修改，这个操作就只会把上次的 commit 消息重写一遍。 

撤销“本地的”修改

场景: 一只猫从键盘上走过，无意中保存了修改，然后破坏了编辑器。不过，你还没有 commit 这些修改。你想要恢复被修改文件里的所有内容 — 就像上次 commit 的时候一模一样。

方法: git checkout --

原理: git checkout 会把工作目录里的文件修改到 Git 之前记录的某个状态。你可以提供一个你想返回的分支名或特定 SHA ，或者在缺省情况下，Git 会认为你希望 checkout 的是 HEAD，当前 checkout 分支的最后一次 commit。

记住：你用这种方法“撤销”的任何修改真的会完全消失。因为它们从来没有被提交过，所以之后 Git 也无法帮助我们恢复它们。你要确保自己了解你在这个操作里扔掉的东西是什么！（也许可以先利用 git diff 确认一下）

重置“本地的”修改

场景: 你在本地提交了一些东西（还没有 push），但是所有这些东西都很糟糕，你希望撤销前面的三次提交 — 就像它们从来没有发生过一样。

方法: git reset  或 git reset --hard

原理: git reset 会把你的代码库历史返回到指定的 SHA 状态。 这样就像是这些提交从来没有发生过。缺省情况下， git reset 会保留工作目录。这样，提交是没有了，但是修改内容还在磁盘上。这是一种安全的选择，但通常我们会希望一步就“撤销”提交以及修改内容 — 这就是 --hard 选项的功能。

在撤销“本地修改”之后再恢复

场景: 你提交了几个 commit，然后用 git reset --hard 撤销了这些修改（见上一段），接着你又意识到：你希望还原这些修改！

方法: git reflog 和 git reset 或 git checkout

原理: git reflog 对于恢复项目历史是一个超棒的资源。你可以恢复几乎 任何东西 — 任何你 commit 过的东西 — 只要通过 reflog。

你可能已经熟悉了 git log 命令，它会显示 commit 的列表。 git reflog 也是类似的，不过它显示的是一个 HEAD 发生改变的时间列表.

一些注意事项：

• 它涉及的只是 HEAD 的改变。在你切换分支、用 git commit 进行提交、以及用 git reset 撤销 commit 时，HEAD 会改变，但当你用  git checkout --  撤销时（正如我们在前面讲到的情况），HEAD 并不会改变 — 如前所述，这些修改从来没有被提交过，因此 reflog 也无法帮助我们恢复它们。
• git reflog 不会永远保持。Git 会定期清理那些 “用不到的” 对象。不要指望几个月前的提交还一直躺在那里。
• 你的 reflog 就是你的，只是你的。你不能用 git reflog 来恢复另一个开发者没有 push 过的 commit。

那么…你怎么利用 reflog 来“恢复”之前“撤销”的 commit 呢？它取决于你想做到的到底是什么：

• 如果你希望准确地恢复项目的历史到某个时间点，用 git reset --hard
• 如果你希望重建工作目录里的一个或多个文件，让它们恢复到某个时间点的状态，用 git checkout --
• 如果你希望把这些 commit 里的某一个重新提交到你的代码库里，用 git cherry-pick

利用分支的另一种做法

场景: 你进行了一些提交，然后意识到你开始 check out 的是 master分支。你希望这些提交进到另一个特性（feature）分支里。

方法: git branch feature, git reset --hard origin/master, and git checkout feature

原理: 你可能习惯了用 git checkout -b 创建新的分支 — 这是创建新分支并马上 check out 的流行捷径 — 但是你不希望马上切换分支。这里， git branch feature 创建一个叫做 feature 的新分支并指向你最近的 commit，但还是让你 check out 在 master 分支上。

下一步，在提交任何新的 commit 之前，用 git reset –hard 把 master 分支倒回 origin/master。不过别担心，那些 commit 还在 feature分支里。

场景: 你在 master 分支的基础上创建了 feature 分支，但 master 分支已经滞后于 origin/master很多。现在 master 分支已经和 origin/master同步，你希望在 feature 上的提交是从现在开始，而不是也从滞后很多的地方开始。

方法: git checkout feature 和 git rebase master

原理: 要达到这个效果，你本来可以通过 git reset (不加 --hard, 这样可以在磁盘上保留修改) 和 git checkout -b  然后再重新提交修改，不过这样做的话，你就会失去提交历史。我们有更好的办法。

git rebase master 会做如下的事情：

• 首先它会找到你当前 check out 的分支和 master分支的共同祖先。
• 然后它 reset 当前  check out 的分支到那个共同祖先，在一个临时保存区存放所有之前的提交。
• 然后它把当前 check out 的分支提到 master 的末尾部分，并从临时保存区重新把存放的 commit 提交到 master 分支的最后一个 commit 之后。

大量的撤销/恢复

场景: 你向某个方向开始实现一个特性，但是半路你意识到另一个方案更好。你已经进行了十几次提交，但你现在只需要其中的一部分。你希望其他不需要的提交统统消失。

方法: git rebase -i

原理: -i 参数让 rebase 进入“交互模式”。它开始类似于前面讨论的 rebase，但在重新进行任何提交之前，它会暂停下来并允许你详细地修改每个提交。

rebase -i 会打开你的缺省文本编辑器，里面列出候选的提交。如下所示：

前面两列是键：第一个是选定的命令，对应第二列里的 SHA 确定的 commit。缺省情况下， rebase -i  假定每个 commit 都要通过  pick 命令被运用。

要丢弃一个 commit，只要在编辑器里删除那一行就行了。如果你不再需要项目里的那几个错误的提交，你可以删除上例中的1、3、4行。

如果你需要保留 commit 的内容，而是对 commit 消息进行编辑，你可以使用 reword 命令。 把第一列里的 pick 替换为 reword (或者直接用 r)。有人会觉得在这里直接重写 commit 消息就行了，但是这样不管用 —rebase -i 会忽略 SHA 列前面的任何东西。它后面的文本只是用来帮助我们记住 0835fe2 是干啥的。当你完成 rebase -i 的操作之后，你会被提示输入需要编写的任何 commit 消息。

如果你需要把两个 commit 合并到一起，你可以使用 squash 或 fixup 命令，如下所示：

squash 和 fixup 会“向上”合并 — 带有这两个命令的 commit 会被合并到它的前一个 commit 里。在这个例子里， 0835fe2 和 6943e85 会被合并成一个 commit， 38f5e4e 和 af67f82 会被合并成另一个。

如果你选择了 squash， Git 会提示我们给新合并的 commit 一个新的 commit 消息； fixup 则会把合并清单里第一个 commit 的消息直接给新合并的 commit 。 这里，你知道 af67f82 是一个“完了完了….” 的 commit，所以你会留着 38f5e4e 的 commit 消息，但你会给合并了 0835fe2 和 6943e85 的新 commit 编写一个新的消息。

在你保存并退出编辑器的时候，Git 会按从顶部到底部的顺序运用你的 commit。你可以通过在保存前修改 commit 顺序来改变运用的顺序。如果你愿意，你也可以通过如下安排把 af67f82 和 0835fe2 合并到一起：

修复更早期的 commit

场景: 你在一个更早期的 commit 里忘记了加入一个文件，如果更早的 commit 能包含这个忘记的文件就太棒了。你还没有 push，但这个 commit 不是最近的，所以你没法用 commit --amend.

方法: git commit --squash  和 git rebase --autosquash -i

原理: git commit --squash 会创建一个新的 commit ，它带有一个 commit 消息，类似于 squash! Earlier commit。 (你也可以手工创建一个带有类似 commit 消息的 commit，但是 commit --squash 可以帮你省下输入的工作。)

如果你不想被提示为新合并的 commit 输入一条新的 commit 消息，你也可以利用 git commit --fixup 。在这个情况下，你很可能会用commit --fixup ，因为你只是希望在 rebase 的时候使用早期 commit 的 commit 消息。

rebase --autosquash -i  会激活一个交互式的 rebase 编辑器，但是编辑器打开的时候，在 commit 清单里任何 squash! 和 fixup! 的 commit 都已经配对到目标 commit 上了，如下所示：

在使用 --squash 和 --fixup 的时候，你可能不记得想要修正的 commit 的 SHA 了— 只记得它是前面第 1 个或第 5 个 commit。你会发现 Git 的 ^ 和 ~ 操作符特别好用。HEAD^ 是 HEAD 的前一个 commit。 HEAD~4 是 HEAD 往前第 4 个 – 或者一起算，倒数第 5 个 commit。

停止追踪一个文件

场景: 你偶然把 application.log 加到代码库里了，现在每次你运行应用，Git 都会报告在 application.log 里有未提交的修改。你把 *.login 放到了 .gitignore 文件里，可文件还是在代码库里 — 你怎么才能告诉 Git “撤销” 对这个文件的追踪呢？

方法: git rm --cached application.log

原理: 虽然 .gitignore 会阻止 Git 追踪文件的修改，甚至不关注文件是否存在，但这只是针对那些以前从来没有追踪过的文件。一旦有个文件被加入并提交了，Git 就会持续关注该文件的改变。类似地，如果你利用 git add -f 来强制或覆盖了 .gitignore， Git 还会持续追踪改变的情况。之后你就不必用-f  来添加这个文件了。

如果你希望从 Git 的追踪对象中删除那个本应忽略的文件， git rm --cached 会从追踪对象中删除它，但让文件在磁盘上保持原封不动。因为现在它已经被忽略了，你在  git status 里就不会再看见这个文件，也不会再偶然提交该文件的修改了。

 

这就是如何在 Git 里撤销任何操作的方法。要了解更多关于本文中用到的 Git 命令，请查看下面的有关文档：

• checkout
• commit
• rebase
• reflog
• reset
• revert
• rm

来源：http://blog.jobbole.com/87700/

MySQL 是一个强大的开源关系数据库管理系统（简称 RDBMS）。它发布于 1995 年（20年前）。它采用结构化查询语言（SQL），这可能是数据库内容管理中最流行的选择。最新的 MySQL 版本是 5.6.25，于 2015 年 5 月 29 日发布。

关于 MySQL 一个有趣的事实是它的名字来自于 Michael Widenius（MySQL 的创始人）的女儿“ My”。尽管有许多关于 MySQL 有趣的传闻，不过本文主要是向你展示一些有用的实践，以帮助你管理你的 MySQL 服务器。

MySQL 性能优化

2009 年 4 月，MySQL 被 Oracle 收购。其结果是MySQL 社区分裂，创建了一个叫 MariaDB 的分支 。创建该分支的主要原因是为了保持这个项目可以在 GPL 下的自由。

今天，MySQL 和 MariaDB 是用于类似 WordPress、Joomla、Magento 和其他 web 应用程序的最流行的 RDMS 之一（如果不是最多的）。

这篇文章将告诉你一些基本的，但非常有用的关于如何优化 MySQL/MariaDB 性能的技巧。注意，本文假定您已经安装了 MySQL 或 MariaDB。如果你仍然不知道如何在系统上安装它们，你可以按照以下说明去安装：

• 在 RHEL/CentOS 7 上安装 LAMP
• 在 Fedora 22 上安装 LAMP
• 在 Ubuntu 15.04 安装 LAMP
• 在 Debian 8 上安装 MariaDB
• 在 Gentoo Linux 上安装 MariaDB
• 在 Arch Linux 上安装 MariaDB

重要提示： 在开始之前，不要盲目的接受这些建议。每个 MySQL 设置都是不同的，在进行任何更改之前需要慎重考虑。

你需要明白这些：

• MySQL/MariaDB 配置文件位于 /etc/my.cnf。 每次更改此文件后你需要重启 MySQL 服务，以使更改生效。
• 这篇文章使用 MySQL 5.6 版本。

1. 启用 InnoDB 的每张表一个数据文件设置

首先，有一个重要的解释， InnoDB 是一个存储引擎。MySQL 和 MariaDB 使用 InnoDB 作为默认存储引擎。以前，MySQL 使用系统表空间来保存数据库中的表和索引。这意味着服务器唯一的目的就是数据库处理，它们的存储盘不用于其它目的。

InnoDB 提供了更灵活的方式，它把每个数据库的信息保存在一个 .ibd数据文件中。每个 .idb 文件代表它自己的表空间。通过这样的方式可以更快地完成类似 “TRUNCATE” 的数据库操作，当删除或截断一个数据库表时，你也可以回收未使用的空间。

这样配置的另一个好处是你可以将某些数据库表放在一个单独的存储设备。这可以大大提升你磁盘的 I/O 负载。

MySQL 5.6及以上的版本默认启用 innodb_file_per_table。你可以在 /etc/my.cnf 文件中看到。该指令看起来是这样的：

innodb_file_per_table=1

2. 将 MySQL 数据库数据存储到独立分区上

注意：此设置只在 MySQL 上有效, 在 MariaDB 上无效。

有时候操作系统的读/写会降低你 MySQL 服务器的性能，尤其是如果操作系统和数据库的数据位于同一块磁盘上。因此，我建议你使用单独的磁盘（最好是 SSD）用于 MySQL 服务。

要完成这步，你需要将新的磁盘连接到你的计算机/服务器上。对于这篇文章，我假定磁盘挂在到 /dev/sdb。

下一步是准备新的分区：

# fdisk /dev/sdb

现在按 “N” 来创建新的分区。接着按 “P”，使其创建为主分区。在此之后，从 1-4 设置分区号。之后，你可以选择分区大小。这里按 enter。在下一步，你需要配置分区的大小。

如果你希望使用全部的磁盘，再按一次 enter。否则，你可以手动设置新分区的大小。准备就绪后按 “w” 保存更改。现在，我们需要为我们的新分区创建一个文件系统。这可以用下面命令轻松地完成：

# mkfs.ext4 /dev/sdb1

现在我们会挂载新分区到一个目录。我在根目录下创建了一个名为 “ssd” 的目录：

# mkdir /ssd/

挂载新分区到刚才创建的目录下：

# mount /dev/sdb1  /ssd/

你可以在 /etc/fstab 文件中添加如下行设置为开机自动挂载：

/dev/sdb1 /ssd ext3 defaults 0 0

现在我们将 MySQL 移动到新磁盘中

首先停止 MySQL 服务：

# service mysqld stop

我建议你​​同时停止 Apache/nginx，以防止任何试图写入数据库的操作：

# service httpd stop
# service nginx stop

现在复制整个 MySQL 目录到新分区中:

# cp /var/lib/mysql /ssd/ -Rp

这可能需要一段时间，具体取决于你的 MySQL 数据库的大小。一旦这个过程完成后重命名 MySQL 目录：

# mv /var/lib/mysql /var/lib/mysql-backup

然后创建一个符号链接：

# ln -s /ssd/mysql /var/lib/mysql

现在启动你的 MySQL 和 web 服务：

# service mysqld start
# service httpd start
# service nginx start

以后你的数据库将使用新的磁盘访问。

3. 优化使用 InnoDB 的缓冲池

InnoDB 引擎在内存中有一个缓冲池用于缓存数据和索引。这当然有助于你更快地执行 MySQL/MariaDB 查询语句。选择合适的内存大小需要一些重要的决策并对系统的内存消耗有较多的认识。

下面是你需要考虑的:

• 其它的进程需要消耗多少内存。这包括你的系统进程，页表，套接字缓冲。
• 你的服务器是否专门用于 MySQL 还是你运行着其它非常消耗内存的服务。

在一个专用的机器上，你可能会把 60-70％ 的内存分配给 innodb_buffer_pool_size。如果你打算在一个机器上运行更多的服务，你应该重新考虑专门用于 innodb_buffer_pool_size的内存大小。

你需要设置 my.cnf 中的此项:

innodb_buffer_pool_size

4. 在 MySQL 中避免使用 Swappiness

“交换”是一个当系统移动部分内存到一个称为 “交换空间” 的特殊磁盘空间时的过程。通常当你的系统用完物理内存后就会出现这种情况，系统将信息写入磁盘而不是释放一些内存。正如你猜测的磁盘比你的内存要慢得多。

该选项默认情况下是启用的：

# sysctl vm.swappiness
vm.swappiness = 60

运行以下命令关闭 swappiness：

# sysctl -w vm.swappiness=0

5. 设置 MySQL 的最大连接数

max_connections指令告诉你当前你的服务器允许多少并发连接。MySQL/MariaDB 服务器允许有 SUPER 权限的用户在最大连接之外再建立一个连接。只有当执行 MySQL 请求的时候才会建立连接，执行完成后会关闭连接并被新的连接取代。

请记住，太多的连接会导致内存的使用量过高并且会锁住你的 MySQL 服务器。一般小网站需要 100-200 的连接数，而较大可能需要 500-800 甚至更多。这里的值很大程度上取决于你 MySQL/MariaDB 的使用情况。

你可以动态地改变 max_connections的值而无需重启MySQL服务器：

# mysql -u root -p
mysql> set global max_connections = 300;

6. 配置 MySQL 的线程缓存数量

thread_cache_size指令用来设置你服务器缓存的线程数量。当客户端断开连接时，如果当前线程数小于 thread_cache_size，它的线程将被放入缓存中。下一个请求通过使用缓存池中的线程来完成。

要提高服务器的性能，你可以设置 thread_cache_size的值相对高一些。你可以通过以下方法来查看线程缓存命中率：

mysql> show status like 'Threads_created';
mysql> show status like 'Connections';

你可以用以下公式来计算线程池的命中率：

100 - ((Threads_created / Connections) * 100)

如果你得到一个较低的数字，这意味着大多数 mysql 连接使用新的线程，而不是从缓存加载。在这种情况下，你需要增加 thread_cache_size。

这里有一个好处是可以动态地改变 thread_cache_size而无需重启 MySQL 服务。你可以通过以下方式来实现：

mysql> set global thread_cache_size = 16;

7. 禁用 MySQL 的 DNS 反向查询

默认情况下当新的连接出现时，MySQL/MariaDB 会进行 DNS 查询解析用户的 IP 地址/主机名。对于每个客户端连接，它的 IP 都会被解析为主机名。然后，主机名又被反解析为 IP 来验证两者是否一致。

当 DNS 配置错误或服务器出现问题时，这很可能会导致延迟。这就是为什么要关闭 DNS 的反向查询的原因，你可以在你的配置文件中添加以下选项去设定：

[mysqld]
# Skip reverse DNS lookup of clients
skip-name-resolve

更改后你需要重启 MySQL 服务。

8. 配置 MySQL 的查询缓存容量

如果你有很多重复的查询并且数据不经常改变 – 请使用缓存查询。 人们常常不理解 query_cache_size的实际含义而将此值设置为 GB 级，这实际上会降低服务器的性能。

背后的原因是，在更新过程中线程需要锁定缓存。通常设置为 200-300 MB应该足够了。如果你的网站比较小的，你可以尝试给 64M 并在以后及时去增加。

在你的 MySQL 配置文件中添加以下设置：

query_cache_type = 1
query_cache_limit = 256K
query_cache_min_res_unit = 2k
query_cache_size = 80M

9. 配置临时表容量和内存表最大容量

tmp_table_size和 max_heap_table_size这两个变量的大小应该相同，它们可以让你避免磁盘写入。tmp_table_size是内置内存表的最大空间。如果表的大小超出限值将会被转换为磁盘上的 MyISAM 表。

这会影响数据库的性能。管理员通常建议在服务器上设置这两个值为每 GB 内存给 64M。

[mysqld]
tmp_table_size= 64M
max_heap_table_size= 64M

10. 启用 MySQL 慢查询日志

记录慢查询可以帮助你定位数据库中的问题并帮助你调试。这可以通过在你的 MySQL 配置文件中添加以下值来启用：

slow-query-log = 1
slow-query-log-file = /var/lib/mysql/mysql-slow.log
long_query_time = 1

第一个变量启用慢查询日志，第二个告诉 MySQL 实际的日志文件存储位置。使用 long_query_time来定义完成 MySQL 查询多少用时算长。

11. 检查 MySQL 的空闲连接

空闲连接会消耗资源，可以的话应该被终止或者刷新。空闲连接是指处于 “sleep” 状态并且保持了很长一段时间的连接。你可以通过运行以下命令查看空闲连接：

# mysqladmin processlist -u root -p | grep “Sleep”

这会显示处于睡眠状态的进程列表。当代码使用持久连接到数据库时会出现这种情况。使用 PHP 调用 mysql_pconnect 可以打开这个连接，执行完查询之后，删除认证信息并保持连接为打开状态。这会导致每个线程的缓冲都被保存在内存中，直到该线程结束。

首先你要做的就是检查代码问题并修复它。如果你不能访问正在运行的代码，你可以修改 wait_timeout变量。默认值是 28800 秒，而你可以安全地将其降低到 60 ：

wait_timeout=60

12. 为 MySQL 选择正确的文件系统

选择正确的文件系统对数据库至关重要。在这里你需要考虑的最重要的事情是 - 数据的完整性，性能和易管理性。

按照 MariaDB 的建议，最好的文件系统是XFS、ext4 和 Btrfs。它们都是可以使用超大文件和大容量存储卷的企业级日志型文件系统。

下面你可以找到一些关于这三个文件系统的有用信息：

文件系统	XFS	Ext4	Btrfs
文件系统最大容量	8EB	1EB	16EB
最大文件大小	8EB	16TB	16EB

我们的这篇文章详细介绍了 Linux 文件系统的利与弊: Linux 文件系统解析。

13. 设置 MySQL 允许的最大数据包

MySQL 把数据拆分成包。通常一个包就是发送到客户端的一行数据。max_allowed_pa​​cket变量定义了可以被发送的最大的包。

此值设置得过低可能会导致查询速度变得非常慢，然后你会在 MySQL 的错误日志看到一个错误。建议将该值设置为最大包的大小。

14. 测试 MySQL 的性能优化

你应该定期检查 MySQL/MariaDB 的性能。这将帮助你了解资源的使用情况是否发生了改变或需要进行改进。

有大量的测试工具可用，但我推荐你一个简单易用的。该工具被称为 mysqltuner。

使用下面的命令下载并运行它：

# wget https://github.com/major/MySQLTuner-perl/tarball/master
# tar xf master
# cd major-MySQLTuner-perl-993bc18/
# ./mysqltuner.pl

你将收到有关 MySQL 使用的详细报告和推荐提示。下面是默认 MariaDB 安装的输出样例：

15. 优化和修复 MySQL 数据库

有时候 MySQL/MariaDB 数据库中的表很容易崩溃，尤其是服务器意外关机、文件系统突然崩溃或复制过程中仍然访问数据库。幸运的是，有一个称为 'mysqlcheck' 的免费开源工具，它会自动检查、修复和优化 Linux 中数据库的所有表。

# mysqlcheck -u root -p --auto-repair --check --optimize --all-databases
# mysqlcheck -u root -p --auto-repair --check --optimize databasename

就是这些！我希望上述文章对你有用，并帮助你优化你的 MySQL 服务器。一如往常，如果你有任何疑问或评论，请在下面的评论部分提交。

---

via: http://www.tecmint.com/mysql-mariadb-performance-tuning-and-optimization/

作者：Marin Todorov 译者：strugglingyouth 校对：ictlyh

本文由 LCTT 原创翻译，Linux中国 荣誉推出

来源：https://linux.cn/article-5730-1.html