What hardware you need depends on what you want to do. Since GT.M is itself very modest in disk requirements (less than 15MB), disk usage will be determined by your operating system and VistA. Each VistA development environment (i.e., without any patient data) will likely require a minimum of 700-800MB disk space, and since you will be journaling databases, allowing 2-3GB per VistA environment (more if there will be patient data) would be prudent. A production environment with patient data and active update activity will need much more disk space, not just for the database, but also journal files, backups, etc. (disk usage with GT.M/Linux is probably on par with other MUMPSen).
Likewise, GT.M memory usage in a development environment is modest. For a small development environment, if you are not running a graphical user interface - KDE, Gnome, Icebox, etc. - but only character mode Linux, I suspect 64MB may be ample. If you are running a GUI, you you should probably have at least 256MB on the machine. For a production environment, with live users, I don't know what the VistA working set is - I suspect 10MB per user would be ample and a good starting point, but whether it would be 2MB or 20MB I can't say.
I would guess that for development or small production environments, just about any CPU 2GHz and above would suffice. If you plan to run in production, perhaps you should look into dual CPU machines.
Others who are using VistA on GT.M on Linux may want to comment - my experience comes primarily from creating VistA live CDs rather than from use of VistA.
If you are configuring for production, you should also get server grade hardware (redundant power supplies, UPS, RAID 5/10 disks, ECC RAM, backup device, dual disk controllers with databases and journals on different controllers, etc.).
For a large production environment, a benchmark phase in the implementation project would be recommended.
Regards
-- Bhaskar
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My *guess* is that you have simply moved your global directory from SPARC Solaris to x86 GNU/Linux. The global directory is a binary file, and the format can change from platform to platform (indeed 32- and 64-bit GT.M on x86 GNU/Linux have different formats) and version to version of GT.M. The format is always different for your two platforms. So, what you will need to do is to create new global directories on x86 GNU/Linux, or if you create them from a text script on SPARC Solaris, use that script on x86 GNU/Linux.
I am curious as to how you came by GT.M on SPARC Solaris, since that is not FOSS. If you are working for an organization that is currently on GT.M support, you can contact GT.M support for assistance with questions such as this. These forums on Source Forge are for community based support are typically used by those who do not have GT.M support contracts. [These support forums are free, but you don't have assured service levels and response times. A GT.M support contract gets you support with assured service levels from the development team.]
Regards
-- Bhaskar
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Bhaskar,
we did have GT.M support but because of the economy and the company just trying to stay afloat we had to drop our contract support. :( which really sucks because you guys are awesome.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In working on a project to convert open vista to esi-objects I need to configure hardware for a linux gt.m open vista stack.
Can you tell me what the gt.m system requirements are, and possibly the Open Vista application, also?
Thank you,
Greg Martinson
Greg --
What hardware you need depends on what you want to do. Since GT.M is itself very modest in disk requirements (less than 15MB), disk usage will be determined by your operating system and VistA. Each VistA development environment (i.e., without any patient data) will likely require a minimum of 700-800MB disk space, and since you will be journaling databases, allowing 2-3GB per VistA environment (more if there will be patient data) would be prudent. A production environment with patient data and active update activity will need much more disk space, not just for the database, but also journal files, backups, etc. (disk usage with GT.M/Linux is probably on par with other MUMPSen).
Likewise, GT.M memory usage in a development environment is modest. For a small development environment, if you are not running a graphical user interface - KDE, Gnome, Icebox, etc. - but only character mode Linux, I suspect 64MB may be ample. If you are running a GUI, you you should probably have at least 256MB on the machine. For a production environment, with live users, I don't know what the VistA working set is - I suspect 10MB per user would be ample and a good starting point, but whether it would be 2MB or 20MB I can't say.
I would guess that for development or small production environments, just about any CPU 2GHz and above would suffice. If you plan to run in production, perhaps you should look into dual CPU machines.
Others who are using VistA on GT.M on Linux may want to comment - my experience comes primarily from creating VistA live CDs rather than from use of VistA.
If you are configuring for production, you should also get server grade hardware (redundant power supplies, UPS, RAID 5/10 disks, ECC RAM, backup device, dual disk controllers with databases and journals on different controllers, etc.).
For a large production environment, a benchmark phase in the implementation project would be recommended.
Regards
-- Bhaskar
Hello,
I am trying to move my current Solaris systems to linux.
When i try to do a mupip create on an already existing gbl file i get an error.
GTM-E-MEMORY, Central memory exhausted during request for 3961651208
SYSTEM-E-EN012, Cannot Allocate memory.
Do i really need 3GB or memory ?
Steve
Steve --
My *guess* is that you have simply moved your global directory from SPARC Solaris to x86 GNU/Linux. The global directory is a binary file, and the format can change from platform to platform (indeed 32- and 64-bit GT.M on x86 GNU/Linux have different formats) and version to version of GT.M. The format is always different for your two platforms. So, what you will need to do is to create new global directories on x86 GNU/Linux, or if you create them from a text script on SPARC Solaris, use that script on x86 GNU/Linux.
I am curious as to how you came by GT.M on SPARC Solaris, since that is not FOSS. If you are working for an organization that is currently on GT.M support, you can contact GT.M support for assistance with questions such as this. These forums on Source Forge are for community based support are typically used by those who do not have GT.M support contracts. [These support forums are free, but you don't have assured service levels and response times. A GT.M support contract gets you support with assured service levels from the development team.]
Regards
-- Bhaskar
Bhaskar,
we did have GT.M support but because of the economy and the company just trying to stay afloat we had to drop our contract support. :( which really sucks because you guys are awesome.