View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001405 | unreal | ircd | public | 2003-12-02 23:15 | 2003-12-04 00:56 |
| Reporter | minifang | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | open | ||
| Summary | 0001405: possible memory leak | ||||
| Description | os : 5.1-RELEASE-p10 FreeBSD 5.1-RELEASE-p10 os : debian 3.0 in both cases used memory climbs until ircd restarts. on the debian box the ircd is the only thing running. it gains 1MB every 1.5 hours . the freebsd box has numerous users but each account is limited to 50MB mem usage.the ircd gets killed by root, approx once a week. ircd version: Unreal beta19 | ||||
| Additional Information | PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND 96 0 3376K 2460K select 0 1:44 0.00% 0.00% ircd that from top stays steady but Mem: 638M Active, 89M Inact, 221M Wired, 39M Cache, 112M Buf, 9656K Free the 638M active continues to climb (until the ircd is restarted) . on the debian machine ,starts at 30M and climbs until all memory is in use . | ||||
| Attached Files | mandrake.config.log (42,144 bytes) bsd.config.log (35,469 bytes) | ||||
| 3rd party modules | |||||
|
|
someone (a coder) mentioned that the leak may be in sjoin |
|
|
Hi, I got "some" questions... 1. How many users should I think of? 2. How many channels? 3. How many users connecting per minute? 4. Do you have netsplits, and if so how often? 5. Do you have any 3rd party modules loaded (even if you think they don't apply), if so.. which? 6. Do you have services, if so which? What do you mean with top/free btw? You mean unrealircd is "invisibly" taking more memory than it shows? Coz that's a bit hard to believe :p. I only trust output from ps or top, not from 'free' (or whatever command it is in freebsd) since that could be anything... |
|
|
Also a quick check doesn't show any memleaks caused by joining, netsplit+netjoin or in chanmode +f. Of course that's just a quick check, but if it leaked 1.5Mb per hour, that's 25kb per minute so it should be a quite huge memleak... I don't see any change in the past 20 minutes (not a single extra kb) after like tens of cycles with 100 clones and 4 squits+connect. So I really think I need additional information/feedback on this ;). |
|
|
Also, have you enabled/disabled any #define's in config.h (or anywhere else for that matter)? And possibly can you include the config.log that was created when you compiled Unreal? |
|
|
syzop : 100 users 25 chans ave 5 connects/dc per min netsplits rare 1x per week approx (bsd box provider has had power issues ) antidcc , join/part ,no colormode auspice services codemastr : no i didnt enable/disable any #define's prior to ./Config and the 2 config.logs are uploaded the top output shows the memory used by unreal and the total mem stats . meaning unreal is "invisibly" ( as you put it ) using memory . the bsd box seems more stable than it 1st appeared to be (ie this morn mem usage was back down) . the linux box continued to use memory ,so i compiled a test box running mandrake 9.1 with malloc 2.7.2 . this box had been stable at 192.7M mem usage +- 100K. i compiled unreal in std format ,using all defaults,except enabling ~ and &. it started using memory and overnight mem usagage grew over 50M . x was not running on this box (known mem hog). the ircd is firewalled off and no connections (client or server)were made . im going to recompile without malloc (as i remember a while back it had some issues with mem leaks) and retest it . |
|
|
in addition , the bsd box does not have malloc.h on it and it seems more stable than either of the linux boxes |
|
|
I would like to keep facts and speculation seperate. ps/top per-process information is what I'm interrested in. output from free or total usage or whatever doesn't mean a thing to me... I don't believe in ghosts and it could be anything, or even.. nothing :P. For example I've a 384Mb box and it also says just 10mb free, but it IS using 182mb (dynamically) as cache etc. So is the _ircd_ mem usage also increasing or not? |
|
|
ircd reported mem usage remains the same top from mandrake box : PR NI VIRT RES SHR S %CPU %MEM TIME+ Command 9 0 1844 1844 916 S 0.0 0.7 0:00.00 ircd it remains there. however overall memory usage increases over time . the only additional process is the ircd. the increase stops when the ircd is stopped. it starts to increase when the ircd is restarted . usage : ./unreal stop - mem increasing usage halts ./unreal start mem increasing resumes so i dunno |
|
|
I just don't believe that, sorry.. *NIX != Windoze :P. /me walks away |
|
|
ok heres what ive found out , the linux kernal is caching the memory that unreal has released back to the memory pool, tho technically in use ,the memory is made availible to another process by the kernal on demand. http://lists.debian.org/debian-user/2003/debian-user-200301/msg04033.html so in other words i goofed :( . |
|
|
What you're saying only makes sense is one condition, a bad malloc implementation. However, that would cause memory spikes from _all_ processes and it is doubtful both systems have the problem. Since you're saying this happens the minute Unreal starts, it makes no sense. Even with no users connected it goes crazy? I've had Unreal running on a FreeBSD machine for a few weeks, it's not using more than 2MB of memory. It sounds like either your system is doing something your not aware of (cache optimizing, anticipatory memory allocation, large/huge-block memory allocation, etc.). Basically what I mean is, the OS might be giving the memory to the IRCd but that doesn't mean the IRCd requested it. Some malloc implementations for example always allocate on 4byte boundaries. So if I request 1 byte of memory, it's possible I could receive as much as 4. Based on the processor it could be even higher, though I'm assuming this is an x86 system. Some systems also have "anticipatory memory allocation" in which the system "guesses" at what is going to need memory and gives it before it is needed. That way the memory can be allocated during idle CPU time rather than when the process is busy and wants it, it therefore makes things run faster. It could be using it for cache memory. If your processor has very little cache (especially if you have an AMD Duron or Intel Celeron) the system might allocate a decent chunk of your system memory to be used as form of cache memory. My main thing is, if this happens from the second Unreal starts, and continues to increase, how come no one else has the problem? It seems as though this is something that we would hear about from many people but we haven't. I'm not saying your lying or anything, just that either you have some very odd system setup that Unreal doesn't work with, or, your system is doing something you're not aware of. When overall memory usage increases but individual process memory usage does not, then that is the OS doing something, not the process. |
|
|
Like I said: [..]"For example I've a 384Mb box and it also says just 10mb free, but it IS using 182mb (dynamically) as cache etc." Anyway, *closing bugreport* |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2003-12-02 23:15 | minifang | New Issue | |
| 2003-12-02 23:17 | minifang | Note Added: 0004185 | |
| 2003-12-03 03:37 | syzop | Note Added: 0004186 | |
| 2003-12-03 04:19 | syzop | Note Added: 0004187 | |
| 2003-12-03 04:50 |
|
Note Added: 0004188 | |
| 2003-12-03 15:49 | minifang | File Added: mandrake.config.log | |
| 2003-12-03 15:49 | minifang | File Added: bsd.config.log | |
| 2003-12-03 16:07 | minifang | Note Added: 0004189 | |
| 2003-12-03 16:10 | minifang | Note Added: 0004190 | |
| 2003-12-03 16:31 | syzop | Note Added: 0004191 | |
| 2003-12-03 16:48 | minifang | Note Added: 0004192 | |
| 2003-12-03 19:29 | syzop | Note Added: 0004194 | |
| 2003-12-03 20:10 | minifang | Note Added: 0004195 | |
| 2003-12-03 20:14 |
|
Note Added: 0004196 | |
| 2003-12-04 00:56 | syzop | Status | new => closed |
| 2003-12-04 00:56 | syzop | Note Added: 0004197 |
