I've got a lot of interesting messages to the question below. The most important ones were that: 1. There is a solution to this as suggested by Lieven Marchand and this was to change the value of swap_maxcontig from the default 1 Mb to 2GB and have as a secondary effect round robin paging disabled. However, he also pointed out that this is highly experimental and the ones willing to try this on their production systems are on their own. I was not willing to try hence I still have no feedback on this solution. 2. The second (indirect) answer is that applications tend to reserve upfront large quantities of memory upfront from which often a half or even one third actually use. So, the fact that swap apear to be used means that in fact that virtual memory was reserved, not necesarilly used. Of course, because of the above, there will not actually be disk paging activity and subsequently no performance problems. Adrian Cockroft personally pointed me that a lot of memory shortage problems can be solved by just configuring more swap (taking care if 32 bit kernel is used, that none of them is larger than 2GB). In that way, applications which reserves virtual memory will reserve not physical memory but disk swap space. This makes sense. Thanks everybody who bottered to respond ! Best Regards, George DONE > I ran in the following annoying "feature" of Solaris: Round Robin paging. > This are the facts: > 1) the space over 2 GB in a swap device is ignored > 2) if you have more than one swap device, Solaris use them all in a round > robin fashion, several pages on each swap device. > Now this is good if you put each swap device on a separate > volume/metadevice, because spreads the disk load. But if you need 12GB of > swap, that means you should use 12 separate disks to create 6 mirrored > chunks of 2GB. This is way too many disks used for that. > Alternativelly, you could place more than one swap metadevice/volume on > the > same pair of mirrored disks but you will soon notice bad performance > because > of long disk seeks. > Now the question is: > How can I disable this round robin and force Solaris to do paging on only > one volume/metadevice and only when the first one is all used to turn to > the > second one ? The gotcha here is that most of the time I use only 1 GB or > so > of swap for paging and I need to configure 12 GB only to insure I will not > run out of virtual memory in worst case batch run-scenario. The machine is > already filled up with physical memory at full capacity. > > Regards, > George DONE > http://www.sunmanagers.org/mailman/listinfo/sunmanagers > > =========================================================== De verzonden informatie is uitsluitend bestemd voor de geadresseerde natuurlijke persoon of rechtspersoon en bevat mogelijk vertrouwelijke en/of geprivilegeerde gegevens. Met uitzondering van de geadresseerde persoon is het niet toegestaan de informatie openbaar te maken, te kopiëren, te verspreiden of anderszins actie te ondernemen op basis van de informatie. Indien u de informatie abusievelijk heeft ontvangen, neem dan contact op met de afzender en verwijder de informatie uit alle computers. Dutchtone staat niet in voor de juiste en complete verzending van de informatie, noch is zij aansprakelijk voor de vertraagde ontvangst hiervan. The information transmitted is intended exclusively for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any disclosure, copying, distribution or other action based upon the information by persons or entities other than the intended recipient is prohibited. If you receive this information in error, please contact the sender and delete the material from any and all computers. Dutchtone does not warrant a proper and complete transmission of this information, nor does it accept liability for any delays. =========================================================== _______________________________________________ sunmanagers mailing list sunmanagers@sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagersReceived on Sun Sep 9 00:02:58 2001
This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:42:25 EST