Server size >10 people
FTB Package 2.5.0
LP Build 114 and 121 confirmed.

Java(TM) SE Runtime Environment (build 1.8.0_92-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.92-b14, mixed mode)

Java Args "$JAVACMD" -server -Xms5G -Xmx5G -XX:NewRatio=3 -XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=80 -XX:+UseG1GC -XX:+UseStringDeduplication -jar FTBServer-1.7.10-1614.jar nogui

Also tested on "$JAVACMD" -server -Xms5G -Xmx5G -XX:NewRatio=3 -XX:SurvivorRatio=3 -XX:TargetSurvivorRatio=80 -XX:MaxTenuringThreshold=15 -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+ExplicitGCInvokesConcurrent -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=70 -jar FTBServer-1.7.10-1614.jar nogui

We have a memory leak that over a 2 hour period will eat up 2-3 gigs of memory and crash the server. We finally narrowed it down to the LP system. It is suspected in Eclipse Memory Analyzer and confirmed through the removal of LP from the FTB pack on our server, memory usage over 2 hours went from >5gb to <1.5gb with only one person standing in the same spot.

Here is a quote from the Eclipse analysis on a heap dump that we took (20 minutes after a server restart).

29,970 instances of "logisticspipes.pipes.basic.LogisticsTileGenericPipe", loaded by "net.minecraft.launchwrapper.LaunchClassLoader @ 0x689affff8" occupy 256,060,032 (20.55%) bytes. These instances are referenced from one instance of "java.util.HashMap$Node[]", loaded by ""

I can provide the map if you need it for duplication.

@theZorro266 why did you close it ??

@loordgek I guess because the issue opened at May 15 and we didn't get any further update since Jun 1, and now it's Oct 13, so we can safely consider it as abandoned.

I'm pretty sure they want to take a look into the heap dump.

I have removed our restart so the server will max out and crash today so I will have a full log tonight when I get home in case they do need a heap dump.

I made sure to make this a good one.

Here is the HPROF and GC log
Here is the map we have the leak on There are 3 major bases all which you can find from using opis.

Let me know if I can be of any help or if you create a fix :)

Holy cows, 90k is a really impressive number. All chickens in the heaven...

@davboecki it means you need the heap dump and logs, right?

These pipes seem to be the source of the leak. When the grid is not loaded but somewhere else in the world is, the leak happens. Having the area loaded or removing the pipes stops the leak, I can only speculate why this was causing a leak but hopefully it helps!

@SmEdD86 have you tried unloading it without having any Thermal Dynamics Ducts connected to the LP system?

I actually removed the TE mod first as I assumed it was the issue. It did not solve the leak, it did slow it down but that was only a side effect of less garbage collections and still had the same magnitude.

@SmEdD86 FYI: TE do not contains the ducts anymore, this is a separated mod, called Thermal Dynamics (or TD). You should remove TD for test, not TE.

@hron84 I should have specified better, I removed all mods created by COFH as I didn't know which files the ducts were under. There were no ducts after loading.

@davboecki I will get one for you this Wednesday.

@SmEdD86 Is there any chance you could provide us with an Memory Dump when COFH's mods are not installed. Because the one you posted points to a problem with the LP - TD interaction. There is no way to pinpoint the bug that's causing a problem when their mods are not installed.

@SmEdD86 any update on this?