7. Varnish 故障排除

有时 Varnish 行为不当，或者更确切地说，它按照您告诉它的方式运行，但不一定按照您希望它的方式运行。为了让您了解发生了什么，您可以检查几个地方。varnishlog、/var/log/syslog、 /var/log/messages都是 Varnish 可能留下有关正在发生的事情的线索的好地方。本节将指导您完成 Varnish 中的基本故障排除。

7.1 当 Varnish 无法启动时

有时 Varnish 无法启动。Varnish 无法在您的机器上启动的原因有很多。从 /dev/null 上的错误权限到其他进程阻塞端口，我们都见过。

以调试模式启动 Varnish，查看发生了什么。

尝试使用与其他方式相同的参数启动 Varnish，但要添加 -d。这将为您提供更多信息。让我们看看当有其他东西在监听 Varnish 的端口时，Varnish 会有什么反应：

# varnishd -n foo -f /usr/local/etc/varnish/default.vcl -s malloc,1G -T 127.0.0.1:2000  -a 0.0.0.0:8080 -d
storage_malloc: max size 1024 MB.
Using old SHMFILE
Platform: Linux,2.6.32-21-generic,i686,-smalloc,-hcritbit
200 193
-----------------------------
Varnish Cache CLI.
-----------------------------
Type 'help' for command list.
Type 'quit' to close CLI session.
Type 'start' to launch worker process.

现在 Varnish 正在运行，但只有主进程在运行，在调试模式下缓存没有启动。现在你在控制台。你可以发出 “start”（启动）指令，让主进程启动缓存：

start
bind(): Address already in use
300 22
Could not open sockets

问题就在这里。有其他东西绑定到了 Varnish 的 HTTP 端口。如果还不行，试试 strace 或 truss，或者到 IRC 上找我们。

7.2 Varnish 崩溃了 - panics

当 Varnish 出错时，子进程就会崩溃。大多数崩溃都会被我们在 Varnish 源代码中包含的许多一致性检查捕获。当 Varnish 遇到这些检查时，缓存进程会以可控方式自行崩溃，并在母进程中留下良好的堆栈跟踪。

在 CLI 中输入 panic.show，即可查看任何紧急信息：

panic.show
Last panic at: Tue, 15 Mar 2011 13:09:05 GMT
Assert error in ESI_Deliver(), cache_esi_deliver.c line 354:
  Condition(i == Z_OK || i == Z_STREAM_END) not true.
thread = (cache-worker)
ident = Linux,2.6.32-28-generic,x86_64,-sfile,-smalloc,-hcritbit,epoll
Backtrace:
  0x42cbe8: pan_ic+b8
  0x41f778: ESI_Deliver+438
  0x42f838: RES_WriteObj+248
  0x416a70: cnt_deliver+230
  0x4178fd: CNT_Session+31d
  (..)

崩溃可能是由于配置错误或错误造成的。如果您怀疑这是一个错误，您可以使用错误报告中的输出，请参阅上面介绍章节中的“故障单”部分。

7.3 Varnish 崩溃了 - 堆栈溢出

抛开错误不谈，最有可能导致崩溃的原因是堆栈溢出，这就是为什么我们添加了一个启发式方法，在崩溃看起来像是由堆栈溢出引起时添加备注。在这种情况下，panics 信息的内容如下

Signal 11 (Segmentation fault) received at 0x7f631f1b2f98 si_code 1
THIS PROBABLY IS A STACK OVERFLOW - check thread_pool_stack parameter

作为第一个措施，请遵循此建议，并检查当您将 128k 添加到任何参数值 thread_pool_stack并重新启动 varnish 时是否仍然发生崩溃。

如果 varnish 在使用较大的 thread_pool_stack 参数时不再崩溃，那就不是错误（至少很可能不是）。

7.4 Varnish 崩溃了 - 段错误

有时，错误会逃脱一致性检查，并且 Varnish 会出现分段错误。当子进程发生这种情况时，它会被记录，核心将被转储，子进程将再次启动。

核心转储通常是由于 Varnish 中的错误造成的。但是，为了调试 segfault，开发人员需要您提供相当多的数据。

• 确保你已经安装了带有调试符号的 Varnish。

• 检查操作系统写入核心文件的位置，确保能真正获取这些文件。例如，在 linux 上，可从 core(5) manpage 了解 /proc/sys/kernel/core_pattern。

• 确保启动 varnishd 的父 shell 允许核心转储。在 shell 中，这将是：ulimit -c unlimited；但如果 varnish 是从 init 脚本启动的，则需要进行调整，或者在 systemd 的情况下，在单元文件LimitCORE=infinity的服务部分中进行设置。[Service]]

获得核心后，cd 进入 varnish 的工作目录（由 -n 参数提供，默认值为 $PREFIX/var/varnish/$HOSTNAME，其中 $PREFIX 是安装前缀，通常为 /usr/local），用 gdb 打开核心，然后发出 bt 命令，获取导致 segfault 的线程的堆栈跟踪。

安装在 /usr/local 下的 varnish 的基本调试会话如下所示：

$ cd /usr/local/var/varnish/`uname -n`/
$ gdb /usr/local/sbin/varnishd core
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
[...]
Core was generated by `/usr/local/sbin/varnishd -a 127.0.0.1:8080 -b 127.0.0.1:8080'.
Program terminated with signal SIGABRT, Aborted.
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51      ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
[Current thread is 1 (Thread 0x7f7749ea3700 (LWP 31258))]

(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x00007f775132342a in __GI_abort () at abort.c:89
#2  0x000000000045939f in pan_ic (func=0x7f77439fb811 "VCL", file=0x7f77439fb74c "", line=0,
    cond=0x7f7740098130 "PANIC: deliberately!", kind=VAS_VCL) at cache/cache_panic.c:839
#3  0x0000000000518cb1 in VAS_Fail (func=0x7f77439fb811 "VCL", file=0x7f77439fb74c "", line=0,
    cond=0x7f7740098130 "PANIC: deliberately!", kind=VAS_VCL) at vas.c:51
#4  0x00007f77439fa6e9 in vmod_panic (ctx=0x7f7749ea2068, str=0x7f7749ea2018) at vmod_vtc.c:109
#5  0x00007f77449fa5b8 in VGC_function_vcl_recv (ctx=0x7f7749ea2068) at vgc.c:1957
#6  0x0000000000491261 in vcl_call_method (wrk=0x7f7749ea2dd0, req=0x7f7740096020, bo=0x0,
    specific=0x0, method=2, func=0x7f77449fa550 <VGC_function_vcl_recv>) at cache/cache_vrt_vcl.c:462
#7  0x0000000000493025 in VCL_recv_method (vcl=0x7f775083f340, wrk=0x7f7749ea2dd0, req=0x7f7740096020,
    bo=0x0, specific=0x0) at ../../include/tbl/vcl_returns.h:192
#8  0x0000000000462979 in cnt_recv (wrk=0x7f7749ea2dd0, req=0x7f7740096020) at cache/cache_req_fsm.c:880
#9  0x0000000000461553 in CNT_Request (req=0x7f7740096020) at ../../include/tbl/steps.h:36
#10 0x00000000004a7fc6 in HTTP1_Session (wrk=0x7f7749ea2dd0, req=0x7f7740096020)
    at http1/cache_http1_fsm.c:417
#11 0x00000000004a72c3 in http1_req (wrk=0x7f7749ea2dd0, arg=0x7f7740096020)
    at http1/cache_http1_fsm.c:86
#12 0x0000000000496bb6 in Pool_Work_Thread (pp=0x7f774980e140, wrk=0x7f7749ea2dd0)
    at cache/cache_wrk.c:406
#13 0x00000000004963e3 in WRK_Thread (qp=0x7f774980e140, stacksize=57344, thread_workspace=2048)
    at cache/cache_wrk.c:144
#14 0x000000000049610b in pool_thread (priv=0x7f774880ec80) at cache/cache_wrk.c:439
#15 0x00007f77516954a4 in start_thread (arg=0x7f7749ea3700) at pthread_create.c:456
#16 0x00007f77513d7d0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97

7.5 Varnish 让我沉思

首先在 varnishlog 中找到相关日志条目。这可能会给你提供线索。由于 varnishlog 记录了大量数据，因此可能很难找到相关条目。你可以发出以下命令，将 varnishlog 设置为记录所有 503 错误：

$ varnishlog -q 'RespStatus == 503' -g request

如果错误发生的时间不长，事务可能还在共享内存日志段中。要让 varnishlog 处理整个共享内存日志，只需添加"-d "参数即可：

$ varnishlog -d -q 'RespStatus == 503' -g request

请参阅 vsl-query 和 varnishlog 首页页，了解更多过滤功能和各种选项的解释。

7.6 Varnish 不缓存

请参阅实现高命中率。