|
From: Brad B. <be...@bl...> - 2016-04-20 19:39:01
|
Daniel,
On other option to try is varying the queryThreadPoolSize in the web.xml
parameters.
Thanks, --Brad
<context-param>
<description>The size of the thread pool used to service SPARQL queries
-OR-
ZERO (0) for an unbounded thread pool.</description>
<param-name>queryThreadPoolSize</param-name>
<param-value>16</param-value>
</context-param>
On Wed, Apr 20, 2016 at 3:30 PM, Daniel Hernandez <da...@de...> wrote:
> Hi,
>
> I have run the experiments again, but now using different parameters in
> the request:
>
> 1. With no options.
> 2. With the option timeout=1.
> 3. With the options timeout=1 and analytic=true.
>
> Simultaneously, I set a timeout in the HTTP client of 120 seconds. Then
> I run the 500 queries. In the three cases queries have small time
> responses,
> but when some of them get a timeout then, all the following get a timeout.
> In the case 1 the first timeout was produced in the query 37, in the second
> in the query 39 and in the third in the query 41. It seems, that the
> timeout
> was not produced because these queries where specially difficult but
> because a process that is initiated a while after starting running the
> queries.
> I guess that this process is the garbage collector.
>
> What can I do to avoid this issue and to improve the resource usage of the
> machine?
>
> Cheers,
> Daniel
>
> ---- On mié, 20 abr 2016 11:30:23 -0300 Daniel Henández <da...@de...>
> wrote ----
> > Hi,
> >
> > I, running an experiment with 583 millions of triples loaded into
> > Blazegraph 2.1.0. I have 500 queries generated randomly with similar
> > complexity. I started running these queries with a timeout of 120
> > seconds in the http client. The first queries get small times around 2
> > seconds, except some that gets around 40 seconds. However, in query 37 I
> > got a timeout. Then, all the following queries get timeouts.
> >
> > I guessed that this behavior was because the server was working in the
> > previous query when the following queries arrive. That is, the server
> > does not notice that the client have a timeout, so it is not waiting for
> > a result.
> >
> > I found the timeout option in the documentation. Thus, now I'm running
> > queries with the option &timeout=1 to check if this behavior was because
> > running queries simultaneously. I starting getting only results in less
> > than 1 second, and some trunked results with an internal timeout error
> > message that truncate the JSON output. However, after some queries I get
> > the timeout in the client again, and then all the following queries get
> > timeout.
> >
> > Now I guess that a GC job that avoid receiving more queries by the
> > server. I set the parameter -Xmx6g in the java command. The machine have
> > 32GB of RAM and 6 cores. I do not put more memory in the heap, because
> > the documentation does not recommend it. However, top says that the
> > process has VIRT=6913m RES=781m and CPU=104%. That is, the process is
> > underusing the machine resources.
> >
> > I found that I can use the option analytic to using the system heap
> > instead of the java heap. The documentation said that this will solve
> > the GC issue.
> >
> > Do you think that am I right in suppositions about the GC?
> >
> > Cheers,
> > Daniel
> >
> >
> >
> ------------------------------------------------------------------------------
> > Find and fix application performance issues faster with Applications
> Manager
> > Applications Manager provides deep performance insights into multiple
> tiers of
> > your business applications. It resolves application problems quickly and
> > reduces your MTTR. Get your free trial!
> > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> > _______________________________________________
> > Bigdata-developers mailing list
> > Big...@li...
> > https://lists.sourceforge.net/lists/listinfo/bigdata-developers
> >
>
>
>
> ------------------------------------------------------------------------------
> Find and fix application performance issues faster with Applications
> Manager
> Applications Manager provides deep performance insights into multiple
> tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> _______________________________________________
> Bigdata-developers mailing list
> Big...@li...
> https://lists.sourceforge.net/lists/listinfo/bigdata-developers
>
--
_______________
Brad Bebee
CEO
Blazegraph
e: be...@bl...
m: 202.642.7961
w: www.blazegraph.com
Blazegraph products help to solve the Graph Cache Thrash to achieve large
scale processing for graph and predictive analytics. Blazegraph is the
creator of the industry’s first GPU-accelerated high-performance database
for large graphs, has been named as one of the “10 Companies and
Technologies to Watch in 2016” <http://insideanalysis.com/2016/01/20535/>.
Blazegraph Database <https://www.blazegraph.com/> is our ultra-high
performance graph database that supports both RDF/SPARQL and Apache
TinkerPop™ APIs. Blazegraph GPU
<https://www.blazegraph.com/product/gpu-accelerated/> andBlazegraph DAS
<https://www.blazegraph.com/product/gpu-accelerated/>L are disruptive new
technologies that use GPUs to enable extreme scaling that is thousands of
times faster and 40 times more affordable than CPU-based solutions.
CONFIDENTIALITY NOTICE: This email and its contents and attachments are
for the sole use of the intended recipient(s) and are confidential or
proprietary to SYSTAP, LLC DBA Blazegraph. Any unauthorized review, use,
disclosure, dissemination or copying of this email or its contents or
attachments is prohibited. If you have received this communication in
error, please notify the sender by reply email and permanently delete all
copies of the email and its contents and attachments.
|