1VARNISHD(1) VARNISHD(1)
2
6 varnishd - HTTP accelerator daemon
7
9 varnishd [-a [name=][ad‐
10 dress][:port][,PROTO][,user=<user>][,group=<group>][,mode=<mode>]] [-b
11 [host[:port]|path]] [-C] [-d] [-F] [-f config] [-h type[,options]] [-I
12 clifile] [-i identity] [-j jail[,jailoptions]] [-l vsl] [-M ad‐
13 dress:port] [-n name] [-P file] [-p param=value] [-r param[,param...]]
14 [-S secret-file] [-s [name=]kind[,options]] [-T address[:port]] [-t
15 TTL] [-V] [-W waiter]
16 varnishd [-x parameter|vsl|cli|builtin|optstring]
18 varnishd [-?]
20
22 The varnishd daemon accepts HTTP requests from clients, passes them on
23 to a backend server and caches the returned documents to better satisfy
24 future requests for the same document.
25
27 Basic options
28 -a <[name=][ad‐
29 dress][:port][,PROTO][,user=<user>][,group=<group>][,mode=<mode>]>
30 Listen for client requests on the specified address and port. The
31 address can be a host name ("localhost"), an IPv4 dotted-quad
32 ("127.0.0.1"), an IPv6 address enclosed in square brackets
33 ("[::1]"), or a path beginning with a '/' for a Unix domain socket
34 ("/path/to/listen.sock"). If address is not specified, varnishd will
35 listen on all available IPv4 and IPv6 interfaces. If port is not
36 specified, port 80 (http) is used. At least one of address or port
37 is required.
38 If a Unix domain socket is specified as the listen address, then the
40 user, group and mode sub-arguments may be used to specify the per‐
41 missions of the socket file -- use names for user and group, and a
42 3-digit octal value for mode. These sub-arguments are not permitted
43 if an IP address is specified. When Unix domain socket listeners are
44 in use, all VCL configurations must have version >= 4.1.
45 Name is referenced in logs. If name is not specified, "a0", "a1",
47 etc. is used. An additional protocol type can be set for the listen‐
48 ing socket with PROTO. Valid protocol types are: HTTP (default), and
49 PROXY.
50 Multiple listening addresses can be specified by using different -a
52 arguments.
53 -b <[host[:port]|path]>
55 Use the specified host as backend server. If port is not speci‐
56 fied, the default is 8080.
57 If the value of -b begins with /, it is interpreted as the abso‐
59 lute path of a Unix domain socket to which Varnish connects. In
60 that case, the value of -b must satisfy the conditions required
61 for the .path field of a backend declaration, see vcl(7). Back‐
62 ends with Unix socket addresses may only be used with VCL ver‐
63 sions >= 4.1.
64 -b can be used only once, and not together with f.
66 -f config
68 Use the specified VCL configuration file instead of the builtin
69 default. See vcl(7) for details on VCL syntax.
70 If a single -f option is used, then the VCL instance loaded from
72 the file is named "boot" and immediately becomes active. If more
73 than one -f option is used, the VCL instances are named "boot0",
74 "boot1" and so forth, in the order corresponding to the -f argu‐
75 ments, and the last one is named "boot", which becomes active.
76 Either -b or one or more -f options must be specified, but not
78 both, and they cannot both be left out, unless -d is used to
79 start varnishd in debugging mode. If the empty string is speci‐
80 fied as the sole -f option, then varnishd starts without start‐
81 ing the worker process, and the management process will accept
82 CLI commands. You can also combine an empty -f option with an
83 initialization script (-I option) and the child process will be
84 started if there is an active VCL at the end of the initializa‐
85 tion.
86 When used with a relative file name, config is searched in the
88 vcl_path. It is possible to set this path prior to using -f op‐
89 tions with a -p option. During startup, varnishd doesn't com‐
90 plain about unsafe VCL paths: unlike the varnish-cli(7) that
91 could later be accessed remotely, starting varnishd requires lo‐
92 cal privileges.
93 -n name
95 Specify the name for this instance. This name is used to con‐
96 struct the name of the directory in which varnishd keeps tempo‐
97 rary files and persistent state. If the specified name begins
98 with a forward slash, it is interpreted as the absolute path to
99 the directory.
100 Documentation options
102 For these options, varnishd prints information to standard output and
103 exits. When a -x option is used, it must be the only option (it outputs
104 documentation in reStructuredText, aka RST).
105 -?
107 Print the usage message.
108 -x parameter
110 Print documentation of the runtime parameters (-p options), see
111 List of Parameters.
112 -x vsl Print documentation of the tags used in the Varnish shared mem‐
114 ory log, see vsl(7).
115 -x cli Print documentation of the command line interface, see var‐
117 nish-cli(7).
118 -x builtin
120 Print the contents of the default VCL program builtin.vcl.
121 -x optstring
123 Print the optstring parameter to getopt(3) to help writing wrap‐
124 per scripts.
125 Operations options
127 -F Do not fork, run in the foreground. Only one of -F or -d can be
128 specified, and -F cannot be used together with -C.
129 -T <address[:port]>
131 Offer a management interface on the specified address and port.
132 See varnish-cli(7) for documentation of the management commands.
133 To disable the management interface use none.
134 -M <address:port>
136 Connect to this port and offer the command line interface.
137 Think of it as a reverse shell. When running with -M and there
138 is no backend defined the child process (the cache) will not
139 start initially.
140 -P file
142 Write the PID of the process to the specified file.
143 -i identity
145 Specify the identity of the Varnish server. This can be accessed
146 using server.identity from VCL and with VSM_Name() from utili‐
147 ties. If not specified the output of gethostname(3) is used.
148 -I clifile
150 Execute the management commands in the file given as clifile be‐
151 fore the the worker process starts, see CLI Command File.
152 Tuning options
154 -t TTL Specifies the default time to live (TTL) for cached objects.
155 This is a shortcut for specifying the default_ttl run-time pa‐
156 rameter.
157 -p <param=value>
159 Set the parameter specified by param to the specified value, see
160 List of Parameters for details. This option can be used multiple
161 times to specify multiple parameters.
162 -s <[name=]type[,options]>
164 Use the specified storage backend. See Storage Backend section.
165 This option can be used multiple times to specify multiple stor‐
167 age files. Name is referenced in logs, VCL, statistics, etc. If
168 name is not specified, "s0", "s1" and so forth is used.
169 -l <vsl>
171 Specifies size of the space for the VSL records, shorthand for
172 -p vsl_space=<vsl>. Scaling suffixes like 'K' and 'M' can be
173 used up to (G)igabytes. See vsl_space for more information.
174 Security options
176 -r <param[,param...]>
177 Make the listed parameters read only. This gives the system ad‐
178 ministrator a way to limit what the Varnish CLI can do. Con‐
179 sider making parameters such as cc_command, vcc_allow_inline_c
180 and vmod_path read only as these can potentially be used to es‐
181 calate privileges from the CLI.
182 -S secret-file
184 Path to a file containing a secret used for authorizing access
185 to the management port. To disable authentication use none.
186 If this argument is not provided, a secret drawn from the system
188 PRNG will be written to a file called _.secret in the working
189 directory (see opt_n) with default ownership and permissions of
190 the user having started varnish.
191 Thus, users wishing to delegate control over varnish will proba‐
193 bly want to create a custom secret file with appropriate permis‐
194 sions (ie. readable by a unix group to delegate control to).
195 -j <jail[,jailoptions]>
197 Specify the jailing mechanism to use. See Jail section.
198 Advanced, development and debugging options
200 -d Enables debugging mode: The parent process runs in the fore‐
201 ground with a CLI connection on stdin/stdout, and the child
202 process must be started explicitly with a CLI command. Terminat‐
203 ing the parent process will also terminate the child.
204 Only one of -d or -F can be specified, and -d cannot be used to‐
206 gether with -C.
207 -C Print VCL code compiled to C language and exit. Specify the VCL
209 file to compile with the -f option. Either -f or -b must be used
210 with -C, and -C cannot be used with -F or -d.
211 -V Display the version number and exit. This must be the only op‐
213 tion.
214 -h <type[,options]>
216 Specifies the hash algorithm. See Hash Algorithm section for a
217 list of supported algorithms.
218 -W waiter
220 Specifies the waiter type to use.
221 Hash Algorithm
223 The following hash algorithms are available:
224 -h critbit
226 self-scaling tree structure. The default hash algorithm in Var‐
227 nish Cache 2.1 and onwards. In comparison to a more traditional
228 B tree the critbit tree is almost completely lockless. Do not
229 change this unless you are certain what you're doing.
230 -h simple_list
232 A simple doubly-linked list. Not recommended for production
233 use.
234 -h <classic[,buckets]>
236 A standard hash table. The hash key is the CRC32 of the object's
237 URL modulo the size of the hash table. Each table entry points
238 to a list of elements which share the same hash key. The buckets
239 parameter specifies the number of entries in the hash table.
240 The default is 16383.
241 Storage Backend
243 The argument format to define storage backends is:
244 -s <[name]=kind[,options]>
246 If name is omitted, Varnish will name storages sN, starting with
247 s0 and incrementing N for every new storage.
248 For kind and options see details below.
250 Storages can be used in vcl as storage.name, so, for example if myStor‐
252 age was defined by -s myStorage=malloc,5G, it could be used in VCL like
253 so:
254 set beresp.storage = storage.myStorage;
256 A special name is Transient which is the default storage for un‐
258 cacheable objects as resulting from a pass, hit-for-miss or
259 hit-for-pass.
260 If no -s options are given, the default is:
262 -s malloc=100m
264 If no Transient storage is defined, the default is an unbound malloc
266 storage as if defined as:
267 -s Transient=malloc
269 The following storage types and options are available:
271 -s <default[,size]>
273 The default storage type resolves to umem where available and
274 malloc otherwise.
275 -s <malloc[,size]>
277 malloc is a memory based backend.
278 -s <umem[,size]>
280 umem is a storage backend which is more efficient than malloc on
281 platforms where it is available.
282 See the section on umem in chapter Storage backends of The Var‐
284 nish Users Guide for details.
285 -s <file,path[,size[,granularity[,advice]]]>
287 The file backend stores data in a file on disk. The file will be
288 accessed using mmap. Note that this storage provide no cache
289 persistence.
290 The path is mandatory. If path points to a directory, a tempo‐
292 rary file will be created in that directory and immediately un‐
293 linked. If path points to a non-existing file, the file will be
294 created.
295 If size is omitted, and path points to an existing file with a
297 size greater than zero, the size of that file will be used. If
298 not, an error is reported.
299 Granularity sets the allocation block size. Defaults to the sys‐
301 tem page size or the filesystem block size, whichever is larger.
302 Advice tells the kernel how varnishd expects to use this mapped
304 region so that the kernel can choose the appropriate read-ahead
305 and caching techniques. Possible values are normal, random and
306 sequential, corresponding to MADV_NORMAL, MADV_RANDOM and
307 MADV_SEQUENTIAL madvise() advice argument, respectively. De‐
308 faults to random.
309 -s <persistent,path,size>
311 Persistent storage. Varnish will store objects in a file in a
312 manner that will secure the survival of most of the objects in
313 the event of a planned or unplanned shutdown of Varnish. The
314 persistent storage backend has multiple issues with it and will
315 likely be removed from a future version of Varnish.
316 Jail
318 Varnish jails are a generalization over various platform specific meth‐
319 ods to reduce the privileges of varnish processes. They may have spe‐
320 cific options. Available jails are:
321 -j <solaris[,worker=`privspec`]>
323 Reduce privileges(5) for varnishd and sub-process to the mini‐
324 mally required set. Only available on platforms which have the
325 setppriv(2) call.
326 The optional worker argument can be used to pass a privi‐
328 lege-specification (see ppriv(1)) by which to extend the effec‐
329 tive set of the varnish worker process. While extended privi‐
330 leges may be required by custom vmods, it is always the more se‐
331 cure to not use the worker option.
332 Example to grant basic privileges to the worker process:
334 -j solaris,worker=basic
336 -j <unix[,user=`user`][,ccgroup=`group`][,workuser=`user`]>
338 Default on all other platforms when varnishd is started with an
339 effective uid of 0 ("as root").
340 With the unix jail mechanism activated, varnish will switch to
342 an alternative user for subprocesses and change the effective
343 uid of the master process whenever possible.
344 The optional user argument specifies which alternative user to
346 use. It defaults to varnish.
347 The optional ccgroup argument specifies a group to add to var‐
349 nish subprocesses requiring access to a c-compiler. There is no
350 default.
351 The optional workuser argument specifies an alternative user to
353 use for the worker process. It defaults to vcache.
354 -j none
356 last resort jail choice: With jail mechanism none, varnish will
357 run all processes with the privileges it was started with.
358 Management Interface
360 If the -T option was specified, varnishd will offer a command-line man‐
361 agement interface on the specified address and port. The recommended
362 way of connecting to the command-line management interface is through
363 varnishadm(1).
364 The commands available are documented in varnish-cli(7).
366 CLI Command File
368 The -I option makes it possible to run arbitrary management commands
369 when varnishd is launched, before the worker process is started. In
370 particular, this is the way to load configurations, apply labels to
371 them, and make a VCL instance active that uses those labels on startup:
372 vcl.load panic /etc/varnish_panic.vcl
374 vcl.load siteA0 /etc/varnish_siteA.vcl
375 vcl.load siteB0 /etc/varnish_siteB.vcl
376 vcl.load siteC0 /etc/varnish_siteC.vcl
377 vcl.label siteA siteA0
378 vcl.label siteB siteB0
379 vcl.label siteC siteC0
380 vcl.load main /etc/varnish_main.vcl
381 vcl.use main
382 Every line in the file, including the last line, must be terminated by
384 a newline or carriage return.
385 If a command in the file is prefixed with '-', failure will not abort
387 the startup.
388
390 Run Time Parameter Flags
391 Runtime parameters are marked with shorthand flags to avoid repeating
392 the same text over and over in the table below. The meaning of the
393 flags are:
394 • experimental
396 We have no solid information about good/bad/optimal values for this
398 parameter. Feedback with experience and observations are most wel‐
399 come.
400 • delayed
402 This parameter can be changed on the fly, but will not take effect
404 immediately.
405 • restart
407 The worker process must be stopped and restarted, before this parame‐
409 ter takes effect.
410 • reload
412 The VCL programs must be reloaded for this parameter to take effect.
414 • wizard
416 Do not touch unless you really know what you're doing.
418 • only_root
420 Only works if varnishd is running as root.
422 Default Value Exceptions on 32 bit Systems
424 Be aware that on 32 bit systems, certain default or maximum values are
425 reduced relative to the values listed below, in order to conserve VM
426 space:
427 • workspace_client: 24k
429 • workspace_backend: 20k
431 • http_resp_size: 8k
433 • http_req_size: 12k
435 • gzip_buffer: 4k
437 • vsl_space: 1G (maximum)
439 • thread_pool_stack: 52k
441 List of Parameters
443 This text is produced from the same text you will find in the CLI if
444 you use the param.show command:
445 accept_filter
447 NB: This parameter depends on a feature which is not available on all
448 platforms.
449 • Units: bool
451 • Default: on (if your platform supports accept filters)
453 Enable kernel accept-filters. This may require a kernel module to be
455 loaded to have an effect when enabled.
456 Enabling accept_filter may prevent some requests to reach Varnish in
458 the first place. Malformed requests may go unnoticed and not increase
459 the client_req_400 counter. GET or HEAD requests with a body may be
460 blocked altogether.
461 acceptor_sleep_decay
463 • Default: 0.9
464 • Minimum: 0
466 • Maximum: 1
468 • Flags: experimental
470 If we run out of resources, such as file descriptors or worker threads,
472 the acceptor will sleep between accepts. This parameter (multiplica‐
473 tively) reduce the sleep duration for each successful accept. (ie: 0.9
474 = reduce by 10%)
475 acceptor_sleep_incr
477 • Units: seconds
478 • Default: 0.000
480 • Minimum: 0.000
482 • Maximum: 1.000
484 • Flags: experimental
486 If we run out of resources, such as file descriptors or worker threads,
488 the acceptor will sleep between accepts. This parameter control how
489 much longer we sleep, each time we fail to accept a new connection.
490 acceptor_sleep_max
492 • Units: seconds
493 • Default: 0.050
495 • Minimum: 0.000
497 • Maximum: 10.000
499 • Flags: experimental
501 If we run out of resources, such as file descriptors or worker threads,
503 the acceptor will sleep between accepts. This parameter limits how
504 long it can sleep between attempts to accept new connections.
505 auto_restart
507 • Units: bool
508 • Default: on
510 Automatically restart the child/worker process if it dies.
512 backend_idle_timeout
514 • Units: seconds
515 • Default: 60.000
517 • Minimum: 1.000
519 Timeout before we close unused backend connections.
521 backend_local_error_holddown
523 • Units: seconds
524 • Default: 10.000
526 • Minimum: 0.000
528 • Flags: experimental
530 When connecting to backends, certain error codes (EADDRNOTAVAIL, EAC‐
532 CESS, EPERM) signal a local resource shortage or configuration issue
533 for which retrying connection attempts may worsen the situation due to
534 the complexity of the operations involved in the kernel. This parame‐
535 ter prevents repeated connection attempts for the configured duration.
536 backend_remote_error_holddown
538 • Units: seconds
539 • Default: 0.250
541 • Minimum: 0.000
543 • Flags: experimental
545 When connecting to backends, certain error codes (ECONNREFUSED, ENETUN‐
547 REACH) signal fundamental connection issues such as the backend not ac‐
548 cepting connections or routing problems for which repeated connection
549 attempts are considered useless This parameter prevents repeated con‐
550 nection attempts for the configured duration.
551 ban_cutoff
553 • Units: bans
554 • Default: 0
556 • Minimum: 0
558 • Flags: experimental
560 Expurge long tail content from the cache to keep the number of bans be‐
562 low this value. 0 disables.
563 When this parameter is set to a non-zero value, the ban lurker contin‐
565 ues to work the ban list as usual top to bottom, but when it reaches
566 the ban_cutoff-th ban, it treats all objects as if they matched a ban
567 and expurges them from cache. As actively used objects get tested
568 against the ban list at request time and thus are likely to be associ‐
569 ated with bans near the top of the ban list, with ban_cutoff, least re‐
570 cently accessed objects (the "long tail") are removed.
571 This parameter is a safety net to avoid bad response times due to bans
573 being tested at lookup time. Setting a cutoff trades response time for
574 cache efficiency. The recommended value is proportional to
575 rate(bans_lurker_tests_tested) / n_objects while the ban lurker is
576 working, which is the number of bans the system can sustain. The addi‐
577 tional latency due to request ban testing is in the order of ban_cutoff
578 / rate(bans_lurker_tests_tested). For example, for
579 rate(bans_lurker_tests_tested) = 2M/s and a tolerable latency of 100ms,
580 a good value for ban_cutoff may be 200K.
581 ban_dups
583 • Units: bool
584 • Default: on
586 Eliminate older identical bans when a new ban is added. This saves CPU
588 cycles by not comparing objects to identical bans. This is a waste of
589 time if you have many bans which are never identical.
590 ban_lurker_age
592 • Units: seconds
593 • Default: 60.000
595 • Minimum: 0.000
597 The ban lurker will ignore bans until they are this old. When a ban is
599 added, the active traffic will be tested against it as part of object
600 lookup. Because many applications issue bans in bursts, this parameter
601 holds the ban-lurker off until the rush is over. This should be set to
602 the approximate time which a ban-burst takes.
603 ban_lurker_batch
605 • Default: 1000
606 • Minimum: 1
608 The ban lurker sleeps ${ban_lurker_sleep} after examining this many ob‐
610 jects. Use this to pace the ban-lurker if it eats too many resources.
611 ban_lurker_holdoff
613 • Units: seconds
614 • Default: 0.010
616 • Minimum: 0.000
618 • Flags: experimental
620 How long the ban lurker sleeps when giving way to lookup due to lock
622 contention.
623 ban_lurker_sleep
625 • Units: seconds
626 • Default: 0.010
628 • Minimum: 0.000
630 How long the ban lurker sleeps after examining ${ban_lurker_batch} ob‐
632 jects. Use this to pace the ban-lurker if it eats too many resources.
633 A value of zero will disable the ban lurker entirely.
634 between_bytes_timeout
636 • Units: seconds
637 • Default: 60.000
639 • Minimum: 0.000
641 We only wait for this many seconds between bytes received from the
643 backend before giving up the fetch. VCL values, per backend or per
644 backend request take precedence. This parameter does not apply to
645 pipe'ed requests.
646 cc_command
648 • Default: exec clang -g -O2 -Wall -Werror -Wno-error=unused-result
649 -Werror -Wno-format-y2k -Wstrict-prototypes -Wmissing-proto‐
650 types -Wpointer-arith -Wcast-qual -Wwrite-strings -Wshadow
651 -Wunused-parameter -Wcast-align -Wchar-subscripts -Wnested-ex‐
652 terns -Wextra -Wno-sign-compare -fstack-protector -Wno-miss‐
653 ing-field-initializers -pthread -fpic -shared -Wl,-x -o %o %s
654 • Flags: must_reload
656 Command used for compiling the C source code to a dlopen(3) loadable
658 object. Any occurrence of %s in the string will be replaced with the
659 source file name, and %o will be replaced with the output file name.
660 cli_limit
662 • Units: bytes
663 • Default: 48k
665 • Minimum: 128b
667 • Maximum: 99999999b
669 Maximum size of CLI response. If the response exceeds this limit, the
671 response code will be 201 instead of 200 and the last line will indi‐
672 cate the truncation.
673 cli_timeout
675 • Units: seconds
676 • Default: 60.000
678 • Minimum: 0.000
680 Timeout for the childs replies to CLI requests from the mgt_param.
682 clock_skew
684 • Units: seconds
685 • Default: 10
687 • Minimum: 0
689 How much clockskew we are willing to accept between the backend and our
691 own clock.
692 clock_step
694 • Units: seconds
695 • Default: 1.000
697 • Minimum: 0.000
699 How much observed clock step we are willing to accept before we panic.
701 connect_timeout
703 • Units: seconds
704 • Default: 3.500
706 • Minimum: 0.000
708 Default connection timeout for backend connections. We only try to con‐
710 nect to the backend for this many seconds before giving up. VCL can
711 override this default value for each backend and backend request.
712 critbit_cooloff
714 • Units: seconds
715 • Default: 180.000
717 • Minimum: 60.000
719 • Maximum: 254.000
721 • Flags: wizard
723 How long the critbit hasher keeps deleted objheads on the cooloff list.
725 debug
727 • Default: none
728 Enable/Disable various kinds of debugging.
730 none Disable all debugging
732 Use +/- prefix to set/reset individual bits:
734 req_state
736 VSL Request state engine
737 workspace
739 VSL Workspace operations
740 waitinglist
742 VSL Waitinglist events
743 syncvsl
745 Make VSL synchronous
746 hashedge
748 Edge cases in Hash
749 vclrel Rapid VCL release
751 lurker VSL Ban lurker
753 esi_chop
755 Chop ESI fetch to bits
756 flush_head
758 Flush after http1 head
759 vtc_mode
761 Varnishtest Mode
762 witness
764 Emit WITNESS lock records
765 vsm_keep
767 Keep the VSM file on restart
768 drop_pools
770 Drop thread pools (testing)
771 slow_acceptor
773 Slow down Acceptor
774 h2_nocheck
776 Disable various H2 checks
777 vmod_so_keep
779 Keep copied VMOD libraries
780 processors
782 Fetch/Deliver processors
783 protocol
785 Protocol debugging
786 vcl_keep
788 Keep VCL C and so files
789 lck Additional lock statistics
791 default_grace
793 • Units: seconds
794 • Default: 10.000
796 • Minimum: 0.000
798 • Flags: obj_sticky
800 Default grace period. We will deliver an object this long after it has
802 expired, provided another thread is attempting to get a new copy.
803 default_keep
805 • Units: seconds
806 • Default: 0.000
808 • Minimum: 0.000
810 • Flags: obj_sticky
812 Default keep period. We will keep a useless object around this long,
814 making it available for conditional backend fetches. That means that
815 the object will be removed from the cache at the end of ttl+grace+keep.
816 default_ttl
818 • Units: seconds
819 • Default: 120.000
821 • Minimum: 0.000
823 • Flags: obj_sticky
825 The TTL assigned to objects if neither the backend nor the VCL code as‐
827 signs one.
828 feature
830 • Default: +validate_headers
831 Enable/Disable various minor features.
833 default
835 Set default value
836 none Disable all features.
838 Use +/- prefix to enable/disable individual feature:
840 http2 Enable HTTP/2 protocol support.
842 short_panic
844 Short panic message.
845 no_coredump
847 No coredumps. Must be set before child process starts.
848 https_scheme
850 Extract host from full URI in the HTTP/1 request line, if the
851 scheme is https.
852 http_date_postel
854 Tolerate non compliant timestamp headers like Date, Last-Mod‐
855 ified, Expires etc.
856 esi_ignore_https
858 Convert <esi:include src"https://... to http://...
859 esi_disable_xml_check
861 Allow ESI processing on non-XML ESI bodies
862 esi_ignore_other_elements
864 Ignore XML syntax errors in ESI bodies.
865 esi_remove_bom
867 Ignore UTF-8 BOM in ESI bodies.
868 wait_silo
870 Wait for persistent silos to completely load before serving
871 requests.
872 validate_headers
874 Validate all header set operations to conform to RFC7230.
875 busy_stats_rate
877 Make busy workers comply with thread_stats_rate.
878 fetch_chunksize
880 • Units: bytes
881 • Default: 16k
883 • Minimum: 4k
885 • Flags: experimental
887 The default chunksize used by fetcher. This should be bigger than the
889 majority of objects with short TTLs. Internal limits in the stor‐
890 age_file module makes increases above 128kb a dubious idea.
891 fetch_maxchunksize
893 • Units: bytes
894 • Default: 0.25G
896 • Minimum: 64k
898 • Flags: experimental
900 The maximum chunksize we attempt to allocate from storage. Making this
902 too large may cause delays and storage fragmentation.
903 first_byte_timeout
905 • Units: seconds
906 • Default: 60.000
908 • Minimum: 0.000
910 Default timeout for receiving first byte from backend. We only wait for
912 this many seconds for the first byte before giving up. VCL can over‐
913 ride this default value for each backend and backend request. This pa‐
914 rameter does not apply to pipe'ed requests.
915 gzip_buffer
917 • Units: bytes
918 • Default: 32k
920 • Minimum: 2k
922 • Flags: experimental
924 Size of malloc buffer used for gzip processing. These buffers are used
926 for in-transit data, for instance gunzip'ed data being sent to a
927 client.Making this space to small results in more overhead, writes to
928 sockets etc, making it too big is probably just a waste of memory.
929 gzip_level
931 • Default: 6
932 • Minimum: 0
934 • Maximum: 9
936 Gzip compression level: 0=debug, 1=fast, 9=best
938 gzip_memlevel
940 • Default: 8
941 • Minimum: 1
943 • Maximum: 9
945 Gzip memory level 1=slow/least, 9=fast/most compression. Memory impact
947 is 1=1k, 2=2k, ... 9=256k.
948 h2_header_table_size
950 • Units: bytes
951 • Default: 4k
953 • Minimum: 0b
955 HTTP2 header table size. This is the size that will be used for the
957 HPACK dynamic decoding table.
958 h2_initial_window_size
960 • Units: bytes
961 • Default: 65535b
963 • Minimum: 0b
965 • Maximum: 2147483647b
967 HTTP2 initial flow control window size.
969 h2_max_concurrent_streams
971 • Units: streams
972 • Default: 100
974 • Minimum: 0
976 HTTP2 Maximum number of concurrent streams. This is the number of re‐
978 quests that can be active at the same time for a single HTTP2 connec‐
979 tion.
980 h2_max_frame_size
982 • Units: bytes
983 • Default: 16k
985 • Minimum: 16k
987 • Maximum: 16777215b
989 HTTP2 maximum per frame payload size we are willing to accept.
991 h2_max_header_list_size
993 • Units: bytes
994 • Default: 2147483647b
996 • Minimum: 0b
998 HTTP2 maximum size of an uncompressed header list.
1000 h2_rx_window_increment
1002 • Units: bytes
1003 • Default: 1M
1005 • Minimum: 1M
1007 • Maximum: 1G
1009 • Flags: wizard
1011 HTTP2 Receive Window Increments. How big credits we send in WINDOW_UP‐
1013 DATE frames Only affects incoming request bodies (ie: POST, PUT etc.)
1014 h2_rx_window_low_water
1016 • Units: bytes
1017 • Default: 10M
1019 • Minimum: 65535b
1021 • Maximum: 1G
1023 • Flags: wizard
1025 HTTP2 Receive Window low water mark. We try to keep the window at
1027 least this big Only affects incoming request bodies (ie: POST, PUT
1028 etc.)
1029 http1_iovs
1031 • Units: struct iovec (=16 bytes)
1032 • Default: 64
1034 • Minimum: 5
1036 • Maximum: 1024
1038 • Flags: wizard
1040 Number of io vectors to allocate for HTTP1 protocol transmission. A
1042 HTTP1 header needs 7 + 2 per HTTP header field. Allocated from
1043 workspace_thread.
1044 http_gzip_support
1046 • Units: bool
1047 • Default: on
1049 Enable gzip support. When enabled Varnish request compressed objects
1051 from the backend and store them compressed. If a client does not sup‐
1052 port gzip encoding Varnish will uncompress compressed objects on de‐
1053 mand. Varnish will also rewrite the Accept-Encoding header of clients
1054 indicating support for gzip to:
1055 Accept-Encoding: gzip
1056 Clients that do not support gzip will have their Accept-Encoding header
1058 removed. For more information on how gzip is implemented please see the
1059 chapter on gzip in the Varnish reference.
1060 When gzip support is disabled the variables beresp.do_gzip and
1062 beresp.do_gunzip have no effect in VCL.
1063 http_max_hdr
1065 • Units: header lines
1066 • Default: 64
1068 • Minimum: 32
1070 • Maximum: 65535
1072 Maximum number of HTTP header lines we allow in
1074 {req|resp|bereq|beresp}.http (obj.http is autosized to the exact number
1075 of headers). Cheap, ~20 bytes, in terms of workspace memory. Note
1076 that the first line occupies five header lines.
1077 http_range_support
1079 • Units: bool
1080 • Default: on
1082 Enable support for HTTP Range headers.
1084 http_req_hdr_len
1086 • Units: bytes
1087 • Default: 8k
1089 • Minimum: 40b
1091 Maximum length of any HTTP client request header we will allow. The
1093 limit is inclusive its continuation lines.
1094 http_req_size
1096 • Units: bytes
1097 • Default: 32k
1099 • Minimum: 0.25k
1101 Maximum number of bytes of HTTP client request we will deal with. This
1103 is a limit on all bytes up to the double blank line which ends the HTTP
1104 request. The memory for the request is allocated from the client
1105 workspace (param: workspace_client) and this parameter limits how much
1106 of that the request is allowed to take up.
1107 http_resp_hdr_len
1109 • Units: bytes
1110 • Default: 8k
1112 • Minimum: 40b
1114 Maximum length of any HTTP backend response header we will allow. The
1116 limit is inclusive its continuation lines.
1117 http_resp_size
1119 • Units: bytes
1120 • Default: 32k
1122 • Minimum: 0.25k
1124 Maximum number of bytes of HTTP backend response we will deal with.
1126 This is a limit on all bytes up to the double blank line which ends the
1127 HTTP response. The memory for the response is allocated from the back‐
1128 end workspace (param: workspace_backend) and this parameter limits how
1129 much of that the response is allowed to take up.
1130 idle_send_timeout
1132 NB: This parameter depends on a feature which is not available on all
1133 platforms.
1134 • Units: seconds
1136 • Default: 60.000
1138 • Minimum: 0.000
1140 • Flags: delayed
1142 Send timeout for individual pieces of data on client connections. May
1144 get extended if 'send_timeout' applies.
1145 When this timeout is hit, the session is closed.
1147 See the man page for setsockopt(2) or socket(7) under SO_SNDTIMEO for
1149 more information.
1150 listen_depth
1152 • Units: connections
1153 • Default: 1024
1155 • Minimum: 0
1157 • Flags: must_restart
1159 Listen queue depth.
1161 lru_interval
1163 • Units: seconds
1164 • Default: 2.000
1166 • Minimum: 0.000
1168 • Flags: experimental
1170 Grace period before object moves on LRU list. Objects are only moved
1172 to the front of the LRU list if they have not been moved there already
1173 inside this timeout period. This reduces the amount of lock operations
1174 necessary for LRU list access.
1175 max_esi_depth
1177 • Units: levels
1178 • Default: 5
1180 • Minimum: 0
1182 Maximum depth of esi:include processing.
1184 max_restarts
1186 • Units: restarts
1187 • Default: 4
1189 • Minimum: 0
1191 Upper limit on how many times a request can restart.
1193 max_retries
1195 • Units: retries
1196 • Default: 4
1198 • Minimum: 0
1200 Upper limit on how many times a backend fetch can retry.
1202 max_vcl
1204 • Default: 100
1205 • Minimum: 0
1207 Threshold of loaded VCL programs. (VCL labels are not counted.) Pa‐
1209 rameter max_vcl_handling determines behaviour.
1210 max_vcl_handling
1212 • Default: 1
1213 • Minimum: 0
1215 • Maximum: 2
1217 Behaviour when attempting to exceed max_vcl loaded VCL.
1219 • 0 - Ignore max_vcl parameter.
1221 • 1 - Issue warning.
1223 • 2 - Refuse loading VCLs.
1225 nuke_limit
1227 • Units: allocations
1228 • Default: 50
1230 • Minimum: 0
1232 • Flags: experimental
1234 Maximum number of objects we attempt to nuke in order to make space for
1236 a object body.
1237 pcre_match_limit
1239 • Default: 10000
1240 • Minimum: 1
1242 The limit for the number of calls to the internal match() function in
1244 pcre_exec().
1245 (See: PCRE_EXTRA_MATCH_LIMIT in pcre docs.)
1247 This parameter limits how much CPU time regular expression matching can
1249 soak up.
1250 pcre_match_limit_recursion
1252 • Default: 20
1253 • Minimum: 1
1255 The recursion depth-limit for the internal match() function in a
1257 pcre_exec().
1258 (See: PCRE_EXTRA_MATCH_LIMIT_RECURSION in pcre docs.)
1260 This puts an upper limit on the amount of stack used by PCRE for cer‐
1262 tain classes of regular expressions.
1263 We have set the default value low in order to prevent crashes, at the
1265 cost of possible regexp matching failures.
1266 Matching failures will show up in the log as VCL_Error messages with
1268 regexp errors -27 or -21.
1269 Testcase r01576 can be useful when tuning this parameter.
1271 ping_interval
1273 • Units: seconds
1274 • Default: 3
1276 • Minimum: 0
1278 • Flags: must_restart
1280 Interval between pings from parent to child. Zero will disable pinging
1282 entirely, which makes it possible to attach a debugger to the child.
1283 pipe_sess_max
1285 • Units: connections
1286 • Default: 0
1288 • Minimum: 0
1290 Maximum number of sessions dedicated to pipe transactions.
1292 pipe_timeout
1294 • Units: seconds
1295 • Default: 60.000
1297 • Minimum: 0.000
1299 Idle timeout for PIPE sessions. If nothing have been received in either
1301 direction for this many seconds, the session is closed.
1302 pool_req
1304 • Default: 10,100,10
1305 Parameters for per worker pool request memory pool.
1307 The three numbers are:
1309 min_pool
1311 minimum size of free pool.
1312 max_pool
1314 maximum size of free pool.
1315 max_age
1317 max age of free element.
1318 pool_sess
1320 • Default: 10,100,10
1321 Parameters for per worker pool session memory pool.
1323 The three numbers are:
1325 min_pool
1327 minimum size of free pool.
1328 max_pool
1330 maximum size of free pool.
1331 max_age
1333 max age of free element.
1334 pool_vbo
1336 • Default: 10,100,10
1337 Parameters for backend object fetch memory pool.
1339 The three numbers are:
1341 min_pool
1343 minimum size of free pool.
1344 max_pool
1346 maximum size of free pool.
1347 max_age
1349 max age of free element.
1350 prefer_ipv6
1352 • Units: bool
1353 • Default: off
1355 Prefer IPv6 address when connecting to backends which have both IPv4
1357 and IPv6 addresses.
1358 rush_exponent
1360 • Units: requests per request
1361 • Default: 3
1363 • Minimum: 2
1365 • Flags: experimental
1367 How many parked request we start for each completed request on the ob‐
1369 ject. NB: Even with the implict delay of delivery, this parameter con‐
1370 trols an exponential increase in number of worker threads.
1371 send_timeout
1373 NB: This parameter depends on a feature which is not available on all
1374 platforms.
1375 • Units: seconds
1377 • Default: 600.000
1379 • Minimum: 0.000
1381 • Flags: delayed
1383 Total timeout for ordinary HTTP1 responses. Does not apply to some in‐
1385 ternally generated errors and pipe mode.
1386 When 'idle_send_timeout' is hit while sending an HTTP1 response, the
1388 timeout is extended unless the total time already taken for sending the
1389 response in its entirety exceeds this many seconds.
1390 When this timeout is hit, the session is closed
1392 shortlived
1394 • Units: seconds
1395 • Default: 10.000
1397 • Minimum: 0.000
1399 Objects created with (ttl+grace+keep) shorter than this are always put
1401 in transient storage.
1402 sigsegv_handler
1404 • Units: bool
1405 • Default: on
1407 • Flags: must_restart
1409 Install a signal handler which tries to dump debug information on seg‐
1411 mentation faults, bus errors and abort signals.
1412 syslog_cli_traffic
1414 • Units: bool
1415 • Default: on
1417 Log all CLI traffic to syslog(LOG_INFO).
1419 tcp_fastopen
1421 NB: This parameter depends on a feature which is not available on all
1422 platforms.
1423 • Units: bool
1425 • Default: off
1427 • Flags: must_restart
1429 Enable TCP Fast Open extension.
1431 tcp_keepalive_intvl
1433 NB: This parameter depends on a feature which is not available on all
1434 platforms.
1435 • Units: seconds
1437 • Default: platform dependent
1439 • Minimum: 1.000
1441 • Maximum: 100.000
1443 • Flags: experimental
1445 The number of seconds between TCP keep-alive probes. Ignored for Unix
1447 domain sockets.
1448 tcp_keepalive_probes
1450 NB: This parameter depends on a feature which is not available on all
1451 platforms.
1452 • Units: probes
1454 • Default: platform dependent
1456 • Minimum: 1
1458 • Maximum: 100
1460 • Flags: experimental
1462 The maximum number of TCP keep-alive probes to send before giving up
1464 and killing the connection if no response is obtained from the other
1465 end. Ignored for Unix domain sockets.
1466 tcp_keepalive_time
1468 NB: This parameter depends on a feature which is not available on all
1469 platforms.
1470 • Units: seconds
1472 • Default: platform dependent
1474 • Minimum: 1.000
1476 • Maximum: 7200.000
1478 • Flags: experimental
1480 The number of seconds a connection needs to be idle before TCP begins
1482 sending out keep-alive probes. Ignored for Unix domain sockets.
1483 thread_pool_add_delay
1485 • Units: seconds
1486 • Default: 0.000
1488 • Minimum: 0.000
1490 • Flags: experimental
1492 Wait at least this long after creating a thread.
1494 Some (buggy) systems may need a short (sub-second) delay between creat‐
1496 ing threads. Set this to a few milliseconds if you see the
1497 'threads_failed' counter grow too much.
1498 Setting this too high results in insufficient worker threads.
1500 thread_pool_destroy_delay
1502 • Units: seconds
1503 • Default: 1.000
1505 • Minimum: 0.010
1507 • Flags: delayed, experimental
1509 Wait this long after destroying a thread.
1511 This controls the decay of thread pools when idle(-ish).
1513 thread_pool_fail_delay
1515 • Units: seconds
1516 • Default: 0.200
1518 • Minimum: 0.010
1520 • Flags: experimental
1522 Wait at least this long after a failed thread creation before trying to
1524 create another thread.
1525 Failure to create a worker thread is often a sign that the end is
1527 near, because the process is running out of some resource. This delay
1528 tries to not rush the end on needlessly.
1529 If thread creation failures are a problem, check that thread_pool_max
1531 is not too high.
1532 It may also help to increase thread_pool_timeout and thread_pool_min,
1534 to reduce the rate at which treads are destroyed and later recreated.
1535 thread_pool_max
1537 • Units: threads
1538 • Default: 5000
1540 • Minimum: thread_pool_min
1542 • Flags: delayed
1544 The maximum number of worker threads in each pool.
1546 Do not set this higher than you have to, since excess worker threads
1548 soak up RAM and CPU and generally just get in the way of getting work
1549 done.
1550 thread_pool_min
1552 • Units: threads
1553 • Default: 100
1555 • Minimum: 5
1557 • Maximum: thread_pool_max
1559 • Flags: delayed
1561 The minimum number of worker threads in each pool.
1563 Increasing this may help ramp up faster from low load situations or
1565 when threads have expired.
1566 Technical minimum is 5 threads, but this parameter is strongly recom‐
1568 mended to be at least 10
1569 thread_pool_reserve
1571 • Units: threads
1572 • Default: 0 (auto-tune: 5% of thread_pool_min)
1574 • Maximum: 95% of thread_pool_min
1576 • Flags: delayed
1578 The number of worker threads reserved for vital tasks in each pool.
1580 Tasks may require other tasks to complete (for example, client requests
1582 may require backend requests, http2 sessions require streams, which re‐
1583 quire requests). This reserve is to ensure that lower priority tasks do
1584 not prevent higher priority tasks from running even under high load.
1585 The effective value is at least 5 (the number of internal priority
1587 classes), irrespective of this parameter.
1588 thread_pool_stack
1590 • Units: bytes
1591 • Default: sysconf(_SC_THREAD_STACK_MIN)
1593 • Minimum: 16k
1595 • Flags: delayed
1597 Worker thread stack size. This will likely be rounded up to a multiple
1599 of 4k (or whatever the page_size might be) by the kernel.
1600 The required stack size is primarily driven by the depth of the
1602 call-tree. The most common relevant determining factors in varnish core
1603 code are GZIP (un)compression, ESI processing and regular expression
1604 matches. VMODs may also require significant amounts of additional
1605 stack. The nesting depth of VCL subs is another factor, although typi‐
1606 cally not predominant.
1607 The stack size is per thread, so the maximum total memory required for
1609 worker thread stacks is in the order of size = thread_pools x
1610 thread_pool_max x thread_pool_stack.
1611 Thus, in particular for setups with many threads, keeping the stack
1613 size at a minimum helps reduce the amount of memory required by Var‐
1614 nish.
1615 On the other hand, thread_pool_stack must be large enough under all
1617 circumstances, otherwise varnish will crash due to a stack overflow.
1618 Usually, a stack overflow manifests itself as a segmentation fault (aka
1619 segfault / SIGSEGV) with the faulting address being near the stack
1620 pointer (sp).
1621 Unless stack usage can be reduced, thread_pool_stack must be increased
1623 when a stack overflow occurs. Setting it in 150%-200% increments is
1624 recommended until stack overflows cease to occur.
1625 thread_pool_timeout
1627 • Units: seconds
1628 • Default: 300.000
1630 • Minimum: 10.000
1632 • Flags: delayed, experimental
1634 Thread idle threshold.
1636 Threads in excess of thread_pool_min, which have been idle for at least
1638 this long, will be destroyed.
1639 thread_pool_watchdog
1641 • Units: seconds
1642 • Default: 60.000
1644 • Minimum: 0.100
1646 • Flags: experimental
1648 Thread queue stuck watchdog.
1650 If no queued work have been released for this long, the worker process
1652 panics itself.
1653 thread_pools
1655 • Units: pools
1656 • Default: 2
1658 • Minimum: 1
1660 • Maximum: 32
1662 • Flags: delayed, experimental
1664 Number of worker thread pools.
1666 Increasing the number of worker pools decreases lock contention. Each
1668 worker pool also has a thread accepting new connections, so for very
1669 high rates of incoming new connections on systems with many cores, in‐
1670 creasing the worker pools may be required.
1671 Too many pools waste CPU and RAM resources, and more than one pool for
1673 each CPU is most likely detrimental to performance.
1674 Can be increased on the fly, but decreases require a restart to take
1676 effect, unless the drop_pools experimental debug flag is set.
1677 thread_queue_limit
1679 • Units: requests
1680 • Default: 20
1682 • Minimum: 0
1684 • Flags: experimental
1686 Permitted request queue length per thread-pool.
1688 This sets the number of requests we will queue, waiting for an avail‐
1690 able thread. Above this limit sessions will be dropped instead of
1691 queued.
1692 thread_stats_rate
1694 • Units: requests
1695 • Default: 10
1697 • Minimum: 0
1699 • Flags: experimental
1701 Worker threads accumulate statistics, and dump these into the global
1703 stats counters if the lock is free when they finish a job (re‐
1704 quest/fetch etc.) This parameters defines the maximum number of jobs a
1705 worker thread may handle, before it is forced to dump its accumulated
1706 stats into the global counters.
1707 timeout_idle
1709 NB: This parameter depends on a feature which is not available on all
1710 platforms.
1711 • Units: seconds
1713 • Default: 5.000
1715 • Minimum: 0.000
1717 Idle timeout for client connections.
1719 A connection is considered idle until we have received the full request
1721 headers.
1722 This parameter is particularly relevant for HTTP1 keepalive connec‐
1724 tions which are closed unless the next request is received before this
1725 timeout is reached.
1726 timeout_linger
1728 • Units: seconds
1729 • Default: 0.050
1731 • Minimum: 0.000
1733 • Flags: experimental
1735 How long the worker thread lingers on an idle session before handing it
1737 over to the waiter. When sessions are reused, as much as half of all
1738 reuses happen within the first 100 msec of the previous request com‐
1739 pleting. Setting this too high results in worker threads not doing
1740 anything for their keep, setting it too low just means that more ses‐
1741 sions take a detour around the waiter.
1742 vary_notice
1744 • Units: variants
1745 • Default: 10
1747 • Minimum: 1
1749 How many variants need to be evaluated to log a Notice that there might
1751 be too many variants.
1752 vcc_acl_pedantic
1754 • Units: bool
1755 • Default: off
1757 Insist that network numbers used in ACLs have an all-zero host part,
1759 e.g. make 1.2.3.4/24 an error. With this option set to off (the de‐
1760 fault), the host part of network numbers is being fixed to all-zeroes
1761 (e.g. the above changed to 1.2.3.0/24), a warning is output during VCL
1762 compilation and any ACL entry hits are logged with the fixed address as
1763 "fixed: ..." after the original VCL entry. With this option set to on,
1764 any ACL entries with non-zero host parts cause VCL compilation to fail.
1765 vcc_allow_inline_c
1767 • Units: bool
1768 • Default: off
1770 Allow inline C code in VCL.
1772 vcc_err_unref
1774 • Units: bool
1775 • Default: on
1777 Unreferenced VCL objects result in error.
1779 vcc_unsafe_path
1781 • Units: bool
1782 • Default: on
1784 Allow '/' in vmod & include paths. Allow 'import ... from ...'.
1786 vcl_cooldown
1788 • Units: seconds
1789 • Default: 600.000
1791 • Minimum: 1.000
1793 How long a VCL is kept warm after being replaced as the active VCL
1795 (granularity approximately 30 seconds).
1796 vcl_path
1798 • Default: /opt/varnish/etc/varnish:/opt/varnish/share/varnish/vcl
1799 Directory (or colon separated list of directories) from which relative
1801 VCL filenames (vcl.load and include) are to be found. By default Var‐
1802 nish searches VCL files in both the system configuration and shared
1803 data directories to allow packages to drop their VCL files in a stan‐
1804 dard location where relative includes would work.
1805 vmod_path
1807 • Default: /opt/varnish/lib/varnish/vmods
1808 Directory (or colon separated list of directories) where VMODs are to
1810 be found.
1811 vsl_buffer
1813 • Units: bytes
1814 • Default: 4k
1816 • Minimum: vsl_reclen + 12 bytes
1818 Bytes of (req-/backend-)workspace dedicated to buffering VSL records.
1820 When this parameter is adjusted, most likely workspace_client and
1821 workspace_backend will have to be adjusted by the same amount.
1822 Setting this too high costs memory, setting it too low will cause more
1824 VSL flushes and likely increase lock-contention on the VSL mutex.
1825 vsl_mask
1827 • Default: -Debug,-ObjProtocol,-ObjStatus,-ObjReason,-Obj‐
1828 Header,-VCL_trace,-ExpKill,-WorkThread,-Hash,-VfpAcct,-H2Rx‐
1829 Hdr,-H2RxBody,-H2TxHdr,-H2TxBody,-VdpAcct
1830 Mask individual VSL messages from being logged.
1832 default
1834 Set default value
1835 Use +/- prefix in front of VSL tag name to unmask/mask individual VSL
1837 messages.
1838 vsl_reclen
1840 • Units: bytes
1841 • Default: 255b
1843 • Minimum: 16b
1845 • Maximum: vsl_buffer - 12 bytes
1847 Maximum number of bytes in SHM log record.
1849 vsl_space
1851 • Units: bytes
1852 • Default: 80M
1854 • Minimum: 1M
1856 • Maximum: 4G
1858 • Flags: must_restart
1860 The amount of space to allocate for the VSL fifo buffer in the VSM mem‐
1862 ory segment. If you make this too small, varnish{ncsa|log} etc will
1863 not be able to keep up. Making it too large just costs memory re‐
1864 sources.
1865 vsm_free_cooldown
1867 • Units: seconds
1868 • Default: 60.000
1870 • Minimum: 10.000
1872 • Maximum: 600.000
1874 How long VSM memory is kept warm after a deallocation (granularity ap‐
1876 proximately 2 seconds).
1877 vsm_space
1879 • Units: bytes
1880 • Default: 1M
1882 • Minimum: 1M
1884 • Maximum: 1G
1886 DEPRECATED: This parameter is ignored. There is no global limit on
1888 amount of shared memory now.
1889 workspace_backend
1891 • Units: bytes
1892 • Default: 64k
1894 • Minimum: 1k
1896 • Flags: delayed
1898 Bytes of HTTP protocol workspace for backend HTTP req/resp. If larger
1900 than 4k, use a multiple of 4k for VM efficiency.
1901 workspace_client
1903 • Units: bytes
1904 • Default: 64k
1906 • Minimum: 9k
1908 • Flags: delayed
1910 Bytes of HTTP protocol workspace for clients HTTP req/resp. Use a mul‐
1912 tiple of 4k for VM efficiency. For HTTP/2 compliance this must be at
1913 least 20k, in order to receive fullsize (=16k) frames from the client.
1914 That usually happens only in POST/PUT bodies. For other traffic-pat‐
1915 terns smaller values work just fine.
1916 workspace_session
1918 • Units: bytes
1919 • Default: 0.75k
1921 • Minimum: 0.25k
1923 • Flags: delayed
1925 Allocation size for session structure and workspace. The workspace
1927 is primarily used for TCP connection addresses. If larger than 4k, use
1928 a multiple of 4k for VM efficiency.
1929 workspace_thread
1931 • Units: bytes
1932 • Default: 2k
1934 • Minimum: 0.25k
1936 • Maximum: 8k
1938 • Flags: delayed
1940 Bytes of auxiliary workspace per thread. This workspace is used for
1942 certain temporary data structures during the operation of a worker
1943 thread. One use is for the IO-vectors used during delivery. Setting
1944 this parameter too low may increase the number of writev() syscalls,
1945 setting it too high just wastes space. ~0.1k + UIO_MAXIOV *
1946 sizeof(struct iovec) (typically = ~16k for 64bit) is considered the
1947 maximum sensible value under any known circumstances (excluding exotic
1948 vmod use).
1949
1951 Varnish and bundled tools will, in most cases, exit with one of the
1952 following codes
1953 • 0 OK
1955 • 1 Some error which could be system-dependent and/or transient
1957 • 2 Serious configuration / parameter error - retrying with the same
1959 configuration / parameters is most likely useless
1960 The varnishd master process may also OR its exit code
1962 • with 0x20 when the varnishd child process died,
1964 • with 0x40 when the varnishd child process was terminated by a signal
1966 and
1967 • with 0x80 when a core was dumped.
1969
1971 • varnishlog(1)
1972 • varnishhist(1)
1974 • varnishncsa(1)
1976 • varnishstat(1)
1978 • varnishtop(1)
1980 • varnish-cli(7)
1982 • vcl(7)
1984
1986 The varnishd daemon was developed by Poul-Henning Kamp in cooperation
1987 with Verdens Gang AS and Varnish Software.
1988 This manual page was written by Dag-Erling Smørgrav with updates by
1990 Stig Sandbeck Mathisen <ssm@debian.org>, Nils Goroll and others.
1991
1993 This document is licensed under the same licence as Varnish itself. See
1994 LICENCE for details.
1995 • Copyright (c) 2007-2015 Varnish Software AS
1997 VARNISHD(1)