This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

[1.401] command-server memory leak

After running for about 2 months, we noticed that the command-server process on our ACC machine had ballooned up to about 1GB of memory usage and the machine was using half the system's swap space. The machine has 648MB RAM and 1GB swap.

Rebooted it and memory usage is nice and minimal again (free reports less than 100MB used after running for a day).

Anyone else see this?


This thread was automatically locked due to age.
Parents Reply Children
  • Anything in the logfiles? Did the buildup occur periodically or all of a sudden?
  • I didn't notice if it happened quickly or over time. I just happened to log in to the machine via ssh and had a look at top. The system still appeared to be functioning OK.

    Any log files in particular I should be looking at? There actually isn't anything in the command-server logs at all since July 27th. Hmm, interestingly, there doesn't seem to be any logging going on since that date. Looks like I have a failing disk on the system, looking at the dmesg.

    hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
    hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=25729714, sector=25729711
    ide: failed opcode was: unknown
    end_request: I/O error, dev hda, sector 25729711
    EXT3-fs error (device hda9): ext3_get_inode_loc: unable to read inode block - inode=162330, block=163856
    Aborting journal on device hda9.
    EXT3-fs error (device hda9) in ext3_reserve_inode_write: IO failure
    EXT3-fs error (device hda9) in ext3_new_inode: IO failure
    ext3_abort called.
    EXT3-fs error (device hda9): ext3_journal_start_sb: Detected aborted journal
    Remounting filesystem read-only
    EXT3-fs error (device hda9) in start_transaction: Journal has aborted
    EXT3-fs error (device hda9) in ext3_mkdir: IO failure
    __journal_remove_journal_head: freeing b_committed_data
    __journal_remove_journal_head: freeing b_committed_data
    __journal_remove_journal_head: freeing b_committed_data
    __journal_remove_journal_head: freeing b_committed_data
    __journal_remove_journal_head: freeing b_committed_data
    __journal_remove_journal_head: freeing b_committed_data
    __journal_remove_journal_head: freeing b_committed_data
    __journal_remove_journal_head: freeing b_committed_data
    __journal_remove_journal_head: freeing b_committed_data
    __journal_remove_journal_head: freeing b_committed_data
    __journal_remove_journal_head: freeing b_committed_data


    I am guessing that this disk has been failing for the past 2 months. I am seriously surprised that it is functioning as well as it is!
  • Hi,

    have you exchanged the failing harddisk and re-experienced the suspected memory leak afterwards? Mayhap the buildup is correlated to the failing disk and the problem of writing logfiles. 

    Thanks and cheers,
    Henning
  • Yes, we actually moved ACC to VMware after this and haven't seen the memory leak again, so I'm pretty sure that the two are related.