ProvideX Problem

[Sanjay Tailor]

Hello,

I am not sure if this the right forum to discuss the problem I am having. I have a D370 with 256MB memory and with HP-UX 10.20. I have two applications. One is called Universe ( UV) and the other is ProvideX ( PVX). I have run UV for about 2.5 years and had no major problems. I loaded PVX about 3 months ago and this process seems to hog a lot of CPU time. In a listing of TOP, PVX ususally ranks topmost. Each UV process takes about 0.5 to 1.0 of processor and PVX will take about 10 to 15 percent of processor. When it does run it spikes the processor in usage.

To any users of PVX, is this a problem with PVX or my machine. Can anyone suggest how I can improve performance before I consider bigger hardware ( a last resort ). Is it a hardware problem ( too little memory, processor)? I am pretty sure it is a software problem since I can have 100 users of UV and the machine queue length will only be about .70 but with just one user of PVX runing the processor might run sometimes at 1 to 1.5 queue length.

Any help is appreciated,
Thanks
Sanjay.

[Tim Malnati]

Universe usually does not run well with other applications on the same machine. This is not the fault of UV but more the fault of the other application involved. These other applications are usually so resource intensive that UV is sitting their waiting. I don't know anything about ProvideX, but it sounds typical.

There are only a few things that you can do to help. If you only have a single processor on your D machine; add another. HP has Process Recource Manager (PRM) software, but it is somewhat limited in what it can control. Not long ago I had the unfortunate experience of trying to control both Sybase and Universe on a T600 9way. UV would be screaming with more than 1000 users until Sybase processes started up; even one Sybase process would have a drastic effect. PRM would help cpu resources, but the product has no way of controlling disk i/o. You can add memory to increase the data in cache, but you have to be careful.

The better solution would probably be to add another machine for ProvideX. I'm not sure of the resource requirements, but an A class machine would be the first thing I would look at. If shared data is an issue, there a variety of solutions to help you out with this as well.

[Sanjay Tailor]

Tim,

Thank you for your reply. Very interesting about UV. I do not have such a large user base but that one process of PVX really hogs processor time. I do not see a large drop in UV performance but the system itself works just a little bit harder than previously. IS it that UV is trying to be "NICE" and getting beat up ( if you know what I mean)?

Thanks,
Sanjay.

[Tim Malnati]

I just did a quick websearch on ProvideX and found a product from Sage (in Canada). If this is the one you are using, I would suggest there are a lot of other products that would be far better suited in a Universe environment. If the Web connect is what your doing, I would suggest that either UV/Web from Ardent/Informix or Coyote from Modular Software ( www.modsoft.com ) would be far better in many ways. Very often 'ease of development' does not easy on the machine. From what I see this is a product that is built on top of Business Basic and ODBC. A far cry in terms of productivity from UV basic and direct database communication.

[Sanjay Tailor]

Tim,

Thanks for your reply. You are right in that ProvideX comes from Sage in Canada. The only reason I have the two applications on the machine is to save money. The 2 applications never talk to each other. Yet ProvideX still slows down the server. Do you think I should still migrate PVX to another machine?
Thanks,
Sanjay.

[Brad Marks]

Sanjay,
Although I'm not well versed in PVX I do use Basis' Pro5 on a K420. PVX, like Pro5, is an interpreted business basic, and, therefore, does use a lot of CPU. At peak times my CPU utilization averages around 65%. I also found that when we went from 256mb to 768mb of memory, performance increased quite a bit. I also just purchased two additional processors which I'm hoping will help widen the processor bottleneck. Hope this helps.

[Tim Malnati]

There are a variety of factors that I would need to become much more aware of before I could give you a solid recommendation. I will elaborate some thoughts though.

The rule of thumb from Ardent/Informix concerning memory is 2.5MB per user. Often this number may be slightly high but it does not take into account additional memory you may need in cache for the application to perform well. You may have had some swap paging activity (before PVX), but it was probably minimal. Before PVX was introduced it seems that your system was relatively happy with your current configuration. I don't know if you have one or two processors on your D machine, but I would suggest that a well written application can perform easily with one alone. A second processor would help during those times when those pesky select statements are running, and will drastically improve maintenance functions such as file resizing. A 0.7 load average suggests to me that the application was probably in good health for the user count that you have. On a UV system it is important to determine the actual disk i/o requirements during production hours to more accurately judge the overall health of the system. Disk i/o is much more often than not the usual bottleneck on a properly configured system.

Now here comes PVX. I know very little about this product other than what I have seen on their website. Brad has mentioned that processing is inturpretive in this environment, some friends of mine in Pro5 shops tell me the same. This will have a significant effect on cpu performance in particular. But I also notice from the PVX site that the framework of their engine is such that it could require a significant amount of memory. I'm not sure of this, but it seems probable. Additionally, I don't know specifically what PVX is processing. What you have mentioned so far is probably either a small level of batch activity or a significant level of interactive processing. In either case, the impact to disk i/o could be creating a problem as well (this may have a drastic impact on UV in particular).

If Glance Plus Pack with full Measureware is installed and has been running on your machine, most of the answers are there waiting to be tapped. I recommend Glance on all production servers. But here is the rub, Perfview Analyser will tell you a lot of the answer but it costs about $8K and has some hardware requirements of its own (best run from another machine and needs an X station for display). This is obviously a bit expensive if you have a single HPUX machine in your shop.

Here are a few more things to look at as well. How important is the PVX application in the scheme of things. Is it important enough to significantly impact the productivity of what appears to be your mission critcal system and the 100 users, etc, etc, etc. For the price of Perfview, you could opt to purchase a smaller A class machine for about the same money. But now you are looking at some additional support costs, administration time, etc. Dressing out the D machine further may improve things, but how much? You will still have a fight for resources between the two environments to some extent. You could also probably purchase a Universe based replacement application for even less. (My comment earlier about the web stuff was a guess where so many UV shops have added this functionality in the last couple of years.) Another thing to consider; what did the vendor of the PVX package promise you? It may be high time for that vendor to eat part of this problem if he promised you that it would run flawlessly in your existing environment.

If you would like some more, put up your email address and we can take this offline. Hope this helps.

[Sam Nicholls]

As mentioned in a previous reply, HP Process Resource Manager (PRM) may be a solution. You could put the PVX processes in their own PRM group and limit how much CPU, memory, and disk bandwidth the group can use.

You can also dynamically reconfigure PRM without rebooting the system. So you could use cron to change the PVX group's limits during certain times of day. This is useful for throttling non-critical applications during business hours, then giving them more resources after hours.

More info about PRM is at www.hp.com/go/wlm

Regards,
Sam Nicholls
Hewlett-Packard