In the later 2.7 releases we added a feature that enforces time ordering on Mango's tasks. Previously tasks could run in parallel to other tasks of the same type. Data source polls were the exception because they had a special mechanism to 'abort' their polls if they tried to run in parallel to another poll.
In heavily loaded systems, or for tasks that take long time to run Mango will now 'Reject' the any additional task of the same type that tries to run in parallel. Unfortunately due to the limitations of what we can change in minor releases we weren't able to implement all of the tracking so you can't know exactly what task is trying to run in parallel to another instance of itself. In 2.8 we will have a full featured tracking mechanism to help you tune Mango better. For now all you can know is that some task is being run more often than is possible (and it is NOT a data source poll).
I was recently doing some testing on a heavily loaded Mango and found that I could reduce task rejections almost completely for periodic tasks by changing the type of Garbage Collector that the JVM uses. I can see from your system output that you are using around 75% of your memory which would likely force the Garbage collector to work hard to free up memory. When this happens the main execution thread of the JVM will hang momentarily and when it restarts there is the potential for many tasks to run at the same time.
You can add this to your JVM parameters to enable a more suitable collector algorithm:
We already have this available to you in the ext-available directory in the bin directory. To enable this you can make a simlink (ln -s) for this file into the ext-enabled directory. Such that:
/mango/bin/ext-enabled/concurrent-garbage-collector.sh --> /mango/bin/ext-available/concurrent-garbage-collector.sh
Give this a try and let me know if it helps.