Actually, Ian clarified that the threadpool can be turned off. Add the
following to the [server] section:
use_threadpool = false
On my linux system, that cut the Virtual from 100Mb to 18Mb.
But this is then single-process mode, I guess?
* threadpool_workers = 10
virtual 108104, resident 18900
(...)
So it looks like it is all about thread-local storage. Maybe just
the thread stack size...
What figures do you get for the above if you run:
ulimit -s 512
*Far* smaller, for example with workers=10 I got virtual about
Marcin Kasperski wrote:
Actually, Ian clarified that the threadpool can be turned off. Add the
following to the [server] section:
use_threadpool = false
On my linux system, that cut the Virtual from 100Mb to 18Mb.
But this is then single-process mode, I guess?
No, it spawns a new thread
Just a (post-mortem?) note. After having very good experience from
migration (on some non-pylons site) from moinmoin hosted on apache
with fastcgi to moinmoin on twisted proxied behind nginx (I did not
make any formal measures, but it just feels that the app runs faster)
I opted for similar path
On Oct 31, 2007, at 8:39 AM, Marcin Kasperski wrote:
I am still not very happy with paster (~100MB virtual, 22MB resident),
and hoping to search for some improvements here. But at least it is
just one such process...
Can you ask your ISP if the virtual is counting against some limit?
The
[server:main]
threadpool_nworkers = 5
did not work for me.
Resolved. One should use
threadpool_workers = 5
(without 'n'). Then it works. Some observations in the next post.
--~--~-~--~~~---~--~~
You received this message because you are
Ben Bangert [EMAIL PROTECTED] writes:
On Oct 31, 2007, at 8:39 AM, Marcin Kasperski wrote:
I am still not very happy with paster (~100MB virtual, 22MB resident),
and hoping to search for some improvements here. But at least it is
just one such process...
Can you ask your ISP
On Oct 31, 2007, at 9:41 AM, Marcin Kasperski wrote:
This is true. But this is also relatively easy to measure, it suffices
to compare virtual size of the running app with virtual size of python
which just loaded all the libraries. The latter is fairly well
approximated by paster shell.
The
On Nov 1, 6:08 am, Ben Bangert [EMAIL PROTECTED] wrote:
On Oct 31, 2007, at 9:41 AM, Marcin Kasperski wrote:
This is true. But this is also relatively easy to measure, it suffices
to compare virtual size of the running app with virtual size of python
which just loaded all the libraries.
On Oct 31, 2007, at 4:44 PM, Graham Dumpleton wrote:
What figures do you get for the above if you run:
ulimit -s 512
in your shell prior to running the web application?
You will need to exit the shell when done to get it back to default
value.
If the VPS Memory Limit (virtual memory size)
On Oct 31, 2007, at 5:05 PM, Ben Bangert wrote:
You can run Pylons with FastCGI, directly loading the Pylons app
(thus no threadpools). This should work great with your nginx setup
as well, and mitigate the Virtual issue from the thread size on
linux. Your virtual should then hover around
you should see if the Apache configuration you are using
defines a value for the ThreadStackSize directive.
Thanks for the hint.
I am still to make my experiments, but here is initial summary for
this thread from my point of view.
It is highly suspected, that significant part of the RAM
On 10/17/07, Graham Dumpleton [EMAIL PROTECTED] wrote:
Note that in general the argument that lighttpd and nginx are better
because they are quicker in serving static files is totally
meaningless in the context of Python web applications, as the real
work is being done in the Python
On 10/17/07, Ian Bicking [EMAIL PROTECTED] wrote:
Ben Bangert wrote:
On Oct 17, 2007, at 2:24 PM, Christoph Haas wrote:
Why am I still confused by the top columns after 15 years of UNIX usage.
Yes, the virtual usage is around 100 MB while the resident size is at
about 18 MB.
Of
On Oct 22, 10:28 pm, Bob Ippolito [EMAIL PROTECTED] wrote:
On 10/17/07, Graham Dumpleton [EMAIL PROTECTED] wrote:
Note that in general the argument that lighttpd and nginx are better
because they are quicker in serving static files is totally
meaningless in the context of Python web
On Oct 22, 10:12 pm, Marcin Kasperski [EMAIL PROTECTED]
wrote:
2) Consider (and test) mod_wsgi daemon mode. Main advantage over
embedded mode is that it will allow to tune wsgi threads (count,
stack size...) separately from main apache threads.
Noting though that mod_wsgi daemon mode
On Thu, 2007-10-18 at 12:18 +0200, Marcin Kasperski wrote:
I am watching with interest efforts to port WSGI to nginx which show
up on some lists. Nevertheless, it seems it will take some time...
Actually I believe Manlio's implementation is usable right now for WSGI
2.0, with WSGI 1.0 support
On Oct 23, 10:53 am, Cliff Wells [EMAIL PROTECTED] wrote:
On Thu, 2007-10-18 at 12:18 +0200, Marcin Kasperski wrote:
I am watching with interest efforts to port WSGI to nginx which show
up on some lists. Nevertheless, it seems it will take some time...
Actually I believe Manlio's
On Mon, 2007-10-22 at 23:24 +, Graham Dumpleton wrote:
The complexity I am referring to is not in configuring nginx, but that
you also have to install and configure some separate supervisor system
which starts up and ensures that your backend process is running.
I think this argument
On Oct 23, 11:54 am, Cliff Wells [EMAIL PROTECTED] wrote:
On Mon, 2007-10-22 at 23:24 +, Graham Dumpleton wrote:
The complexity I am referring to is not in configuring nginx, but that
you also have to install and configure some separate supervisor system
which starts up and ensures
One more thing to possibly add to this list of suggestions for cutting
down Apache memory usage.
If you are using a Linux system and are using the worker MPM for
Apache, you should see if the Apache configuration you are using
defines a value for the ThreadStackSize directive. It seems that if
I've run a few tests on my OSX machine, can you run them on your box?
Could you share the [EMAIL PROTECTED] of test apps? I wouldn't like to
experiment too much with creating them
Cheap VPS's (like serveraxis.com) start around $30/mth with half
a gig of ram, and a gig of swap...
Well, I
Are the Zope and Moin numbers from the same environment your Pylons
is running on?
Yes. [EMAIL PROTECTED] in both cases.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this
On Oct 18, 2007, at 3:18 AM, Marcin Kasperski wrote:
Bah. Even Zope - yes, Zope! - takes less:
(zope after starting, standard standalone server)
marcink 5028 0.0 0.1 70084 2340 ?Sl Jul10 0:02 /
usr/bin/python /home/marcink/Zope/Install/lib/python/Zope2/Startup/
run.py -C
On Oct 18, 2007, at 11:34 AM, Ben Bangert wrote:
On Oct 18, 2007, at 3:18 AM, Marcin Kasperski wrote:
Bah. Even Zope - yes, Zope! - takes less:
(zope after starting, standard standalone server)
marcink 5028 0.0 0.1 70084 2340 ?Sl Jul10 0:02 /
usr/bin/python
On Oct 18, 2007, at 3:18 AM, Marcin Kasperski wrote:
Bah. Even Zope - yes, Zope! - takes less:
(zope after starting, standard standalone server)
marcink 5028 0.0 0.1 70084 2340 ?Sl Jul10 0:02 /
usr/bin/python /home/marcink/Zope/Install/lib/python/Zope2/Startup/
run.py -C
Ben Bangert wrote:
If you'd like to contribute a patch of continue to hunt down what's
taking the ram, we'll be happy to apply patches.
Working scripts/tools to give analysis of where the memory is being used
would probably be even more useful than patches. There's tools out
there, but
Any ideas how could I reduce pylons app RAM usage? At the moment
pylons process takes above 100MB (almost static site serving some
templates) - both when run with paste, and when run under mod_wsgi.
Quite a lot, considering that for example whole moinmoin manages to
work
On Tue, Oct 16, 2007 at 04:22:14PM +0200, Marcin Kasperski wrote:
Any ideas how could I reduce pylons app RAM usage? At the moment
pylons process takes above 100MB (almost static site serving some
templates) - both when run with paste, and when run under mod_wsgi.
Quite a lot, considering
On 10/17/07, Christoph Haas [EMAIL PROTECTED] wrote:
On Tue, Oct 16, 2007 at 04:22:14PM +0200, Marcin Kasperski wrote:
Any ideas how could I reduce pylons app RAM usage? At the moment
pylons process takes above 100MB (almost static site serving some
templates) - both when run with paste,
On Oct 17, 2007, at 2:59 AM, Marcin Kasperski wrote:
RSS. VSS is also fairly significant, 16-17MB.
I think you have those reversed according to the other numbers.
Development machine, paste server immediately after startup
26815 marcink 15 0 109m 15m 2840 S1 0.8 0:01.76
On Wed, Oct 17, 2007 at 09:03:12PM +0300, Max Ischenko wrote:
On 10/17/07, Christoph Haas [EMAIL PROTECTED] wrote:
On Tue, Oct 16, 2007 at 04:22:14PM +0200, Marcin Kasperski wrote:
Any ideas how could I reduce pylons app RAM usage? At the moment
pylons process takes above
On Oct 17, 2007, at 2:24 PM, Christoph Haas wrote:
Why am I still confused by the top columns after 15 years of UNIX
usage.
Yes, the virtual usage is around 100 MB while the resident size is at
about 18 MB.
Of course, since most of this ram use is from the libraries, it means
it will
Ben Bangert wrote:
Apache is rather a pig on resources (the threading worker helps a
bit), I'd suggest checking out nginx or lightty. nginx has a bit more
modules to replace Apache functionality and has been more reliable in
my experience, but both of them will mean dropping Apache (which
Ben Bangert wrote:
On Oct 17, 2007, at 2:24 PM, Christoph Haas wrote:
Why am I still confused by the top columns after 15 years of UNIX usage.
Yes, the virtual usage is around 100 MB while the resident size is at
about 18 MB.
Of course, since most of this ram use is from the libraries,
On 10/16/07, Marcin Kasperski [EMAIL PROTECTED] wrote:
Any ideas how could I reduce pylons app RAM usage? At the moment
pylons process takes above 100MB (almost static site serving some
templates) - both when run with paste, and when run under mod_wsgi.
Quite a lot, considering that for
36 matches
Mail list logo
