System Responsiveness

[omni]

Roger,

Please see below email. This client does not use any client server, but all users are on a terminal server, with the app and dll on the terminal server, and the files on the data server. Has worked well that way for years. (since 2012). Obviously, the file sizes have grown, and they get in these ‘deadlocks’ during the day, probably when all the users are hacking away, and the server is just busier. They also use multi-processors (4) and memory is 30g, using 80% when I checked today. There are no work stations or users logging into data server.

I know of no method to identify what may be happening when the users cannot open the main booking (it takes forever) and assume it is one file causing the problem, as there are 30-40 files open on that menu. Fairly consistent spot that has the issue. Sometimes it can be seen using computer management and there is a file that is open 30-40 times and the cdx is open 50 times, indicating an issue opening and closing file on the server for a user. There are no errors.

I cannot commit to the client server, as they want multiple clients and this is the only one that it may help. I have suggested the client server to my client over the years, but they ignored it and the speed and integrity most of the time is excellent. Immediate responsiveness.


Below is email:

Fred,

The issues with responsiveness are becoming a problem that we cannot avoid, and it’s bothering me that we are not able to pin them down well enough to explain what’s going on for your guys to help. I’m sure it’s equally frustrating for your guys to see a ticket about responsiveness, log in to our server, and have the program run perfectly fine.

To isolate the source of the problems, so far we’ve gone through the process of allocating all available resources to the remote server, we have monitored and checked CPU, memory, and disk I/O numbers for the last two weeks, updated all of our servers to the most recent Windows rollouts, and even updated the firmware(s) and respective devices that make our network infrastructure. That pretty much eliminates a hardware or server restriction causing problems.

At this point, we have also done our best to stamp out frivolous uses of the system that could be having an impact, such as unimportant reports being run during business hours and unnecessary large exports. Major routines are run on their respective days (billing/invoicing/payroll Friday, payroll/emailing/EDI on Monday, deposits posted every afternoon usually after 4) and nothing else really happens outside of early morning reindex procedures. Servers are still rebooted every day at 2am on the spot. That pretty much eliminates most of the major regular activities from directly causing the issues, although they may still contribute in small amounts that add up.


Initially, the problem really started several months ago where intermittently (it started as once or twice a week, not more than once per day, and slowly increased to about once per day) the software would become unresponsive or extremely slow to load anything for several minutes during the afternoon. Usually we would simply wait out the problems and they would resolve themselves within a few short minutes, but occasionally they would last long enough or be problematic enough that we would require a server restart. Lately, the problem has gotten worse, to a multiple-times-per-day issue. Generally, the problems do not seem to be as severe (or go unreported) during the weekends or after hours, which leads me to the suspicion that it would be user/file related, hence log 3545 detailing what I watched this morning.

Since we had 93 open copies of OPMENU running today during the most recent problem (none of them were showing an abnormal amount of memory or CPU usage), it seems feasible to Ronnie and myself that perhaps the issue is that we have hit a wall of too many users running the software. I know you have other clients who are larger and have more users, but I suspect our version of the software is more heavily modified than others’ versions; perhaps we simply have too many additional things happening and it is starting to slow us down. The other thing that seemed very feasible was the idea that file handles were not releasing properly or race conditions were occurring where multiple users were waiting on a locked file and creating deadlock situations.

*******************

After further discussion the client may want to try the client server, but unsure if that helps the 'deadlocks' as he calls them. Most of the time the system is very responsive due to the set up running the app on the remote server with the files on the data server. Opening the app on the data server takes 10 seconds to load, for example, but less than 1 second on the remote server.

It also may be that the data needs to be purged on his major files, which is fairly standard, but never 'archived' on his system. His files for main operating files are around 400,000 records, which is not that large. We have clients with millions of records, but not with that many users.

Looking for any suggestions..


Thanks

Fred
Omni

[unixkd]

If your proposed Client/Server is ADS then you can be rest assured that the problem may vanish for ever. We make it mandatory for ALL our client to get ADS. It is extremely low priced and that make it easy for them to acquire. If you are already using Xbase++ 2.0 then you can explore cubeSQL (a client/server version of SQLite) that is equally low priced.

Thanks.

Joe

[rdonnay]

cannot open the main booking (it takes forever) and assume it is one file causing the problem

I have a customer who has had problems like this with Windows 8 workstations.

We found that if we opened the files on the data server and left them opened that the problem disappears.
We never found another solution.

I suggest writing a program that only opens the files in shared mode and leaves them open.
It may not solve your problem but it's so simple to give it a try.

[bwolfsohn]

Fred,

Regardless of the # of records, this does strike me as some sort of a design issue...

a couple of items off the top of my head..

Are there a significant # of deleted records ??

Do you use some form of str(recno(),10) in everyone of your indexes to insure unique index keys ?

[rdonnay]

Do you use some form of str(recno(),10) in everyone of your indexes to insure unique index keys ?

This is an important point.
I2Bin(RecNo()) also works.

Example

INDEX ON CustNmbr + I2Bin(Recno()) TAG 'CUSTNMBR'