Btw, also unaffected is S1 on analytics-store. If desperate for enwiki, go
there.
-s
___
Analytics mailing list
Analytics@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/analytics
Hi!
Just a heads-up:
Today s1-analytics-slave db1047 encountered an issue with a enwiki table,
which in turn stopped S1 replication. The bug has been idetified and the
affected table is being repaired, so replag should catch up within a few
hours.
Note that this did not affect M2 replication (ev
Hi all,
the Multimedia team is preparing to collect data to better understand
usability problems with UploadWizard. UW has a "checkout" structure (step
1: put files in basket, step 2: choose license, step 3: add description,
step 4: you are done), so a funnel analysis to identify which step causes
Thanks Lane -- I'm very happy that we were able to help with this project!
-Toby
On Mon, May 12, 2014 at 1:05 PM, Lane Rasberry wrote:
> Hello Analytics list!
>
> I am following up on a thread I started in October 2013 in which I asked
> for guidance about framing claims on the popularity of Wi
Sean,
tendril is really awesome. I too would love to review the performance of some
queries used for the EE dashboards. One in particular [1] used to be fairly
fast and is now taking an ugly lot of time to complete, possibly due to some
schema change I was unaware of.
I’ll drop you a line off-
Hi,
On Fri, May 02, 2014 at 07:56:58PM +0200, Christian Aistleitner wrote:
> just a quick heads up that the replication lag for the enwiki database
> on the analytics s1 slave (s1-analytics-slave.eqiad.wmnet,
> db1047.eqiad.wmnet) is again >12 hours [1].
during the Zürich Hackathon, replication c
On Tue, May 13, 2014 at 7:02 AM, Aaron Halfaker wrote:
> >(Aaron? still keen?)
>
> Totally. :). I'm down for some query performance review too. I'm already
> doing that informally.
>
Great! I therefore added you to a pending gerrit review ;-)
> > For queries that need indexes on wiki schemas, I
On Mon, May 12, 2014 at 11:48 PM, Gilles Dubuc wrote:
> It would be awesome if you could add a similar (wiki, timestamp) index for
> exactly the same reasons to all the MultimediaViewerNetworkPerformance*
> tables on the same database. Those tables haven't been problematic yet
> because they're a
On Tue, May 13, 2014 at 2:16 AM, Gilles Dubuc wrote:
> I noticed the IS NOT NULL version appear. Forcing the index in that case
>> may not help; I suspect not-null will just cause an index scan and double
>> the overhead compared to the table scan (because the secondary index isn't
>> clustered).
