Conversation
During tests we use loglevel=debug and we have small datasets. Under these conditions, we have a lot of very short active defrag cycles (one every 1ms in extreme cases). Every time a defrag cycles starts and ends it prints some information to the log, which makes the log file very big and the server to work much slower. This commit removes exisiting logs and adds a log message that is printed every 1s, summarizing active-defrag's performance in that second that passed.
🎉 Snyk checks have passed. No issues have been found so far.✅ security/snyk check is complete. No issues have been found. (View Details) ✅ license/snyk check is complete. No issues have been found. (View Details) |
|
@guybe7 Originally, there were three types of logs: start, end, and mid. |
|
@sundb i don't mind changing it to DEBUG and yes, we lose some debugging visibility in exchange for non-flooded logs (for example, we don't have "start" and "end" logs of active-expiry) |
|
When the db doesn't have a lot of data, and is repeatedly running short defrag cycles, these start and stop prints will flood the log. They must be throttled in some way |
|
@guybe7 Is the final conclusion as follows now?
|
|
@sundb yes |
… timer to run twice as fast (#14081) This bug was introduced in [#13814](#13814), and was found by @guybe7. It incorrectly moved the update of `server.cronloops` from `whileBlockedCron()` to `activeDefragTimeProc()`, causing the cron-based timers to effectively run twice as fast when active defrag is enabled. As a result, memory statistics are not updated during blocked operations. The repair parts from #13995, because it needs to be backport, so use a separate pr repair it.
… timer to run twice as fast (redis#14081) This bug was introduced in [redis#13814](redis#13814), and was found by @guybe7. It incorrectly moved the update of `server.cronloops` from `whileBlockedCron()` to `activeDefragTimeProc()`, causing the cron-based timers to effectively run twice as fast when active defrag is enabled. As a result, memory statistics are not updated during blocked operations. The repair parts from redis#13995, because it needs to be backport, so use a separate pr repair it.
… timer to run twice as fast (#14081) This bug was introduced in [#13814](#13814), and was found by @guybe7. It incorrectly moved the update of `server.cronloops` from `whileBlockedCron()` to `activeDefragTimeProc()`, causing the cron-based timers to effectively run twice as fast when active defrag is enabled. As a result, memory statistics are not updated during blocked operations. The repair parts from #13995, because it needs to be backport, so use a separate pr repair it.
During tests, we use loglevel=debug and have small datasets. Under these conditions, we have many very short active defrag cycles (one every 1ms in extreme cases). Every time a defrag cycle starts and ends, it prints some information to the log, which makes the log file very big and the server work much slower.
This commit removes existing logs and adds a log message printed every 1s, summarizing active-defrag's performance in that second that passed.
Other:
Fix run_with_period (used to run every 0.5X instead of every X ms)