Calculating storage requirements for Node.js applications

To start one or more Node.js applications in a CICS® region, you must ensure that there is enough free storage available for each Node.js application to use. CICS and other products that are running in the same region might require a considerable amount of z/OS® storage. CICS storage allocation parameters such as DSALIM and EDSALIM affect storage availability and might be over-allocated compared to the peak requirements.

About this task

The storage that is required for a Node.js application is not allocated from CICS DSA or EDSA storage. Some storage is managed by the Language Environment® handling requests such as malloc() issued by C code, and some is managed directly by the Node.js application that uses z/OS storage management requests such as IARV64 and STORAGE OBTAIN. Language Environment uses z/OS storage services.

4 KB of 24-bit storage is required for each thread used by the Node.js runtime. The number of threads used is fixed once the Node.js runtime has started, and is typically between 8 and 12, unless you set the UV_THREADPOOL_SIZE environment variable. In addition, UNIX System Services require 256 KB of contiguous 24-bit storage during the process of creating each thread.

The Node.js runtime allocates a heap for JavaScript objects and JIT compiled code. On z/OS 2.2, the heap is allocated in 31-bit storage. On z/OS 2.3, the heap can span both 31-bit and 64-bit storage. Also, the heap is comprised of several spaces, and their sizes vary independently. Measuring the heap usage in a test environment is the simplest way to estimate the heap size requirement. 31-bit storage is also required to load UNIX System Services dynamic link library (DLL) files for the Node.js runtime.

In addition, 64-bit storage is allocated by Language Environment for the C++ heap and stack. This used by Node.js runtime code internally, and by native modules.

To estimate the total storage required for Node.js applications, perform the following procedure.

Note: The following procedure is valid only if the MVS private area is maximized by setting the z/OS parameter REGION as 0M.

Procedure

  1. Use the sample statistics program DFH0STAT to measure 24-bit, 31-bit and 64-bit memory usage.
    • Note the value for  1  Private Area storage available below 16 Mb, which is the currently available 24-bit private storage in the region.
    • Note the value for  2  Private Area storage available above 16 Mb, which is the currently available 31-bit private storage in the region.
    • Note the value for  3  MEMLIMIT minus usable within Private Memory Objects, which is the currently available 64-bit private storage in the region.
    Storage BELOW 16MB                                                     
__________________                                                     
  Private Area Region size below 16Mb . . . . . . . . :      10,216K   
    Max LSQA/SWA storage allocated below 16Mb (SYS) . :         660K   
    Max User storage allocated below 16Mb (VIRT). . . :       5,460K   
    System Use. . . . . . . . . . . . . . . . . . . . :          20K   
    RTM . . . . . . . . . . . . . . . . . . . . . . . :         250K   
  __________________________________________________________________   
  Private Area storage available below 16Mb . . . . . :       3,826K    1 

Storage ABOVE 16MB                                                    
__________________                                                    
  Private Area Region size above 16Mb . . . . . . . . :   1,417,216K  
    Max LSQA/SWA storage allocated above 16Mb (SYS) . :      84,500K  
    Max User storage allocated above 16Mb (EXT) . . . :     987,936K  
  __________________________________________________________________  
  Private Area storage available above 16Mb . . . . . :     344,780K   2 

    Storage ABOVE 2GB   
_________________________  
  MEMLIMIT Size. . . . . . . . . . . . :               15,360M    
  MEMLIMIT Set By. . . . . . . . . . . :                  JCL 
  
  Current Address Space active (bytes) :      1,143,996,416    
  Current Address Space active . . . . :             1,091M    
  Peak Address Space active. . . . . . :             1,091M       
     
  MEMLIMIT minus Current Address Space active. . . . . . . :          14,269M     3 
  MEMLIMIT minus allocated to Private Memory Objects . . . :          13,144M
  MEMLIMIT minus bytes usable within Private Memory Objects:          14,269M 
  Number of Private Memory Objects . . . . . . . . . . . . :               33 
    ....minus Current GDSA extents . . . . . . . . . . . . :               32 
  Bytes allocated to Private Memory Objects. . . . . . . . :           2,216M  =       2,323,644,416
    ....minus Current GDSA allocated . . . . . . . . . . . :           1,192M  =       1,249,902,592
  Bytes hidden within Private Memory Objects . . . . . . . :           1,125M  =       1,179,648,000
    ....minus Current GDSA hidden. . . . . . . . . . . . . :           1,124M  =       1,178,599,424
      ....minus CICS Internal Trace Table hidden . . . . . :             130M 
  Bytes usable within Private Memory Objects . . . . . . . :           1,091M  =       1,143,996,416
  Peak bytes usable within Private Memory Objects  . . . . :           1,806M  =       1,893,728,256
  Current GDSA Allocated . . . . . . . . . . . . . . . . . :           1,024M  =       1,073,741,824
  Peak GDSA Allocated. . . . . . . . . . . . . . . . . . . :           1,024M
  2. Enable the NODEJSAPP and run a representative workload. Observe how the values for each private storage area available change, and make sure that the private storage areas are not constrained.