Mem requirement for additional JREs

I have 15 years as a Solaris developer but very little experience in administration. I have a customer on Solaris 8 (or 9) that is questioning that every instance of one of our java applications "takes 189Meg", he plans to run 40 instances per machine. Address Kbytes Resident Shared Private .... total Kb 189112 57960 28624 29336 Looking at the pmap -x above I told him that although 189 Meg is addressed, only 58Meg is resident and of that only 30Meg is actually private. So I told him that additional instances of this same process (same JRE, same java classes, same jars) would probably take just over 30 Meg of additional OS resources. He came back by starting 20 instances of our application and running swap -s between starting each one. It turns out that swap -s shows an additional 130 Meg of "reserved" space each time the process is started. So, what is going on here? Is the OS "reserving" more memory than it needs, with the expectation that it will later return it if it needs it? Is it really taking 130 Meg of space for each instance of this process??? BTW: I know I can effect memory to some extent with -Xm params to the jre, but I'm more interested in what the OS is doing here. -Robert

On Mar 6, 6:11 pm, "Robert M. Gary" <N70...@gmail.com> wrote: > I have 15 years as a Solaris developer but very little experience in > administration. > > I have a customer on Solaris 8 (or 9) that is questioning that every > instance of one of our java applications "takes 189Meg", he plans to > run 40 instances per machine. > > Address Kbytes Resident Shared Private > ... > total Kb 189112 57960 28624 29336 > > Looking at the pmap -x above I told him that although 189 Meg is > addressed, only 58Meg is resident and of that only 30Meg is actually > private. So I told him that additional instances of this same process > (same JRE, same java classes, same jars) would probably take just over > 30 Meg of additional OS resources. > > He came back by starting 20 instances of our application and running > swap -s between starting each one. > > It turns out that swap -s shows an additional 130 Meg of "reserved" > space each time the process is started. > > So, what is going on here? Is the OS "reserving" more memory than it > needs, with the expectation that it will later return it if it needs > it? Is it really taking 130 Meg of space for each instance of this > process??? > > BTW: I know I can effect memory to some extent with -Xm params to the > jre, but I'm more interested in what the OS is doing here. > > -Robert Why would anyone want to run 40 instances of the JRE? Also a cold start of a JVM consumes a lot more resources than a warm / restarted JVM.

On Mar 6, 11:11 pm, "Robert M. Gary" <N70...@gmail.com> wrote: > So, what is going on here? Is the OS "reserving" more memory than it > needs, with the expectation that it will later return it if it needs > it? Is it really taking 130 Meg of space for each instance of this > process??? Someone will know better than me, but it seems to me that it might be because the thing is mapping memory with copy-on-write semantics, but then not actually writing to much of it. The system has to be pessimistic and assume that all the memory will actually be written & reserve enough swap for that, but since most of it actually is *not* written it is actually still shared. There is a story here about overcommit: I think there is a paper (blueprint?) on this somewhere at Sun. I know the default is that Solaris doesn't do it, but there are ways of making very large sparse address spaces which don't involve reserving huge amounts of swap or possibly nuking the system (which is a much better approach than just allowing overcommit).

On Mar 7, 5:22 am, "Tim Bradshaw" <tfb+goo...@tfeb.org> wrote: > On Mar 6, 11:11 pm, "Robert M. Gary" <N70...@gmail.com> wrote: > > > So, what is going on here? Is the OS "reserving" more memory than it > > needs, with the expectation that it will later return it if it needs > > it? Is it really taking 130 Meg of space for each instance of this > > process??? > > Someone will know better than me, but it seems to me that it might be > because the thing is mapping memory with copy-on-write semantics, but > then not actually writing to much of it. The system has to be > pessimistic and assume that all the memory will actually be written & > reserve enough swap for that, but since most of it actually is *not* > written it is actually still shared. > > There is a story here about overcommit: I think there is a paper > (blueprint?) on this somewhere at Sun. I know the default is that > Solaris doesn't do it, but there are ways of making very large sparse > address spaces which don't involve reserving huge amounts of swap or > possibly nuking the system (which is a much better approach than just > allowing overcommit). Is it correct to assume that the memory that swap -s shows as "reserved" is not assigned to any process but rather a cache of memory claimed by the OS? Here is what the man page on a Sol 8 (sparc) box says... reserved The total amount of swap space in bytes not currently allocated, but claimed by memory mappings for possible future use. -Robert

Tim Bradshaw <tfb+google@tfeb.org> wrote: > On Mar 6, 11:11 pm, "Robert M. Gary" <N70...@gmail.com> wrote: >> So, what is going on here? Is the OS "reserving" more memory than it >> needs, with the expectation that it will later return it if it needs >> it? Is it really taking 130 Meg of space for each instance of this >> process??? > Someone will know better than me, but it seems to me that it might be > because the thing is mapping memory with copy-on-write semantics, but > then not actually writing to much of it. Exactly. Or that memory is requested by the application (malloc()), but not yet used. Either one will cause the VM to account for the space, but not create a page for it in RAM. > The system has to be > pessimistic and assume that all the memory will actually be written & > reserve enough swap for that, but since most of it actually is *not* > written it is actually still shared. Yes. -- Darren Dunham ddunham@taos.com Senior Technical Consultant TAOS http://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area < This line left intentionally blank to confuse you. >

Robert M. Gary <N7093v@gmail.com> wrote: > Is it correct to assume that the memory that swap -s shows as > "reserved" is not assigned to any process but rather a cache of memory > claimed by the OS? Here is what the man page on a Sol 8 (sparc) box > says... 'reserved' memory is a VM page that has been requested from the OS (say via malloc), but not yet used in any manner. This page may be shared or private. Since it's not actually used yet, I suppose you could say that the *memory* is not assigned to any process. But the reservation is assigned to at least one process (or I suppose the kernel could also reserve it). > reserved The total amount of swap > space in bytes not currently > allocated, but claimed by > memory mappings for possible > future use. Run malloc in code and don't use it. You'll see the reserved portion of the VM space increase. -- Darren Dunham ddunham@taos.com Senior Technical Consultant TAOS http://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area < This line left intentionally blank to confuse you. >

On Mar 7, 1:18 pm, Darren Dunham <ddun...@redwood.taos.com> wrote: > Run malloc in code and don't use it. You'll see the reserved portion of > the VM space increase. > So would using the memory result in the reserved portion decreasing (since now its used)? -Robert

Robert M. Gary <N7093v@gmail.com> wrote: > On Mar 7, 1:18 pm, Darren Dunham <ddun...@redwood.taos.com> wrote: >> Run malloc in code and don't use it. You'll see the reserved portion of >> the VM space increase. >> > So would using the memory result in the reserved portion decreasing > (since now its used)? Yes. Once you use it, it's not simple accounting any longer. The OS has to actually map it to a real page (in RAM at first). In swap -s, that page will now appear as "allocated" rather than "reserved". -- Darren Dunham ddunham@taos.com Senior Technical Consultant TAOS http://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area < This line left intentionally blank to confuse you. >

On Mar 7, 5:08 pm, "Robert M. Gary" <N70...@gmail.com> wrote: > Is it correct to assume that the memory that swap -s shows as > "reserved" is not assigned to any process but rather a cache of memory > claimed by the OS? Here is what the man page on a Sol 8 (sparc) box > says... In addition to what Darren said (which I'm sure is correct!) it's worth pointing out that reserved memory is essentially just an accounting thing going on in the system: it hasn't grabbed any pages of physical memory or anything like that. All it's doing is noting down to itself that it might need that memory at some future time, so it should be careful not to reserve more space than it actually has (where `space' means the total of swap and physical memory). Essentially the reservation is a promise to the application that, if it wants it, it can have that memory, and the system is being careful about remembering reservations so it knows it can keep its promises, as not being able to do so leaves it in an awkward position[*]. *If* you know that the application will never actually call on the reservation (which you may or may not) then a reasonable approach is just to provide a lot of swap space: the system will happily reserve against this swap space (note again: it doesn't actually touch the disk to do this, it's just doing accounting) but will never actually need to use it. Of course if you're wrong about the never calling on the reservation bit performance will be appalling. --tim [*] Solaris is the kind of OS which keeps all its money under the bed. Some other OSs are more like investment banks, and quite happily make lots of promises they can't keep on the assumption that they'll only ever have to make good on a few of them. They get to drink in really expensive bars in the city but occasionally collapse in a heap and everyone loses their money.