Not sure if this is significant, but rmprocs(2) returns immediately with :ok and frees up the memory (again, according to Activity Monitor).
On Wednesday, September 9, 2015 at 2:06:24 PM UTC-7, Seth wrote: > > julia> remotecall_fetch(2, whos, ) > From worker 2: ArrayViews 137 KB Module : > ArrayViews > From worker 2: AutoHashEquals 5345 bytes Module : > AutoHashEquals > From worker 2: Base 20321 KB Module : Base > From worker 2: Compat 25 KB Module : Compat > From worker 2: Core 2741 KB Module : Core > From worker 2: FactCheck 34 KB Module : > FactCheck > From worker 2: GZip 250 KB Module : GZip > From worker 2: GraphMatrices 294 KB Module : > GraphMatrices > From worker 2: LightGraphs 296 KB Module : > LightGraphs > From worker 2: LightXML 35 KB Module : > LightXML > From worker 2: Main 25038 KB Module : Main > From worker 2: ParserCombinator 206 KB Module : > ParserCombinator > From worker 2: StatsBase 342 KB Module : > StatsBase > From worker 2: StatsFuns 348 KB Module : > StatsFuns > > Nothing showing the 10.30GB Activity Monitor is showing for this instance. > > On Wednesday, September 9, 2015 at 2:06:15 AM UTC-7, Nils Gudat wrote: >> >> I think whos() should help you, it'll give a list of all objects defined, >> as well as their size in memory. If you run it as remotecall_fetch(2, whos, >> ), where 2 is the number of the worker process (of course you could pick >> any number returned by procs()), you should be able to figure out what's >> taking up the space in memory. >> >> Let me know if this works! >> >
