Hello Willy, thank you very much for your response and please excuse my very late reply! 🙁
On Aug 23, 2022 at 20:08, Willy Tarreau wrote: It makes me think that something is wrong with the date, though I can't imagine what. Is it entirely reproducible or does it happen spuriously ? I'm wondering if it could be a memory corruption for example. Could you please share the output of "show info" ? (beware there's the host name there that you might want to delete if it's sensitive to you). Maybe we'll find something weird there. The hardware has ECC (AMD Epyc) and no warnings/ errors logged. Haproxy is run in a qemu VM. I double checked the date/time of the VM and it's correct. It's automatically synced by systemd. No other vms/ applications have any issues, so I don't think the hardware is faulty. Just thinking, would it be possible that you first started with a very high expiration value (by accident) and that you then adjusted the config and reloaded ? From what I remember, the time left is preserved in exchanges between peers, so having, say, a 24 days value, then a reconfig to 24 hours and a reload would preserve the 24 days one (arguably we should enforce the new limit), but that's definitely something that would make sense to me. We are not using peers, it's a single instance. But I indeed did a lof of configuration changes and reloaded haproxy using signal HUP many times. However I don't remember all the changes I did, so I can't tell for sure if I also changed the expiration times between reloads. The good news is, that after restarting (and not only reloading) haproxy, the issue seems to be gone. However, performing a reload of haproxy without any configuration changes seems to make the issue of unrealistic/too high http_req_rate values appear again. Using show table I can see more and more http_req_rate values going up over time. Please note I also upgraded to 2.6.5-987a4e2. Kind regards Corin
