#1297 Memory leak noticed in the daemon

2.12.0
closed-fixed
5
2008-07-18
2007-10-31
dr_mohan
No

Have been running the daemon (Version 2.8.1) for one week. Noticed the virtual memory and resident memory used by the daemon continues to increase as reported by top -p PID

It went from
PID,USER,PR,NI,VIRT,RES,SHR,S,%CPU,%MEM,TIME+,COMMAND
11067,root,15,0,211m,29m,4352,S,0,0.8,44:40.08,openhpid
to
11067,root,15,0,358m,161m,4364,S,0,4.1,2313:57,openhpid

It is a dl385 box running RHEL5 (Tikanga).

Do not know where is the memory leak coming from or if it is fixed on the trunk.

Mohan

Discussion

  • Renier Morales

    Renier Morales - 2007-11-01
    • milestone: --> 752710
    • assigned_to: nobody --> renierm
     
  • Renier Morales

    Renier Morales - 2007-11-01

    Logged In: YES
    user_id=660960
    Originator: NO

    What plugin are you using?

     
  • Renier Morales

    Renier Morales - 2007-11-03

    Logged In: YES
    user_id=660960
    Originator: NO

    Memory consumption may increase over time due to other reasons, not necessarily a memory leak.
    The domain event log can grow indefinitely over time if you don't configure a limit. Same story with alarms.

     
  • Renier Morales

    Renier Morales - 2007-11-03
    • milestone: 752710 --> 761457
     
  • Nobody/Anonymous

    Logged In: NO

    I am using the simulator plugin. hpi_cmd's showevtlog returned the following output
    OpenHPI> showevtlog
    EventLog: entries = 0, size = 10000, enabled = 1
    UpdateTime = SAHPI_TIME_UNSPECIFIED CurrentTime = 2007-11-05 10:52:32 Overflow = 0
    SEL is empty

    OpenHPI> evtlogstate
    Event Log State: Enable
    Do not know how to check for alarms.

    OpenHPI> evtlogreset
    OpenHPI> evtlogtime
    Current event log time: 2007-11-05 11:12:24

    Even after the evlogreset the
    top -p "PID" shows 334m 187m 1364 as virtual, resident and shared memory respectively (within a week it went from
    100m,16m,1364 to the above value.

    The rate at which the memory is growing shows that the daemon may not be able to run for a long time (in months) without affecting the system performance badly.

    Killing the daemon does release significant memory (may not be a significant memory leak, but a significant memory hog), the memory went from

    Mem: 4047260k total, 4006096k used, 41164k free, 203896k buffers
    to
    Mem: 4047260k total, 3814608k used, 232652k free, 203896k buffers

    Let me know if I can do something more to help.

     
  • Renier Morales

    Renier Morales - 2008-02-29
    • milestone: 761457 --> 761458
     
  • Shuah Khan

    Shuah Khan - 2008-03-25

    Logged In: YES
    user_id=1884926
    Originator: NO

    This is a memory usage issue not a leak. We noticed memory usage doubles during the saftest loop test after the first loop and then the memory increments level of with each additional loop. Closing it no change after consulting the submitter.

     
  • Renier Morales

    Renier Morales - 2008-04-08
    • milestone: 761458 --> 761459
     
  • Ric White

    Ric White - 2008-04-25

    Logged In: YES
    user_id=2058939
    Originator: NO

    I'm taking a look at this to see if I can discover where and why the memory is being consumed.

    -Ric

     
  • Renier Morales

    Renier Morales - 2008-05-27
    • assigned_to: renierm --> shuah
    • milestone: 761459 --> 831933
     
  • peter dinh phan

    peter dinh phan - 2008-06-24
    • milestone: 831933 --> 831934
     
  • peter dinh phan

    peter dinh phan - 2008-07-17
    • milestone: 831934 --> 2.12.0
     
  • Bryan Sutula

    Bryan Sutula - 2008-07-17
    • assigned_to: shuah --> sutula
     
  • Bryan Sutula

    Bryan Sutula - 2008-07-17

    Logged In: YES
    user_id=814412
    Originator: NO

    I have some patches from PG. Working on review and applying them, hopefully in time for 2.12.0.

     
  • Bryan Sutula

    Bryan Sutula - 2008-07-18
    • status: open --> closed-fixed
     
  • Bryan Sutula

    Bryan Sutula - 2008-07-18

    Logged In: YES
    user_id=814412
    Originator: NO

    Committed revision 6851, with two leaks fixed. At this point, we are not seeing memory leakage while running the tests that Mohan described. Additional stress testing is in process, and we will reopen the bug if we find anything else based on this testing.

    Of course, there may be other leaks, but this particular one seems to be fixed.

    Thanks, in particular, to efforts by PG (Raghavendra Ganesha) for some excellent debugging and the patch contribution.
    Bryan

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks