Sorry I meant port 8002 Very informative data there
Sent from my iPhone On Sep 22, 2014, at 6:07 PM, David Lee <[email protected]<mailto:[email protected]>> wrote: Take a quick look at monitoring history tab on port 2000 Sent from my iPhone On Sep 22, 2014, at 5:46 PM, Michael Blakeley <[email protected]<mailto:[email protected]>> wrote: 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. <PastedGraphic-7.png> 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]<mailto:[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]<mailto:[email protected]> http://developer.marklogic.com/mailman/listinfo/general _______________________________________________ General mailing list [email protected]<mailto:[email protected]> http://developer.marklogic.com/mailman/listinfo/general
_______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
