Menu
▾
▴
Re: [Bigdata-developers] trivial ASK takes over 5s
|
From: Jeremy J C. <jj...@sy...> - 2016-03-21 20:27:40
|
Yes - or blocking some other part of the process ... > On Mar 21, 2016, at 12:12 PM, Bryan Thompson <br...@sy...> wrote: > > Is the thought then that there might be some barrier that is blocking the start of a new query during some part of that large create? > > ---- > Bryan Thompson > Chief Scientist & Founder > Blazegraph > e: br...@bl... <mailto:br...@bl...> > w: http://blazegraph.com <http://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 Tinkerpop/Blueprints 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. > > > On Mon, Mar 21, 2016 at 12:40 PM, Jeremy J Carroll <jj...@sy... <mailto:jj...@sy...>> wrote: > The logs I have are: > - full GC logs > - python level logs of http requests and errors/warnings (of our application server: not the blazegraph http requests) > > I can map those logs into SPARQL requests approximately, and I see that at the point where I got the long wait, there were a single large create operations that use the > INSERT-by-POST operation taking approximately 30s (including python processing) which normally is much more than 50% of blazegraph time. > > Very minor other activity going on > > No interesting GC activity > > Jeremy > > > > >> On Mar 19, 2016, at 11:57 AM, Bryan Thompson <br...@sy... <mailto:br...@sy...>> wrote: >> >> Do you have full logs for the server during this interval? >> Bryan >> >> ---- >> Bryan Thompson >> Chief Scientist & Founder >> Blazegraph >> e: br...@bl... <mailto:br...@bl...> >> w: http://blazegraph.com <http://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 Tinkerpop/Blueprints 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. >> >> >> On Fri, Mar 18, 2016 at 6:53 PM, Jeremy J Carroll <jj...@sy... <mailto:jj...@sy...>> wrote: >> I checked the GC logs. We have no GC stoppage of more than a second for days either side of the slow query. >> >> The slow query was on March 6th, there was a 3s stoppage on Feb 29th and a 1.8s stoppage on March 9th >> >> Any other thoughts? >> >> Jeremy >> >> >>> On Mar 17, 2016, at 2:54 PM, Bryan Thompson <br...@sy... <mailto:br...@sy...>> wrote: >>> >>> 5s is probably a major GC event. >> >> > > |
