Проблеми с Varnish

Torbalan Trolski

Well-Known Member
Имам пуснат Varnish на един VPS, който за 4 месеца не ми е правил никакви фалове. VPS-а е рестартиран веднъж поради хардуерни проблеми.
И сега без да е пипано каквото и да е по него ми забива вече трети път е рамките на 24-часа. Рестарт на демона оправя нещата.

/etc/sysconfig/varnish
Код:
## Alternative 3, Advanced configuration
#
# See varnishd(1) for more information.
#
# # Main configuration file. You probably want to change it :)
VARNISH_VCL_CONF=/etc/varnish/default.vcl
#
# # Default address and port to bind to
# # Blank address means all IPv4 and IPv6 interfaces, otherwise specify
# # a host name, an IPv4 dotted quad, or an IPv6 address in brackets.
#VARNISH_LIsTEN_ADDRESS="217.174.151.160 217.174.151.172"
#VARNISH_LISTEN_PORT=80


#FIRST_ADDR=1
#for ADDR in $VARNISH_LISTEN_ADDRESS
#do
#       if [ $FIRST_ADDR = 0 ]
#       then
#               VARNISH_LISTEN="$VARNISH_LISTEN, "
#       fi
#
#       FIRST_ADDR=0
#       VARNISH_LISTEN="$VARNISH_LISTEN$ADDR:$VARNISH_LISTEN_PORT"
#done


# VARNISH_LISTEN_ADDRESS=217.174.151.172
VARNISH_LISTEN_PORT=80
#
# # Telnet admin interface listen address and port
VARNISH_ADMIN_LISTEN_ADDRESS=127.0.0.1
VARNISH_ADMIN_LISTEN_PORT=6082
#
# # Shared secret file for admin interface
VARNISH_SECRET_FILE=/etc/varnish/secret
#
# # One thread pool for CPU core
VARNISH_CPU_CORES=2
#
# # The minimum number of worker threads to start
VARNISH_MIN_THREADS=100
#
# # The Maximum number of worker threads to start
VARNISH_MAX_THREADS=1000
#
# # Idle timeout for worker threads
VARNISH_THREAD_TIMEOUT=120
#
# # Cache file location
VARNISH_STORAGE_FILE=/var/lib/varnish/varnish_storage.bin
#
# # Cache file size: in bytes, optionally using k / M / G / T suffix,
# # or in percentage of available disk space using the % suffix.
VARNISH_STORAGE_SIZE=1G
#
# # Backend storage specification
VARNISH_STORAGE="file,${VARNISH_STORAGE_FILE},${VARNISH_STORAGE_SIZE}"
# # Memory storage size
VARNISH_MALLOC_SIZE=128M
VARNISH_MALLOC_STORAGE="malloc,$VARNISH_MALLOC_SIZE"
#
# # Default TTL used when the backend does not specify one
VARNISH_TTL=120
#
# # DAEMON_OPTS is used by the init script.  If you add or remove options, make
# # sure you update this section, too.
DAEMON_OPTS="-a ${VARNISH_LISTEN_AGGRESS}:${VARNISH_LISTEN_PORT} \
             -f ${VARNISH_VCL_CONF} \
             -T ${VARNISH_ADMIN_LISTEN_ADDRESS}:${VARNISH_ADMIN_LISTEN_PORT} \
             -t ${VARNISH_TTL} \
             -w ${VARNISH_MIN_THREADS},${VARNISH_MAX_THREADS},${VARNISH_THREAD_TIMEOUT} \
             -u varnish -g varnish \
             -S ${VARNISH_SECRET_FILE} \
             -p thread_pools=${VARNISH_CPU_CORES} \
             -s ${VARNISH_MALLOC_STORAGE} \
             -s ${VARNISH_STORAGE}"
#

Код:
lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                4
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 42
Stepping:              1
CPU MHz:               3300.018
BogoMIPS:              6600.03
Hypervisor vendor:     KVM
Virtualization type:   full

free -m
             total       used       free     shared    buffers     cached
Mem:          1024        384        639          0          0        148
-/+ buffers/cache:        235        788
Swap:         1024         24        999


с това умира
Код:
Nov 10 08:15:40 centos varnishd[10528]: Platform: Linux,2.6.32-042stab081.3,x86_64,-smalloc,-sfile,-smalloc,-hcritbit
..............
Nov 10 19:30:14 centos varnishd[10528]: child (31711) Started
Nov 10 19:30:14 centos varnishd[10528]: Child (31711) said Child starts
Nov 10 19:30:14 centos varnishd[10528]: Child (31711) said SMF.s1 mmap'ed 1073741824 bytes of 1073741824
Nov 10 19:30:27 centos varnishd[10528]: Child (31711) not responding to CLI, killing it.
Nov 10 19:30:31 centos varnishd[10528]: Child (31711) not responding to CLI, killing it.
Nov 10 19:30:31 centos varnishd[10528]: Child (31711) not responding to CLI, killing it.
Nov 10 19:30:31 centos varnishd[10528]: Child (31711) died signal=3
Nov 10 19:30:31 centos varnishd[10528]: child (31746) Started
Nov 10 19:30:41 centos varnishd[10528]: Pushing vcls failed:#012CLI communication error (hdr)
Nov 10 19:30:41 centos varnishd[10528]: Child (31746) said Child starts
Nov 10 19:30:41 centos varnishd[10528]: Child (31746) said SMF.s1 mmap'ed 1073741824 bytes of 1073741824
Nov 10 19:30:47 centos varnishd[10528]: Child (31746) said Child dies
Nov 10 19:31:07 centos varnishd[10528]: Child (31746) died status=1
 
От: Проблеми с Varnish

Не си пуснал коя е версията.

Вдигни cli_timeout-a и провери дали backend-a не се лагва. Т.е. виж дали няма iowait когато крашне или някой друг ресурс недостига.

https://www.varnish-cache.org/docs/3.0/reference/varnishd.html?highlight=cli_timeout

Възможно е и бъг да е, за това винаги пускай коя е версията и обновявай до последната stable - в момента е 3.0.4

Това е, което намирам в Google, нещо което и ти можеш да направиш :wink: А най-добре питай в IRC канала на Varnish във Freenode - irc.freenode.org или https://webchat.freenode.net/ Пичовете там си знаят работата.
 
От: Проблеми с Varnish

Бях забравил да пусна версията, ама по дефолт винаги си мисля, че трябва да е последната stable :D -> varnishd (varnish-3.0.4 revision 9f83e8f)

Естествено, че ровя и аз гугъла, ама за сега нищо смислено.
Това с cli_timeout го бях видял в 2-3 тикета, ама не видях да resolved, но ще го пробвам.
As I said, you can try to increase cli_timeout, if the problem is disk-i/o pileups.

cli_timeout
Units: seconds
Default: 10
Timeout for the childs replies to CLI requests from the master.
Не мисля, че имам кавито и да е проблеми с I/O, машината е 1Г рам, 128 МБ за varnisha, 64 memcache, 64 zend opcache. При 3-7к импресии на ден всичко се събира в паметта и има място за поне още 10 сайта.
Бакенд apache, WP + W3 Total Cache (memcached). 10 секунди по дефолт би трябвало да са достатъчни.

Changed 11 months ago
We have added this as a future feature item, to have some parameter to control restart handling. See https://www.varnish-cache.org/trac/wiki/Future_Usability#Parametertocontrolrestartbehavior
Освен, че са добавили евентуално за бъдеще контрол на рестарта не .

За IRC-то не бях се сетил мерси.
Продължавам да ровя
 
въпроса е трябва ли ти варниш при горния сетъп? в3 то с малко повече рам за memcached и по дълги пеприоди page cache който за при коментар или нова статия си се чисти трябва да работи доста леко... само за цмси който нямат толкова адвансъд кеширане може да се ползва

аз поне за него не мога да напиша много всичко каквото тествах като varnish cpanel плъгин преди време не издържаше и ден стабилно....
 
От: Re: Проблеми с Varnish

въпроса е трябва ли ти варниш при горния сетъп? в3 то с малко повече рам за memcached и по дълги пеприоди page cache който за при коментар или нова статия си се чисти трябва да работи доста леко... само за цмси който нямат толкова адвансъд кеширане може да се ползва

аз поне за него не мога да напиша много всичко каквото тествах като varnish cpanel плъгин преди време не издържаше и ден стабилно....

Това, че с cPanel plugin не е работил добре, не означава че проблема е във Varnish. Даже бих казал напротив.

Varnish работи отлично дори с default настройки и може да се комбинира с memcached много лесно - а двете неща са коренно различни. Моят съвет е да си прегледа всички ресурси/процеси на сървъра и да дебъгне какво точно става. През това време може да пусне watchdog или някоя друга глупост, която автоматично да го рестартира ако крашне.

П.П. - с какви ресурси е това чудо? 3-7к импресии са прекалено малко, че чак още един layer да се слага, поне според мен. Аз по-скоро backend-a бих сменил. (хем няма да се пули да дебъгва Varnish).
 
От: Re: Проблеми с Varnish

въпроса е трябва ли ти варниш при горния сетъп? в3 то с малко повече рам за memcached и по дълги пеприоди page cache който за при коментар или нова статия си се чисти трябва да работи доста леко... само за цмси който нямат толкова адвансъд кеширане може да се ползва


аз поне за него не мога да напиша много всичко каквото тествах като varnish cpanel плъгин преди време не издържаше и ден стабилно....
Първоначално машината беше предвидена и да други натоварвания, ама се отложиха малко във времето.
cpanel изобщо не съм инсталирал един ssh ми върши чудна работа.
А и нищо му нямаше на varnisha три-четири месеца един ребут на цялта машина е имало заради харуерен проблем.


Това, че с cPanel plugin не е работил добре, не означава че проблема е във Varnish. Даже бих казал напротив.

Varnish работи отлично дори с default настройки и може да се комбинира с memcached много лесно - а двете неща са коренно различни. Моят съвет е да си прегледа всички ресурси/процеси на сървъра и да дебъгне какво точно става. През това време може да пусне watchdog или някоя друга глупост, която автоматично да го рестартира ако крашне.

П.П. - с какви ресурси е това чудо? 3-7к импресии са прекалено малко, че чак още един layer да се слага, поне според мен. Аз по-скоро backend-a бих сменил. (хем няма да се пули да дебъгва Varnish).
Не съм пускал nginx до сега пък сакралното reduce server response time under 200ms си го докарвам и в комбото apache+varnish.

Varnish-a не съм го туниговал, кой знае колко почти с дефолт съм го пуснал, той и там си разпилен достатъчно.
По един пул на всяко ядро, 100 min 1000 max - threads. На някои места препоръват 500-4000.

Просто се чудя, какво става при положение че машината не пипана от маса време изведнъж да започне така да се дъни.
Бачкаше перфектно месеци наред без рестарт и сега бум 3 пъти за 24 часа.
 
Е може и да работи ок това ми бяха тестовете и споделих :) Иначе аз каквото гледах като тестове на моя сегашен сетъп с варниш или микрокеш или микрокеш + варниш не даваше особени разлики при синтетични тестове....

а конкретно за неговия слуачй : ами то му зарежда статични страниците така или иначе от бекенда - в случая от рама на мемкешъд ... и той кешира статичните още веднъж във варниш няма нужда от този слой докато е на урпрес с този сетъп :) и най вече с w3-total лесно е сетъпнато кеша да се чисти при всяка промяна по страница или коментар а има и минифай има и лесни настроики на браузър кеша иначе всичко споменато трябва да го направи на ръка като настроики или с други плъгини .... (това са ми доводите да махне варниша) а не да маха w3 total и че няма да види особени разлики без него
 
От: Re: Проблеми с Varnish

Е може и да работи ок това ми бяха тестовете и споделих :) Иначе аз каквото гледах като тестове на моя сегашен сеъп с варниш или микрокеш или микрокеш + варниш не даваше особени разлики при синтетични тестове....

а конкретно за неговия слуачй : ами то му зарежда статични страниците така или иначе от бекенда - в случая от рама на мемкешъд ... и той кешира статичните още веднъж във варниш няма нужда от този слой докато е на урпрес с този сетъп :) и най вече с w3-total лесно е сетъпнато кеша да се чисти при всяка промяна по страница или коментар а има и минифай има и лесни настроики на браузър кеша иначе всичко споменато трябва да го направи на ръка като настроики или с други плъгини .... (това са ми доводите да махне варниша) а не да маха w3 total и че няма да види особени разлики без него
Всичките благини на W3 total ги ползвам. Принципно първо бях пуснал varnish + W3 без memcache.
И пак казвам машината беше готвена за други натоварвания.
 
може днес да ти ден за тестове сложи по голям ттл на пеиджкеша (3600 е дефултния) само с мемкешъд и отдели рама който ти е за варниша за него (според сайта може и да няма нужда) и си следи натоварването без варниш (не мисля че ще мръдне много) после може да споделиш как е :)


иначе ползването варниш си е съвсем оправдано ако хостваш и други скриптове и цмси който не могат да се възползват така добре от остналите възможностти за кеширане*

*както споделих аз преди като го тесвах не бях много доволен от варниша и сега бих предпочел да ползвам nginx с микрокеш вместо него
 
От: Проблеми с Varnish

Вдигнах cli_timeout-а от 10 на 60с, за сега два дена нямам ядове.
Ама то и преди това три месеца нямах :)
 

Горе