Seem to have a similar issue. Currently running 1.4.5 on RHEL 6.5.
We have 545 hosts and I'm not running and anytrends manually foreman seems ot be running these trends on it's own.
I'm running this in a KVM VM with 6 cores and 16GB RAM ot this point but it's obviously never enough.
I'll be upgrading through 1.5 and 1.6 in the coming days and looking to see if that helps.

Top show this after 'service foreman stop; service httpd stop'
30143 foreman 20 0 8407m 7.9g 6544 D 11.6 50.9 42:44.19 rake

I have to 'kill -9' the rake process as it doesn't die on it's own.

'ps -lef | grep 30143'
/opt/rh/ruby193/root/usr/bin/ruby /opt/rh/ruby193/root/usr/bin/rake trends:clean

Can it be related to the amount of data in the trend_counters table?

We're running into this issue too. I haven't done a ton with ActiveRecord, but the issue are these lines in the trends:clean rake task:

counts = TrendCounter.group([:trend_id, :created_at]).count

dupes = counts.select{ |attrs, count| count > 1}

Rather than doing the aggregation inside the database, the task first executes a very expensive GROUP and then filters the results it needs in plain Ruby.

Again, not an ActiveRecord expert, but I think replacing those two lines with the following should significantly speed it up:

dupes = TrendCounter.having('count(*) > 1').group([:trend_id, :created_at]).count

This translates the SQL from this:

SELECT COUNT(*) AS count_all, trend_id AS trend_id, created_at AS created_at FROM "trend_counters" GROUP BY trend_id, created_at ORDER BY created_at

...to this:

SELECT COUNT(*) AS count_all, trend_id AS trend_id, created_at AS created_at FROM "trend_counters" GROUP BY trend_id, created_at HAVING count(*) > 1 ORDER BY created_at

Huh, I must have misread this issue initially, which is for trends:counter not trends:clean. Oh well, I submitted a PR for the trends:clean issue anyways