Our friends at Oracle give us a nice list of requirements for their Application Server and Portal products, to help us define to our customers what is needed to run these mammoths of ability and power. But can you make it run on less? And if so, how much less?
Note: Oracle does not condone or recommend any of the following practices. In a real production environment, I agree. This was done as a test to see if it could be done.
The Base Information
Oracle says that to run Application Server 10g you need a few things. For this post, we are on the Windows Server OS. It is put forth you need to be on at least SP1 of Server 2003, Have a minimum 300 MHz CPU (although they recommend a 450, and really recommend 2 GHz and up), and 1 GB of RAM, on an NTFS file system. There is of course the need for a Network interface, and some other ancillary items, but above are the core hardware specs, pulled from their installation documents.
If I said you could make it work in 640 MB of RAM, at 1.4 GHz of CPU on a desktop motherboard, you might say I’m crazy. Well it can be done, and has been done. The trick is to understand what Oracle needs to install, and how to give it that, or make it think it has it.
The OS itself needs to be as lean as it can get. If you don’t need it, don’t enable it. This goes for server roles, as well as secondary applications. Since Oracle installs Apache, you don’t even need to enable Web server functions. The less you have to install the better. The breakdown is below for how I made this work.
The Oracle Setup
Your primary enemy is timeouts. They alone can bring an otherwise perfect concept to it’s knees. Also, you need to know what it is you really need installed. Obviously, to run Portal as well as OAS, you need the full Infrastructure with Identity Management installed, not much option there, and that usually will install without much issue. The trick is in Portal itself. Installing the Portal system gives you many options, and many packages they need to be deployed and setup, and as anyone who has done this knows, if it fails, it UN-deploys anything in process. Portal deployment is where most of the timeouts tend to occur in this build.
The fix? Once the infrastructure is in, and running (and for safety sake, a backup made) the timeouts need to be increased, doubling them usually works, in some cases tripling them is better. If there is a retry setting available, bump it up a notch or two. While it seems crazy, the object is to get it to install. Tweaking them back down can be done once it’s up and running. Also, look into limiting the number of connections, and the settings that affect, or are affected by those numbers. Also don’t shy from touching the settings that dictate how much RAM Oracle looks for and allocates itself at start-up. ORACLE says not to touch them for the record, but by reading the documentation carefully, for the purposes of NON-PRODUCTION systems, you have a little wiggle room. For the install referenced here, the Web Cache, J2EE, Portal and Wireless options were installed, Business intelligence was left out, as even with the increased timeouts, the system couldn’t handle the load.
Now yes, this does make your normal 90 minute install of OAS and Portal take upwards of 3-4 hours, but it will take. Of course, backup the whole system once it’s in, and then go back to tweaking the timeouts back down. Surprisingly, you can actually get the system to respond well to external requests, even though the console itself runs very slow. In my configuration, the external response time was only about 5 seconds (most people say the average net person is willing to wait 3 for a response) for most pages.
The end result is a basic install of OAS and Portal, on the same box, ready for dev work or process testing. Obviously, given the limited resources, you can’t have more than about 10 concurrent users or even then the tweaks stop working and the system grinds to a halt.
The system this was built on had this for hardware:
- Intel d850 desktop mainboard, 1.4 GHz Pentium CPU, 640 MB of RAMBUS PC800 RAM
- Linksys 10/100 PCI Network Card
- Matrox Millennium G550 AGP Video
- Maxtor 20 GB UDMA100 Drive (system/ pagefile)
- Maxtor 10 GB UDMA 66 Drive (apps/data)
Mitsumi 52x CD-Rom
Configured with each hard drive as a Master on each IDE chain, with the CD-ROM on the Secondary Slave channel. No audio whatsoever. Windows bundled video driver for video, and Linksys installed network drivers. Primary hard drive dedicated to OS and a fixed size 2GB swap file. Diskeeper installed as only other program on OS. IIS Lockdown was run, and Frontpage extensions enabled. No server roles defined. Set to optimize network traffic. Secondary drive dedicated to Oracle applications and data storage (didn’t have a 3rd drive to use for that). CD-Rom disconnected once system install complete to get every last drop of I/O out of the controllers.
Oracle was configured with only 5 users (above the built in ones) at varying levels of access privileges. Portal was upgraded to 10.1.4 and a custom front-end page was built for the Portal system. No support was purchased from Oracle, so no effective DB tuning could be performed. After each major component was installed, a complete defragmenting was performed, and a backup made.
I don’t recommend this type of exercise for the faint of heart, but it was a fun challenge, and taught me a lot about how some of the internals work together in the Windows platform Oracle install to make it all happen.