Project

General

Profile

Actions

Bug #5418

closed

http app memory leak

Added by eric fool almost 2 years ago. Updated over 1 year ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Target version:
-
Affected Versions:
Effort:
Difficulty:
Label:

Description

when there is a lot http flows in suricata, the suricata use memery of linux from 200MB to 1.2GB whatched by "top" command of linux,and call HTPMemuseGlobalCounter can see http use about 0.9GB memery.
when those http flows above time out ,and call HTPMemuseGlobalCounter can see http using mem become 0 B, but "top" cimmand still show suricata use memery of 1.2GB instead of reduce to 200MB。
see the code of HTPFree, if htp_memuse become 0, the HTPFree must has been called the same times。 But why the "top" and "free -m" command show the mem still not be freed to linux (centos 7.5)???

void HTPFree(void *ptr, size_t size)
{
    SCFree(ptr);

    HTPDecrMemuse((uint64_t)size);
}

Related issues 1 (0 open1 closed)

Related to Suricata - Bug #5417: flow memory leak RejectedActions
Actions #1

Updated by Victor Julien almost 2 years ago

  • Subject changed from http app memery leak to http app memory leak
  • Assignee deleted (OISF Dev)
  • Priority changed from Urgent to Normal

Suricata 4.1 is EOL, and has been for quite some time. Please try 6.0.5.

Actions #2

Updated by Victor Julien almost 2 years ago

  • Status changed from New to Closed
  • Target version deleted (TBD)
Actions #3

Updated by Victor Julien over 1 year ago

  • Description updated (diff)
Actions #4

Updated by Victor Julien over 1 year ago

  • Status changed from Closed to Rejected

In general, memory behavior around returning memory from the process seems better with an allocator like jemalloc.

Actions #5

Updated by Victor Julien over 1 year ago

  • Related to Bug #5417: flow memory leak added
Actions

Also available in: Atom PDF