Skip client tracking eviction test when using I/O threads

valkey-io · Jul 24, 2024 · d21ecc2 · d21ecc2
1 parent 3cca268
commit d21ecc2
Show file tree

Hide file tree

Showing 3 changed files with 65 additions and 59 deletions.
diff --git a/tests/unit/info.tcl b/tests/unit/info.tcl
@@ -309,7 +309,7 @@ start_server {tags {"info" "external:skip"}} {
         }
 
         # skip the following 2 tests if we are running with io-threads as the eventloop metrics are different in that case.
-        if {[r config get io-threads] eq 0} {
+        if {[r config get io-threads] eq "io-threads 1"} {
             test {stats: eventloop metrics} {
                 set info1 [r info stats]
                 set cycle1 [getInfoProperty $info1 eventloop_cycles]

diff --git a/tests/unit/maxmemory.tcl b/tests/unit/maxmemory.tcl
@@ -457,67 +457,73 @@ start_server {tags {"maxmemory external:skip"}} {
 }
 
 start_server {tags {"maxmemory external:skip"}} {
-    test {client tracking don't cause eviction feedback loop} {
-        r config set latency-tracking no
-        r config set maxmemory 0
-        r config set maxmemory-policy allkeys-lru
-        r config set maxmemory-eviction-tenacity 100
 
-        # 10 clients listening on tracking messages
-        set clients {}
-        for {set j 0} {$j < 10} {incr j} {
-            lappend clients [valkey_deferring_client]
-        }
-        foreach rd $clients {
-            $rd HELLO 3
-            $rd read ; # Consume the HELLO reply
-            $rd CLIENT TRACKING on
-            $rd read ; # Consume the CLIENT reply
-        }
-
-        # populate 300 keys, with long key name and short value
-        for {set j 0} {$j < 300} {incr j} {
-            set key $j[string repeat x 1000]
-            r set $key x
-
-            # for each key, enable caching for this key
+    # Skip the following test when running with IO threads
+    # With IO threads, we asynchronously write to tracking clients.
+    # This invalidates the assumption that their output buffers will be free within the same event loop.
+    if {[r config get io-threads] eq "io-threads 1"} {
+        test {client tracking don't cause eviction feedback loop} {
+            r config set latency-tracking no
+            r config set maxmemory 0
+            r config set maxmemory-policy allkeys-lru
+            r config set maxmemory-eviction-tenacity 100
+
+            # 10 clients listening on tracking messages
+            set clients {}
+            for {set j 0} {$j < 10} {incr j} {
+                lappend clients [valkey_deferring_client]
+            }
             foreach rd $clients {
-                $rd get $key
-                $rd read
+                $rd HELLO 3
+                $rd read ; # Consume the HELLO reply
+                $rd CLIENT TRACKING on
+                $rd read ; # Consume the CLIENT reply
             }
+
+            # populate 300 keys, with long key name and short value
+            for {set j 0} {$j < 300} {incr j} {
+                set key $j[string repeat x 1000]
+                r set $key x
+
+                # for each key, enable caching for this key
+                foreach rd $clients {
+                    $rd get $key
+                    $rd read
+                }
+            }
+
+            # we need to wait one second for the client querybuf excess memory to be
+            # trimmed by cron, otherwise the INFO used_memory and CONFIG maxmemory
+            # below (on slow machines) won't be "atomic" and won't trigger eviction.
+            after 1100
+
+            # set the memory limit which will cause a few keys to be evicted
+            # we need to make sure to evict keynames of a total size of more than
+            # 16kb since the (PROTO_REPLY_CHUNK_BYTES), only after that the
+            # invalidation messages have a chance to trigger further eviction.
+            set used [s used_memory]
+            set limit [expr {$used - 40000}]
+            r config set maxmemory $limit
+
+            # make sure some eviction happened
+            set evicted [s evicted_keys]
+            if {$::verbose} { puts "evicted: $evicted" }
+
+            # make sure we didn't drain the database
+            assert_range [r dbsize] 200 300
+
+            assert_range $evicted 10 50
+            foreach rd $clients {
+                $rd read ;# make sure we have some invalidation message waiting
+                $rd close
+            }
+
+            # eviction continues (known problem described in #8069)
+            # for now this test only make sures the eviction loop itself doesn't
+            # have feedback loop
+            set evicted [s evicted_keys]
+            if {$::verbose} { puts "evicted: $evicted" }
         }
-
-        # we need to wait one second for the client querybuf excess memory to be
-        # trimmed by cron, otherwise the INFO used_memory and CONFIG maxmemory
-        # below (on slow machines) won't be "atomic" and won't trigger eviction.
-        after 1100
-
-        # set the memory limit which will cause a few keys to be evicted
-        # we need to make sure to evict keynames of a total size of more than
-        # 16kb since the (PROTO_REPLY_CHUNK_BYTES), only after that the
-        # invalidation messages have a chance to trigger further eviction.
-        set used [s used_memory]
-        set limit [expr {$used - 40000}]
-        r config set maxmemory $limit
-
-        # make sure some eviction happened
-        set evicted [s evicted_keys]
-        if {$::verbose} { puts "evicted: $evicted" }
-
-        # make sure we didn't drain the database
-        assert_range [r dbsize] 200 300
-
-        assert_range $evicted 10 50
-        foreach rd $clients {
-            $rd read ;# make sure we have some invalidation message waiting
-            $rd close
-        }
-
-        # eviction continues (known problem described in #8069)
-        # for now this test only make sures the eviction loop itself doesn't
-        # have feedback loop
-        set evicted [s evicted_keys]
-        if {$::verbose} { puts "evicted: $evicted" }
     }
 }
 

diff --git a/tests/unit/memefficiency.tcl b/tests/unit/memefficiency.tcl
@@ -405,7 +405,7 @@ run_solo {defrag} {
         } {OK}
 
         # Skip the following two tests if we are running with IO threads, as the IO threads allocate the command arguments in a different arena. As a result, fragmentation is not as expected.
-        if {[r config get io-threads] eq 0} {
+        if {[r config get io-threads] eq "io-threads 1"} {
         test "Active defrag pubsub: $type" {
             r flushdb
             r config resetstat