Posts by drain

    Update: I have added "memory reservation" for 100 MB and it looks very good now: when the server needs memory, container grows, after it shrinks down to 100 MB. Before it was just growing and growing...

    I have found out that Docker provides settings called "memory reservation". This might help to reclaim the memory when it is not needed anymore:

    Quote


    The container can use as much memory as it needs. The memory reservation setting ensures the container doesn’t consume too much memory for long time, because every memory reclaim shrinks the container’s consumption to the reservation.


    https://docs.docker.com/engine…/#user-memory-constraints


    Marcel, thank you for your insight.

    Marcel, maybe it is Docker related. The container have memory usage about 2.3 GiB. I tried to find some more info about the memory, here is a memory stat from the docker. I see cache and inactive_file are pretty high:



    https://docs.docker.com/engine…memory-metrics-memorystat

    There is only one process running in the container. PID 1 belongs to a bash script which makes sure that log and data directories are created and starts dgate -p5600 -^/dgate/logs/serverstatus.log

    The exportconverter string is simple:

    Code
    ExportConverters = 1
    ExportConverter0 = 'postprocess.sh "%f"'


    Longer story: I have created a docker container with the server, based on Debian image (the host machine is also running Debian), all worked well but I have observed that the container is growing and never shrinking (or shrinking just some megabytes but not more), the biggest container size I have seen until now was over 2 GB, after I have restarted it. In the container is running only the dgate server, when I execute "pmap" in the container with the PID of the dgate server, it corresponds with the container size as Docker shows.


    I have found out that in my script for post-processing I have called dcmdump (which by default processed all the data, see +M option). When I tried to use -M, the memory foot print looks better right now... but it is probably just about making the symptoms smaller:

    Quote


    +M --load-all load very long tag values (default)
    -M --load-short do not load very long values (e.g. pixel data)

    Hello Marcel,


    thank you for your replay. After some more testing it looks the problem was in my ExportConverter where I use dcmtk and other tools to postprocess the data. When I commented it out the memory use is pretty low and stable. Thank you for your time, I should have tried it already before.

    Hello Marcel and everybody.


    I have a question related to the memory consumption of the DICOM server. Is it common for the server to use over 1 GB of memory in the idle state?
    I am running Debian 8 (kernel version 4.9.2-2~bpo8+1), server version 1.4.17d with MySQL.


    Marcel, thank you for having your eye on it. That is a good point. The postprocess script doesn't call dgate but in some situations deletes the file. I will have to check it. That must be it.

    Here is my dicom.ini:

    Hi Marcel and everybody.


    I am experiencing "Could not remove IOD":

    Code
    Wed Oct 5 07:46:01 2016 Application Context : "1.2.840.10008.3.1.1.1", PDU length: 28672
    Wed Oct 5 07:46:01 2016 Presentation Context 0 "1.2.840.10008.1.1" 1
    Wed Oct 5 07:46:01 2016 Presentation Context 1 "1.2.840.10008.5.1.4.1.1.6.1" 1
    Wed Oct 5 07:46:01 2016 Presentation Context 2 "1.2.840.10008.5.1.4.1.1.3.1" 1
    Wed Oct 5 07:46:01 2016 Presentation Context 3 "1.2.840.10008.5.1.4.1.1.6.1" 1
    Wed Oct 5 07:46:03 2016 Removed file: [MAG0:18476-1/1.2.410.200001.1.1103.1950654136.2.20161005.1083311812.330.1_0001_000001_14756532500915.dcm]
    Wed Oct 5 07:46:03 2016 ***Could not remove IOD ../data/18476-1/1.2.410.200001.1.1103.1950654136.2.20161005.1083311812.330.1_0001_000001_14756532500915.dcm
    Wed Oct 5 07:46:03 2016 ***Error saving to SQL: 18476-1/1.2.410.200001.1.1103.1950654136.2.20161005.1083311812.330.1_0001_000001_1475653563091f.dcm


    Unfortunately it appears only from time to time. I have no idea why I get the message.
    Some ideas?

    Ah, so. I always did only --debuglevel:2. Thank you!


    I think, it looks clear now "1.2.840.10008.1.20.1", Storage Commitment:


    Just a question, are there any plans to support it in the future?

    I just tried to compile it on Raspberry and I finished with following message:

    Code
    /usr/bin/ld: lua.o: undefined reference to symbol 'dlsym@@GLIBC_2.4'
    //lib/arm-linux-gnueabihf/libdl.so.2: error adding symbols: DSO missing from command line
    collect2: ld returned 1 exit status


    :cry:

    Hi Marcel,


    I tried the version 1.4.17e2, it looks the same.

    Code
    Mon Jan 19 11:05:40 2015 UPACS THREAD 6: STARTED AT: Mon Jan 19 11:05:40 2015Mon Jan 19 11:05:40 2015 *** connection terminatedMon Jan 19 11:05:40 2015 UPACS THREAD 6: ENDED AT: Mon Jan 19 11:05:40 2015


    But I just discovered when I added to dgatesop.lst:

    Code
    STORAGECOMMITMENTPUSHCLASS 1.2.840.10008.1.20.1 sopSTORAGECOMMITMENTPUSHINST 1.2.840.10008.1.20.1.1 sop


    It started to bring following errors:


    Storage commitment is not supported, right?