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

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

Github user zellerh commented on a diff in the pull request:

    https://github.com/apache/incubator-trafodion/pull/953#discussion_r100892378
  
    --- Diff: core/sql/cli/memorymonitor.cpp ---
    @@ -223,12 +229,12 @@ void MemoryMonitor::update(float &scale) {
        char * currPtr;
             bytesRead = fread(buffer, 1, 2048, fd_meminfo_);
             // Make sure there wasn't an error (next fseek will clear eof)
    -        if (!feof(fd_meminfo_))// Make sure there wasn't an error
    -        {
    -           scale = 6;
    -           pressure_ = 0;
    -           return;
    -        }
    +        if (ferror(fd_meminfo_))
    +           assert(false); 
    +        if (feof(fd_meminfo_))
    +           clearerr(fd_meminfo_); 
    +        else
    +           buffer[bytesRead] = '\0';
    --- End diff --
    
    @selvaganesang, I like that you added the terminating \0 to the buffer 
read, since we are using strstr below and since fread does not add this 
terminator. My comment was that we should be doing this unconditionally, 
otherwise strstr could potentially go beyond the buffer - although this is 
unlikely to happen in real life.


> 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