Re^3: memory not freed after perl exits. Solaris.

so what I understand from what you wrote:
by sending the log file (STDOUT) to /tmp I am forcing the system to use memory to hold the log file?
Is that correct?
The log file is often larger than the amount of memory which is no longer free (often larger than the system physcial memory)
Log file may be up to 8G
Physical Memory = 4G
Memory "lost" on one run ~ 300M to 2G
But why does the memory stay lost (not free)?
What can I do to get it back?
Shouldn't it be given back when the programme exits and the log file is written to disk (flushed?).

I log in via a Citrix connection over a (relatively) slow link, so I can't have gigabytes spewing out to an xterm. Sending it to a file on /tmp seemed a good way to keep the output for debugging purposes.

Would I be better off sending the STDOUT to a file on the NFS?
That seems like an odd thing if so!

Comment on Re^3: memory not freed after perl exits. Solaris.

Replies are listed 'Best First'.
Re^4: memory not freed after perl exits. Solaris. by afoken (Chancellor) on Nov 25, 2010 at 12:49 UTC
so what I understand from what you wrote: by sending the log file (STDOUT) to /tmp I am forcing the system to use memory to hold the log file? Is that correct? Yes The log file is often larger than the amount of memory which is no longer free (often larger than the system physcial memory) Log file may be up to 8G Physical Memory = 4G This should make your machine swap like mad. I don't know Solaris that well, on Linux, top and /proc/swaps tell me how much swap is used. I would bet that swap usage is about as large as your log file on /tmp. Memory "lost" on one run ~ 300M to 2G That would match a machine that has stuffed most of the file written to swap, keeping only the most recently used blocks (i.e. the last few mega/giga bytes) in RAM. But why does the memory stay lost (not free)? Because you don't delete the logfile? What can I do to get it back? Delete the logfile from /tmp. Shouldn't it be given back when the programme exits and the log file is written to disk (flushed?). There is no disk behind /tmp. (Well, there is one, if you count the swap partition, but not in the way there is a disk behind /usr or /var.) The swap filesystem is essentially a ramdisk that can overflow into the swap disk, so you can allocate nearly all of your physical RAM plus nearly all of your swap space for temporary data. I log in via a Citrix connection over a (relatively) slow link, so I can't have gigabytes spewing out to an xterm. Sending it to a file on /tmp seemed a good way to keep the output for debugging purposes. Write to a real disk local to the machine you are working on. Ask your admins for a reasonable space. /var/tmp should be a world-writeable directory configured to survive a reboot (i.e. on a disk- or flash-based filesystem) and to be machine-specific (i.e. local disk / flash). Would I be better off sending the STDOUT to a file on the NFS? That seems like an odd thing if so! NFS would put some load on the network, and it is way slower than a local disk or a ramdisk. Think about a less verbose log. Try to filter the log on the fly. Something like: `perl yourscript.pl -foo bar \| grep 'Important' > log.txt` or `perl yourscript.pl -foo bar \| grep -v 'Notice' > log.txt` or `perl yourscript.pl -foo bar \| grep -v 'irrelevant' \| grep -v 'useless' \| grep -v 'crap' > log.txt` Alexander -- Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^4: memory not freed after perl exits. Solaris.
by afoken (Chancellor) on Nov 25, 2010 at 12:49 UTC

so what I understand from what you wrote: by sending the log file (STDOUT) to /tmp I am forcing the system to use memory to hold the log file? Is that correct?

Yes

The log file is often larger than the amount of memory which is no longer free (often larger than the system physcial memory) Log file may be up to 8G Physical Memory = 4G

This should make your machine swap like mad. I don't know Solaris that well, on Linux, top and /proc/swaps tell me how much swap is used. I would bet that swap usage is about as large as your log file on /tmp.

Memory "lost" on one run ~ 300M to 2G

That would match a machine that has stuffed most of the file written to swap, keeping only the most recently used blocks (i.e. the last few mega/giga bytes) in RAM.

But why does the memory stay lost (not free)?

Because you don't delete the logfile?

What can I do to get it back?

Delete the logfile from /tmp.

Shouldn't it be given back when the programme exits and the log file is written to disk (flushed?).

There is no disk behind /tmp. (Well, there is one, if you count the swap partition, but not in the way there is a disk behind /usr or /var.) The swap filesystem is essentially a ramdisk that can overflow into the swap disk, so you can allocate nearly all of your physical RAM plus nearly all of your swap space for temporary data.

I log in via a Citrix connection over a (relatively) slow link, so I can't have gigabytes spewing out to an xterm. Sending it to a file on /tmp seemed a good way to keep the output for debugging purposes.

Write to a real disk local to the machine you are working on. Ask your admins for a reasonable space. /var/tmp should be a world-writeable directory configured to survive a reboot (i.e. on a disk- or flash-based filesystem) and to be machine-specific (i.e. local disk / flash).

Would I be better off sending the STDOUT to a file on the NFS? That seems like an odd thing if so!

NFS would put some load on the network, and it is way slower than a local disk or a ramdisk.

Think about a less verbose log. Try to filter the log on the fly. Something like:

perl yourscript.pl -foo bar | grep 'Important' > log.txt

perl yourscript.pl -foo bar | grep -v 'Notice' > log.txt

perl yourscript.pl -foo bar | grep -v 'irrelevant' | grep -v 'useless' | grep -v 'crap' > log.txt

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

[reply]
[d/l]
[select]