Solaris

Just an observation - in my own experience I only ever see this when /tmp is full.

Non researched suggestion: add a (bigger) swap volume!

You have a *tiny* /tmp so it wouldn't be unusual to see a scheduled activity fill it. If that process then dies and cleans up you will have your 145MB back again. However there are also situations where a Virtual Memory (swap) reservation fails. [See Note2]

Note: In Solaris /tmp is backed off onto the virtual memory subsystem (swap). Available swap is the sum of physical swap space + (some?) free RAM (the freelist?).
This is not visible from the output you have given.
Use swap -l to see physical swap space and swap -s for the summary.

Note2: Solaris refuses to overcommit virtual memory and a large parent process calling a fork may try to reserve the same memory footprint of the forking process. Search "Minimizing Memory Usage for Creating Application Subprocesses" in oracle.com for an article covering this.

I would look where descriptor 1 goes, with

Code:

pfiles $$

Or, if this is not possible, display the pid

Code:

echo $$

and run the pfiles <pid> in another shell.

I've seen this alot. there are a few causes. I'll list them in order of occurrence for me.

1. Boot Environments; see

Code:

beadm list

2. Snapshots; see

Code:

zfs list -t snapshot

3. extraneous files in /; see

Code:

du -akd /|sort -nr|more