mfg/pro resposnse time issue

sreekuax

Member
Hello All..

Recently we installed a new instance to mfg/pro eb2. But the instance is having slow response to each functional keys...say accessing a menu(eg : 1.4.1, 28.1.1...just examples...all menus )... processing i.e prssing F1.. its taking almost 10 secs to see the next frame... No idea why this is happening as other instances responses in 1 sec or less than that for every functional keys....

Can anyone suggest a way to solve this out ?....​
 
It's probably spam.

In reply to your question... that's a rather broad question. Did you check the "go really slow" box on installation?

More seriously... what's different between this install and those which perform well? The quickest way to see obvious differences at the database level is to extract the 50 or so lines from the .lg file that come immediately after your most recent startup. These show the startup parameters that were actually used. Do the same with a database that performs well. Compare and see what is different. If nothing is different then the problem probably isn't a simple and obvious parameter change.
 
It's probably spam.

In reply to your question... that's a rather broad question. Did you check the "go really slow" box on installation?

More seriously... what's different between this install and those which perform well? The quickest way to see obvious differences at the database level is to extract the 50 or so lines from the .lg file that come immediately after your most recent startup. These show the startup parameters that were actually used. Do the same with a database that performs well. Compare and see what is different. If nothing is different then the problem probably isn't a simple and obvious parameter change.

Hi Tom,

really excited that I got a reply...I am in sea you can say for searching an answer for this issue..
am not sure what is the "go really slow" box on installation? we are in eB2 CHUI SP8 version and while installation of the new instance(one database multiple schemas).

There is no such difference but the one is performing well and one is having issues are setup in same code directory and fetching same code.

Can you be more specific in giving me the name of the .lg file fully ?

Also just now I found that inside client script of the good working one, the .pf (parammeter file) is residing in the same propath where it fetches the code while the issue one's is residing a dir other than its propath. !!

illustration :

working well one - client.working.well is residing in /abc/def/ghi/jkl
.pf of the working well - working_well.pf is residing in /abc/def/ghi/jkl

issue one - client.issue.one is residing in /abc/def/ghi/jkl
.pf of the issue one - issue_one.pf is residing in /abc/ghi/def/

well this could be a problem ... ???? leading to slow response ?

Please help
 
There are an endless supply of reasons why you might be seeing slow response times.

You are posting in "database administration" so my answers tend to be focused on reasons that might be related to database performance. Of course if you don't have a database performance issue I'm just wasting my breath.

There is a log file for every database. Mfg/pro usually has several databases associated with each instance. The names vary depending on which version of mfg/pro this is and who installed it. But the log files will all be of the form <dbname>.lg.

Branching out from "db" topics... Yes, the path can make a difference to client performance. Being at the end of a long list of possible path entries, some of which are on slow or inaccessible network drives, is especially deadly.
 
There are an endless supply of reasons why you might be seeing slow response times.

You are posting in "database administration" so my answers tend to be focused on reasons that might be related to database performance. Of course if you don't have a database performance issue I'm just wasting my breath.

There is a log file for every database. Mfg/pro usually has several databases associated with each instance. The names vary depending on which version of mfg/pro this is and who installed it. But the log files will all be of the form <dbname>.lg.

Branching out from "db" topics... Yes, the path can make a difference to client performance. Being at the end of a long list of possible path entries, some of which are on slow or inaccessible network drives, is especially deadly.

Hi Tom,

Surely we dont have a DB performance issue. Its been clarified by the DBA. Its not like I puprosefully posted the question in this space for DB .. I have asked the same in QAD mfg/pro section also. I was forced to post the question here because I was not getting a reply from mfg/prto section... :)

Hmm it seems we are in sea !!
so propath seems to be an issue.. does it lead to another install for curing this ????!!! :(
 
PROPATH (or PATH) /could/ be an issue. It seems to be a difference but that doesn't necessarily make it a problem.

Did the DBA "clarify" that there is no db performance problem with any data? Or is it just a bold assertion?

Anyhow... you can flail around randomly changing things and you might, eventually, get lucky. Or you can step back and start measuring specifics, collecting data and analyzing the situation.
 
Hello All,


We were trying to do a debug test for this issue.
Created a new DB schema exactly as that of the one which is having response delay issues...
Loaded the default tables and created a dummy instance. Now the performance and response was excellent of the dummy one without any data in it..
So we decided to load all the data from issue affected instance to this fresh dummy one..
Loaded... and unluckily... now the fresh one also is having the same response delay !!!!!

We are totally in sea.... and not able to find a way to the shore.... Can anybody help or help me in getting knowing what data or table is causing this problem !!!!!!!
 
So with no data it is fast but when you add data it is slow?

That sounds like a clarification that it is actually a database performance problem.

In which case the starting point is to do as I suggested 10 days ago and share the startup parameters and configuration details. A few details about the server and operating system configuration would also be helpful. You might also want to spend some quality time with PROMON. For starters go to the R&D menu, option 2 (activity), option 1 (summary) and obtain samples (the "s" key) during periods of poor performance and share those.
 
So with no data it is fast but when you add data it is slow?

That sounds like a clarification that it is actually a database performance problem.

In which case the starting point is to do as I suggested 10 days ago and share the startup parameters and configuration details. A few details about the server and operating system configuration would also be helpful. You might also want to spend some quality time with PROMON. For starters go to the R&D menu, option 2 (activity), option 1 (summary) and obtain samples (the "s" key) during periods of poor performance and share those.

Hi ..

Yes I too think so that its a DB issue now.. (after all these doings and R&D !)
Startup parameters.. do you want the client script ?(if so pls tell I can share...)
Server is HPUX with Solaris OS... version of mfg/pro is eB2 CHUI with SP8...

Also can you be more clear from the PROMON section... With my little experience , am not sure if that is a hidden menu or something like that.. if you can be more clear..sure it will be a gr8 help....

Also .. when there was no data it was just superb.. but after loading the data... it slowed down.. can this be a problem of indexing/ index issue of the tables ?
quoting once again.. slowness means.. if I try to access 7.1.1 menu (for eg..imagine any menu) its will take atleast 11 secs to show up the frames and fileds of the menu !...
 
As Tom says, you can poke around in the dark or gather data or, if you don't know how to gather data, then you can hire a consultant to help you track things down ... and hopefully provide some education in the process.

There simply isn't enough data here for anyone to make a reasonable guess.
 
Solaris is an operating system from SUN/Oracle -- not HP. If this is HP gear then the OS is probably HPUX. But just knowing the name of the OS isn't very helpful. The make & model# of the server is also useful. We would also want to know what version of the OS (major, minor & patches) 32 bit or 64 bit, how many CPUs & cores (and what speed), how much RAM, what the disk subsystem is and how it is configured (NAS, SAN, JBOD, fiber, iscsi, RAID levels etc, etc...)

From a Progress db perspective we obviously want to know what version of Progress (major, minor & patches) and all of the startup and config information. As I mentioned way back up top the easiest way to provide most of the config data is to simply take the 50 or so lines of the .lg file following your most recent database start and share them.

Then we would also want to know what the load is on the system and how it behaves. That's where PROMON comes in. I already gave you instructions on how to get to the basic PROMON summary screen. On the OS side of things you could provide "sar" or "vmstat" or "iostat" data. Ideally sampled at the same time that you are obtaining PROMON data.

You might want to consider getting some training. Or attending a user-group ("PUG") meeting such as PUG Challenge Americas

Or you could take Thomas' suggestion and hire a consultant to help you out and teach you all of this stuff (see .sig for an idea along those lines). It would solve your problem a lot faster.
 
Hello,

we identified that ... in the issue instance...the no .of rows for
select * from user_indexes; is 29 rows
and as in perfectly working one is 2538 rows.... We identified that the indexes are not there...
We are trying for a index rebuild... any can suggest if an index re-build will help us to resolve the response delay issue ?
 
Back
Top