Database very slow, after Reboot the Server. - Forum - OpenEdge RDBMS - Progress Community

Database very slow, after Reboot the Server.

 Forum

Database very slow, after Reboot the Server.

This question is not answered
Hello friends,

I have the following problem.
A large database (40GB) is integrated in the RDBMS.
If the server is restarted, it takes a long time until the client can access the DB. It is OE 11.4 and Server 2016 from Windows. If the database runs on the server for some time, the performance is ok. Only after the restart is it extremely slow. It is an ESXI host where a virtual machine with Server 2016 is running, an idea or a tip?

All Replies
  • > On Dec 16, 2019, at 7:36 AM, shubuya wrote:

    >

    > If the server is restarted, it takes a long time until the client can access the DB.

    Was the database shut down in an orderly fashion or did the system crash?

  • Hello, the DB was shut down,it is More than 5 Minutes , the clients can Access dB, there is 128GB RAM, best CPU, only the HDD is Not the best, but More than 5 Minutes , it is too Long

  • Hello, the DB was shut down,it is More than 5 Minutes , the clients can Access dB, there is 128GB RAM, best CPU, only the HDD is Not the best, but More than 5 Minutes , it is too Long

  • It sounds like the database performance improves as data is cached in the -B buffers.  This could suggest that the database itself resides on much slower or remote storage which I think you elude to.  I am not too sure how you could make this any better other than to improve your storage infrastructure

  • > only the HDD is Not the best

    Test read speed of bad disks. Compare with the results on  good disk. Just check the time of 'type LargeFile >nul'.

  • Thank you all, but it is not normann, that it takes more than 5 Minutes , i can login to the application, after log in it takes also 3-4 minutes, are the parameters you know, i can edit,kind regards

  • You are correct.  That is not normal.

    --
    Tom Bascom
    tom@wss.com

  • If you would like to get some help from the forum to improve the situation you should provide some more detailed information about your configuration.  Some things that I would like to know before commenting further:

    1) What CPUs do you have?  ("best" is not helpful)  How many, what model, what clock speed?

    2) What is the IO subsystem?  (knowing that the HDD is not the best is hardly surprising)  Are the HDDs internal to the host?  Or are they in a SAN?  Is there any RAID involved?  If the disks are external -- how is that external device connected?

    3) You mention that you are running in a VM.  How is that VM configured?  What resources does the host actually have? What else is running on the host?

    4) Windows is involved so your users are presumably connecting over a network.  Tell us about the network.  Are the users local to the server or are they connecting over a WAN?

    5) Tell us about the application architecture.  Is it an old-style "fat" client-server application?  Or does it use app servers?  Is webspeed involved?  Or is it, perhaps, a web based app using PASOE?  Or something else?  Is it home-grown?  Or provided by a vendor?  If it is vendor provided then which vendor?  (Someone may have relevant experience with a known application.)

    6) There are many, many startup parameters and configuration options that impact database and application performance.  Some of the most relevant:

    a) To quickly and easily find out what startup parameters are actually being used open the database .lg file and search for the last instance of message "(333)".  The next 100 or so lines list the startup parameters that were actually used to start the db.  Post those.

    b) From a "proenv" command prompt run:  proutil dbname -C describe

    c) From a "proenv" command prompt run:  prostrct list dbname

    If you provide enough detail then there is a good chance that someone will be able to point out opportunities to improve your performance.  Without more information you will only get guesses and uninformed speculation.

    --
    Tom Bascom
    tom@wss.com