Here by the way are two dashboard to check on vital signs of the query service: * http://discovery.wmflabs.org/wdqs/#wdqs_usage * https://grafana.wikimedia.org/dashboard/db/wikidata-query-service Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher Product Manager for Wikidata Wikimedia Deutschland e.V. Tempelhofer Ufer 23-24 10963 Berlin www.wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/029/42207.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Listeria has been down since at least Monday. I e-mailed Magnus because of that yesterday. Cheers Yellowcard Emilio J. Rodríguez-Posada schrieb:

It looks like one of the two query machines has died, and the other has stopped taking updates from wikidata. Thus expect you queries to currently work 50% of the time, but the result to be out of date (currently just over 7 hours lag in the data) Addshore On 3 February 2016 at 16:40, <christian.hauschke(a)hs-hannover.de> wrote: -- Addshore

SPARQL query response is currently excellent.  Thanks! Regards, James Weaver On Wed, Feb 3, 2016, at 11:55 AM, Addshore wrote: Christian -----Ursprüngliche Nachricht----- Von: Wikidata [mailto:wikidata-bounces@lists.wikimedia.org] Im Auftrag von Franz Deelmann (Yellowcard) Gesendet: Mittwoch, 3. Februar 2016 16:23 An: wikidata(a)lists.wikimedia.org Betreff: Re: [Wikidata] SPARQL service slow? -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Listeria has been down since at least Monday. I e-mailed Magnus because of that yesterday. Cheers Yellowcard Emilio J. Rodríguez-Posada schrieb: > Listeria is down for me https://tools.wmflabs.org/listeria Not sure if > related. > > 2016-02-03 15:33 GMT+01:00 Lydia Pintscher > &lt;Lydia.Pintscher(a)wikimedia.de > <mailto:Lydia.Pintscher@wikimedia.de>>: > > Here by the way are two dashboard to check on vital signs of the query > service: * http://discovery.wmflabs.org/wdqs/#wdqs_usage * > https://grafana.wikimedia.org/dashboard/db/wikidata-query-service > > Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher > Product Manager for Wikidata > > Wikimedia Deutschland e.V. Tempelhofer Ufer 23-24 10963 Berlin > www.wikimedia.de <http://www.wikimedia.de> > > Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. > V. > > Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg > unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das > Finanzamt für Körperschaften I Berlin, Steuernummer 27/029/42207[1]. > > _______________________________________________ Wikidata mailing list > Wikidata(a)lists.wikimedia.org <mailto:Wikidata@lists.wikimedia.org> > https://lists.wikimedia.org/mailman/listinfo/wikidata > > > > > _______________________________________________ Wikidata mailing list > Wikidata(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikidata > _______________________________________________ Wikidata mailing list >>> Wikidata(a)lists.wikimedia.org >>> https://lists.wikimedia.org/mailman/listinfo/wikidata _______________________________________________ Wikidata mailing list Links: 1. tel:27%2F029%2F42207

Nice that the SPARQL service is upgraded. We noticed something was going on and terminated our bots to wait for more stability. 1. Is that stability now reached? 2. Is there some sort of flag-mechanism, that would indicate if the SPARQL endpoint is stable, being upgraded or had change in state? The SPARQL endpoint is core to our efforts in genewiki's ProteinBoxBot, for a spectrum of reasons. (e.g. concept resolution, identifying data inconsistencies (an item on a gene and protein being incorrectly merged), getting precision and recall numbers on included data sources, etc) Whenever there is an issue, we usually take a step back and retry later. However, this is based on trial and error. It would be quite convenient if we could use a flag-mechanism to decide if we can start or if already started we need to terminate. Can we do this? Advise on different approaches would be also appreciated. Regards, Andra Waagmeester On Wed, Feb 3, 2016 at 7:53 PM, Stas Malyshev &lt;smalyshev(a)wikimedia.org&gt; wrote:

would've been great to make sure everyone has the chance to know what's going on Well, we only noticed what was up due to this email! Take a look at https://phabricator.wikimedia.org/T119915 So you can always get an overall view of the query service at https://grafana.wikimedia.org/dashboard/db/wikidata-query-service Key here for your issue would be the lag graph in the middle right. This is generated using the following query: SELECT * WHERE { <http://www.wikidata.org> schema:dateModified ?y } Which gives you the last modified date for the data stored! Addshore On 3 February 2016 at 21:44, Andra Waagmeester &lt;andra(a)micelio.be&gt; wrote: -- Addshore

Hi! Yes, we need to look into it. The problem is that the service has two failure modes: 1. Completely dead, rejecting all queries. This would be caught by icinga and alerted. 2. Crawling slow, but still partially alive, just performing very very badly. For this one, we do not have adequate alert system. This failure mode is rare, but we've seen it to happen, both due to somebody sending a torrent of heavy queries and some bug scenarios. Icinga does not catch that because it only checks very basic queries and those are still under timeout. -- Stas Malyshev smalyshev(a)wikimedia.org