On 10/17/19 5:07 PM, Antonio SJ Musumeci wrote: > the option is listed in relation to SMP and not referenced by rock docs. The second paragraph in cache_dir rock directive documentation implies SMP -- it talks about various processes that rock uses to avoid locking (if it can). SMP usage is the primary rock scalability feature. There is more info at https://wiki.squid-cache.org/Features/RockStore (and https://wiki.squid-cache.org/Features/LargeRockStore). > Also it should be possible to check /dev/shm's free space > and compare that against the file size needed. Clearly it knows based on > the requested storage and slot sizes. Even a guess with a warning rather > than leaving it to fail otherwise silently with a SIGBUS. Unfortunately, a simple implementation may produce a lot of false warnings in some environments while a quality implementation may not be as easy as you think: Accessing free space info may require special permissions and correctly accounting for the existing shared memory segments in that partition would be tricky (they can be leftovers from the previous Squid run that will be overwritten or something completely unrelated to Squid). Even finding the right partition name in a portable way may be tricky! IMHO, the future development directions outlined when adding shared_memory_locking are more promising in general, but I would be happy to learn that there are even better options. Cheers, Alex. > On 10/17/2019 2:53 PM, Alex Rousskov wrote: >> On 10/17/19 12:28 PM, Antonio SJ Musumeci wrote: >> >>> After a lot of tinkering and turning on full debug I realized the reason >>> rock was failing for me in my container was due to the small default SHM >>> size allocated by Docker. Increasing the SHM size with `--shm-size` >>> fixed the issue. >>> >>> It'd be significantly more helpful if the Squid reported precisely what >>> the issue and exited gracefully rather than SIGBUS'ing. >> Does enabling shared_memory_locking in squid.conf trigger the behavior >> you want? >> >> If yes, then you may be wondering why this is not the default setting. >> The answer is in the following two squid-dev messages. Message [1] is a >> high-level description. Message [2] contains more low-level details and >> examples of ~60 second startup delays that locking may cause. >> >> [1] >> http://lists.squid-cache.org/pipermail/squid-dev/2016-March/005260.html >> >> [2] >> http://lists.squid-cache.org/pipermail/squid-dev/2015-December/004112.html >> >> >> Enhancing shared memory management (e.g., implementing ideas mentioned >> in the "As we gain more experience" paragraph of [1]) is welcomed. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
