valkey-io/valkey

[test-failure] Active defrag - AOF loading + edge case, 32-bit

Opened this issue · 2 comments

Some of the active defrag test cases are failing, possibly after we merged #1242. @JimB123 can you take a look?

Today, https://github.com/valkey-io/valkey/actions/runs/12170639212/job/33946010031:

*** [err]: Active defrag - AOF loading in tests/unit/memefficiency.tcl
Expected 1.42 < 1.4 (context: type eval line 34 cmd {assert {$frag < 1.4}} proc ::test)
*** [err]: Active defrag edge case: standalone in tests/unit/memefficiency.tcl
Expected 1.19 < 1.1 (context: type eval line 92 cmd {assert {$frag < 1.1}} proc ::start_server)
Cleanup: may take some time... OK

Yesterday, https://github.com/valkey-io/valkey/actions/runs/12150400350/job/33883093665:

*** [err]: Active defrag - AOF loading in tests/unit/memefficiency.tcl
Expected 1.45 < 1.4 (context: type eval line 34 cmd {assert {$frag < 1.4}} proc ::test)
*** [err]: Active defrag edge case: standalone in tests/unit/memefficiency.tcl
Expected 1.18 < 1.1 (context: type eval line 92 cmd {assert {$frag < 1.1}} proc ::start_server)

I'll take a look. Some of the test logic looked a little brittle.

I fixed the first one with AOF. The 2nd one is a little weird. I'm not even completely sure that the test is valid. It seems to be trying to create a scenario where all of the jmalloc slabs have exactly the same fragmentation in an attempt to confuse the defrag process. I'm not sure that it's possible to reliably create this scenario. And even if we can create it, I'm not sure that it tests anything meaningful. @zvi-code can you look at this test also? I'd like a second opinion on this one: https://github.com/valkey-io/valkey/blob/unstable/tests/unit/memefficiency.tcl#L623-L728