DGATE fails

    I am having an issue with my CONQUEST server. The service is running but dgate.exe keeps dying and will not come back online by itself.


    I am running version 1.4.14.2


    Server Information
    On Server 2008 Enterprise SP2
    256GB Memory
    2.66GHz (4 processors)
    64-bit OS
    ungodly amount of storage space (over 10TB)


    Has anyone seen this before? I am coming in every Monday to find the dgate.exe has stopped. Normally I can just stop the service, start it back up and see dgate.exe start back up and everything goes fine. This morning though dgate.exe kept failing after about 30 minutes. I am restarting the server but that takes about 30 minutes to an hour because of our database size which is in the TB range.


    Thank you,

    Hi,


    First, backup (I would use 7z) the database files.


    Then, how big are the database files? And can you find the crash address? And what does the log says when it crashed? You may have hit some unknown limit in the DbaseIII code (I tested up to 6 million images).


    Then for completeness try to startup with the latest 1.4.16j (top post in the forum). Just backup your dgate.exe and replace it with the latest one. See if it still crashes. The most important change in in the way compression works, but the default setting (without changing dicom.ini) should work the same as 1.4.14a.


    If that fails and you have an earlier backup of the database try to roll the database back a few days (keeping the newly backuped).


    Good luck,


    Marcel

    We are currently housing about 26 million images but it is on a seperate SQL server. Right now we are restarting the server which has been "shutting down" for about 5 hours. We are going to try to updating the dgate to the latest version you mentioned below.


    We are using CONQUEST to just recieve images.


    I will let you know how that goes.

    Hm,


    I assumed you used DBASE, since that requires long startup times.


    I would try to run SQL server database maintenance. A SQL server should not take that long to startup, and dgate does not read anything from a SQL server when it starts up. So I am curious what is taking the long time and what crashes the server. In SQL server, 26 million images should not be an issue (this is approximately the size of our old research server using SQL server).


    Marcel

    Question:


    We are currently using the 32bit version. To upgrade to the 64bit version.


    Can we just drop in the dgate64.exe and replace it that way or do we need to update any dll's as well? Like the libmysql64.dll and libpq64.dll?


    The SQL database is stored on a separate SQL server. So we don't have to worry about that. Just FYI our shutdown process took 7 hours. Our SQL server was never shutdown this was just shutting down the CONQUEST server.

    Hi,


    the 64 bits version would use 64 bits ODBC and does not require additional DLLs. However, it will not be started automatically from the old conquestdicomserver.exe. I would suggest the following:


    backup your dgate.exe
    copy dgate64.exe and dgate.exe from the 1.4.16k or 1.4.16 distribution
    run dgate as: "dgate -v" and see what happens
    if that works, kill it with ^C
    rund dgate64.exe as "dgate64 -v"
    see if that works
    if that works, kill it with ^C


    If all answer yes, update conquestdicomserver.exe as well.


    However, I have no idea what is taking so long, or is the server very active all the time?


    Marcel

    What about DgateServ.exe do we need to update that as well? We did the update for dgate.exe to dgate64.exe and the conquestDICOMserver.exe


    We uninstalled the service and reinstalled it so it would start the dgate64.exe and it is up and running. I am pushing 500+ images right now to test it to see if dgate will stay up and running. Here the past two days it hasn't stayed up for more than 10 minutes before it would just fail.


    So now on the conquestdicomserver.exe when we open that under "Configuration" there is a check box "Keep Server Alive" do we need to check that? Because we have seen where dgate would stop and the service would not restart dgate.exe even though the service was still running.




    The server that is accepting these images is taking in about 10,000 plus images a day. We have generated about 2TB of data since January 2012.
    So don't know what it does during the shutdown process that requires so much time.


    We are testing now by sending about 600 images to test if it works then we will open the flood gates.

    Hi,


    dgateserv is the boss of dgate if it runs as a service
    conquestdicomserver is the boss of dgate if it runs as application


    I guess you need to replace all three of them, if you want to run the server as service. However dgateserv.exe has no function other than starting dgate.exe and installing / deinstalling the service so you can replace it with little risk.


    Keep server alive should not be required - it tests the server once a minute and kills and restarts it if it does not reply timely. The server is however generally highly reliable. We do not have the keep alive option enabled on any production server in our hospital.


    Did dgate64 start up instantly? My feeling is that SQL server may be the culprit slowing things down. If database maintenance is not regularly run, the first queries kan take a very long time as the B-trees used to lookup date become highly unbalanced. There is a little information about this and my tests in the manual.


    Marcel

    dgate64.exe started up instantly.


    We replaced all three files, once we replaced the conquestdicomserver and reinstalled the service it referenced the dgate64.exe instead of the dgate.exe. The service started up quick, and we started testing to see how reliable it was. Hopefully dgate64.exe will stay up and running.


    No one actually query's the server, we use this as a central repository for storing images. If I do run a query though it is very fast and responsive. We are going to perform another server restart this weekend to see how long it takes to restart. I would have to ask our database administrator how often maintenance is done on the SQL server but I am pretty sure it is done quite often. I'll let you know how the second restart goes this weekend.

    Marcel,


    So everything has been working fine until today. dgate64.exe grabbed all 28 processors and maxed them out at 99%. So we had to set the processor affinity so it didn't have access to 16 procs. It is also using about 18GB of RAM out of 256GB which is not a concern to us right now.


    dgate64.exe has not failed though or stopped so that is good!


    I can send you our dicom.ini file and some screenshots if you would like. Do you have an e-mail address that I can send them to you. Once you receive my e-mail you will understand why I do not want to post them online.

    Hi,


    From the email exchange, I found out the 230 source servers (1.4.14 I believe) are bombarding the central server (on a really huge machine). Under these circumstances, the 1.4.14 and 1.4.16i servers leak memory and threads. The 32 bit server however, only crashed because it was out of memory; the 64 bit server keeps going. I hope I will be able to find out what causes the leaks; although we do not see them in our hospital.


    Marcel

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login