dcm4chee runs out of memory

[Dhaval Joshi]

Hi,

I have dcm4chee jboss server running, it keeps on running out of memory every 48 hours, I have tried to increased max heap size ( 2048m ) but does not make any difference, below is log snippet and attaching run.conf, Can any one please suggest how can fix this issue.


2014-04-12 18:13:27,456 INFO  -> (Thread-8737) [org.dcm4chex.archive.mbean.FileSystemMgt2Service] Check file system group ONLINE_STORAGE for deletion of orphaned private files
2014-04-12 18:13:28,978 INFO  -> (Thread-8738) [org.dcm4chex.archive.mbean.FileSystemMgt2Service] Check file system group LOSSY_STORAGE for deletion of orphaned private files
2014-04-12 18:13:41,552 INFO  -> (http-0.0.0.0-8443-26) [com.icrco.services.prefetch.PrefetchQuery] Prefetching for machine with IP: 127.0.0.1
2014-04-12 18:14:26,171 INFO  -> (Thread-8739) [org.dcm4chex.archive.mbean.FileSystemMgt2Service] Check file system group ONLINE_STORAGE for deletion of orphaned private files
2014-04-12 18:14:29,641 INFO  -> (Thread-8741) [org.dcm4chex.archive.mbean.FileSystemMgt2Service] Check file system group LOSSY_STORAGE for deletion of orphaned private files
2014-04-12 18:15:13,747 WARN  -> (Thread-5) [com.arjuna.ats.jta.logging.loggerI18N] [com.arjuna.ats.internal.jta.resources.arjunacore.norecoveryxa] [com.arjuna.ats.internal.jta.resources.arjunacore.norecoveryxa] Could not find new XAResource to use for recovering non-serializable XAResource < 131075, 29, 27, 1-7f000001:def8:530e24a4:47a97f000001:def8:530e24a4:47aa                                                                         >
2014-04-12 18:15:26,292 INFO  -> (Thread-8742) [org.dcm4chex.archive.mbean.FileSystemMgt2Service] Check file system group ONLINE_STORAGE for deletion of orphaned private files
2014-04-12 18:15:29,755 INFO  -> (Thread-8744) [org.dcm4chex.archive.mbean.FileSystemMgt2Service] Check file system group LOSSY_STORAGE for deletion of orphaned private files
2014-04-12 18:16:26,678 INFO  -> (Thread-8745) [org.dcm4chex.archive.mbean.FileSystemMgt2Service] Check file system group ONLINE_STORAGE for deletion of orphaned private files
2014-04-12 18:16:30,171 INFO  -> (Thread-8747) [org.dcm4chex.archive.mbean.FileSystemMgt2Service] Check file system group LOSSY_STORAGE for deletion of orphaned private files
2014-04-12 18:17:27,331 INFO  -> (Thread-8748) [org.dcm4chex.archive.mbean.FileSystemMgt2Service] Check file system group ONLINE_STORAGE for deletion of orphaned private files
2014-04-12 18:17:33,829 INFO  -> (Thread-8750) [org.dcm4chex.archive.mbean.FileSystemMgt2Service] Check file system group LOSSY_STORAGE for deletion of orphaned private files
2014-04-12 18:18:24,510 WARN  -> (Thread-5) [com.arjuna.ats.jta.logging.loggerI18N] [com.arjuna.ats.internal.jta.resources.arjunacore.norecoveryxa] [com.arjuna.ats.internal.jta.resources.arjunacore.norecoveryxa] Could not find new XAResource to use for recovering non-serializable XAResource < 131075, 29, 27, 1-7f000001:def8:530e24a4:47a97f000001:def8:530e24a4:47aa                                                                         >
2014-04-12 18:18:27,236 INFO  -> (Thread-8751) [org.dcm4chex.archive.mbean.FileSystemMgt2Service] Check file system group ONLINE_STORAGE for deletion of orphaned private files
2014-04-12 18:18:33,360 INFO  -> (Thread-8753) [org.dcm4chex.archive.mbean.FileSystemMgt2Service] Check file system group LOSSY_STORAGE for deletion of orphaned private files
2014-04-12 18:19:26,078 ERROR -> (ScannerThread) [STDERR] Exception in thread "ScannerThread"
2014-04-12 18:19:27,621 INFO  -> (Thread-8754) [org.dcm4chex.archive.mbean.FileSystemMgt2Service] Check file system group ONLINE_STORAGE for deletion of orphaned private files
2014-04-12 18:19:28,019 ERROR -> (ScannerThread) [STDERR] java.lang.OutOfMemoryError: Java heap space
2014-04-12 18:19:28,401 ERROR -> (ScannerThread) [STDERR]     at java.lang.StringCoding$StringEncoder.encode(StringCoding.java:249)
2014-04-12 18:19:31,084 ERROR -> (ScannerThread) [STDERR]     at java.lang.StringCoding.encode(StringCoding.java:289)
2014-04-12 18:19:33,012 ERROR -> (ScannerThread) [STDERR]     at java.lang.String.getBytes(String.java:954)
2014-04-12 18:19:33,777 ERROR -> (ScannerThread) [STDERR]     at java.io.UnixFileSystem.getLastModifiedTime(Native Method)
2014-04-12 18:19:34,157 INFO  -> (Thread-8756) [org.dcm4chex.archive.mbean.FileSystemMgt2Service] Check file system group LOSSY_STORAGE for deletion of orphaned private files
2014-04-12 18:19:35,303 ERROR -> (ScannerThread) [STDERR]     at java.io.File.lastModified(File.java:896)
2014-04-12 18:19:41,153 ERROR -> (ScannerThread) [STDERR]     at org.jboss.net.protocol.file.FileURLConnection.getLastModified(FileURLConnection.java:173)
2014-04-12 18:19:43,477 ERROR -> (ScannerThread) [STDERR]     at org.jboss.deployment.scanner.URLDeploymentScanner$DeployedURL.getLastModified(URLDeploymentScanner.java:792)
2014-04-12 18:19:44,638 ERROR -> (ScannerThread) [STDERR]     at org.jboss.deployment.scanner.URLDeploymentScanner$DeployedURL.isModified(URLDeploymentScanner.java:805)
2014-04-12 18:19:44,639 ERROR -> (ScannerThread) [STDERR]     at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:582)
2014-04-12 18:19:44,639 ERROR -> (ScannerThread) [STDERR]     at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
2014-04-12 18:19:44,639 ERROR -> (ScannerThread) [STDERR]     at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(AbstractDeploymentScanner.java:274)
2014-04-12 18:19:44,639 ERROR -> (ScannerThread) [STDERR]     at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(AbstractDeploymentScanner.java:225)
2014-04-12 18:20:27,753 INFO  -> (Thread-8757) [org.dcm4chex.archive.mbean.FileSystemMgt2Service] Check file system group ONLINE_STORAGE for deletion of orphaned private files
2014-04-12 18:20:37,574 INFO  -> (Thread-8759) [org.dcm4chex.archive.mbean.FileSystemMgt2Service] Check file system group LOSSY_STORAGE for deletion of orphaned private files
2014-04-12 18:21:03,430 ERROR -> (Thread-8757) [org.dcm4chex.archive.mbean.FileSystemMgt2Service] deleteOrphanedPrivateFiles() failed:
java.lang.ClassCastException: java.lang.OutOfMemoryError cannot be cast to java.lang.Exception
    at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:124)
    at org.jboss.invocation.InvokerInterceptor.invokeLocal(InvokerInterceptor.java:209)
    at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:195)
    at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:61)
    at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:70)
    at org.jboss.proxy.ejb.HomeInterceptor.invoke(HomeInterceptor.java:184)
    at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:100)
    at com.sun.proxy.$Proxy250.create(Unknown Source)
    at org.dcm4chex.archive.mbean.AbstractDeleterService.fileSystemMgt(AbstractDeleterService.java:382)
    at org.dcm4chex.archive.mbean.FileSystemMgt2Service.deleteOrphanedPrivateFiles(FileSystemMgt2Service.java:788)
    at org.dcm4chex.archive.mbean.FileSystemMgt2Service$2$1.run(FileSystemMgt2Service.java:301)
    at java.lang.Thread.run(Thread.java:701)
2014-04-12 18:21:05,057 ERROR -> (RMI TCP Connection(idle)) [STDERR] Exception in thread "RMI TCP Connection(idle)"
2014-04-12 18:21:05,057 ERROR -> (RMI TCP Connection(idle)) [STDERR] java.lang.OutOfMemoryError: Java heap space
2014-04-12 18:21:05,434 ERROR -> (RMI TCP Connection(idle)) [STDERR] Exception in thread "RMI TCP Connection(idle)"
2014-04-12 18:21:05,435 ERROR -> (RMI TCP Connection(idle)) [STDERR] java.lang.OutOfMemoryError: Java heap space

[Alvaro [Andor]]

Hi Dhaval,

Are you using, by any change, any kind of compression on the server, to JPEG2000 or JPEGLS ?

Thanks

--
You received this message because you are subscribed to the Google Groups "dcm4che" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dcm4che+u...@googlegroups.com.
To post to this group, send email to dcm...@googlegroups.com.
Visit this group at http://groups.google.com/group/dcm4che.
For more options, visit https://groups.google.com/d/optout.

[Dhaval Joshi]

No compression is disabled

You received this message because you are subscribed to a topic in the Google Groups "dcm4che" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/dcm4che/tFnyGVAttEU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to dcm4che+u...@googlegroups.com.

[Rob McLear]

I am also having this issue, I do use compression but limit it to a single compression-decompression process.  Still having memory issues on a frequent basis. Would really appreciate some help figuring this one out and/or developer involvement. Happy to do whatever testing it takes to pin down the issue.

-Rob

[Álvaro G. [Andor]]

Jpeg2000 compression on JAIIO has a memory leak, so, it eats and eats memory slowly on your system until it fails...

I had that problem on some clients and finally had to switch to jpeg loseless (not jpeg LS).

I had some documents abut that but I cannot remember where... I should check the list archives, I've said it before...

--
Enviado desde mi teléfono con Kaiten Mail. Disculpa mi brevedad

[Rob McLear]

That is excellent info, I will try changing compression protocols. I have noticed that the java process is just gradually growing over time, regardless of how I set up the memory allocation.

Thank you!

-Rob

> You received this message because you are subscribed to a topic in the Google Groups "dcm4che" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/dcm4che/tFnyGVAttEU/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to dcm4che+u...@googlegroups.com.

> To post to this group, send email to dcm...@googlegroups.com.
> Visit this group at http://groups.google.com/group/dcm4che.
> For more options, visit https://groups.google.com/d/optout.

Rob

--

robm...@me.com

[Dhaval Joshi]

Try adding parallel garbage collection parameter in run.conf  that should resolve the issue

[Rob McLear]

How is that configured? Right now my run.conf uses these parameters:

if [ "x$JAVA_OPTS" = "x" ]; then
JAVA_OPTS="-Xms128m -Xmx512m -XX:MaxPermSize=128m -Dsun.rmi.dgc.client.gcInterval=600000 -Dsun.rmi.dgc.server.gcInterval=600000"
fi

Thanks.

-Rob

[Dhaval Joshi]

Add JAVA_OPTS="$JAVA_OPTS -XX:+UseParallelGC" to line below you printed above and restart service or server, for long term resolution you need to enable java hot spot in run.conf, that can be done by un-commenting and adding right path to parameters below

#JAVA_HOME="/opt/java/jdk"
#
# Specify the exact Java VM executable to use.
#
#JAVA=""

[Aaron Boxer]

Gentlemen, 

If there is a memory leak, then changing the garbage collector is not going to fix it.

A leak will not be cleaned up because there are references to the memory still.

We need a leak-free codec, instead. 

On Tue, Apr 15, 2014 at 10:26 AM, Dhaval Joshi <dhava...@gmail.com> wrote:

Add JAVA_OPTS="$JAVA_OPTS -XX:+UseParallelGC" below line you printed above and restart service or server, for long term resolution you need enable java hot spot in run.conf, that can be done by un-commenting and adding right path to parameters below

#JAVA_HOME="/opt/java/jdk"
#
# Specify the exact Java VM executable to use.
#
#JAVA=""

Thanks
Dhaval Joshi

[Rob McLear]

Here is my run.conf from a machine which has been having memory related issues:

## -*- shell-script -*- ######################################################
## ##
## JBoss Bootstrap Script Configuration ##
## ##
##############################################################################

### $Id: run.conf 13711 2010-07-07 09:59:21Z gunterze $

#
# This file is optional; it may be removed if not needed.
#

#
# Specify the maximum file descriptor limit, use "max" or "maximum" to use
# the default, as queried by the system.
#
# Defaults to "maximum"
#
#MAX_FD="maximum"

#
# Specify the profiler configuration file to load.
#
# Default is to not load profiler configuration file.
#
#PROFILER=""

#
# Specify the location of the Java home directory. If set then $JAVA will
# be defined to $JAVA_HOME/bin/java, else $JAVA will be "java".
#

#JAVA_HOME="/opt/java/jdk"

#
# Specify the exact Java VM executable to use.
#
#JAVA=""

#
# Specify options to pass to the Java VM.
#

if [ "x$JAVA_OPTS" = "x" ]; then
JAVA_OPTS="-Xms128m -Xmx512m -XX:MaxPermSize=128m -Dsun.rmi.dgc.client.gcInterval=600000 -Dsun.rmi.dgc.server.gcInterval=600000"
fi

#
# Specify the ID of the ServerPeer used by JBoss Messaging. Must be unique per JBoss instance
#
JAVA_OPTS="$JAVA_OPTS -Djboss.messaging.ServerPeerID=0"

#
# Use Compiling XSLT Processor (XSLTC)
#
JAVA_OPTS="$JAVA_OPTS -Djavax.xml.transform.TransformerFactory=com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl"

# Uncomment to enable the jconsole agent locally
# JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote"
# Tell JBossAS to use the platform MBean server
# JAVA_OPTS="$JAVA_OPTS -Djboss.platform.mbeanserver"
# Make the platform MBean server able to work with JBossAS MBeans
# JAVA_OPTS="$JAVA_OPTS -Djavax.management.builder.initial=org.jboss.system.server.jmx.MBeanServerBuilderImpl"

# Uncomment to enable the jconsole agent remotely on port 12345 with disabled security and ssl transport
# JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.port=12345"
# JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.authenticate=false"
# JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.ssl=false"

#
# Set headless option to run without X enviornment
#
JAVA_OPTS="$JAVA_OPTS -Djava.awt.headless=true"

#
# Set app.name and used in emitted audit log messages
#
JAVA_OPTS="$JAVA_OPTS -Dapp.name=dcm4chee"

#
# Set Node Name displayed in web login page
# (display hostname if dcm4che.archive.nodename isn't set)
#
#JAVA_OPTS="$JAVA_OPTS -Ddcm4che.archive.nodename=DCM4CHEE"

# Sample JPDA settings for remote socket debuging
#JAVA_OPTS="$JAVA_OPTS -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n"

# Sample JPDA settings for shared memory debugging
#JAVA_OPTS="$JAVA_OPTS -Xrunjdwp:transport=dt_shmem,server=y,suspend=n,address=jboss"

# Sample SSL debugging option:
#JAVA_OPTS="$JAVA_OPTS -Djavax.net.debug=ssl,handshake,data,trustmanager,help"
#JAVA_OPTS="$JAVA_OPTS -Djavax.net.debug=ssl,handshake"

# Sample https protocol settings
# Uncomment to disable SSLv2Hello when SSL handshake failed with 'javax.net.ssl.SSLHandshakeException: SSLv2Hello is disabled'
# JAVA_OPTS="$JAVA_OPTS -Dhttps.protocols=SSLv3,TLSv1"



On Apr 15, 2014, at 10:48 AM, Dhaval Joshi <dhava...@gmail.com> wrote:

> There is no leak send me your run.conf

[Alvaro [Andor]]

There is no leak?

Check this thread:

https://groups.google.com/forum/#!msg/dcm4che/jaLGca6c1LY/tT9BKJ42RB4J

Where finally Mr. Kovalchuk points to certain blog post regarding JAIIO:

http://blog.idrsolutions.com/2011/03/java-jai-image-io-jpeg2000-memory-leak-fix/

Thing is, we are really sold when dealing with any JAIIO problems... Oracle put it to sleep...

On 15/04/14 16:48, Dhaval Joshi wrote:

There is no leak send me your run.conf

On Apr 15, 2014 7:45 AM, "Aaron Boxer" <box...@gmail.com> wrote:

[Dhaval Joshi]

I agree with you Andor :) , I was referring about my case, I do not use any compression, by putting Java Path and VM path as below , I have not seen out of memory error in last 18 hours so far..

JAVA_HOME="/usr/java/jdk"

#
# Specify the exact Java VM executable to use.
#

JAVA="/usr/java/jdk/bin/java"

[Alvaro G. [Andor]]

Ah ok!

We mixed threads then...

Remember the Ghostbusters... Don't cross the beams!

El 15/04/14 20:29, Dhaval Joshi escribió:

[asgarhu...@raster.in]

Hi,

Please try with following in "run.conf" file

 

         if [ "x$JAVA_OPTS" = "x" ]; then 

               JAVA_OPTS="-Xms1g -Xmx2g -XX:MaxPermSize=256m -Dsun.rmi.dgc.client.gcInterval=600000 -Dsun.rmi.dgc.server.gcInterval=600000" 
         fi 

 

here

  Xms - Min. memory configuration. I set to 1GB.

  Xmx - Max. memory configuration. I set to 2 GB.

  -XX:PermSize -XX:MaxPermSize are used to set size for Permanent Generation.

Permanent Generation: The Permanent Generation is where class files are kept. These are the result of compiled classes and jsp pages. If this space is full, it triggers a Full Garbage Collection. If the Full Garbage Collection cannot clean out old unreferenced classes and there is no room left to expand the Permanent Space, an Out‐of‐ Memory error (OOME) is thrown and the JVM will crash.

Hope this will help you.

[Rob McLear]

I am running dcm4chee on an Amazon virtual machine with only 600MB of memory available, so the settings suggested below aren't feasible. I really just need it to live happily within its allocated memory of 512MB.

-Rob

[Rafael Cruz]

Hi Rob,

I would like to try to reproduce this error. Can you tell me how?

I started a fresh DCM4CHEE 2.18.0 install on a t1.micro instance at Amazon. (No ARR, no compression set, never received a DICOM object).

Regards.

[Rob McLear]

I think if you set the compression service to use JPEG2000 compression and then continue to push DICOM objects to the server for storage and compression then you should see gradually increased memory utilization. For our machine it was taking 3-7 days depending on the number of studies received, but the memory usage increased throughout that time.

Since I've switched to JPEG-LS lossless compression, our memory utilization has hovered between 55-65% consistently on our t1.micro instance.

Let me know if you need more information.

-Rob

[Rafael Cruz]

How do you check for memory usage?

This is what my server shows when using top command, after dcm4chee starts.

How should I monitor memory?

Regards.

[Rob McLear]

I just use top and sort by memory usage. Immediately before a crash I would routinely see java using 90%+ of total memory.

-Rob

On Apr 22, 2014, at 1:50 PM, Rafael Cruz <rfl...@gmail.com> wrote:

> How do you check for memory usage?
> This is what my server shows when using top command, after dcm4chee starts.

> How should I monitor memory?
>
>
>
>
>

[Rafael Cruz]

Hi Rob,

Unfortunately I was not able to reproduce your issue.

Initially, after a couple of tentatives, I was able to push only about 3000 non compressed CT/MR images to the server. That's because (in every try) I had my java process killed because low memory resources (without any ERROR output from DCM4CHEE).

dmesg output:

[1219388.065068] Out of memory: Kill process 1382 (java) score 736 or sacrifice child

[1219388.065088] Killed process 1382 (java) total-vm:1425536kB, anon-rss:461692kB, filers:0kB

Then I though that I would have more chances to stress DCM4CHEE if my java process lives longer.

I could considered two possibilities: (1) reducing allocation of heap memory (which I think may be not advisable?) to avoid consuming all system memory or (2) create a SWAP file to give alternatives to the system other than killing my java.

I created a 1GB swap file.

After that I wast able to push more than 13000 uncompressed CT/MR images with no issues.

Yes, a lot of swap used. Java hardly got over 67%. This morning, after some time not receiving images it's back to 57%.

I should note that, uploading at 130 KB/s, I am able to push only one uncompressed image every 6.7 seconds.

Thats very low I know, but considering java got back to 57%, I think we can assume that the leak hypothesis is not the problem (?).

In these tests I was running:

DCM4CHEE 2.18.0 (J2KR for all incoming files)

Open JDK 1.6.0_30

MySQL 5.5

Ubuntu Server 12.04 (64 bit)

You may also have your process killed by Amazon when sustaining hight CPU usage in a t1.micro (saying just in case).

What do you think Rob? Would you like to try to help me stress my server?

Regards.

[Rob McLear]

Are you sure you have J2KR compression active? I had to set it up both in the StoreSCP and CompressionServices preferences.

I had a similar experience with use of swap, but even with a 1GB swap file the memory creep issue persisted and would recur about once every 4-8 days depending on usage. The server would rarely receive studies from multiple sources at the same time, but the connection speeds were typically quite a bit higher than what you are using.

Since I changed from J2KR to JPLL I have had no memory issues at all.

Noting your setup below, my machine is using 2.17.0, not 18, and 32-bit Ubuntu Server 12.04, not 64-bit. I wasn't actually aware 64-bit was an option for the t1.micro instances.

I'm happy to try and flood your server if that's what you want to do. Contact me offline with your server details if you'd like.

-Rob

On Apr 27, 2014, at 5:50 AM, Rafael Cruz wrote:

> Hi Rob,
>
> Unfortunately I was not able to reproduce your issue.
>
> Initially, after a couple of tentatives, I was able to push only about 3000 non compressed CT/MR images to the server. That's because (in every try) I had my java process killed because low memory resources (without any ERROR output from DCM4CHEE).
>
> dmesg output:
> [1219388.065068] Out of memory: Kill process 1382 (java) score 736 or sacrifice child
> [1219388.065088] Killed process 1382 (java) total-vm:1425536kB, anon-rss:461692kB, filers:0kB
>
> Then I though that I would have more chances to stress DCM4CHEE if my java process lives longer.
> I could considered two possibilities: (1) reducing allocation of heap memory (which I think may be not advisable?) to avoid consuming all system memory or (2) create a SWAP file to give alternatives to the system other than killing my java.
> I created a 1GB swap file.
>
> After that I wast able to push more than 13000 uncompressed CT/MR images with no issues.
> Yes, a lot of swap used. Java hardly got over 67%. This morning, after some time not receiving images it's back to 57%.
>
>

[Rafael Cruz]

Hi Rob,

AMI ID from Amazon: ubuntu-precise-12.04-amd64-server-20140217.1 (ami-1da90a00)

service=StoreScp>CompressionRules: J2KR
service=CompressionService>CompressionRules (Unchanged from default installation)

When I upload uncompressed files I receive this log output from DCM4CHEE:

2014-04-27 14:42:22,247 INFO  BPWS01->BPCLOUD (TCPServer-1) [org.dcm4cheri.net.FsmImpl] received [pc-105] 3885:C_STORE_RQ with Dataset

        class:  1.2.840.10008.5.1.4.1.1.4/MR Image Storage

        inst:   1.2.840.113619.2.275.57473.14165661.21771.1337864455.225/?

2014-04-27 14:42:22,252 INFO  BPWS01->BPCLOUD (TCPServer-1) [org.dcm4chex.archive.dcm.storescp.StoreScpService] M-WRITE file:/pacs-archive/2014/4/27/14/13B3C39F/BD55CFCE/BD71EFE7

2014-04-27 14:42:22,252 INFO  BPWS01->BPCLOUD (TCPServer-1) [org.dcm4chex.archive.codec.CodecCmd] start compression of image: 512x512x1 (current codec tasks: compress&decompress:1 compress:1)

2014-04-27 14:42:24,617 INFO  BPWS01->BPCLOUD (TCPServer-1) [org.dcm4chex.archive.codec.CodecCmd] finished compression 2.4839768 : 1 in 2365ms. (remaining codec tasks: compress&decompress:0 compress:0)

2014-04-27 14:42:24,644 INFO  BPWS01->BPCLOUD (TCPServer-1) [org.dcm4chex.archive.ejb.session.StorageBean] inserting instance FileMetaInfo[uid=1.2.840.113619.2.275.57473.14165661.21771.1337864455.225

        class=1.2.840.10008.5.1.4.1.1.4/MR Image Storage

        ts=1.2.840.10008.1.2.4.90/JPEG 2000 Lossless Image Compression

        impl=1.2.40.0.13.1.1.1-dcm4che-1.4.34]

Because I have little experience with DCM4CHEE I also uploaded uncompressed files to the cloud, then downloaded them via WADO (Original Syntax) to check file compression locally using OsiriX. Everything seems to be working.

If you want, I can change any attribute from JMX-CONSOLE to match your setup.

I´ll send you an email with my server information.

Regards.

[Alvaro [Andor]]

I have to clear something:

No, Amazon/AWS will NOT kill your processes even when peaking 100% forever.

The thing is: Micro instances have a low CPU use allowance, but will
allow short bursts of higher power. So if you sustain a 100% CPU load
over around 30 seconds (I cannot remember exactly how long is the
limit), it will "steal" your CPU cycles and reduce your system speed to
keep you on limits.

Check this if you have any doubt:
http://iamondemand.com/blog/who-stole-my-cpu/

[Alvaro [Andor]]

Hi Rafael,

On 27/04/14 11:50, Rafael Cruz wrote:

> I could considered two possibilities: (1) reducing allocation of heap
> memory (which I think may be not advisable?) to avoid consuming all
> system memory or (2) create a SWAP file to give alternatives to the
> system other than killing my java.
> I created a 1GB swap file.

You need to keep the heap memory size on limits (knowing your RAM size)
or your server is going to crawl swaping. You either lower your heap
memory allocation or assign more memory to that instance. But seriously,
you aren't going to get far with 600MB of ram for DCM4CHEE and MySQL.
Assign a bigger instance just during the time of the test.

Also, if you need to push studies faster to test performance, upload the
dicom first to the server, to its local storage, and then push them via
command line with the dcmsnd utility from dcm4che tools.

Did you activate the J2KR on the compression service or in the Storage
SCP service?
Are you using the native libraries?

Thanks

[Rafael Cruz]

Hi Andor,

Thank you very much for clarifying things. This is my second week using DCM4CHEE and Amazon EC2.

I'm a radiologist, and I'm considering DCM4CHEE+EC2 as solution to my case (need to distribute DICOM images to colleagues, so we don't loose our job to teleradiology). My goal is to check how DCM4CHEE performs under my (unexperienced) maintenance.

In this meantime I came across the issue reported by Dhaval and Rob, and I thought we could help each other, so now I'm trying to replicate this error (with no luck).

dcm4chee.archive > service=StoreScp > CompressionRules > J2KR

dcm4chee.archive > service=CompressionService > CompressionRules > "default values unchanged"

I'm using libclib_jiio.so from http://download.java.net/media/jai-imageio/builds/release/1.1/jai_imageio-1_1-lib-linux-amd64.tar.gz

Regards.

[coco...@sina.com]

hi Rob

   do you fix this issue?   

在 2014年4月15日星期二 UTC+8下午9:44:32，Rob McLear写道：

[Rob McLear]

If you stop using the JPEG2000 compression codec, it will fix the problem. My understanding is that there is a memory leak in the codec. I only use JPEG-LS now, and my machines are totally stable for the last 2 years.

-Rob

> You received this message because you are subscribed to a topic in the Google Groups "dcm4che" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/dcm4che/tFnyGVAttEU/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to dcm4che+u...@googlegroups.com.

> To post to this group, send email to dcm...@googlegroups.com.

> Visit this group at https://groups.google.com/group/dcm4che.

[coco...@sina.com]

Thanks Rob,  but there is no JPEG-LS reader in jai-imageio.jar,  which reader do you use?   You modified the dcm4che codes by yourself?   

在 2016年9月21日星期三 UTC+8下午9:47:23，Rob McLear写道：

[Nicolas Roduit]

I would recommend to check that dcm4chee runs the very last compiled version of imageio (1.2.0-b04). Here is the list of fixes of this unreleased version. It contains jpeg crash and memory leak with jpeg2000 decoder.

Here is the Linux binaries (download it and rename to libclib_jiio.so) to be placed in dcm4chee/bin/native. For old dcm4chee it is also necessary to replace the jars in dcm4chee/server/default/lib: jai_imageio.jar and clibwrapper_jiio.jar.

[coco...@sina.com]

hi Nicolas,

       It really really dose work.  Thank you very very much.   

在 2016年9月22日星期四 UTC+8下午7:50:00，Nicolas Roduit写道：

[dedi....@gmail.com]

how to know that the pacs old enough so it needs the last two files to be also updated. 

[coco...@sina.com]

To check the  jai_imageio.jar version  in dcm4chee/server/default/lib,   If it is elder than 1.2.0-b04,  you need to update the two files

--------------------------------

 
       祝工作顺利！

 

刘玉涛

 

----- 原始邮件 -----
发件人："dedi....@gmail.com" <dedi....@gmail.com>
收件人：dcm4che <dcm...@googlegroups.com>
主题：Re: [dcm4che-group] dcm4chee runs out of memory
日期：2020年08月31日 16点49分

To view this discussion on the web visit https://groups.google.com/d/msgid/dcm4che/119ab262-4709-46d9-b01e-203e1214ac79n%40googlegroups.com.

[dedi....@gmail.com]

Thank you for the solution, it's been 2 days after updating and so far my pacs still run well. The memory utilization from java actually still growing but significantly slower down. Before the update, i had to restart the server 2-4 times a day depend on the transaction loads. I am curious, is it normal if the  memory use  of dcm4chee instance (java) increasing time by time?

Dedi