On Thursday, February 21, 2013 9:30:11 AM UTC-8, Tom Demeyer wrote: > > Not neccessarily (or even likely to be) a sequel issue, but your combined > experience may be able to point me in the right direction.. > We're writing an api based on nginx, passenger, postgres, sinatra and > sequel. > Everything runs fine with single requests, but as soon as I hit it with a > buch of simultaneous requests ruby rack processes start to hit 100% cpu and > hang. > Running strace against these shows a continuous loop on 'close' with a bad > file descriptor error. > A GDB stacktrace (with ruby-gdb, pusewicz) seems to suggest that this > happens somewhere in the sequel postgres adapter. > Setting the passenger_max_pool_size to 1 resolves the issue, but this is > of course not the solution.. > This has me miffed for a couple of days now, not getting anywhere. > Any ideas?? Postgres configuration? Setting Sinatra :lock doesn't do > anything to help. > > Most likely you are not calling Database#disconnect before forking, so child processes are sharing the same database sockets. That would explain why it works fine with passenger_max_pool_size = 1.
Thanks, Jeremy -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sequel-talk?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
