Dale, In a subsequent email to the group, I found that the vast, vast majority of resources are tied up in Java. Also, due to a strange configuration in Sun's default jvm.cfg, java tried to allocate an absurd amount of memory if the server has 2gb or more RAM.
OpenVZ is a container-based, not a hypervisor-based, virtualization platform. Because of that, the Linux running inside of the container does not have access to a swap partition, thus no swap space. However, the OpenVZ host can explicitly be instructed to allocate a certain amount of physical RAM and swap to each container, which will appear to container as entirely physical RAM. Those two items considered, it makes sense that the allocation of the RAM in the container happens almost instantly. Changing the jvm.cfg to never assume that it should run in "server" mode solved the first pure consumption issue. After that, I successfully allocated just 256mb of physical RAM and 1792mb of swap to the container which runs sipXecs. The container believes it has 2048mb of physical RAM. I know it sounds strange (and it is), but OpenVZ is a very widely used platform in the hosting world. Because it's a container, the performance impact is negligible (1-3% estimated). It's why I chose it for this project over KVM or VMware. -- Robert Dale Worley wrote: > > I'm not sure exactly what phenomena you are seeing, although that may be > due to my lack of familiarity with your virtualization system. > > But your general observation is correct: If you want to run multiple > instances of sipXecs, the needed resources are the sum of the resources > needed by each instance. If your customers are small, you can probably > do with 1 Gb per instance. If your virtualization system is not good at > reallocating real resources among the virtual machines depending on > demand, you will have to take some care to pre-allocate RAM. > > If your customers are small, 1 Gb per instance probably suffices. How > much does an additional Gb cost these days? (How much does an > additional server cost?) > > Dale > > > _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/
