The OpenEdge Hive

I was talking to my managers about the new hardware configurations and I mentioned that for test like readprobe, more CPU can introduce issues,and I think everyone of them was holding their breath and thinking "what is this guy talking about?". but the fact is that more CPU don't always means better performance.

One of the frustrating tasks can easily be the testing. When you are developer, you are asked to do the unit test and sometimes system testing, the full scaled test. It is a tricky thing in my opinion and here is why. When you are programing, you are confined within the parameters, usually the business requirement, things like with this rule with this condition, and those baselines, I need the program to produce this result or range of results. But when you are done, you are facing the whole another range of test, the system test.

In this particular place, now I look back and think back, in the span of two to three years, how the infrastructure has changed with performance tuning effort...

To collect performance related data, I think VST is the way to go. It is original and nothing beats the original. I feel like I never know enough of them and here is the place I can learn a few "useful" one, There will be "VST two", "VST three", etc.

this writing is the summary of an old document "Progress Tuning Workshop" from 2001.

1. _actSummary
aiming for high commit(high throughput), that's _summary_commits field
look at the _summary_flushed row for the flushed block, that will tell you if you have enough APWs

one of the big factors I noticed when I was doing the test to move the users from the share-memory connect to the remote-client connect, was the network messages. I never paid close attention to how they are used or how big those messages(packets) are. In the test servers, after I moved the users to the frontends, the CPU on the database server didn't seem to drop at all, one thing I noticed was the system CPU was a lot higher than the user CPU in the vmstat output which was not what I wanted to see.

I never use OE managment before, not sure if there is a web version and I think web version has an edge when it comes to monitoring. The first version of charts I built was on OFC(open flesh chart), it is a great open app. It has more updated version now, working more with JSON(if I remember it correctly). One thing I needed and it doens't have is the abablity to see the trends unless you draw it, that's something Google charts can provide. Have you ever noticed on the google finance charts, the annotatedtimeline chart.

The last project I was doing for this company was database reorganization, to remove the unwanted tables/extents/areas . The task was to get rid of the areas and free up the SAN space. First I went through the process the analysis of data see which table in which area; which way I should should move to make the whole thing more effective; after that, it is the process of testing which methods I should use to move the tables to different areas, table move or dump&load.

This will the summary of my experiences in last couple of years over ports in Progress (and AIX).

Progress uses the buffer pool which is the single largest memory usage by the database engine. Other than that, the 102B user each uses around 30M of memory. So for 1000 users, the system will use about 4G of memory and that is not a lot. The VST stats are part of the memory, they go away when you shutdown the database. VST has many parts, so if you are not careful, they might bite you when you least expected.

In the 102B06 release, one of the most beneficial improvements is the LRU skip.