-
Notifications
You must be signed in to change notification settings - Fork 301
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
logstorage: Adds option to write logs in gzip format #442
logstorage: Adds option to write logs in gzip format #442
Conversation
Fixed your comments. The optional compile possibility introduces a lot of |
That's something for @michael-methner to decide as I actually do not have any permissions here. Just stumbled upon your PR and was interested in the changes |
Hello @LiquidityC , btw: Have you done performance measurements? Do you have an indication how much cpu performance is affected by turning on the compression? Thank you very much. |
No performance testing done no. I'll have to admit that I didn't check if you had any benchmarking setup in the project. |
I did some very basic monitoring of CPU usage with and without gzip compression enabled (same build, only config change). With gzip enabled the worst case usage stuck solidly at 1.7% when hammering the daemon with 1 message every 1ms (WriteOnMsg strategy). Without compression the cpu usage would fluctuate between 1.0-1.7%. Wild guess is that this fluctuation comes down to I/O buffering when gzip is disabled. But when it's enabled we have a stable cpu (higher) usage consumed by compression and we draw no benefit from I/O buffering done by the OS. This is by no means scientific. It's just me abusing the daemon and monitoring it with In our use case I'm certain we have the cycles to spare. Our concern and the reason for me submitting this change is 'wear leveling' and a reduction in disk usage. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add status so that user could check when build with zip, maybe like:
message(STATUS "WITH_DLT_LOGSTORAGE_CTRL_UDEV = ${WITH_DLT_LOGSTORAGE_CTRL_UDEV}")
message(STATUS "WITH_DLT_LOGSTORAGE_GZIP = ${WITH_DLT_LOGSTORAGE_GZIP}")
...
Squashed the commits. |
Hello all, I have done some raw stress tests from my side: Setup: dlt_logstorage.conf dlt.conf: enable:
Enable $dlt-daemon $ dlt-test-multi-process -m 100000 -p 100 -t 1 -l 1000 -d 10 -g $ dlt-test-stress -123
Starting stress test2...
Starting stress test3...
without gzip: max 1.37%CPU $ dlt-test-stress-user -n 100000 -d 1 -s 10000 Conclusion: Gzip feature is working fine with CPU consumption at an acceptable level |
Hello @LiquidityC I would like to propose my suggestion for code sequential cohesion
Please kindly have a look and leave your comment Thank you so much for your contribution! |
Hello @LiquidityC |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hello,
Could you kindly upload unit test result for this feature?
triggered by: -DWITH_DLT_UNIT_TESTS=ON
Many thanks in advance!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hello,
Please kindly rebase and upload your unit test result onto this review comment.
Thank you in advance!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you, let me check that fail test case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great, thanks for your hard work 💪
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I need to do one more change. I'm forgetting about the compile flags. It will be in shortly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
DltLogStorageFilterConfig::gzlog
doesn't exist if WITH_DLT_LOGSTORAGE_GZIP
isn't enabled.
I safed up most of the tests by ensuring data is cleared in the DltLogStorageConfig before usage since not doing this can cause some awkward bugs.
New commit submitted with this fix. Testresults are confirmed both with and without WITH_DLT_LOGSTORAGE_GZIP
.
Sorry about all the confusion. Lot's of things on my table this week 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great, sooner or not DLT team will need to zero initialize those POD objects in those test suites.
Thank you so much!
Adds functionality to allow storing offline logs in gzipped files instead of standard dlt files.
@lvklevankhanh |
Hello @LiquidityC Many thanks, |
@minminlittleshrimp Understandable. Just to double check. I'll just wait. Apart from possible review comments/changes there is nothing else you require from me. Right? |
Sure, I think we’ve done the best so far. For now please kindly wait for the release. |
Hello @LiquidityC , |
Hi @michael-methner / @LiquidityC |
What size are the |
Compressed log files are around 16 KB. dlt_logstorage.conf file looks like |
I don't think there's anything in the log then. Your sync behavior is set to write when a certain buffer size has been reached. Are you sure the logs have been written when you are checking the file? Perhaps use a more aggressive sync behavior just to confirm that the log is actually being written? I also see that you haven't specified any |
By adding LogAppName and ContextName and removing sync behavior in dlt_logstorage.conf file, decompressed logs are working fine. Thanks for the quick response. |
Hello @tjlingesh There are many options for the filter:
Except for above scenarios, we do not support multi App + multi Ctx at the same time, and at least 1 field (Ecu,app,ctx) must be declared or else no logs will be collected. For the sync behavior, you need to send a sync signal, say: $ dlt-logstorage-ctrl -s Could you please kindly try again with this command for the sync behavior? Regards |
@@ -53,28 +53,30 @@ | |||
|
|||
#include <search.h> | |||
#include <stdbool.h> | |||
#include <zlib.h> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi, quick question regarding zlib use in dlt-deamon. If none of WITH_DLT_LOGSTORAGE_GZIP
, WITH_DLT_COREDUMPHANDLER
, or WITH_DLT_FILETRANSFER
are defined, isn't ZLIB_LIBRARY
undefined? And if so, how does CMake find this header (assuming it's not installed on the system), and how is zlib linked to dlt-daemon?
I'm trying to understand how this project works without zlib installed on the system already (if at all). Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some of this might be obsolete now since this PR is old and AFAIC see there has been some re-writing of logstorage. ZLIB is linked with the daemon in src/daemon/CMakeLists.txt
. Guarded by the variables you mentioned.
If ZLIB is excluded the variable is set to empty string.
Adds functionality to allow storing offline logs in gzipped files instead of standard dlt files.
This change got more invasive then I would have liked. But it can't be helped. Since I'm quite new to the project I wouldn't mind some extra scrutiny.
In particular in regards to the
dlt_logstorage_get_idx_of_log_file()
function which got a major overhaul. Perhaps I'm under-thinking this logic?Currently the setting
GzipCompression=1
is handled as an int. Is this something where we'd like to introduce a boolean settings type? It could still be 0/1 but we can parse it to a boolean instead perhaps? I don't mind putting in some extra work if it helps get this through. We (my company) would really benefit from it.