Linux on 390 Port <[email protected]> wrote on 11/28/2006 01:19:02 PM: Marcy Replied:
> David wrote: > >3) Have a Java profiler handy. Much of the animal product that doubles > as application programs that you'll be handed from the small-systems > world worked acceptably there because CPU cycles were low-cost. Stupid > programming techniques will become highly visible very quickly in this > environment, and without evidence that "it's the program, stupid", it > will be your fault. > > Very good point. Programmers do crazy things when they are used to > having the whole machine to themselves - real life example a) Let's wake > up every 2 seconds and see if such and such process is alive b) Let's > run log scanning to see if we have any occurences of error messages we > should report (prod logs are HUGE). We encountered that very early on. We said 'here is your problem' they made ONE code change and CPU utilization dropped by 70%. Another thing to look for is taking advantage of the build in hardware features like hipersockets to get at z/OS resources such as DB2 if they're on the same box. > > None of our WAS virtual machine are bigger than 1500M. A lot depends on > the app and how many apps per virtual machine. Just about all of the > run MQ Series as well. > > David mentions cluster. That requires the ND version of WAS - you > probably won't get to try that out with the trial version, but is > definitely the way to go when you purchase. > Once you get into many instances look up Steve Wehr's paper on running WebSphere with ONE executeable directory and sharing that to each linux guest, to 1) minimize your maintenance nightmare and 2) reduce the amount of disk you needlessly would duplicate. > For large apps, you may want to consider running IHS in a sep virtual > machine too if you are using that. We found we gained some performance > doing that. We wish we did that and eventually will do this. If you have the IHS front end in a smaller machine and it has the plug-in in it, you can direct traffic to the members of the cluster. A node of the cluster can go down, and other nodes will still do work. Right now we have our IHS on our primary node for the cluster. So we can't ever take the primary node down for maintenance without an outage. If you run IHS as it's own guest, your maintenance is invisible to the customer. Or nearly so. -J > > -----Original Message----- > From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of > David Boyes > Sent: Tuesday, November 28, 2006 10:35 AM > To: [email protected] > Subject: Re: [LINUX-390] Websphere > > > Any problems/headaches or other words of advice anyone wishs to share > > about Websphere on zLinux? > > 1) Websphere expands to fill all available resources, both human and > machine. Plan on it. > > 2) Make sure you have plenty of contiguous page space. Virtual machines > containing WAS tend to be very large. > > 3) Have a Java profiler handy. Much of the animal product that doubles > as application programs that you'll be handed from the small-systems > world worked acceptably there because CPU cycles were low-cost. Stupid > programming techniques will become highly visible very quickly in this > environment, and without evidence that "it's the program, stupid", it > will be your fault. > > > This will be on SUSE 9. 31 or 64 bit for Websphere? > > 64-bit. Helps ameliorate #1. > > > I can start the install on z/VM 5.1, but I have z/VM 5.2 on second > > level. Should I wait to install Websphere until I'm on z/VM 5.2? > > If you can, wait until you have 5.2 up. WAS machines often rapidly > expand beyond 2G, and you'll see the 2G limitations of 5.1 very quickly > after that point. > > > As this is just a test, I plan on installing everything in the same > > package (that is the Java machine along with the webserver). Big > > mistake? > > Not huge, but warps your test results somewhat -- philosophically, it's > always better to start as you mean to continue, and splitting things up > also allows you to demonstrate the ability to construct both production > and test environments on the same system. Having multiple small > instances for VM to juggle is usually better than a small number of > ginormous instances. It's where you want to manage the complexity > (inside WAS or at the VM layer). The separate machines also give you > finer control over resource utilization caps for different pieces of the > app. > > > If we start to go the route of Websphere, I, most likely will install > > it over a dozen times in the next year. Different variations of dasd > > setup and machine setup, to see which meets our needs best and also to > > > allow me to take "baby steps" in implimenting new technology. > > Another reason for small, separate servers. You can have different > virtual machine configurations in the same WAS server farm and see which > one works best. You can then take the others out of the WAS cluster with > only a little pain, rebuild them in the way that works best, and bring > them back. > > Consider carefully whether you really need all that WAS overhead for > your apps. Tomcat may be more than sufficient for your apps, and is a > LOT lighter weight. > > -- db > ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
