Home > Archive > PERL POE > November 2005 > Unuse modules
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| Kaare Rasmussen 2005-10-30, 3:58 am |
| Hi
I'm wondering if there is a way to unuse a perl module. This means removing
all structures from memory.
Similarily I'd like to know if there is a way to return memory to the OS. The
standard Garbage Collector is too simple to do that, but according to the
documentation, there is a more thorough one that is used when Perl exits.
Can this be used to keep a POE server slim and fit ?
| |
| Artur Bergman 2005-10-30, 7:58 am |
|
On 30 Oct 2005, at 09:54, Kaare Rasmussen wrote:
> Hi
>
> I'm wondering if there is a way to unuse a perl module. This means
> removing
> all structures from memory.
>
>
Yes, but if they use XS code it is quite unlikely you can get rid of
that.
> Similarily I'd like to know if there is a way to return memory to
> the OS. The
> standard Garbage Collector is too simple to do that, but according
> to the
> documentation, there is a more thorough one that is used when Perl
> exits.
>
> Can this be used to keep a POE server slim and fit ?
>
>
Not reliably. But then again, you shouldn't leak.
Cheers
Artur
| |
| Kaare Rasmussen 2005-11-02, 7:04 pm |
| > Yes, but if they use XS code it is quite unlikely you can get rid of
> that.
How would you remove a module? And why is XS a problem?
> Not reliably. But then again, you shouldn't leak.
Not leaking. But maybe running fat modules. Do you have any info about how
to do it?
| |
| Matt S Trout 2005-11-02, 7:04 pm |
| On Wed, Nov 02, 2005 at 03:39:18PM +0100, Kaare Rasmussen wrote:
>
> How would you remove a module? And why is XS a problem?
Dynamically unloading shared libraries etc. is at least as hard as it looks.
>
> Not leaking. But maybe running fat modules. Do you have any info about how
> to do it?
Have a look at the way Apache::Reload, Module::Refresh et. al. do it (and
have a quick nose round CPAN, there's at least a couple others).
--
Matt S Trout Specialists in Perl consulting, web development, and
Technical Director UNIX/Linux systems architecture and automation. Mail
Shadowcat Systems Ltd. mst (at) shadowcatsystems.co.uk for more information
+ Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ +
| |
| Artur Bergman 2005-11-02, 7:04 pm |
|
On 2 Nov 2005, at 14:39, Kaare Rasmussen wrote:
>
> How would you remove a module? And why is XS a problem?
Because XS modules can allocate memory not accessible by perl.
Have you tried just undefing the namespace? (This won't fix lexical
values)
>
> Not leaking. But maybe running fat modules. Do you have any info
> about how to do it?
Huh? What are fat modules/
Cheers
Artur
| |
| Kaare Rasmussen 2005-11-03, 3:59 am |
| > Have you tried just undefing the namespace? (This won't fix lexical
> values)
Can I look into the memory allocation of of a running server written in
Perl?
| |
| Artur Bergman 2005-11-03, 3:59 am |
|
On 3 Nov 2005, at 08:06, Kaare Rasmussen wrote:
>
> Can I look into the memory allocation of of a running server
> written in Perl?
I think so, why?
Also, there is a threads module by liz which I think unloads things.
Cheers
Artur
| |
|
| On (11/03 09:06), Kaare Rasmussen wrote:
> Can I look into the memory allocation of of a running server written in
> Perl?
Devel::Size is pretty goodly for this. It has some known problems but in
my opinion they are minor. At work, I'm actually using Devel::Size and
POE together with great success. We're actually recording the
approximate memory footprint of each session so we can determine which
subsystem is causing memory bloat. because of the Devel::Size's
problems, its only approximate but its way better than nothing.
--
sungo
[url]http:// .org[/url]
|
|
|
|
|