Thank you for letting us know. This will be useful to others.

On Thursday, 25 July 2013 10:28:07 UTC+2, dederocks wrote:
>
> I found the problem!
>
> And the source was (of course) me.
>
> The connexion class was defined as follows:
>
> class Connexion(object):
>
>     rCMD = redis.Redis(host='127.0.0.1')
>                                        
>     def __init__(self):
>         if not self.rCMD.exists('ConsistoPort'):
> (...)
>
>
> Which is wrong, as I have to do:
>
> class Connexion(object):
>
>     rCMD = None
>                                        
>     def __init__(self):
>         self.rCMD = redis.Redis(host='127.0.0.1')        
>         if not self.rCMD.exists('ConsistoPort'):
> (...)
>
>
> I appologize for the noise and at the same time thank for the very 
> constructive feedbacks!
>
> Le jeudi 25 juillet 2013 09:07:14 UTC+2, Paolo Valleri a écrit :
>>
>> I am not a redis expert and I don't know how web2py handles the 
>> interaction with redis, either.
>> However the scenario could be, either you instantiate one or more new 
>> connections for request or 'expired' connections are not closed. 
>> I am for the former case, could you post few lines where redis is 
>> instantiated?
>>
>>  Paolo
>>
>> On Thursday, July 25, 2013 8:48:37 AM UTC+2, dederocks wrote:
>>>
>>> Thank you Paolo for the benchmark!
>>> In my case, I start at 107, and at the end of the process the count is 
>>> at 672!! nginx on the other hand is stable around 55.
>>> And the culprit is (drums ...): redis! The large majority of the files 
>>> opened are the redis port.
>>> Extract from lsof:
>>> uwsgi   2128 www-data  511u  IPv4      62305      0t0     TCP 
>>> localhost:56632->localhost:6379 (ESTABLISHED)
>>> uwsgi   2128 www-data  512u  IPv4      62536      0t0     TCP 
>>> localhost:56661->localhost:6379 (ESTABLISHED)
>>> uwsgi   2128 www-data  513u  IPv4      62361      0t0     TCP 
>>> localhost:56639->localhost:6379 (ESTABLISHED)
>>> uwsgi   2128 www-data  514u  IPv4      62377      0t0     TCP 
>>> localhost:56641->localhost:6379 (ESTABLISHED)
>>> uwsgi   2128 www-data  515u  IPv4      62392      0t0     TCP 
>>> localhost:56643->localhost:6379 (ESTABLISHED)
>>>
>>> Does someone know how to fix this?
>>>
>>> Le jeudi 25 juillet 2013 08:28:08 UTC+2, Paolo Valleri a écrit :
>>>>
>>>> dederocks, I've just tried to run lsof -p <uwsgi pid#> on a ubuntu 
>>>> server running web2py
>>>> In my case, it returns 138 opened files among libraries, sockets and so 
>>>> on; the most opened file is /dev/zero, opened 55 times.  
>>>>
>>>> Paolo
>>>>
>>>> On Thursday, July 25, 2013 8:18:32 AM UTC+2, dederocks wrote:
>>>>>
>>>>> Thanks a lot for the link. Unfortunately it didn't help.
>>>>> @roberto: the uwsgi process is then indeed eating all the CPU - but 
>>>>> I'm not sure it means uwsgi is the culprit, at least at this stage (could 
>>>>> be the case earlier though).
>>>>> Is there in linux a way to know who opened which file and when? lsof 
>>>>> gives only the process, not the time.
>>>>>
>>>>> Le mercredi 24 juillet 2013 23:56:10 UTC+2, Niphlod a écrit :
>>>>>>
>>>>>> it's a problem on the layers "at the base" of web2py, such as the os, 
>>>>>> nginx or uwsgi.
>>>>>> http://www.cyberciti.biz/faq/linux-unix-nginx-too-many-open-files/
>>>>>> let's see if @roberto (the developer behind uwsgi) passes by with 
>>>>>> some useful tips too. 
>>>>>>
>>>>>> On Wednesday, July 24, 2013 4:30:51 PM UTC+2, dederocks wrote:
>>>>>>>
>>>>>>> I'm running web2py on nginx /uwsgi.
>>>>>>> And in a sequence implying frequent serveur calls, I eventually get 
>>>>>>> an error 500 from the server, which is actualy an error 24: too many 
>>>>>>> files 
>>>>>>> open (see ticket in attachement).
>>>>>>>
>>>>>>> I checked former reports on this error, but none seems to match this 
>>>>>>> case: I'm not using rocket, and running the latest web2py stable 
>>>>>>> version.
>>>>>>> I checked also on opening files myself, but that is never the case 
>>>>>>> (e.g. always done by web2py).
>>>>>>> I tried to increase the file opened limit (ulimit -SHn 4048), but to 
>>>>>>> no improvement.
>>>>>>>
>>>>>>> Any suggestion?
>>>>>>>
>>>>>>> Thanks in advance, Andre
>>>>>>>
>>>>>>>
>>>>>>>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to web2py+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to