Not easily. There are elements for fragments-added and fragments-deleted in the output from xdmp:query-meters. But normally they are always zero, because the output is generated before the commit phase has been run.
declare namespace qm="http://marklogic.com/xdmp/query-meters"; ; xdmp:document-insert('test', <x/>), xdmp:query-meters()/(qm:fragments-added|qm:fragments-deleted)/string() => 0 0 Commit doesn't run until the request is done, so it's difficult to get any information about what happened during the commit phase. One way around this is to wrap your update work in a read-only request, so that it runs with different-transaction isolation. Here's an example using xdmp:eval - but I'd prefer xdmp:invoke for a real implementation. declare namespace qm="http://marklogic.com/xdmp/query-meters"; ; xdmp:eval("xdmp:document-insert('test', <x/>)"), xdmp:query-meters()/(qm:fragments-added|qm:fragments-deleted)/string() => 2 0 I'm pretty sure that will work with ML5. But with ML7 you could use invoke-function instead, which is pretty slick. declare namespace qm="http://marklogic.com/xdmp/query-meters"; ; xdmp:invoke-function( function() { xdmp:document-insert('test1', <x/>), (: When using invoke-function, be sure to commit. :) xdmp:commit() }, <options xmlns="xdmp:eval"> <transaction-mode>update</transaction-mode> </options>), xdmp:query-meters()/(qm:fragments-added|qm:fragments-deleted)/string() => 2 2 Both times we see that two fragments were added. That's the document fragment plus the properties fragment, because I had maintain-last-modified enabled. And the second time, two old fragments were deleted. This doesn't tell us everything. We can say that there was I/O from timestamp updates. If journaling was enabled then there were also journal writes. After that the state of any existing in-memory stands might drive more I/O, including saves and merges. For journal traffic it would also be important to have an idea how large the fragments were. -- Mike On 9 Jul 2014, at 13:12 , Timothy Pearce <[email protected]> wrote: > Is there a way to profile what file operations happen during a given query? > Much like there is the profile you can run which says time taken per query, > I'm interested in getting a file I/O record. Importantly it's where/when the > data inside the file stands are being changed is in question. > > The premise of the issue is, the backup solution is doing a i/o transaction > log and replaying it to a remote storage, so any extraneous writes can > balloon this log, and the goal is to identify if such writes are happening. > There is a selection process which tags certain documents into collections, > and these initial queries may return thousands of documents within the > marklogic DB, but only tags a select number. The amount of data changes going > to the backup is much larger than the expected for this operation, and thus > the need to identify if a query function is writing to the files inside the > db which it should not. > > Currently running Marklogic Server Enterprise Edition 5.0. > If this functionality has been added in a newer version, that would be useful > to be a solution. > > Thanks, > Tim > > > Nothing in this message is intended to constitute an electronic signature > unless a specific statement to the contrary is included in this message. > Confidentiality Note: This message is intended only for the person or entity > to which it is addressed. It may contain confidential and/or proprietary > material. Any review, transmission, dissemination or other use, or taking of > any action in reliance upon this message by persons or entities other than > the intended recipient is prohibited. If you received this message in error, > please contact the sender and delete it from your computer. > _______________________________________________ > General mailing list > [email protected] > http://developer.marklogic.com/mailman/listinfo/general > _______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
