On Friday, August 24, 2012 2:31:22 PM UTC-7, Jeremy Evans wrote:
>
> On Friday, August 24, 2012 9:22:31 AM UTC-7, Ravi wrote:
>>
>> On Thursday, August 23, 2012 8:34:50 PM UTC-7, Jeremy Evans wrote:
>>
>>> With that configuration, you'll get an error if a thread waits more than
>>> 30 seconds and still cannot acquire a connection.
>>>
>>
>> The default setting is 5sec. So increasing to 30 may reduce the timeout
>> issue.
>>
>
> Correct. Assuming your threads can wait 30 seconds for a connection, it
> may be an OK fix.
>
>>
>> You might want to increase the sleep time, as otherwise you can end up
>>> with a lot of threads waking up, seeing there are no available connections,
>>> and going back to sleep.
>>>
>> This might increase the overall throughput time.
>>
>
> Key word being "might". It depends on the current bottleneck. If you are
> also bottlenecked on the CPU, then increasing pool_sleep_time may decrease
> running time in certain situations.
>
>
>> Also the way Sequel's connection pools currently work, threads are not
>>> serviced in order of request. So you can end up with a situation like this:
>>>
>>> 1) thread A requests a connection from the pool, none in pool, so
>>> sleeps for sleep time
>>> 2) thread B returns a connection to the pool
>>> 3) thread B requests a connection from the pool, gets the one it just
>>> returned
>>> 4) go to 1)
>>>
>>> This is obviously a non-optimal situation, but it's not a major issue as
>>> in general practice you should make sure your connection pool is large
>>> enough that threads are rarely if ever waiting for connections.
>>>
>>> I'd be open to fixing this so that thread A gets the connection
>>> immediately when thread B checks it in, but it requires a Queue class where
>>> Queue#pop accepts a timeout. Currently, ruby's Queue class only takes a
>>> single non-block flag, so it isn't suitable.
>>>
>>
>> There is an option called :connection_handling in
>> Sequel::ThreadedPoolConnection class. Changing that to :queue can also the
>> issue you are talking about, default is :stack.
>> I have not used that though, still need to figure out if I can set at the
>> time of connection, Sequl.connect(......., :connection_handling=>:queue).
>>
>
> :connection_handling=>:queue can reduce the risk of connection staleness,
> but will not affect thread fairness in the example I used above.
>
> Thats true.
I think increasing the number of max_connection solved the isseue. I did
not see any more "Too many connections" errors since past three days.
Few more question: When I open a connection to db, does the connection
close automatically. How the connection is handled by Sequel and what is
its scope?
eg:
I have a following class dbConnect to connect to db:
class dbConnect
def initialize
@db = Sequel.connect("myswl:...", :max_connection=>3,
:pool_sleep_time=>0.01, :pool_timeout=>30)
end
def execute_query
#perform some query here
end
end
Can I define a function to close this particular (@db) connection or it
will be handled by Sequel??
Now, in another file:
def db_perform
db = dbConnect.new
db.exec_query
end
db_perform
Scope of this connection? Does the db connection automatically close at the
end of the above function (db_perform)?
> Jeremy
>
--
You received this message because you are subscribed to the Google Groups
"sequel-talk" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/sequel-talk/-/U0WrMLRohdwJ.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sequel-talk?hl=en.
