After updating db2 to fix pack 7, the DPF database worked fine, until most of the memory was cached by OS. When free memory got near 2 GB (OS free-uncached memory limit) the db2 slowed down noticeably - response time increased 3-4 times.
What I noticed from the OS side - when the free memory gets close to 2 GB - migration/nn threads start consuming CPU cycles, total system CPU usage and load average increases. We release the cached memory by setting free-uncached memory limit to 10GB and then back to 2 GB (~12 GB of memory gets released from the cache). The system CPU usage and load average decreases instantaneously, db2 response time gets back to normal. However, after few hours the free memory slowly gets cached again by OS - db2 slows down and we are back to were we started.

Currently, we have 4 partitions, 0 - controlled by STMM, 1/2/3 - set to manual values.

There is only one type of error messages in db2diag.log:
MESSAGE : Appl failed to start up on this node with error =
DATA #1 : Hexdump, 4 bytes
0x00007FFFE4FFC3E8 : 48FC FFFF H...

But we had those messages before the fix pack update, all the values, related to agents and applications are set to AUTOMATIC in DB and DBM CFG.

No relevant messages in /var/log/messages file either.

Any idea of what could be happening here?