Francisco Fernández added a comment - 2018-12-04 09:48 After analysing the issue I've seen that the CPU usage is high even in support-core-2.47 , which is the version previous to anonymization since it's moving huge files. Anonymization implies the process of huge files such as logs. The difference is the process time needed to anonymize those files. That process is performed line per line and applies some filter to each line of each log and file, so the anonymization takes a long time. This heavy process during such a long time makes the instances unresponsive. Where can we touch to improve the performance? InetAddressContentFilter search for any String that is susceptible to be an IP address and create an new mapping object. Although the mapping existed previously, the mapping file is saved all the times by the ContentMappings class and not only when the mapping is a new one. That's a bunch of unnecessary disk accesses on write mode. Both InetAddressContentFilter and SensitiveContentFilter are using the method ContentMapping#filter which executes the Pattern#matcher and therefore compiles the pattern every time the filter is executed. This is a heavy operation and as the filter is executed line per line the process needs a long time to be executed. Since the mapping has already got the replacement String, we can substitute the Pattern objects with StringUtils invocations. As the logs are showing, the filtering is taking place inside the OutputStream ( FilteredOutputStream and FilteredWriter ) objects that are writing the content of the files in the final zip file. It's less expensive (from the PoV of the process time) filter the content previously to write it on the zip file. The more Stream are needed, the more expensive is the performance.