Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add AgentRunner and LongRunnable to support long running agents #819

Merged
merged 5 commits into from
Sep 9, 2015

Conversation

dsander
Copy link
Collaborator

@dsander dsander commented May 10, 2015

This changes HuginnScheduler and TwitterStream to use the new AgentRunner

TwitterStream now uses the twitter gem to access the streaming API which removes the eventmachine dependency (in production).

I have been working on this for a while now and it finally seems to reach a point where everything is running smoothly (at least in development).

The AgentRunner is basically an improved threaded.rb. It handles failure of workers and reloads them if the configuration changed.

What is still missing is a way for a LongRunning Agents to receive events. This would, for example, allow the XMPP Agent to stay connected to the server.

@cantino
Copy link
Member

cantino commented May 10, 2015

Very cool!

# periodically propagating and expiring Events. It also running TwitterStreamAgents and Agents that support long running
# background jobs.

Dotenv.load if Rails.env == 'development'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this so you don't have to use foreman?

Rails.env.development? works too

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Foreman, right! I was wondering why I did not have issues like this before. Do you think it's worth keeping? In development I like to start the background worker without foreman to be able to restart them faster.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's totally reasonable to keep, if we can make it work both with and without a Procfile.

@cantino
Copy link
Member

cantino commented May 10, 2015

This seems really good!

If someone wants to run multiple delayed_job processes, how would they do that in this new world?

@dsander
Copy link
Collaborator Author

dsander commented May 10, 2015

Not much compared to the current threaded.rb worker. It should be no problem to spawn addition DJ workers via rake jobs:work

@dsander dsander force-pushed the agent-runner branch 3 times, most recently from 1329177 to 55a3aa5 Compare May 14, 2015 11:42
@dsander dsander changed the title [WIP] Add AgentRunner and LongRunnable to support long running agents Add AgentRunner and LongRunnable to support long running agents May 14, 2015
@dsander
Copy link
Collaborator Author

dsander commented May 14, 2015

I am running this in production now and everything seems fine so far. Had an issue with ActiveRecord::ConnectionTimeoutError exceptions first, that was probably because the HuginnScheduler is now using a global mutex (shared with all threads running). The last commit fixed those issues.

Would be great if some of you could test it in production too. /cc @knu @virtadpt

@virtadpt
Copy link
Collaborator

I'll try to test it on Saturday morning, I'm swamped at work right now.

@cantino
Copy link
Member

cantino commented May 17, 2015

I'll merge this into my personal Huginn and see how it goes as well.

@cantino
Copy link
Member

cantino commented May 18, 2015

Hey @dsander, I deployed it and my twitter streaming agents stopped working:

Restarting 981...(key and a list of the terms I track)
Exception :
/home/huginn/app/shared/bundle/ruby/2.1.0/gems/twitter-5.14.0/lib/twitter/streaming/response.rb:21:in `on_headers_complete'
/home/huginn/app/shared/bundle/ruby/2.1.0/gems/twitter-5.14.0/lib/twitter/streaming/response.rb:16:in `<<'
/home/huginn/app/shared/bundle/ruby/2.1.0/gems/twitter-5.14.0/lib/twitter/streaming/response.rb:16:in `<<'
/home/huginn/app/shared/bundle/ruby/2.1.0/gems/twitter-5.14.0/lib/twitter/streaming/connection.rb:22:in `stream'
/home/huginn/app/shared/bundle/ruby/2.1.0/gems/twitter-5.14.0/lib/twitter/streaming/client.rb:118:in `request'
/home/huginn/app/shared/bundle/ruby/2.1.0/gems/twitter-5.14.0/lib/twitter/streaming/client.rb:37:in `filter'
/home/huginn/app/releases/20150518000152/app/models/agents/twitter_stream_agent.rb:187:in `stream!'
/home/huginn/app/releases/20150518000152/app/models/agents/twitter_stream_agent.rb:161:in `run'
/home/huginn/app/releases/20150518000152/app/concerns/long_runnable.rb:37:in `block in run!'

@dsander
Copy link
Collaborator Author

dsander commented May 18, 2015

@cantino Thanks for testing it! It the twitter agent seems to have raised an exception which I did not expect to happen. I changed the twitter exception code handling to show the exception class (all the information it exposes).

Do you have any special filters? To be honest I just tested it with two TwitterStreamAgents which use the same oauth_token each having one filter

@dsander
Copy link
Collaborator Author

dsander commented May 21, 2015

Wow, this is frustrating. It turns out the twitter gem is not properly escaping the query string as per twiters rules. That is why @cantino was getting 401 errors when an @ was included in the filters.

While working on a fix for the twitter gem I discovered the http.rb gem seems to unescape the query string, which feels like a really stupid thing to do.

I will open an issue for the twitter gem to see what the maintainers think about this, but I guess the only solution for us right now is to revert to twitter-stream 😞

@cantino
Copy link
Member

cantino commented May 22, 2015

Wow, that's pretty bad. However, I'm okay if we deploy this. I don't really need the @ sign.

@cantino
Copy link
Member

cantino commented May 22, 2015

I can deploy it again to my system soon and try it without the @.

@dsander
Copy link
Collaborator Author

dsander commented May 22, 2015

Actually we are requiring the http.rb version which normalizes the uri. To fix it, the http.rb would need support to pass the characters which should left encoded to adressable, and then the new release needs to be included in the twitter. So nothing that is going to happen soon.
I am going to revert the TwitterStreamAgent to twitter-stream over the weekend, at least we know that gem works 😄

@dsander dsander force-pushed the agent-runner branch 4 times, most recently from cbbf7a6 to bc786f2 Compare May 24, 2015 19:55
@dsander
Copy link
Collaborator Author

dsander commented May 24, 2015

The specs are passing again and I squashed and reordered the commits. Hopefully everything is working now 😄 The JabberAgent has been performing very well for me (I use it in a HipChat room to grab URLs and post the facebook opengraph summary of articles, HipChat used to have a integration which did this but it was removed due to "legal concerns")

I am testing the TwitterStreamAgent in production now.

@dsander dsander force-pushed the agent-runner branch 2 times, most recently from 5778b01 to c7caee0 Compare May 25, 2015 08:13
@coveralls
Copy link

Coverage Status

Coverage increased (+0.58%) to 89.24% when pulling c7caee0 on dsander:agent-runner into 562f95a on cantino:master.


muc.join(agent.interpolated['jabber_receiver'])

while @client.is_connected? do sleep 1; end
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can this be this?

sleep 1 while @client.is_connected?

@cantino
Copy link
Member

cantino commented Sep 7, 2015

If we don't hear anything in a day or so, let's merge it!

On Monday, September 7, 2015, Dominik Sander notifications@github.com
wrote:

@cantino https://github.com/cantino Yes it does, it is surprising how
many websites provide opengraph meta tags [image: 😄]


Reply to this email directly or view it on GitHub
#819 (comment).

@dsander
Copy link
Collaborator Author

dsander commented Sep 9, 2015

Merged! @cantino Thanks for the reviews and testing! It required more work then I expected 😄

dsander added a commit that referenced this pull request Sep 9, 2015
Add AgentRunner and LongRunnable to support long running agents
@dsander dsander merged commit 06b022f into huginn:master Sep 9, 2015
@cantino
Copy link
Member

cantino commented Sep 9, 2015

Nice!

@cantino
Copy link
Member

cantino commented Sep 11, 2015

I had my Twitter stream stop again 3 days ago, unfortunately. It was on the pre-merged version of this PR. I just updated to master and added some logging to see if I can debug if it happens again.

@dsander
Copy link
Collaborator Author

dsander commented Sep 11, 2015

That is annoying, i suppose you did not get an exception?

@cantino
Copy link
Member

cantino commented Sep 11, 2015

I was having trouble finding the right point in the logs, so I've added timestamps to the output and will keep an eye on it.

@cantino
Copy link
Member

cantino commented Sep 19, 2015

So far, so good.

@cantino
Copy link
Member

cantino commented Oct 1, 2015

@dsander, unfortunately my Twitter streams stopped working on the 21st. There are no errors in the jobs log, but the production.log shows this around the same time:

E, [2015-09-25T08:25:39.577907 #3350] ERROR -- : 2015-09-25T08:25:39-0700: [Worker(host:li260-181 pid:3350)] Job ActiveJob::QueueAdapters::DelayedJobAdapter::JobWrapper (id=1262926) FAILED (0 prior attempts) with Twitter::Error: execution expired
I, [2015-09-25T08:25:39.586234 #3350]  INFO -- : 2015-09-25T08:25:39-0700: [Worker(host:li260-181 pid:3350)] Job Agent.run_schedule (id=1262927) RUNNING

Any ideas?

@dsander
Copy link
Collaborator Author

dsander commented Oct 1, 2015

That sucks, judging from the log It looks like the run_schedule job is hanging somehow. Can you try to use the separate background worker processes to see which of the stops working?

@cantino
Copy link
Member

cantino commented Oct 2, 2015

Seemed like it might be just twitter since I was still seeing scheduled event propagation working? I think twitter is the only long runnable I use.

@cantino
Copy link
Member

cantino commented Oct 2, 2015

@dsander, what is the separate background worker configuration you recommend? What's frustrating is that I can't reproduce this symptom without waiting a week or so, then twitter events just stop being created.

@dsander
Copy link
Collaborator Author

dsander commented Oct 2, 2015

I mean the old Procfile configuration, I wonder if the same happens when the TwitterStreamAgent is running in its own process.

@cantino
Copy link
Member

cantino commented Oct 2, 2015

I can try this. Also seeing if my Event JSON resue code helps. Is there
anywhere we should add logging to capture info since it takes so long to
repro?

On Thursday, October 1, 2015, Dominik Sander notifications@github.com
wrote:

I mean the old Procfile configuration
https://github.com/cantino/huginn/blob/master/Procfile#L27-L31, I
wonder if the same happens when the TwitterStreamAgent is running in its
own process.


Reply to this email directly or view it on GitHub
#819 (comment).

@dsander
Copy link
Collaborator Author

dsander commented Oct 3, 2015

Maybe around run_schedule in the scheduler and the agent model?

I am also wondering which log file did you post earlier? I switched to runit recently and do not seem to get log entries for ActiveJob anywhere.

@cantino
Copy link
Member

cantino commented Oct 3, 2015

I posted upstart, but see also adding Delayed::Worker.logger = Rails.logger to the delayed_job initializer as in #1057.

@cantino
Copy link
Member

cantino commented Oct 7, 2015

Okay, so everything crashed again last night after working for a day or two. First I got

Twitter error: ActiveRecord::StatementInvalid: Mysql2::Error: This connection is still waiting for a result, try again once you have the result:
 ROLLBACK

then a series like

 --> Twitter error: ActiveRecord::StatementInvalid: Mysql2::Error: This connection is in use by: #<Thread:0xf2cb2d14 sleep>: SELECT  `agents`.* FROM `agents` WHERE `agents`.`id` = 12 LIMIT 1

about 5 times

then

Agent#9: Agents::TwitterStreamAgent-9-ad7a059ed25bd3ad993dfa836be45e5a966f453c Exception Could not parse data entirely (0 != 201):
/home/huginn/app/shared/bundle/ruby/2.1.0/bundler/gems/twitter-stream-f7e7edb0bae0/lib/twitter/json_stream.rb:128:in `<<'
/home/huginn/app/shared/bundle/ruby/2.1.0/bundler/gems/twitter-stream-f7e7edb0bae0/lib/twitter/json_stream.rb:128:in `receive_data'
/home/huginn/app/shared/bundle/ruby/2.1.0/gems/eventmachine-1.0.8/lib/eventmachine.rb:193:in `run_machine'
/home/huginn/app/shared/bundle/ruby/2.1.0/gems/eventmachine-1.0.8/lib/eventmachine.rb:193:in `run'
/home/huginn/app/releases/20151004211024/app/models/agents/twitter_stream_agent.rb:169:in `run'
/home/huginn/app/releases/20151004211024/app/concerns/long_runnable.rb:69:in `block in run!'
Restarting Agents::TwitterStreamAgent-9-ad7a059ed25bd3ad993dfa836be45e5a966f453c

a few times

then the following just repeats indefinitely

Agent#28: Exception during check. Mysql2::Error: Lock wait timeout exceeded; try restarting transaction: UPDATE `agents` SET `events_count` = COALESCE(`events_count`, 0) + 1 WHERE `agents`.`id` = 28: /home/huginn/app/shared/bundle/ruby/2.1.0/gems/activerecord-4.2.4/lib/active_record/connection_adapters/abstract_mysql_adapter.rb:305:in `query'
...
/home/huginn/app/shared/bundle/ruby/2.1.0/gems/activerecord-4.2.4/lib/active_record/transactions.rb:348:in `with_transaction_returning_status'
/home/huginn/app/shared/bundle/ruby/2.1.0/gems/activerecord-4.2.4/lib/active_record/transactions.rb:291:in `save!'
/home/huginn/app/releases/20151004211024/app/models/agent.rb:119:in `create_event'
/home/huginn/app/releases/20151004211024/app/concerns/dry_runnable.rb:75:in `create_event'
/home/huginn/app/releases/20151004211024/app/models/agents/twitter_stream_agent.rb:99:in `block in check'
/home/huginn/app/releases/20151004211024/app/models/agents/twitter_stream_agent.rb:98:in `each'
/home/huginn/app/releases/20151004211024/app/models/agents/twitter_stream_agent.rb:98:in `check'
/home/huginn/app/releases/20151004211024/app/jobs/agent_check_job.rb:7:in `perform'

I don't think the server has run out of RAM. Any ideas?

Do you think we should revert this PR?

@dsander
Copy link
Collaborator Author

dsander commented Oct 7, 2015

Okay, so everything crashed again last night after working for a day or two. First I got

Do you have a backtrace for the first one? It looks like the other issues are related to the first exception. Is it possible similar to this issue reported on the mysql2 gem? We are running a pretty old version of it 0.3.16 when the most recent one is 0.4.1, might it be worth updating?

Do you think we should revert this PR?

If we cant resolve the issue we might have to, I will try to set up a instance using mysql myself since it seems not to be happening on postgres.

@cantino
Copy link
Member

cantino commented Oct 7, 2015

I'll try updating the mysql2 gem. Here's the backtrace:

--> Twitter error: ActiveRecord::StatementInvalid: Mysql2::Error: This connection is still waiting for a result, try again once you have the result: ROLLBACK
        /home/huginn/app/shared/bundle/ruby/2.1.0/gems/activerecord-4.2.4/lib/active_record/connection_adapters/abstract_mysql_adapter.rb:305:in `query'
        /home/huginn/app/shared/bundle/ruby/2.1.0/gems/activerecord-4.2.4/lib/active_record/connection_adapters/abstract_mysql_adapter.rb:305:in `block in execute'
        /home/huginn/app/shared/bundle/ruby/2.1.0/gems/activerecord-4.2.4/lib/active_record/connection_adapters/abstract_adapter.rb:473:in `block in log'
        /home/huginn/app/shared/bundle/ruby/2.1.0/gems/activesupport-4.2.4/lib/active_support/notifications/instrumenter.rb:20:in `instrument'
        /home/huginn/app/shared/bundle/ruby/2.1.0/gems/activerecord-4.2.4/lib/active_record/connection_adapters/abstract_adapter.rb:467:in `log'
        /home/huginn/app/shared/bundle/ruby/2.1.0/gems/activerecord-4.2.4/lib/active_record/connection_adapters/abstract_mysql_adapter.rb:305:in `execute'
        /home/huginn/app/shared/bundle/ruby/2.1.0/gems/activerecord-4.2.4/lib/active_record/connection_adapters/mysql2_adapter.rb:231:in `execute'
        /home/huginn/app/shared/bundle/ruby/2.1.0/gems/activerecord-4.2.4/lib/active_record/connection_adapters/abstract_mysql_adapter.rb:334:in `exec_rollback_db_transaction'
        /home/huginn/app/shared/bundle/ruby/2.1.0/gems/activerecord-4.2.4/lib/active_record/connection_adapters/abstract/database_statements.rb:266:in `rollback_db_transaction'
        /home/huginn/app/shared/bundle/ruby/2.1.0/gems/activerecord-4.2.4/lib/active_record/connection_adapters/abstract/query_cache.rb:14:in `rollback_db_transaction'
        /home/huginn/app/shared/bundle/ruby/2.1.0/gems/activerecord-4.2.4/lib/active_record/connection_adapters/abstract/transaction.rb:145:in `rollback'
        /home/huginn/app/shared/bundle/ruby/2.1.0/gems/activerecord-4.2.4/lib/active_record/connection_adapters/abstract/transaction.rb:179:in `rollback_transaction'
        /home/huginn/app/shared/bundle/ruby/2.1.0/gems/activerecord-4.2.4/lib/active_record/connection_adapters/abstract/transaction.rb:191:in `ensure in within_new_transaction'
        /home/huginn/app/shared/bundle/ruby/2.1.0/gems/activerecord-4.2.4/lib/active_record/connection_adapters/abstract/transaction.rb:193:in `within_new_transaction'
        /home/huginn/app/shared/bundle/ruby/2.1.0/gems/activerecord-4.2.4/lib/active_record/connection_adapters/abstract/database_statements.rb:213:in `transaction'
        /home/huginn/app/shared/bundle/ruby/2.1.0/gems/activerecord-4.2.4/lib/active_record/transactions.rb:220:in `transaction'
        /home/huginn/app/shared/bundle/ruby/2.1.0/gems/activerecord-4.2.4/lib/active_record/transactions.rb:348:in `with_transaction_returning_status'
        /home/huginn/app/shared/bundle/ruby/2.1.0/gems/activerecord-4.2.4/lib/active_record/transactions.rb:291:in `save!'
        /home/huginn/app/releases/20151004211024/app/concerns/dry_runnable.rb:56:in `save!'
        /home/huginn/app/releases/20151004211024/app/models/agents/twitter_stream_agent.rb:89:in `process_tweet'
        /home/huginn/app/releases/20151004211024/app/models/agents/twitter_stream_agent.rb:238:in `block (3 levels) in handle_status'
        /home/huginn/app/releases/20151004211024/lib/agent_runner.rb:62:in `block in with_connection'
        /home/huginn/app/shared/bundle/ruby/2.1.0/gems/activerecord-4.2.4/lib/active_record/connection_adapters/abstract/connection_pool.rb:292:in `with_connection'
        /home/huginn/app/releases/20151004211024/lib/agent_runner.rb:61:in `with_connection'
        /home/huginn/app/releases/20151004211024/app/models/agents/twitter_stream_agent.rb:237:in `block (2 levels) in handle_status'
        /home/huginn/app/releases/20151004211024/app/models/agents/twitter_stream_agent.rb:235:in `each'
        /home/huginn/app/releases/20151004211024/app/models/agents/twitter_stream_agent.rb:235:in `block in handle_status'
        /home/huginn/app/releases/20151004211024/app/models/agents/twitter_stream_agent.rb:233:in `each'
        /home/huginn/app/releases/20151004211024/app/models/agents/twitter_stream_agent.rb:233:in `handle_status'
        /home/huginn/app/releases/20151004211024/app/models/agents/twitter_stream_agent.rb:171:in `block (2 levels) in run'
        /home/huginn/app/releases/20151004211024/app/models/agents/twitter_stream_agent.rb:198:in `call'
        /home/huginn/app/releases/20151004211024/app/models/agents/twitter_stream_agent.rb:198:in `block in stream!'
        /home/huginn/app/shared/bundle/ruby/2.1.0/bundler/gems/twitter-stream-f7e7edb0bae0/lib/twitter/json_stream.rb:296:in `call'
        /home/huginn/app/shared/bundle/ruby/2.1.0/bundler/gems/twitter-stream-f7e7edb0bae0/lib/twitter/json_stream.rb:296:in `parse_stream_line'
        /home/huginn/app/shared/bundle/ruby/2.1.0/bundler/gems/twitter-stream-f7e7edb0bae0/lib/twitter/json_stream.rb:227:in `block in receive_stream_data'
        /home/huginn/app/shared/bundle/ruby/2.1.0/bundler/gems/twitter-stream-f7e7edb0bae0/lib/twitter/json_stream.rb:226:in `each'
        /home/huginn/app/shared/bundle/ruby/2.1.0/bundler/gems/twitter-stream-f7e7edb0bae0/lib/twitter/json_stream.rb:226:in `receive_stream_data'
        /home/huginn/app/shared/bundle/ruby/2.1.0/bundler/gems/twitter-stream-f7e7edb0bae0/lib/twitter/json_stream.rb:128:in `call'
        /home/huginn/app/shared/bundle/ruby/2.1.0/bundler/gems/twitter-stream-f7e7edb0bae0/lib/twitter/json_stream.rb:128:in `<<'
        /home/huginn/app/shared/bundle/ruby/2.1.0/bundler/gems/twitter-stream-f7e7edb0bae0/lib/twitter/json_stream.rb:128:in `receive_data'
        /home/huginn/app/shared/bundle/ruby/2.1.0/gems/eventmachine-1.0.8/lib/eventmachine.rb:193:in `run_machine'
        /home/huginn/app/shared/bundle/ruby/2.1.0/gems/eventmachine-1.0.8/lib/eventmachine.rb:193:in `run'
        /home/huginn/app/releases/20151004211024/app/models/agents/twitter_stream_agent.rb:169:in `run'
        /home/huginn/app/releases/20151004211024/app/concerns/long_runnable.rb:69:in `block in run!' at 2015-10-06 15:53:44 -0700 <--

@cantino
Copy link
Member

cantino commented Oct 8, 2015

The newest that works with Rails appears to be 0.3.20, so I'm trying that. (See rails/rails#21544)

@dsander dsander deleted the agent-runner branch November 6, 2015 16:07
@cantino
Copy link
Member

cantino commented Nov 11, 2015

Well, it seems like this has been running successfully on my system for
quite a while now. Maybe the event JSON parse rescue fixed it? Have you
run into any issues on your system?

On Wednesday, October 7, 2015, Dominik Sander notifications@github.com
wrote:

Okay, so everything crashed again last night after working for a day or
two. First I got

Do you have a backtrace for the first one? It looks like the other issues
are related to the first exception. Is it possible similar to this issue
brianmario/mysql2#566 reported on the mysql2
gem? We are running a pretty old version of it 0.3.16 when the most
recent one is 0.4.1, might it be worth updating?

Do you think we should revert this PR?

If we cant resolve the issue we might have to, I will try to set up a
instance using mysql myself since it seems not to be happening on postgres.


Reply to this email directly or view it on GitHub
#819 (comment).

@dsander
Copy link
Collaborator Author

dsander commented Nov 11, 2015

On which commit is that rescue? In general it sounds like a good idea to rescue potential errors early, but even when the Agent crashed it should automatically be restarted.

I never had any issues on my main instance (which has more then enough RAM) but saw a few crashes on my DO droplet due to the machine running OOM.

@cantino
Copy link
Member

cantino commented Nov 11, 2015

I was referring to #1049 because I don't know of anything else that has changed.

Also, at least some people aren't seeing memory leaks: https://twitter.com/rem0_o/status/664299186138038273

@dsander
Copy link
Collaborator Author

dsander commented Nov 11, 2015

Right, totally forgot about that one, great that your instance is now running without issues.

If the server has enough memory and restart huginn every few weeks I guess you would never notice a leak. I never found anything that was leaking but the memory usage looks a bit suspicious:

huginn   18212  0.0  0.9 432672 162308 ?       Sl   Nov06   0:03 unicorn master -c config/unicorn.rb
huginn   18222  0.3  2.1 772804 344740 ?       Sl   Nov06  29:28 bin/twitter_stream.rb
huginn   18247  0.2  1.1 842908 190068 ?       Sl   Nov06  15:58 bin/schedule.rb
huginn   18273  0.0  1.2 849360 207260 ?       Sl   Nov06   4:06 bin/agent_runner.rb
huginn   18301  0.4  1.5 666756 251776 ?       Sl   Nov06  32:41 ruby script/delayed_job run

@cantino
Copy link
Member

cantino commented Nov 11, 2015

I thought you did see a leak?

Also in #978 and #1114.

@dsander
Copy link
Collaborator Author

dsander commented Nov 11, 2015

Sorry, yes I saw the allocated object count increase, sometimes even jump nearly by the factor 2, but the heap dumps never revealed the source. It could also be that these object were garbage collected a few ticks later. As far as I understand rubys memory allocation an increase of the RSS is not necessarily cause by a leak, it could also be a spike of allocated objects which are garbage collected later.

@cantino
Copy link
Member

cantino commented Mar 12, 2016

I've recently seen this on other projects as well. It may be a symptom of the generational GC.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants