Is there a way to get the number of requests that are currently awaiting to be executed by my rails app by unicorn? Or there is no queue in unicorn and I should look for this information somewhere in nginx or other front-end server? Couldn''t find much information about this topic, so decided to ask here first.
Troex Nevelin <list at mrtech.ru> wrote:> Is there a way to get the number of requests that are currently awaiting > to be executed by my rails app by unicorn? > > Or there is no queue in unicorn and I should look for this information > somewhere in nginx or other front-end server?The queue is in the kernel and controlled by the listen(2) syscall. If you''re in Linux, you can inspect this with Raindrops[1] or just read the output of ss(8) or /proc/net/tcp. I don''t know how to do this in non-Linux kernels. All TCP servers actually have this queue, so you can use ss(8), /proc/net/tcp or raindrops to inspect this queue in nginx, too. [1] http://raindrops.bogomips.org/ I''ve found this example surprisingly useful, too: http://raindrops.bogomips.org/examples/linux-tcp-listener-stats.rb -- Eric Wong
On 02/06/2011 10:02 PM, Eric Wong wrote:> [1] http://raindrops.bogomips.org/ > I''ve found this example surprisingly useful, too: > http://raindrops.bogomips.org/examples/linux-tcp-listener-stats.rbThank a lot for this link, I also found a lot of interesting. I''m currently using thin (rails2.3 on ruby1.8), but thinking to try unicorn on next update. I was monitoring nginx and thin using raindrops: Nginx: # ./linux-tcp-listener-stats.rb -d 1 80.93.53.99:80 address active queued 80.93.53.99:80 929 0 80.93.53.99:80 984 0 80.93.53.99:80 978 0 80.93.53.99:80 941 0 Nginx is almost always shows that all sockets are active (~1000) and queued sometimes I can see 1 or 2. As I understand that means that nginx is fast and works well. Thin: # ./linux-tcp-listener-stats.rb -d 1 10.0.0.1:4000 address active queued 10.0.0.1:4000 21 8 10.0.0.1:4000 21 9 10.0.0.1:4000 21 10 10.0.0.1:4000 23 0 10.0.0.1:4000 1 0 10.0.0.1:4000 0 0 10.0.0.1:4000 2 0 What can you say about these numbers? Actually I don''t understand the ''active'' table. As I thought thin or unicorn can serv only one request at a time because ruby/rails works like forks, so what means this ''active''?
Troex Nevelin <list at mrtech.ru> wrote:> On 02/06/2011 10:02 PM, Eric Wong wrote: >> [1] http://raindrops.bogomips.org/ >> I''ve found this example surprisingly useful, too: >> http://raindrops.bogomips.org/examples/linux-tcp-listener-stats.rb > > Thank a lot for this link, I also found a lot of interesting. I''m > currently using thin (rails2.3 on ruby1.8), but thinking to try unicorn > on next update. > I was monitoring nginx and thin using raindrops: > > Nginx: > # ./linux-tcp-listener-stats.rb -d 1 80.93.53.99:80 > address active queued > 80.93.53.99:80 929 0 > 80.93.53.99:80 984 0 > 80.93.53.99:80 978 0 > 80.93.53.99:80 941 0 > > Nginx is almost always shows that all sockets are active (~1000) and > queued sometimes I can see 1 or 2. As I understand that means that nginx > is fast and works well.Yep, nginx does its job very well.> Thin: > # ./linux-tcp-listener-stats.rb -d 1 10.0.0.1:4000 > address active queued > 10.0.0.1:4000 21 8 > 10.0.0.1:4000 21 9 > 10.0.0.1:4000 21 10 > 10.0.0.1:4000 23 0 > 10.0.0.1:4000 1 0 > 10.0.0.1:4000 0 0 > 10.0.0.1:4000 2 0 > > What can you say about these numbers? Actually I don''t understand the > ''active'' table. As I thought thin or unicorn can serv only one request > at a time because ruby/rails works like forks, so what means this > ''active''?Thin can hold multiple connections open in a single process (idle or doing I/O), but only execute the Rack app for one client at a time (unless you''re using the non-standard "app.deferred?" stuff). With Unicorn, you''ll still see multiple active because all the worker processes share the same listener socket, but the active numbers will be smaller and capped at the number of worker processes you have. The queue is likely to be smaller if you''re running multiple workers, too. -- Eric Wong
On 02/12/2011 12:20 AM, Eric Wong wrote:> Thin can hold multiple connections open in a single process (idle or > doing I/O), but only execute the Rack app for one client at a time > (unless you''re using the non-standard "app.deferred?" stuff).No I''m using any deferred stuff, I have delayed_job but this is other story.> With Unicorn, you''ll still see multiple active because all the worker > processes share the same listener socket, but the active numbers > will be smaller and capped at the number of worker processes you have. > The queue is likely to be smaller if you''re running multiple workers, > too.Currently I use thin 10 instances and pass 10 sockets to nginx. I forgot that unicorn uses only one socket to communicate with frontend :) What I really want to track with unicorn is to see how many clients are really waiting in queue. I hope if I ran 10 unicorn instances and monitor socket during peak load I''ll see 10 active and the queue will be the real queue :) As you showed me above that thin can take requests ''on hold'' and that is why I didn''t understand the active number bigger than 1 with thin. I''ll post the results here, when I migrate to unicorn.
On 02/12/2011 06:58 PM, Troex Nevelin wrote:> Currently I use thin 10 instances and pass 10 sockets to nginx. I forgot > that unicorn uses only one socket to communicate with frontend :) > What I really want to track with unicorn is to see how many clients are > really waiting in queue. I hope if I ran 10 unicorn instances and > monitor socket during peak load I''ll see 10 active and the queue will be > the real queue :) > As you showed me above that thin can take requests ''on hold'' and that is > why I didn''t understand the active number bigger than 1 with thin. > > I''ll post the results here, when I migrate to unicorn.We''ve moved to unicorn and I embeded Raindrops as middleware into our rails app, now I''m able to get some stats using /_raindrops url: http://www.kinokopilka.tv/_raindrops calling: 4 writing: 174 /var/www/kk/current/tmp/sockets/unicorn.sock active: 5 /var/www/kk/current/tmp/sockets/unicorn.sock queued: 0 The last 2 lines I undersand, that is what I wanted to get. But what about ''calling'' and ''writing'', what does these numbers says?
Troex Nevelin <list at mrtech.ru> wrote:> We''ve moved to unicorn and I embeded Raindrops as middleware into our > rails app, now I''m able to get some stats using /_raindrops url: > http://www.kinokopilka.tv/_raindrops > > calling: 4This is the number of application dispatchers running. Should always be <= worker_processes.> writing: 174This is the number of clients being written to. Make sure Raindrops::Middleware is at the outermost/topmost layer of your middleware stack (top of config.ru). Some other middlewares may clobber/ignore the #close method. You should probably contact the middleware authors and make sure they properly proxy response bodies that require a close. Normally, (calling + writing) <= Unicorn worker_processes> /var/www/kk/current/tmp/sockets/unicorn.sock active: 5 > /var/www/kk/current/tmp/sockets/unicorn.sock queued: 0 > > The last 2 lines I undersand, that is what I wanted to get. But what > about ''calling'' and ''writing'', what does these numbers says?
Seemingly Similar Threads
- [PATCH] replace fchmod()-based heartbeat with raindrops
- Master repeatedly killing workers due to timeouts
- [PATCH] examples/nginx.conf: add ipv6only comment
- [PATCH] rework master-to-worker signaling to use a pipe
- Rack content-length Rack::Lint::LintErrors errors with unicorn