Aviad Pineles

In that post they say that reverting to chart.js version 2.5.0 solves the problem. This is not really a solution since chart.js is now at version 2.8.0...

Thanks, I wanted to say that it happens about 5-6 times a day. Redis recovers from it automatically but it takes about 2 minutes for the recovery during which requests...

There are very long values, they are strings with json values so no particular type. INFO command output: ``` # Server redis_version:5.0.9 redis_git_sha1:9414ab9b redis_git_dirty:0 redis_build_id:25845e7feb545d77 redis_mode:standalone os:Windows arch_bits:64 multiplexing_api:WinSock_IOCP atomicvar_api:pthread-mutex...

Does `client_recent_max_input_buffer:63105320` mean that there was a really long string value set? It is expected from my particular work load though, it is not indicative of a problem.

Hey take a look at this, this is another type of crash we've been having and this looks weird: ``` [7408] 23 Jun 23:04:38.269 * Background saving terminated with success...

Note that in both cases the crash is in `rdbSaveLzfStringObject` I think it sees a bad string prefix, in one case it results in an allocation attempt of too many...

It only ever happens as a result of fork right?

The paging file size on the drive where redis runs is 20GB, system memory is ~195GB... could that be the problem?

Do I need to have the paging file at 390GB then?

Having a bad day, got 3 crashes in 15 minutes now...