Appendix C. Handling Memory Problems
Prev   Next

Appendix C. Handling Memory Problems

The ML is designed to work with large images and with many modules that work on these images. This, however, does not mean that working with large images and many modules is no problem anymore. It is still possible to run into memory problems that the ML cannot avoid automatically. In most cases, these problems can be solved by reconfiguring some settings.

  1. Check whether you machine has enough main memory!

    Problem: The computer does not have sufficient physical memory.

    Possible Solution: Theoretically, pure ML programs could work with only a few MB of main memory. In many cases, however, the processed images and the applications using the ML programs will strongly benefit from more memory. 256 MB is considered to be a reasonable minimum memory size; assign as much memory as possible to achieve optimal results. Working with a memory of less than 256 MB might be possible but will often lead to slow performance and will also require the ML and the images to be configured appropriately. The following items might help you to work with less than 256 MB, but they do not guarantee success.

  2. Check whether other applications use too much memory!

    Problem: Other applications use too much memory.

    Possible solution: Terminate other applications running on your system, especially those which use much memory. To find out which application uses much memory, check the Task Manager (Windows systems) or use "top" (Linux systems).

    If you do not want or cannot terminate those applications, it might help to make these applications sleep or to set them to an inactive state; the system can swap the memory that these applications use into the virtual memory and your ML process can use the physical memory more efficiently. That, however, might require you to increase the virtual memory size of your system.

  3. Set an adequate ML cache size!

    Problem: The ML uses the cache to reduce the number of required page recalculations. If the user spends too much cache memory, the ML will try to use it, even if the required physical memory is not available which might lead to a memory allocation failure. This problem often occurs after a certain working time, because the cache needs some time to be filled with calculated data.

    Possible solution: Take the physical memory size of your computer, subtract the memory other applications and the system require (to find out these values you may want to use the "Task Manager" on Windows systems, or "top" on Linux systems), and also subtract the memory that the application using the ML needs (in most cases MeVisLab which works fine with about 256 MB). The remaining memory size should be the maximum limit for your cache size - better use less when you are not absolutely sure. A cache size that is too small can degrade image processing performance, but normally does not lead to memory problems since the ML will always use the minimum memory requirements for image processing, even if it exceeds the cache size.

    [Note]Note

    MeVisLab 2.0 and newer versions will not have an ML cache anymore but a global cache for ML and other libraries such as GVR or MeVisAP. The cache limit should be set to the size of the available free memory there.

  4. Avoid global image processing modules or take them outside critical network branches!

    Problem: For different reasons, some ML modules request or lock so much memory that there is not enough memory for the system and the ML. This is often caused by inadequate or lazy algorithm programming, performance requirements or bad parameter settings of the ML or some modules.

    Possible Solutions:

    • Try to replace those modules by other page-based solutions or - if the modules have such a parameter - select a page-based algorithms setting. There might be other modules which perform similar or the same tasks.

    • Outsource large images and memory-expensive calculations. Calculate them once and store the results on disk. Then replace them by a Load module in the network. This, however, is often not possible, e.g., when module results change often.

    • Reimplement the module and make it page-based, e.g., by using the VirtualVolume concept (see Section 2.3.7, “ VirtualVolume ”) or by using more efficient or packed data structures such as the BitImage concept (see e.g., Section 4.4.3, “BitImage Concept” for details) to manage flag images.

  5. The processed images are too large

    Problem: The ML cannot process images with inappropriate page and image extents; e.g., extents with dimensions of more than 231 or pages with more than 512K voxels.

    Possible Solution: The ML can process images with up to 244 voxels, even on 32 bit systems. However, the extent in each dimension should not exceed 231 and the number of pages per image is limited to 223. Hence, try to avoid extreme extents in any dimension and too small and also too large pages.

  6. The page extent is too large

    Problem: One or more modules in the network set a page extent which is too large (e.g., sometimes modules use image extent for page extent). This leads to a degeneration of the image processing process in the network. As a result, paging, caching, multithreading and effective memory usage do not work appropriately anymore.

    Possible Solution:

    • If the loaded input image has already an inadequate page extent (e.g., the page extent is identical to the image extent), try to load the module, set the page extent to a smaller value, e.g., with the ImagePropertyConvert module, and save the image with this new page exent under a new filename. Use that new image instead of the original one.

    • Try to find those modules in the network and the reasons why they specify an inappropriate page extent. If possible, reconfigure or replace these modules in such a way that large page extents do not occur anymore.

    • If the modules cannot be reconfigured or replaced you may want to revise the module in such a way that it does not set these page extents anymore; that might be sensible because setting such an page extent is "bad module behavior" and may cause other users to have the same problem in the future.

  7. The process runs continuously out of memory after long usage

    Problem: Although it should not happen in well-programmed code: module networks often include a large number of stable and new modules and sometimes some of these modules have memory leaks that result in memory problems after longer operation.

    Possible Solutions:

    • Check the memory your process uses (use e.g., "Task Manager" on Windows or "top" on Linux) and check whether this behavior remains when you have temporarily deactivated some network components or some functionality. Thus you can isolate the module(s) that cause such a problem.

      [Note]Note

      Be aware that the ML also caches memory. To distinguish memory leaks from cached image fragments, use the Clear Image Cache in the menu Extras of MeVisLab or the Clear Cache feature of the CoreControl module.

    • Use software tools or libraries which allow for checking for memory leaks. It might be helpful to check all modules used with the module tester of the MeVisLab application (if you work with MeVisLab); this could be the fastest way to detect memory leaks. You can also use the Tester module of the project MLDiagnosis.

  8. If all the above measures do not help

    The measures might reduce memory usage and could be helpful; they, however, do not solve the actual problem:

    • Try to work on downscaled images or on image fragments.

    • Use 2D slice viewing instead of 3D volume rendering.

    • Do not use the MemCache or other memory caching modules.

    • Increase the memory optimization mode in the CoreControl module; this reduces the cache load at the expense of computing performance. Note: This mode is not available anymore in MeVisLab 2.0 or newer versions.

    • Simplify your module network and/or use smaller subnetworks to process images step by step and not at once.

    • Disable multithreading, because it temporarily uses more memory than single threading.

    • Increase the virtual memory size of your computer. This could increase reliability of the process but also may degrade performance if it is used too much.

    • Think about adding more memory to your computer, if possible.

    • Migrate to a 64 bit MeVisLab/ML version if you have not done so yet, and/or buy more memory.

© 2024 MeVis Medical Solutions AG

Prev   Next
B.2. Optimizing Data Flow in Module Networks Home Appendix D. Messages and Errors