[modwsgi] Re: Intermittent NoReverseMatch errors
Sorry this reply took so long, I am in the middle of changing jobs.
Anyway,
WSGIApplicationGroup %{GLOBAL}
does not change the rough frequency with which I see the problems. I
only added that directive for the port 80 virtual host, while the 443
virtual host doesn't have it. Should I add it to both?
Thanks,
Alex
On Apr 30, 1:47 am, Graham Dumpleton graham.dumple...@gmail.com
wrote:
2009/4/18 Alex Robbins alexander.j.robb...@gmail.com:
When you say 'Also, I get no errors if I remove the maximum-requests',
is that on all configurations?
Yes, that fixes it in all of the cases.
When you run your tests, are requests always sequential? Ie., no
concurrent requests.
No, the url checker is threaded, it normally runs 10 concurrent
threads, each making a urllib.open call, printing the status code if
not 200, then terminating.
Does it make a difference if you specify:
WSGIApplicationGroup %{GLOBAL}
Not sure, home sick today so I can't try it.
Finally, what other third party C extension modules do you use besides
GeoDjango? Ie., databases, etc. Do you use ctypes module?
We are using the mysql backend (mysqldb I think) and Pycrypto.
No ctypes, and we don't use GeoDjango
Also, those pages don't use any crypto, that is only for credit card
stuff or transaction submission.
Any update on whether:
WSGIApplicationGroup %{GLOBAL}
made a difference or not?
Graham
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
modwsgi group.
To post to this group, send email to modwsgi@googlegroups.com
To unsubscribe from this group, send email to
modwsgi+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/modwsgi?hl=en
-~--~~~~--~~--~--~---
[modwsgi] http://www.cherrypy.org/ticket/916#preview
http://www.cherrypy.org/ticket/916#preview Graham can you review this ticket please to see if its compatible with mod_wsgi please The patch defenatly works for me. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups modwsgi group. To post to this group, send email to modwsgi@googlegroups.com To unsubscribe from this group, send email to modwsgi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en -~--~~~~--~~--~--~---
[modwsgi] Re: Apache using lots of memory
2009/5/2 Tim Valenta tonightslasts...@gmail.com: Hello all-- I have yet to get down and dirty with my apache installation, so I'm not 100% sure of the issue yet. I have access to the server right now, but I'm a work currently and can't really just dedicate time to having a look until probably tomorrow. I thought I'd pitch it out here though, in case anybody else had a similar experience. By lots of memory, I mean about 180~200mb more than after an apache restart-- it's truly not all that much, but the whole setup is pretty little, so it was an interesting point. All I'm running on the web server is my Django site and a corresponding SVN repository. I routinely have a script compare the revision numbers of the live site and of the latest SVN revision. If they're different, I have the live Django site (running mod_wsgi, of course) update from its own SVN repository, and then do an apache reload command, to push my updates. After a pretty busy number of 30 reloads in a single day, I noticed that the memory consumption for apache was a lot higher than normal. For all I know, this could be pretty normal-- apache caching stuff, threads off doing things, etc, etc. But if not, is there any reason to think that lots of reloads would be the source of anything unfavorable? Again, if not, then I should pay attention to my Django and Python stats, and this discussion doesn't really apply to mod_wsgi Quick stats... Apache 2.x (not sure which revision number, at the moment), using SVN through dav_svn and authz_svn apache modules, and Django is at its most recent SVN checkout. Python is version 2.5.4. The 30 reloads was kind of excessive, but there were a lot of SVN updates that day :) In the future, the updates would be much less frequent. The site is in a kind of public beta/dev version, and I don't anticipate this kind of situation to be normal after about a week from now. I really haven't gotten into examining anything yet, and I have not tried playing with any configurations for apache or mod_wsgi to allow for some optimizations. If anybody thinks a particular few apache directives could help, please suggest. If you still have mod_python enabled then disable it. For mod_wsgi, make sure you are using mod_wsgi 2.4. Both mod_python and older mod_wsgi versions leak memory into the Apache parent process on a 'restart', ie., not a full 'stop' and 'start'. This is because the Python interpreter wasn't being shutdown properly. Even if using mod_wsgi 2.4, you need to get rid of mod_python as when both exist mod_python is handling interpreter initialisation. That said, even though mod_wsgi 2.4 fixes that, Python itself leaks memory when initialised/destroyed and then initialised again in the same process. How much leaks depends on the version of Python being used. What you need to do is identify which is the Apache parent process and monitor its memory use on a restart. If it grows on every restart, then one possibility is the leaks in the Python interpreter. This is one of the reasons why on mod_wsgi roadmap want to get rid of Python initialisation out of Apache parent process. In mod_wsgi 3.0 there is a mechanism for delaying initialisation of Python interpreter until child process creation. Although this avoids memory creep problem, by not being able to initialise before fork, process will take more memory as no copy on write benefits occurring. The memory leak issue is number 3 in bugs listed in: http://code.google.com/p/modwsgi/wiki/ChangesInVersion0204 That links to mod_wsgi ticket on issue. That said, the amount of memory increase does seem to be a lot more than amount I have seen Python interpreter leaking in the past. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups modwsgi group. To post to this group, send email to modwsgi@googlegroups.com To unsubscribe from this group, send email to modwsgi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en -~--~~~~--~~--~--~---
[modwsgi] Apache using lots of memory
Hello all-- I have yet to get down and dirty with my apache installation, so I'm not 100% sure of the issue yet. I have access to the server right now, but I'm a work currently and can't really just dedicate time to having a look until probably tomorrow. I thought I'd pitch it out here though, in case anybody else had a similar experience. By lots of memory, I mean about 180~200mb more than after an apache restart-- it's truly not all that much, but the whole setup is pretty little, so it was an interesting point. All I'm running on the web server is my Django site and a corresponding SVN repository. I routinely have a script compare the revision numbers of the live site and of the latest SVN revision. If they're different, I have the live Django site (running mod_wsgi, of course) update from its own SVN repository, and then do an apache reload command, to push my updates. After a pretty busy number of 30 reloads in a single day, I noticed that the memory consumption for apache was a lot higher than normal. For all I know, this could be pretty normal-- apache caching stuff, threads off doing things, etc, etc. But if not, is there any reason to think that lots of reloads would be the source of anything unfavorable? Again, if not, then I should pay attention to my Django and Python stats, and this discussion doesn't really apply to mod_wsgi Quick stats... Apache 2.x (not sure which revision number, at the moment), using SVN through dav_svn and authz_svn apache modules, and Django is at its most recent SVN checkout. Python is version 2.5.4. The 30 reloads was kind of excessive, but there were a lot of SVN updates that day :) In the future, the updates would be much less frequent. The site is in a kind of public beta/dev version, and I don't anticipate this kind of situation to be normal after about a week from now. I really haven't gotten into examining anything yet, and I have not tried playing with any configurations for apache or mod_wsgi to allow for some optimizations. If anybody thinks a particular few apache directives could help, please suggest. Thanks for any ideas. Tim --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups modwsgi group. To post to this group, send email to modwsgi@googlegroups.com To unsubscribe from this group, send email to modwsgi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en -~--~~~~--~~--~--~---
[modwsgi] Re: http://www.cherrypy.org/ticket/916#preview
On May 1, 4:59 pm, gert gert.cuyk...@gmail.com wrote:
http://www.cherrypy.org/ticket/916#preview
Graham can you review this ticket please to see if its compatible with
mod_wsgi please
The patch defenatly works for me.
Somebody has been busy :)
gert hello :)
gert http://pastebin.com/m2c1fb44
gert i found a issue about environ['wsgi.input'].read().decode
('utf-8') using python3
gert when i remove that line it displays hello world as a respons
on a post
gert when i include that it does not respond hello world any more
gert also it does read the post content
gert so its seems like you can read a POST request but can not
respond to it
--|TokyoDan (~tokyo...@v046157.dynamic.ppp.asahi-net.or.jp) has
joined #cherrypy
gert can i make a ticket for it ?
fumanchu of course
fumanchu check if one already exists?
gert first i would like to know if it is not something stupid on my
side :P
fumanchu I think it's just read() with no size
fumanchu Graham Dumpleton has been bugging me to make that use
Content-Length (if available) to keep from blocking forever
gert and how do i know the size ?
fumanchu for now, you should try using C-L
gert alright :)
fumanchu environ['HTTP_CONTENT_LENGTH'] I think...?
gert a yes see i knew it would be somthing on my site :)
gert ok back to drawing board
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
modwsgi group.
To post to this group, send email to modwsgi@googlegroups.com
To unsubscribe from this group, send email to
modwsgi+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/modwsgi?hl=en
-~--~~~~--~~--~--~---
[modwsgi] Re: Apache using lots of memory
Thanks-- I'll monitor that stuff in the near future. I'm fairly certain that mod_python is not enabled or installed on the server, though I will double-check that. The 'apache restart' seemed to actual cure the problem, whereas the memory creep seemed to happen over the day full of 'reload' commands, instead. I believe I'm using mod_wsgi 2.3, as I seem to remember you were requesting some testing of 2.4 as I was only getting started with this whole thing. I shall update that, as well. I'll let you know how it goes, whether or not I see a change take place. Tim On Fri, May 1, 2009 at 4:15 PM, Graham Dumpleton graham.dumple...@gmail.com wrote: 2009/5/2 Tim Valenta tonightslasts...@gmail.com: Hello all-- I have yet to get down and dirty with my apache installation, so I'm not 100% sure of the issue yet. I have access to the server right now, but I'm a work currently and can't really just dedicate time to having a look until probably tomorrow. I thought I'd pitch it out here though, in case anybody else had a similar experience. By lots of memory, I mean about 180~200mb more than after an apache restart-- it's truly not all that much, but the whole setup is pretty little, so it was an interesting point. All I'm running on the web server is my Django site and a corresponding SVN repository. I routinely have a script compare the revision numbers of the live site and of the latest SVN revision. If they're different, I have the live Django site (running mod_wsgi, of course) update from its own SVN repository, and then do an apache reload command, to push my updates. After a pretty busy number of 30 reloads in a single day, I noticed that the memory consumption for apache was a lot higher than normal. For all I know, this could be pretty normal-- apache caching stuff, threads off doing things, etc, etc. But if not, is there any reason to think that lots of reloads would be the source of anything unfavorable? Again, if not, then I should pay attention to my Django and Python stats, and this discussion doesn't really apply to mod_wsgi Quick stats... Apache 2.x (not sure which revision number, at the moment), using SVN through dav_svn and authz_svn apache modules, and Django is at its most recent SVN checkout. Python is version 2.5.4. The 30 reloads was kind of excessive, but there were a lot of SVN updates that day :) In the future, the updates would be much less frequent. The site is in a kind of public beta/dev version, and I don't anticipate this kind of situation to be normal after about a week from now. I really haven't gotten into examining anything yet, and I have not tried playing with any configurations for apache or mod_wsgi to allow for some optimizations. If anybody thinks a particular few apache directives could help, please suggest. If you still have mod_python enabled then disable it. For mod_wsgi, make sure you are using mod_wsgi 2.4. Both mod_python and older mod_wsgi versions leak memory into the Apache parent process on a 'restart', ie., not a full 'stop' and 'start'. This is because the Python interpreter wasn't being shutdown properly. Even if using mod_wsgi 2.4, you need to get rid of mod_python as when both exist mod_python is handling interpreter initialisation. That said, even though mod_wsgi 2.4 fixes that, Python itself leaks memory when initialised/destroyed and then initialised again in the same process. How much leaks depends on the version of Python being used. What you need to do is identify which is the Apache parent process and monitor its memory use on a restart. If it grows on every restart, then one possibility is the leaks in the Python interpreter. This is one of the reasons why on mod_wsgi roadmap want to get rid of Python initialisation out of Apache parent process. In mod_wsgi 3.0 there is a mechanism for delaying initialisation of Python interpreter until child process creation. Although this avoids memory creep problem, by not being able to initialise before fork, process will take more memory as no copy on write benefits occurring. The memory leak issue is number 3 in bugs listed in: http://code.google.com/p/modwsgi/wiki/ChangesInVersion0204 That links to mod_wsgi ticket on issue. That said, the amount of memory increase does seem to be a lot more than amount I have seen Python interpreter leaking in the past. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups modwsgi group. To post to this group, send email to modwsgi@googlegroups.com To unsubscribe from this group, send email to modwsgi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en -~--~~~~--~~--~--~---
[modwsgi] Re: http://www.cherrypy.org/ticket/916#preview
2009/5/2 gert gert.cuyk...@gmail.com: http://www.cherrypy.org/ticket/916#preview Graham can you review this ticket please to see if its compatible with mod_wsgi please The patch defenatly works for me. Nothing to do with mod_wsgi. That is a CherryPy WSGI server issue with its handling of chunking in response data. The mod_wsgi module doesn't have problem as Apache does that at a lower level and so don't have to worry about it in mod_wsgi. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups modwsgi group. To post to this group, send email to modwsgi@googlegroups.com To unsubscribe from this group, send email to modwsgi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en -~--~~~~--~~--~--~---
[modwsgi] Re: Apache using lots of memory
Noting that init script reload is equivalent to apachectl restart and init script restart is equivalent to apachectl stop and start. At least I think that is the case for Linux distributions. Confusing isn't it. When I talk about it, I talk about what apachectl does, not the init script. Graham 2009/5/2 Tim Valenta tonightslasts...@gmail.com: Thanks-- I'll monitor that stuff in the near future. I'm fairly certain that mod_python is not enabled or installed on the server, though I will double-check that. The 'apache restart' seemed to actual cure the problem, whereas the memory creep seemed to happen over the day full of 'reload' commands, instead. I believe I'm using mod_wsgi 2.3, as I seem to remember you were requesting some testing of 2.4 as I was only getting started with this whole thing. I shall update that, as well. I'll let you know how it goes, whether or not I see a change take place. Tim On Fri, May 1, 2009 at 4:15 PM, Graham Dumpleton graham.dumple...@gmail.com wrote: 2009/5/2 Tim Valenta tonightslasts...@gmail.com: Hello all-- I have yet to get down and dirty with my apache installation, so I'm not 100% sure of the issue yet. I have access to the server right now, but I'm a work currently and can't really just dedicate time to having a look until probably tomorrow. I thought I'd pitch it out here though, in case anybody else had a similar experience. By lots of memory, I mean about 180~200mb more than after an apache restart-- it's truly not all that much, but the whole setup is pretty little, so it was an interesting point. All I'm running on the web server is my Django site and a corresponding SVN repository. I routinely have a script compare the revision numbers of the live site and of the latest SVN revision. If they're different, I have the live Django site (running mod_wsgi, of course) update from its own SVN repository, and then do an apache reload command, to push my updates. After a pretty busy number of 30 reloads in a single day, I noticed that the memory consumption for apache was a lot higher than normal. For all I know, this could be pretty normal-- apache caching stuff, threads off doing things, etc, etc. But if not, is there any reason to think that lots of reloads would be the source of anything unfavorable? Again, if not, then I should pay attention to my Django and Python stats, and this discussion doesn't really apply to mod_wsgi Quick stats... Apache 2.x (not sure which revision number, at the moment), using SVN through dav_svn and authz_svn apache modules, and Django is at its most recent SVN checkout. Python is version 2.5.4. The 30 reloads was kind of excessive, but there were a lot of SVN updates that day :) In the future, the updates would be much less frequent. The site is in a kind of public beta/dev version, and I don't anticipate this kind of situation to be normal after about a week from now. I really haven't gotten into examining anything yet, and I have not tried playing with any configurations for apache or mod_wsgi to allow for some optimizations. If anybody thinks a particular few apache directives could help, please suggest. If you still have mod_python enabled then disable it. For mod_wsgi, make sure you are using mod_wsgi 2.4. Both mod_python and older mod_wsgi versions leak memory into the Apache parent process on a 'restart', ie., not a full 'stop' and 'start'. This is because the Python interpreter wasn't being shutdown properly. Even if using mod_wsgi 2.4, you need to get rid of mod_python as when both exist mod_python is handling interpreter initialisation. That said, even though mod_wsgi 2.4 fixes that, Python itself leaks memory when initialised/destroyed and then initialised again in the same process. How much leaks depends on the version of Python being used. What you need to do is identify which is the Apache parent process and monitor its memory use on a restart. If it grows on every restart, then one possibility is the leaks in the Python interpreter. This is one of the reasons why on mod_wsgi roadmap want to get rid of Python initialisation out of Apache parent process. In mod_wsgi 3.0 there is a mechanism for delaying initialisation of Python interpreter until child process creation. Although this avoids memory creep problem, by not being able to initialise before fork, process will take more memory as no copy on write benefits occurring. The memory leak issue is number 3 in bugs listed in: http://code.google.com/p/modwsgi/wiki/ChangesInVersion0204 That links to mod_wsgi ticket on issue. That said, the amount of memory increase does seem to be a lot more than amount I have seen Python interpreter leaking in the past. Graham --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups modwsgi group. To
[modwsgi] Re: http://www.cherrypy.org/ticket/916#preview
I have told you before that calling read() with no argument is
disallowed by WSGI specification. You are only allowed to at most read
CONTENT_LENGTH. Don't do that and you have problems with WSGI servers
that don't implement an input end sentinel.
Graham
2009/5/2 gert gert.cuyk...@gmail.com:
On May 1, 4:59 pm, gert gert.cuyk...@gmail.com wrote:
http://www.cherrypy.org/ticket/916#preview
Graham can you review this ticket please to see if its compatible with
mod_wsgi please
The patch defenatly works for me.
Somebody has been busy :)
gert hello :)
gert http://pastebin.com/m2c1fb44
gert i found a issue about environ['wsgi.input'].read().decode
('utf-8') using python3
gert when i remove that line it displays hello world as a respons
on a post
gert when i include that it does not respond hello world any more
gert also it does read the post content
gert so its seems like you can read a POST request but can not
respond to it
--| TokyoDan (~tokyo...@v046157.dynamic.ppp.asahi-net.or.jp) has
joined #cherrypy
gert can i make a ticket for it ?
fumanchu of course
fumanchu check if one already exists?
gert first i would like to know if it is not something stupid on my
side :P
fumanchu I think it's just read() with no size
fumanchu Graham Dumpleton has been bugging me to make that use
Content-Length (if available) to keep from blocking forever
gert and how do i know the size ?
fumanchu for now, you should try using C-L
gert alright :)
fumanchu environ['HTTP_CONTENT_LENGTH'] I think...?
gert a yes see i knew it would be somthing on my site :)
gert ok back to drawing board
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
modwsgi group.
To post to this group, send email to modwsgi@googlegroups.com
To unsubscribe from this group, send email to
modwsgi+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/modwsgi?hl=en
-~--~~~~--~~--~--~---
[modwsgi] Re: http://www.cherrypy.org/ticket/916#preview
Doh, I forgot about that, anyway works now :)
On May 2, 12:33 am, Graham Dumpleton graham.dumple...@gmail.com
wrote:
I have told you before that calling read() with no argument is
disallowed by WSGI specification. You are only allowed to at most read
CONTENT_LENGTH. Don't do that and you have problems with WSGI servers
that don't implement an input end sentinel.
Graham
2009/5/2 gert gert.cuyk...@gmail.com:
On May 1, 4:59 pm, gert gert.cuyk...@gmail.com wrote:
http://www.cherrypy.org/ticket/916#preview
Graham can you review this ticket please to see if its compatible with
mod_wsgi please
The patch defenatly works for me.
Somebody has been busy :)
gert hello :)
gert http://pastebin.com/m2c1fb44
gert i found a issue about environ['wsgi.input'].read().decode
('utf-8') using python3
gert when i remove that line it displays hello world as a respons
on a post
gert when i include that it does not respond hello world any more
gert also it does read the post content
gert so its seems like you can read a POST request but can not
respond to it
--| TokyoDan (~tokyo...@v046157.dynamic.ppp.asahi-net.or.jp) has
joined #cherrypy
gert can i make a ticket for it ?
fumanchu of course
fumanchu check if one already exists?
gert first i would like to know if it is not something stupid on
my
side :P
fumanchu I think it's just read() with no size
fumanchu Graham Dumpleton has been bugging me to make that use
Content-Length (if available) to keep from blocking forever
gert and how do i know the size ?
fumanchu for now, you should try using C-L
gert alright :)
fumanchu environ['HTTP_CONTENT_LENGTH'] I think...?
gert a yes see i knew it would be somthing on my site :)
gert ok back to drawing board
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
modwsgi group.
To post to this group, send email to modwsgi@googlegroups.com
To unsubscribe from this group, send email to
modwsgi+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/modwsgi?hl=en
-~--~~~~--~~--~--~---
