High CPU

    Hello Marcel.


    Sorry, this is all there is in the previous log files....but please read on.


    Interesting thing is, that when I "fixed" the issue with another system trying to store images with already existing images from another patient on the same image UID then the system is no longer getting up to 100% cpu.


    This Conquest server is used as backup for Carestream System 5 server that keeps retrying to send the studies over until it manages to do so successfully. Since it never managed to get a success when sending those over, it kept trying, and in this process it seems to have used up 1 core for every retry. The server has now been running 24 hours and is still at "0%" cpu use. (before I fixed the issue with the studies it would be at 100% after 24 hours for sure)


    I managed to replicate this :-)


    I did the same change in Carestream System as before, that is, merge a study to another patient. Doing so seems to change the patient name and ID of the images, without changing the UID.
    First I tested with US images, and I would not get any cpu load when sending them over to Conquest.
    Then I tested with MG images like those that caused the problem before and "hurray" it worked.... eh that is.. it fails...


    Each time the Carestream system tryes to send this "merged" study over, it will "freeze" one CPU core.


    I did this with test images so I could send them to you for testing. I hope you dont mind, but I uploaded them.


    During the test I enabled Debug logging and this is the result of trying to send one "changed" study over.




    Unfortunately for the progress of this matter, but fortunately for me :-) I am going on 2 weeks holiday now. (I will leave on monday afternoon)
    During my holiday I can not connect into the server, but still can answer some questions.


    Thanks for the help and for Conquest, it certainly is great dicom server.


    Best regards
    Steini.

    Hi,


    I tried to reproduce this sending from another conquest, and the conquest query/move client hangs up after the first fail and no 100% cpu occurs. In your last sample it sends two images. So it seems the problem is also related to how the sending party responds to error messages. But I will keep looking.


    Edit: it also seems strange that the log says the thread ends, while in fact it starts using 100% CPU (you are positive it is at the same time?). As far as I can see in th code, after this message, ServerChild returns, ServerChildThread returns, DriverHelper returns, and the thread ends.


    Edit: also the very fast operation could be strange. The server recieves some large files (17 MB uncompressed), compresses it, and then fails to save to the database. All this in less than 1 second.


    Marcel

    Hi,


    Hi Steini, could you try to reproduce the same effect sending from a conquest server? If in the receiving server you add "StorageFailedErrorCode = 0" in dicom.ini, the sending server would not stop sending and the net effect should be the same. I have trouble reproducing the same effect.


    Edit: it would also be worthwhile to positively determine that the 100% CPU load does not occur with 1.4.13. I can then slowly downgrade parts of the code to see when it dissapears.


    Edit: the ***Error saving to SQL: message precedes a large memory leak. Does the 100% occur at the first instance or after a couple? Could shortage of memory be a factor?


    Marcel

Participate now!

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

Register Yourself Login