Hmm. My zeneventserver is greedy but nothing like that greedy. However, it is the only part of Zenoss that is written in java rather than python.....
Have you checked for a bad transform in the Event Console? Set a filter on the summary field of "transform".
Try the toolbox tools but they only check the Zenoss Database (ZODB) not the zep events database and I think your issue is with events - unless you have a transform that is possibly querying the ZODB for attributes of a device and that object is broken?? Just possible but unlikely.
Do you have my "Event Management for Zenoss Core 4" paper - https://www.skills-1st.co.uk/papers/jane/zenoss4-events/
Chapter 8 is on Testing & Debugging and provides a little help with trying to test transforms. Basically, if you run the zeneventd daemon in debug mode then everything is in the zeneventd.log but it is exceedingly verbose. I have really only succeeded with this technique when I get get the system down to only producing the one or two events I am interested in - setting virtually all of your devices temporarily to Decommissioned Production Status can help.
Before you do that, have you checked your rabbit queues? The events subsystem is a pipeline where the events initially entering the system are in the zep.rawevents queue. If that has more than zero events then the pipeline is blocked and is often a bad rule or transform. As the zenoss user, try:
[zenoss@zen42 HttpMonitor]$ rabbitmqctl -p /zenoss list_queues
Listing queues ...
The zenevents queue takes processed events from zeneventd to zeneventserver which then saves events in the zep database, makes them available to the Event Console GUI and uses the signal queue to send events to zenactiond which drives triggers and notifications, so you might also check the log for zenactiond to see if there is anything nasty going on there that is blocking your pipeline. More info on this architecture in chapter 2 of the paper.
Hope some of that help,