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.
