|
From: Kevin F. <kf...@ar...> - 2016-08-24 19:41:48
|
Thanks, Bryan.
Reducing the amount of max memory, thereby avoiding swapping, had a
positive impact.
Yours,
Kevin
On 8/19/16 16:06, Bryan Thompson wrote:
> You might also give it less memory for a small data set. What is
> important is making sure that there is NO swapping. Java handles
> swapping very poorly because it needs to do memory scans during GC.
>
> Thanks,
> Bryan
>
> On Fri, Aug 19, 2016 at 4:36 PM, Kevin Ford <kf...@ar...
> <mailto:kf...@ar...>> wrote:
>
> Thanks, Bryan.
>
> We're looking at whether we can increase the memory on the machine
> (currently 8gb, but has other applications running on it) and see if
> that improves matters.
>
> Yours,
> Kevin
>
>
> On 8/18/16 12:32, Bryan Thompson wrote:
> > Kevin,
> >
> > I would not anticipate the kinds of times that you are reporting below
> > for these update requests. Assuming that URI and URI/other are
> not all
> > of the triples in your graph, these should be very fast updates.
> >
> > Can you confirm that the machine has at least those 4GB of RAM
> available
> > beyond the other active processes?
> >
> > Note that Linux distributions will begin to swap out processes
> once 50%
> > of the physical memory has been used unless you set swappiness to zero
> > (a kernel parameter - see the Blazegraph wiki for more information on
> > this topic).
> >
> > Bryan
> >
> > On Wednesday, August 17, 2016, Kevin Ford <kf...@ar...
> <mailto:kf...@ar...>
> > <mailto:kf...@ar... <mailto:kf...@ar...>>> wrote:
> >
> > Dear All,
> >
> > I have a question about SPARQL DELETE/INSERT performance.
> >
> > We have a job that issues two DELETE queries followed by an INSERT
> > query, per request, to keep our triplestore up to date. The
> pattern is
> > as follows:
> >
> > DELETE { <URI> ?p ?o };
> > DELETE { <URI/other> ?p ?o };
> > INSERT {
> > <URI> <new> '1' .
> > <URI> <new> '2' .
> > <URI> <new> '3' .
> > <URI/other> <new> '1' .
> > }
> >
> > We've noted two things:
> >
> > 1) If a store is empty, this is relatively fast.
> > 2) IF the store is configured for automatic inferencing, it is
> slower
> > than a store without that feature activated.
> >
> > Neither of those observations seems particularly surprising,
> but each of
> > those two DELETE statements and the one INSERT takes more than
> 3 seconds
> > against a store with only 4.6 million triples. See below for
> a sample
> > of the output.
> >
> > Blazegraph is allocated 4g of memory.
> >
> > We're working within a framework that produces these series of
> queries
> > so, before making any custom modifications, I was wondering if
> this
> > performance is to be expected? If not, would it point to a
> configuation
> > issue of some kind, or something else?
> >
> > Also, I've noted that issuing a DELETE HTTP request appears to
> handle
> > the deletes faster, but is there a more optimal way to
> construct those
> > three queries (the DELETE/INSERT WHERE pattern did not appear
> to improve
> > matters based on a few isolated tests).
> >
> > Cordially,
> > Kevin
> >
> >
> > $ curl -X POST
> https://laketsidx/blazegraph/namespace/lakeidx/sparql
> <https://laketsidx/blazegraph/namespace/lakeidx/sparql>
> > <https://laketsidx/blazegraph/namespace/lakeidx/sparql
> <https://laketsidx/blazegraph/namespace/lakeidx/sparql>>
> > --data @bg-test-02.sparql -H "Content-type:
> > application/x-www-form-urlencoded"
> > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
> > "http://www.w3.org/TR/html4/loose.dtd
> <http://www.w3.org/TR/html4/loose.dtd>
> > <http://www.w3.org/TR/html4/loose.dtd
> <http://www.w3.org/TR/html4/loose.dtd>>"><html><head><meta
> > http-equiv="Content-Type"
> > content="text/html;charset=UTF-8"><title>blazegraph™ by
> > SYSTAP</title
> > ></head
> > ><body<p>totalElapsed=33ms, elapsed=33ms, connFlush=0ms,
> > batchResolve=0, whereClause=23ms, deleteClause=9ms,
> insertClause=23ms</p
> > ><hr><p>totalElapsed=2579ms, elapsed=21ms, connFlush=2524ms,
> > batchResolve=0, whereClause=21ms, deleteClause=0ms,
> insertClause=21ms</p
> > ><hr><p>totalElapsed=2582ms, elapsed=2ms, connFlush=0ms,
> > batchResolve=0, whereClause=0ms, deleteClause=0ms,
> insertClause=0ms</p
> > ><hr><p>COMMIT: totalElapsed=3118ms, commitTime=1471453475719,
> > mutationCount=62</p
> > ></html
> >
> > $ curl -X POST
> https://laketsidx/blazegraph/namespace/lakeidx/sparql
> <https://laketsidx/blazegraph/namespace/lakeidx/sparql>
> > <https://laketsidx/blazegraph/namespace/lakeidx/sparql
> <https://laketsidx/blazegraph/namespace/lakeidx/sparql>>
> > --data @bg-test-02.sparql -H "Content-type:
> > application/x-www-form-urlencoded"
> > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
> > "http://www.w3.org/TR/html4/loose.dtd
> <http://www.w3.org/TR/html4/loose.dtd>
> > <http://www.w3.org/TR/html4/loose.dtd
> <http://www.w3.org/TR/html4/loose.dtd>>"><html><head><meta
> > http-equiv="Content-Type"
> > content="text/html;charset=UTF-8"><title>blazegraph™ by
> > SYSTAP</title
> > ></head
> > ><body<p>totalElapsed=24ms, elapsed=24ms, connFlush=0ms,
> > batchResolve=0, whereClause=12ms, deleteClause=11ms,
> > insertClause=12ms</p
> > ><hr><p>totalElapsed=2966ms, elapsed=12ms, connFlush=2929ms,
> > batchResolve=0, whereClause=12ms, deleteClause=0ms,
> insertClause=12ms</p
> > ><hr><p>totalElapsed=2969ms, elapsed=2ms, connFlush=0ms,
> > batchResolve=0, whereClause=0ms, deleteClause=0ms,
> insertClause=0ms</p
> > ><hr><p>COMMIT: totalElapsed=3669ms, commitTime=1471453483251,
> > mutationCount=62</p
> > ></html
> >
> >
> >
> ------------------------------------------------------------------------------
> > _______________________________________________
> > Bigdata-developers mailing list
> > Big...@li...
> <mailto:Big...@li...> <javascript:;>
> >
> https://lists.sourceforge.net/lists/listinfo/bigdata-developers
> <https://lists.sourceforge.net/lists/listinfo/bigdata-developers>
> >
> <https://lists.sourceforge.net/lists/listinfo/bigdata-developers
> <https://lists.sourceforge.net/lists/listinfo/bigdata-developers>>
> >
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bigdata-developers mailing list
> Big...@li...
> <mailto:Big...@li...>
> https://lists.sourceforge.net/lists/listinfo/bigdata-developers
> <https://lists.sourceforge.net/lists/listinfo/bigdata-developers>
>
>
|