Устранение неполадок Varnish

Когда Varnish не запускается

Иногда Varnish не запускается. Причин может быть множество, от неправильных разрешений на /dev/null до блокировки портов другими процессами.

Запустите Varnish в отладочном режиме, чтобы посмотреть, что происходит.

Попробуйте запустить Varnish с теми же аргументами, что и обычно, но добавьте -d. Это даст вам больше информации о происходящем. Посмотрим, как 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

И вот проблема. Что-то другое привязано к HTTP-порту Varnish. Если это не помогло, попробуйте strace или truss, или обратитесь к нам на IRC.

Varnish аварийно завершает работу — паники

Когда Varnish терпит неудачу, дочерние процессы аварийно завершают работу. Большинство аварийных завершений обрабатываются одной из многочисленных проверок целостности, включенных в исходный код Varnish. Когда Varnish обнаруживает одну из них, процесс кеширования аварийно завершает работу контролируемым образом, оставляя удобный стек вызовов в родительском процессе.

Вы можете проверить любые сообщения о панике, набрав 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
  (..)

Авария может быть вызвана неправильной настройкой или ошибкой. Если вы подозреваете ошибку, вы можете использовать вывод в отчёте об ошибке, см. раздел «Билеты по проблемам» в главе «Введение» выше.

Varnish аварийно завершает работу — переполнение стека

Помимо ошибок, наиболее вероятной причиной аварийных завершений являются переполнения стека, поэтому мы добавили эвристику, чтобы указывать на это, если авария выглядит как вызванная переполнением стека. В этом случае сообщение о панике содержит что-то вроде этого:

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

В качестве первой меры, следуйте этому совету и проверьте, не происходят ли аварии, если вы добавите 128 кБ к значению параметра thread_pool_stack и перезапустите varnish.

Если Varnish перестаёт аварийно завершаться с параметром thread_pool_stack большего размера, это не ошибка (по крайней мере, скорее всего).

Varnish аварийно завершает работу — ошибки сегментирования

Иногда ошибка избегает проверок целостности, и Varnish получает ошибку сегментации. Когда это происходит с дочерним процессом, это записывается в журнал, создаётся дамп ядра, и дочерний процесс перезапускается.

Дамп ядра обычно является следствием ошибки в Varnish. Однако, чтобы отладить ошибку сегментирования, разработчикам необходимо предоставить значительное количество данных.

• Убедитесь, что Varnish установлен с символами отладки.
• Проверьте, где ваша операционная система записывает файлы core, и убедитесь, что вы их получаете. Например, в Linux, ознакомьтесь с /proc/sys/kernel/core_pattern из руководства core(5).

• Убедитесь, что дампы ядер разрешены в родительской оболочке, из которой запускается varnishd. В оболочке это будет:

  ulimit -c unlimited
  

  но если varnish запускается из скрипта init, это необходимо будет скорректировать, или в случае systemd, LimitCORE=infinity должно быть установлено в разделе [Service]] файла единицы.

После получения ядра cd в рабочую директорию Varnish (указанную параметром -n, значение которого по умолчанию $PREFIX/var/varnish/$HOSTNAME, а $PREFIX — это префикс установки, обычно /usr/local, откройте ядро с помощью gdb и выполните команду bt, чтобы получить стек вызовов потока, вызвавшего ошибку сегментирования.

Пример сессии отладки для Varnish, установленного в /usr/local, может выглядеть следующим образом:

$ 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

Varnish выдаёт "Guru meditation"

Сначала найдите соответствующие записи в журнале varnishlog. Это, вероятно, даст вам подсказку. Так как varnishlog регистрирует много данных, отслеживание записей может быть сложным. Вы можете настроить varnishlog для регистрации всех ошибок 503, выполнив следующую команду:

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

Если ошибка произошла совсем недавно, транзакция может всё ещё находиться в сегменте журнала общей памяти. Чтобы заставить varnishlog обработать весь журнал общей памяти, просто добавьте параметр «-d»:

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

См. страницы руководств vsl-query и varnishlog для получения дополнительной информации о возможностях фильтрации и описании различных опций.

Varnish не кеширует

См. Достижение высокой частоты попаданий.