[ 
https://issues.apache.org/jira/browse/TRAFODION-2478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15864057#comment-15864057
 ] 

ASF GitHub Bot commented on TRAFODION-2478:
-------------------------------------------

Github user prashanth-vasudev commented on a diff in the pull request:

    https://github.com/apache/incubator-trafodion/pull/953#discussion_r100663267
  
    --- Diff: core/sql/bin/ex_esp_main.cpp ---
    @@ -357,15 +357,18 @@ Int32 runESP(Int32 argc, char** argv, 
GuaReceiveFastStart *guaReceiveFastStart)
       cliGlobals->initiateDefaultContext();
       NAHeap *espIpcHeap = cliGlobals->getIpcHeap();
       IpcEnvironment *ipcEnvPtr = cliGlobals->getEnvironment();
    -  //
    -  // Start the  memory monitor for dynamic memory management
    -  Lng32 memMonitorWindowSize = 10;
    -  Lng32 memMonitorSampleInterval = 10;
    -  MemoryMonitor memMonitor(memMonitorWindowSize,
    +  if (statsGlobals != NULL)
    +     cliGlobals->setMemoryMonitor(statsGlobals->getMemoryMonitor());
    +  else 
    +  {
    +     // Start the  memory monitor for dynamic memory management
    +     Lng32 memMonitorWindowSize = 10;
    +     Lng32 memMonitorSampleInterval = 10;
    +     MemoryMonitor memMonitor(memMonitorWindowSize,
    --- End diff --
    
    Should this allocation be made with espExecutorHeap?


> Reduce the number of  memory monitoring threads in Trafodion SQL processes 
> ---------------------------------------------------------------------------
>
>                 Key: TRAFODION-2478
>                 URL: https://issues.apache.org/jira/browse/TRAFODION-2478
>             Project: Apache Trafodion
>          Issue Type: Improvement
>          Components: sql-exe
>    Affects Versions: any
>            Reporter: Selvaganesan Govindarajan
>            Assignee: Selvaganesan Govindarajan
>
> A memory monitor thread is created in every SQL process to handle the memory 
> pressure in BMO (Big memory operators).  This has following drawbacks:
> 1) No consistent view of the memory pressure in the node
> 2) Overhead of calculating the memory pressure in every trafodion SQL process.
> Proposal is to move this thread to RMS SSCP process. All SQL processes have 
> access to RMS shared segment. Hence SQL processes can get the view of the 
> memory pressure readily and easily from the shared segment.
> It is also possible to increase the frequency of the memory pressure 
> calculation to get near real tiime picture of the memory pressure.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Reply via email to