My laptop with 10.9.4 is pretty stable, and I also have 8-GiB. My last restart was after uptime of almost 80 days. The symptoms that led me to restart were similar: huge VM utilization. But there was an important difference: stopping MarkLogic didn't reduce it significantly. Instead from what I could tell the problem was huge allocations by the OS kernel_task itself. Oddly the Activity Monitor app didn't show this in its table view: I discovered it by looking at the process inspector. It looked something like this, except that the kernel_task had allocated something like 60-GiB virtual memory and its "real size" was about 5-GiB.
It's possible that my kernel task and your MarkLogic process both tickled a similar bug somewhere in the OSX VM subsystem. Or the events might have had completely different causes. Looking at your screenshots, I'd expect a 12-GB database averaging 17-kB/doc to have forest in-memory size around 500-MiB to 1.5-GiB, depending on the content and the index configuration. However the database status page doesn't show memory utilization directly. So check the "in-memory size" at the bottom of the forest status page for the actual number. Another thing to check for is inadvertent over-tuning. It's easily possible to tune up the group-level caches or the database in-memory limits to a point where the allocations run into tens of GiB. Sometimes people do this while trying to resolve cache-full errors. -- Mike On 22 Sep 2014, at 14:06 , Jakob Fix <[email protected]> wrote: > Hi, > > I've recently noticed on my Macbook Pro (8Gb RAM, 512 Gb SSD) that running > MarkLogic as a service uses excessive amounts of "Virtual Memory"[1], > actually making other applications unresponsive to the point where the Finder > says "Your system has run out of application memory". See the screenshots at > the link below. > > http://imgur.com/a/q2yB3/all > > Apparently, by looking at the second screenshot (of the Activity Monitor), > MarkLogic is using a whopping 72Gb of Virtual Memory ... ! Stopping the > MarkLogic daemon divides the Virtual Memory by seven (last screenshot) which > makes me think that it's indeed MarkLogic and not another running application. > > I'm using 7.0-3. Here's the status of the principal database used on this > system: > > Forest Host State Documents Fragments Deleted > Fragments Stands Size Free Space Large Free Space Fast > Free Space > Documents jfix.local open 713,683 1,436,507 232 5 > 12,380 MB 66,758 MB n/a n/a > > Total 713,683 1,436,507 232 5 12,380 MB > > > Is this size of database getting too big for a development laptop? Also, if > there is not enough free disk space available, could that play a part when ML > hoards virtual memory, maybe to run its merge operations? > > cheers, > Jakob. > > [1] > https://developer.apple.com/library/mac/documentation/performance/conceptual/managingmemory/articles/aboutmemory.html > > _______________________________________________ > General mailing list > [email protected] > http://developer.marklogic.com/mailman/listinfo/general
_______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
