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 [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
