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. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
