On Sun, Apr 25, 2010 at 6:08 AM, Richard L. Hamilton <rlha...@smart.net> wrote: > A 32-bit process _can't_* be bigger than 4GB, and as far as the kernel > is concerned, AFAIK won't be bigger than 2GB in terms of regular memory > (although it could have a frame buffer or something mapped in the > part of the address space reserved for I/O devices, making its total > size perhaps appear larger than 2GB, but still definitely <= 4GB). > > *actually, a 32-bit _address space_ can't be. On suitable hardware, a 32-bit > kernel > can use special instructions to address more than 4GB of RAM, and some other > OSs allow even a user process to own more than one address space. I don't > think > any of that applies here though.
This is what we assumed. But none of the senior admins expected ksh to be a 64bit shell and we were quite worried about the out-of-control 32bit process. > Assuming you're running OpenSolaris and not Solaris 10 or SXCE, > ksh is actually ksh93, and was built both 32-bit and 64-bit. OK. This comes as surprise, albeit a good one. We've figured we did a mistake and passed the whole set of data to the script and not the demo data, which is a difference between 500 files (demo set) and 725298 files (production set). We've figured that without a 64bit shell the script would've crashed. > To get around the problem > pmap: cannot examine 5608: address space is changing > > and get a closer look, try stopping the process first: > > pstop 5608 > > and then running pmap or whatever to inspect it, and finally running > > prun 5608 > > to let it run again. Why is pmap not doing this? > I suspect the shell script being run is the real problem; not too many > well-written shell scripts should grow to such monster size. We called upon the author to explain: He said the script caches many data in memory (arrays) during execution and the 19G memory peak usage matches the working set of the input data. We're still verifying the output because the script finished in four hours while the legacy perl version of the script used to run a whole weekend. This is suspicious and too good to be true. Yves _______________________________________________ observability-discuss mailing list observability-discuss@opensolaris.org
