[squid-users] FATAL: assertion failed: mem/PageStack.cc:159: "StoredNode().is_lock_free()"

[Alex Rousskov]

On 2024-06-28 01:38, Nishant Sharma wrote:
> On 27/06/24 23:06, Alex Rousskov wrote:
>> and how your traffic tickles them, SMP Squid without atomic locks 
>> might become very slow! We do not (and, IMO, should not) optimize 
>> performance for environments without lock-free atomics!
>>
>> I see the following options for going forward:
>>
>> * Comment out the assertion, void your warranty, and hope for the best.
>> * Audit relevant code to confirm that the assertion is safe to remove.
>> * Find a usable OS/environment that has lock-free 64-bit atomics.
> 
> I am not a developer, so it will take me some help to get the code and 
> repercussions of it's modification understood.
> 
> In our use case, we do not use caching at all except a small in-memory 
> cache of say 64MB.
> 
> Squid is used for access control with external acl helper and SSL Bump 
> where SMP used to help with version 4.x.
> 
> Would it be catastrophic to comment out the assertion and then remove 
> relevant code for such a use case where there is no disk cache available 
> for probable corruption?

I do not know the answer to your question. SMP performance penalties are 
often smaller for smaller cache sizes, but cache size is not the only 
performance-affecting locking-sensitive parameter, so YMMV.


 > ... and then remove relevant code ...

Just to avoid a misunderstanding: Other than commenting out the 
assertion line, no code removal is suggested in my bulleted list quoted 
above. The first bullet is a speculative "remove the assertion and see 
what happens" experiment. The second bullet is about reviewing existing 
code (without code modifications) to validate the need for that 
assertion. That audit/validation is required to remove the assertion 
from official Squid sources. That need (and that decision) do not depend 
on cache sizes and other deployment specifics.


HTH,

Alex.