Symantec Engineering has identified that certain topologies and traffic profiles that memory utilization increases and will not decrease, leading to a situation in which there is no more memory available. This causes an out of memory condition which may lead to services being restarted as well as a possible lock up or reboot of the appliance. Due to the nature of this issue it will most likely cause a disruption in services.
The architectural differences in memory management on the SSLv 3.x and SSLv 4.x are large. In the SSLv 3.x we allowed ssldata to take as much memory as needed, believing as processes no longer needed the memory it would be reclaimed by Linux. This structure, as we see now, has some pitfalls. We can get to a point where so much memory is required to process traffic that the appliance eventually utilizes all its resources, not leaving enough for the appliance to actually run and manage itself.
In SSLv 4.x architecture, we have pre-allocated memory with a hard limit. Therefore the SSLv does not get into a situation in which is starves it processes of memory while trying to pass and decrypt traffic. Due to the nature of the differences in the code versions, this change cannot be implemented within the SSLv 3.x branch of code.
Upgrade to the current SSLV 4.x version of code where the issue has been addressed. SSLV 4.x code has a different architecture with significant differences in the way traffic is handled and memory is managed. Under certain conditions users will be directed to upgrade to the SSLV 4.x branch of code instead of using the SSLV 3.x code.
As an intermediary workaround, before upgrade, a scheduled reboot of the box will clear the high memory usage temporarily. With this work around the memory will once again be maximized over time until upgrade.