My thin server is timing out after 30 seconds. I would like to override this ruby file.
DEFAULT_TIMEOUT from 30 seconds to 120 seconds. how to do it? Please let me know.
code is here:
https://github.com/macournoyer/thin/blob/master/lib/thin/server.rb
I would like to override without "already initialized constant" Warnings.
See the help
➜ ~/app ✓ thin --help | grep timeout
-t, --timeout SEC Request or command timeout in sec (default: 30)
So you can change it from the command line when starting the server
➜ ~/app ✓ thin --timeout 60 start
or you can set a config file somewhere like /etc/thin/your_app.yml with something like this
---
timeout: 60
and then run thin, pointing it at this YAML file with
thin -C /etc/thin/your_app.yml start
As a side note, you should consider if increasing your timeout is really necessary. Typically long running requests should be queued up and run later through a service like delayed_job or resque
After seeing your comment and learning you're using Heroku, I suggest you read the documentation
Occasionally a web request may hang or take an excessive amount of time to process by your application. When this happens the router will terminate the request if it takes longer than 30 seconds to complete. The timeout countdown begins when the request leaves the router. The request must then be processed in the dyno by your application, and then a response delivered back to the router within 30 seconds to avoid the timeout.
I even more strongly suggest looking into delayed_job, resque, or similar if you're using Heroku. You will have at least one worker running to handle the queue. HireFire is an excellent service to save you money by only spinning up workers when your queue actually has jobs to process.
Related
I use a gem called whenever to manage my cron jobs.
In cronfile, I have every 1 minute cron job which call a task XXXX. My config/schedule.rb is like this：
every '* * * * *' do
rake "XXXXXXXX"
end
This cron job is working fine with make slight delay. Task XXXX starts to run its first line a few seconds after process is created. Since this task finishes in less than 1 minute, I should never have multiple processes at the same time.
However, the server is heavily loaded, this delay will become a few minutes.
This leads that many undone processes remain in my process list beacause cron job creates a process every minute.
This will cause the server to become heavier, if worst comes to worst, the server is completely dead.
why does it happen? How can I prevent cronjob from to delay calling a task?
you can add a dependent task to check whether the server is running or not, fail fast (a.k.a. fail early), for example i want to verify that my rails server is already started on port 3000 before call the rake :test
# Rakefile
task :check_localhost do
pid = system("lsof -i tcp:3000 -t")
fail unless pid # or you can use `abort('message')`
end
task :test => :check_localhost do
puts "****** THIS IS TEST ******"
end
I've recently switch from unicorn to puma.
As expected, the performances are better !
However, there is something happening that I dont understand.
All the time, my API is handling thing well for the 95 percentile and below.
But, for no apparent reason, from time to time, I've got some strange Timeout from heroku on the 99 percentile (over 30seconds of waiting time)
Here in the screenshot, the big rectangles are timeout on the 99th percentile...
So I've check me log reader, and some random routes are randomly in timeout, so this is not a question of API performance.
Also !
I have the rack timeout gem
with the following configuration :
# config/initializers/rack_timeout.rb
Rack::Timeout.service_timeout = 25 # seconds
but the timeout are never raised here, only in H12 on heroku (so after 30sec)
This happens from the moment I started using Puma
Any idea ?
API configuration :
ruby 2.5.1
rails 5.1.4
PUMA configuration
gem version 3.11.4
3 workers
5 threads
preload_app!
I need to send email notifications if sidekiq crashes or stops at anytime and also can i send notification when sidekiq start.
It will be really helpful for me if i get notification email.
I use monit for this. You'll need to run sidekiq as a service first, see init script example here: https://github.com/mperham/sidekiq/blob/master/examples/sidekiq
A sample monit file for tracking the process would be:
check process sidekiq with pidfile /home/deployer/my_app/current/tmp/pids/sidekiq.pid
start program = "/etc/init.d/sidekiq start"
stop program = "/etc/init.d/sidekiq stop"
if totalmem is greater than 800 MB for 2 cycles then restart
if 5 restarts within 5 cycles then timeout
You may use airbrake gem.
for more detail about airbrake gem click here: https://github.com/airbrake/airbrake
and airbrake: https://airbrake.io/
I'm using sidekiq in my Rails App to asynchronously execute a stored procedure in my SQL Server database when the user moves from one specific page to another.
The problem is that the stored procedure takes up to 4 minutes to complete and sidekiq returns a timeout message (and then retry).
I don't want to change my application's global database timeout setting in database.yml (I don't even know if it would resolve, but I can't do that).
Is there any way to tell sidekiq that my method can take long and then stop getting timeout errors?
I really appreciate any help.
UPDATE #1
2013-06-03T17:14:18Z 6136 TID-1ac4ik GeneratePropertyProfile JID-de571df94f21b9159c74db6b INFO: start
2013-06-03T17:19:03Z 6136 TID-1ac4ik GeneratePropertyProfile JID-de571df94f21b9159c74db6b INFO: fail: 285.218 sec
2013-06-03T17:19:03Z 6136 TID-1ac4ik WARN: {"retry"=>true, "queue"=>"default", "class"=>"GeneratePropertyProfile", "args"=>[{"id"=>41915658}], "jid"=>"de571df94f21b9159c74db6b", "error_message"=>"TinyTds::Error: Adaptive Server connection timed out: EXEC gaiainc.sp_wait", "error_class"=>"ActiveRecord::StatementInvalid", "failed_at"=>2013-06-03 17:19:03 UTC, "retry_count"=>0}
2013-06-03T17:19:03Z 6136 TID-1ac4ik WARN: TinyTds::Error: Adaptive Server connection timed out: EXEC gaiainc.sp_wait
UPDATE #2
I got it to work without changing my database.yml. However, I had to add the following code in my initializers/sidekiq.rb:
Sidekiq.configure_server do |config|
ActiveRecord::Base.connection.disconnect!
ActiveRecord::Base.configurations[Rails.env]['timeout'] = 300000
ActiveRecord::Base.establish_connection
end
I know it's an ugly solution but I had no time to find another solution to make it work.
If anyone has a cleaner solution, please reply to this topic.
Thank you!
TERM signals that Sidekiq should shut down within the -t timeout option. Any workers that do not finish within the timeout are forcefully terminated and their messages are lost. The timeout defaults to 8 seconds
The Sidekiq TERM timeout is set in config/sidekiq.yml or with the -t parameter. Sidekiq will do its best to exit by this timeout when it receives TERM.
:timeout: 300
I'm using rufus-scheduler to run a process every day from a rails server. For testing purposes, let's say every 5 minutes. My code looks like this:
in config/initializers/task_scheduler.rb
scheduler = Rufus::Scheduler::PlainScheduler.start_new
scheduler.every "10m", :first_in => '30s' do
# Do stuff
end
I've also tried the cron format:
scheduler.cron '50 * * * *' do
# stuff
end
for example, to get the process to run every hour at 50 minutes after the hour.
The infuriating part is that it works on my local machine. The process will run regularly and just work. It's only on my deployed-to-production app that the process will run once, and not repeat.
ps faux reveals that cron is running, passenger is handling the spin-up of the rails process, the site has been pinged again so it knows it should refresh, and production shows the changes in the code. The only thing that's different is that, without a warning or error, the scheduled task doesn't repeat.
Help!
You probably shouldn't run rufus-scheduler in the rails server itself, especially not with a multi-process framework like passenger. Instead, you should run it in a daemon process.
My theory on what's happening:
Passenger starts up a ruby server process and uses it to fork off other servers to handle requests. But since rufus-scheduler runs its jobs in a separate thread from the main thread, the rufus thread is only alive in the original ruby process (ruby's fork only duplicates the thread that does the forking). This might seem like a good thing because it prevents multiple schedulers from running, but... Passenger may kill ruby processes under certain conditions - and if it kills the original, the scheduler thread is gone.
Add the Below lines to your apache2 config /etc/apache2/apach2.conf and restart your apache server
RailsAppSpawnerIdleTime 0
PassengerMinInstances 1
Kelvin is right.
Passenger kills 'unnecessary' threads.
http://groups.google.com/group/rufus-ruby/search?group=rufus-ruby&q=passenger