[squid-users] Is this related? store.cc:1094: "store_status == STORE_PENDING" + TCP_MISS_ABORTED

[Alex Rousskov]

On 11/23/21 5:10 AM, Loučanský Lukáš wrote:

> I've noticed that my squid asserted on store.cc line 1094 which I
> read as a test to see if the store is in progress while the transfer
> is being aborted.

I would not describe STORE_PENDING status as "the store is in progress"
because that status covers other StoreEntry states as well. I cannot be
sure without research, but I suspect that the code author was trying to
assert() that the StoreEntry has not been fully written/stored at the
time of the abort() method call. I do not like that assertion, but I
hesitate suggesting specific fixes without understanding the cause of
the problem in your use case.


> Is it possible that the store is too slow 

Yes, of course: Any storage can be too slow, for some definition of "too
slow".


> and is still pending operation while there is request abort?

There is a significant difference between StoreEntry::abort() and a
premature closure of a client-to-Squid connection (i.e. what you
probably mean by "request abort"). That difference aside and roughly
speaking, yes, a client or server may abort the transaction at any time.
And there might be other reasons beyond Squid control for transaction
and StoreEntry aborts.


> This rock storage is 64GB in size, slot size 32kB, max-swap-rate 200,
> swap-timeout 250. fio with randomread shows 587 IOPS (bs 32k, iodepth
> 1), with rwmixread 75 read IOPS 490 write IOPS 167.

If the measured limit is 167 raw writes/s, then I would be concerned
that you are overloading your disks with 200 IOs/s max-swap-rate,
especially if your disk byte hit ratio is low (it usually is). You may
be able to tell whether the disks are overloaded by monitoring their
utilization percentage in "iostats -dx" or similar, especially if you
are using hard drives rather than SSDs.


> Is this related? Can I do anyzhing to avoid such asserts?

I can only repeat my earlier suggestion: File a bug report with "bt
full" backtrace from the assertion and keep the core file around for
analysis. If you can reproduce the assertion at will (e.g., by aborting
long downloads), then please post the reproducing instructions as well.
We can often fix the bugs we can reproduce much faster than other bugs.


HTH,

Alex.