Closed JacobDorman closed 7 years ago
Did you find a solution?
Check out this patch which will significantly reduce cache memory usage from layout XML which is what appears to be eating almost your entire cache. https://gist.github.com/colinmollenhour/14ed23d029e5b991a3e31ad1fe0841d4
@JacobDorman @colinmollenhour
Hi guys, did you perhaps managed to solve this issue? Like Jacob, I've went through all materials online in trying to solve it, but with no luck. I used suggested patch, it does prolong the lifetime of the website, however, still at some point it breaks down.
used_memory:28800640
used_memory_human:27.47M
used_memory_rss:46886912
used_memory_peak:1586815696
used_memory_peak_human:1.48G
used_memory_lua:36864
mem_fragmentation_ratio:1.63
mem_allocator:jemalloc-3.6.0
We observe it through the day, it slowly rises up to about 1.5G and then breaks on this line:
602 $this->_redis->exec();
and since it's not part of the try/catch block it kills the whole site.
LMSOTFY: https://stackoverflow.com/a/31600531/187780 😁
Redis is exceeding it's maxmemory which is preventing cache from being cleaned.
Apparently this is intended behaviour:
but this leaves the server in a non-functional state, complaining of cache and indexes being out of date and not able to clean or reindex.
This happens after a large traffic spike. After which most of the admin is inaccessible and the server is swapping memory to disk (possibly causally related?)
Of course there are multiple ways of manually fixing this, however i'm looking for a way to avoid or at least recover from this state. Upgrading the server memory is an obvious choice, but solving the issue seems a better option as the site grows.
free -m (during)
Magento Config
Output from redis-cli INFO ALL
Output From stats.php