Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (710)
Games in Android Showcase (212)
games submitted by our members
Games in WIP (785)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  NIO Memory leak  (Read 2625 times)
0 Members and 1 Guest are viewing this topic.
Offline blahblahblahh

JGO Coder

Medals: 1

« Posted 2004-04-09 08:31:54 »

I seem to have found a way to make NIO leak 100Mb in about 2-4 seconds. And, usually, that memory is unrecoverable.

Since it's native memory being leaked, the JVM doesn't claim to possess it (System.Runtime reports only about 4Mb extra memory used from before the leak to after), although linux betrays the process as having shot from 24Mb to sometimes as high as 220Mb in just a few seconds.

Sometimes, System.gc() will recover up to 25% of the lost RAM. Usually, it will only recover 5% at most.

This has a catastrophic effect on the system. I was wondering if anyone has had any experience with NIO memory leaks? The last memory leak I found was in 1.3 (to do with files) and I'd hoped never to find one again Sad. At the moment, I'm struggling to come up with an isolated small test-case: note that I can reproduce the problem 100% of the time BUT it is dependent upon several things that make it damn hard to turn into a test case - including the fact that if you make the same series of requests sequentially, LITTLE OR NO MEMORY IS LEAKED, but if you make them in parallel, with just the right timing, Boom!

FYI I've tried different tools to issue parallel requests, and although they functionally all do the same thing, only SOME of them cause the system to explode Sad.

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder

Medals: 1

« Reply #1 - Posted 2004-04-09 10:45:00 »

(from Mark's post in the tools thread, where I referenced this post).

I presume this is with Memory Mapped Files or direct allocated byte buffers? I was able to leak GB as a result of this:

No MMing AFAIAA, but a combination of direct and indirect BB's (and I tried converting everything to indirect, but the leak kept happening; so I started working on creating as-simple-as-possible detailed test-case - there may still be a direct BB somewhere, but it's unlikely).

My first reaction when I saw our test machine die was "bet that's a direct BB not being recycled" because I recently made a change in one part of the system from re-using one direct BB shared between all channels to having one BB per channel.


In its current state I think the memory mapping capability is almost useless.

Indeed, the general paucity of unmapping control had brought me to that conclusion already Sad.

I get quite frustrated that current books and articles on NIO are clearly written by people who've never used the darned thing "in anger". They've just read the API docs and written a book; they've not encountered all the bugs and inadequacies that are what users *really* need to know about Sad.

malloc will be first against the wall when the revolution comes...
Offline Mark Thornton

Senior Devvie

« Reply #2 - Posted 2004-04-09 11:07:12 »

Sorry about my earlier reply going in the wrong thread. I wonder what happens when you use indirect buffers with socket channels. In particular do they allocate system memory and copy your data there before continuing with the I/O.
Otherwise I can't think of any other parts of NIO that would allocate (and thus potentially lose) memory outside of the Java heap.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline blahblahblahh

JGO Coder

Medals: 1

« Reply #3 - Posted 2004-04-09 19:52:01 »

I seem to have found the problem, and it's just a simple GC conundrum, but exacerbated by Sun's incredibly (literally so) memory-hungry implementation of NIO. [note: I haven't positively verified this yet, but am 98% sure]

What was happening was this:

  • User connects on a port, gets serviced by our server
  • Some clients read the response and fetch the extra resources they're told to in parallel (and this can be separately simulated by running an HTTP daemon on the server and using a standard web-browser, most of which are happy to open multiple connections to each webserver)
  • Sun's NIO converts 100k of raw byte data stored in byte-buffers with zero overhead into 150Mb of RAM usage (this is supposition - I haven't positively proved that its reads or writes that are doing this, but there is very little else to point the finger at; no other code has changed significantly, and there's almost no other object creation going on)
  • Hence the test machine starts running *very* low on memory...
  • Inside our gameserver, some of the requests need to connect to a DB to get some data.
  • They connect to a cheap-n-nasty MySQL running on the test machine (artifact of having a dedicated single-machine to run performance tests on - but for this product there are plenty of customers who would probalby deploy like this anyway)
  • MySQL / MySQL's JDBC driver goes "gasp! not enough memory to service this request! Will hang for 30 seconds!"
  • This locks the threads that are holding references to the allocated NIO buffers for sending that response in-memory whilst MySQL/their JDBC driver shifts its butt around to timing out
  • Because we have parallel requests, more requests are coming in all the time, and so this gets worse
  • Even if you have an interactive shell (as we do) and start frantically invoking "System.gc()" it won't help you because the threads that are "about to" release their references to the buffers are blocked on the 30 second timeout
  • Machine runs critically low on memory, and being linux it's a lottery as to whether:

    • ...OS kills the server process
    • ...OS runs away crying and crashes the machine
    • (IME, linux really isn't very good in these situations, and has an astonishing tendency to the do the latter when it could/should have done the former)

So, we now have the situation where a MASSIVE usage of memory (> 100Mb) to send a TINY amount of data (<100k) by sun's NIO (1.4.2_04) can cause a vicious circle that very quickly cripples the machine.

There appears to be no memory leak, as far as I can tell (and I've spent a whole day building test suites - that's another story, though: working around bugs in Apache's Jmeter Smiley).

Next step is to try and determine precisely which method calls are being so greedy - my suspicion is that it's gathering-write, which I already know to be fatally broken. Perhaps, even, some kindly NIO engineer tried to fix my outstanding bugs on GW, and this greedy algo was their patch. That would be truly tragic if so Smiley.

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder

Medals: 1

« Reply #4 - Posted 2004-04-27 13:15:14 »

Update: 1.5 beta is better (takes approx 50% less memory) but still not perfect.

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder

Medals: 1

« Reply #5 - Posted 2004-04-27 20:18:14 »

Another update: it seems that the following changes convert the problem from 100% reproducable to 100% non-reproducable:

1. Convert all buffer allocations from indirect to direct
2. Convert all "gathering write" channel operations to sequential "write" operations iterating over all the buffers in the gathering-array

BOTH steps are necessary; on their own, neither has any effect whatsoever at all. Both had been tried individually before, but Elias's comment that he'd fixed a similar problem using 1 above was enough to make me retest 1 individually with every other possible change we'd tried, and 2 turned out to be the magic one.

malloc will be first against the wall when the revolution comes...
Offline elias

Senior Devvie

« Reply #6 - Posted 2004-04-28 04:13:17 »

Yes, and then 1. (nondirect->direct) was enough for me because I didn't use gathering read/writes at all.

- elias

Offline cknoll

Junior Devvie

Flame On!

« Reply #7 - Posted 2004-04-28 16:02:59 »

I found this article at:

Perhaps you could take a look at the EmberIO lib (it looks like a NIO wrapper) and see if it solves any of your poblems?

Pages: [1]
  ignore  |  Print  
You cannot reply to this message, because it is very, very old.

numerical (124 views)
2017-02-21 07:32:16

numerical (123 views)
2017-02-21 07:31:46

theagentd (230 views)
2017-02-18 13:42:33

theagentd (231 views)
2017-02-18 13:35:16

h.pernpeintner (1394 views)
2017-01-24 22:39:11

h.pernpeintner (1382 views)
2017-01-24 22:38:32

Galdo (1944 views)
2017-01-12 13:44:09

Archive (2013 views)
2017-01-02 05:31:41

0AndrewShepherd0 (2550 views)
2016-12-16 03:58:39

0AndrewShepherd0 (2318 views)
2016-12-15 21:50:57
List of Learning Resources
by elect
2016-09-09 09:47:55

List of Learning Resources
by elect
2016-09-08 09:47:20

List of Learning Resources
by elect
2016-09-08 09:46:51

List of Learning Resources
by elect
2016-09-08 09:46:27

List of Learning Resources
by elect
2016-09-08 09:45:41

List of Learning Resources
by elect
2016-09-08 08:39:20

List of Learning Resources
by elect
2016-09-08 08:38:19

Rendering resources
by Roquen
2016-08-08 05:55:21 is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!