Squid configuration directive shared_memory_locking

Available in: 4  

History:

Changes to shared_memory_locking in Squid-4:

New directive to ensure shared memory is all available immediately on startup. Protects against SIGBUS errors, but delays startup.

This directive is not available in the 3.5 version of Squid.

For older versions than 3.3 see the linked pages above

Configuration Details:

Option Name:shared_memory_locking
Replaces:
Requires:
Default Value:shared_memory_locking off
Suggested Config:

	Whether to ensure that all required shared memory is available by
	"locking" that shared memory into RAM when Squid starts. The
	alternative is faster startup time followed by slightly slower
	performance and, if not enough RAM is actually available during
	runtime, mysterious crashes.

	SMP Squid uses many shared memory segments. These segments are
	brought into Squid memory space using an mmap(2) system call. During
	Squid startup, the mmap() call often succeeds regardless of whether
	the system has enough RAM. In general, Squid cannot tell whether the
	kernel applies this "optimistic" memory allocation policy (but
	popular modern kernels usually use it).

	Later, if Squid attempts to actually access the mapped memory
	regions beyond what the kernel is willing to allocate, the
	"optimistic" kernel simply kills Squid kid with a SIGBUS signal.
	Some of the memory limits enforced by the kernel are currently
	poorly understood: We do not know how to detect and check them. This
	option ensures that the mapped memory will be available. 

	This option may have a positive performance side-effect: Locking
	memory at start avoids runtime paging I/O. Paging slows Squid down.

	Locking memory may require a large enough RLIMIT_MEMLOCK OS limit,
	CAP_IPC_LOCK capability, or equivalent.

 

Back

 

Introduction

Documentation

Support

Miscellaneous

Web Site Translations

Mirrors