ori added a comment.
Follow-up items to get the Puppet repo on deployment-puppetmaster04 in good
shape:
- The two cherry-picked reverts should be removed
(https://gerrit.wikimedia.org/r/c/operations/puppet/+/823638,
https://gerrit.wikimedia.org/r/c/operations/puppet/+/823639
ori closed this task as "Resolved".
TASK DETAIL
https://phabricator.wikimedia.org/T277817
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: ori
Cc: Ladsgroup, Lydia_Pintscher, hoo, Aklapper, ori, Invadibot, maantietaja,
Akuckartz, dar
ori added a comment.
The change I'm proposing (I6b36c1647
<https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/674472/>)
should not introduce any significant discontinuity, since the counter delta is
proportional to the sampling rate: i.e., with a sampling rate of 1%,
ori added a comment.
By the way: this would be a good first patch for a new contributor, and I'd
be happy to mentor someone through it.
TASK DETAIL
https://phabricator.wikimedia.org/T277817
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: ori
Cc
ori added a comment.
...and if you increment the stat by a 100 each time, you wouldn't need to
change the dashboards.
TASK DETAIL
https://phabricator.wikimedia.org/T277817
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: ori
Cc: Lydia_Pintscher
ori added a comment.
I like this idea, but wouldn't N reset to zero every time we called into Lua
code? How would you persist it?
An alternative approach would be random sampling: e.g., log only if
`math.random(100) == 1`.
TASK DETAIL
https://phabricator.wikimedia.org/T277817
EMAIL
ori added a comment.
Can you add some ad hoc console#log statements to your local instance?TASK DETAILhttps://phabricator.wikimedia.org/T147798EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: oriCc: ori, Aklapper, Krinkle, aude, thiemowmde, Jonas
ori added a comment.
We are definitely sending duplicate purges. I added some debug logging and
saw URLs get purged a half dozen times for the same job.
TASK DETAIL
https://phabricator.wikimedia.org/T124418
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel
ori added a subscriber: EBernhardson.
ori added a comment.
@EBernhardson made it so when a job fragments into a number of child jobs,
each child job has the same request ID as its parent. This also makes it
possible to aggregate PURGEs by individual parent job:
Top PURGE issuers by orig
ori added a comment.
Breakdown of 10,718,138 PURGEs, captured on 2016-06-01 between 18:00 and
22:00 UTC:
Top PURGE issuers by wiki
-
| Wiki | Percent |
| | --- |
| svwiki | 24.64% |
| itwiki | 12.05% |
| enwiki
ori reopened this task as "Open".
ori added a comment.
Doing this via the job queue is not a good solution, in my opinion. There is
something fundamentally broken about tying updates to parser cache events.
Subscribing to changes via a ParserCacheSaveComplete hook handler is a
ori closed this task as a duplicate of T128029: TemplateData's PHP JSON
validation isn't strict enough because WMF cluster's HHVM allows trailing
commas.
TASK DETAIL
https://phabricator.wikimedia.org/T103346
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel
ori added a comment.
In https://phabricator.wikimedia.org/T124418#1986594, @BBlack wrote:
> Regardless, the average rate of HTCP these days is normally-flat-ish (a few
> scary spikes aside), and is mostly throttled by the jobqueue. The question
> still remains: what caused permane
ori added a comment.
Distribution of purge URLs by hostname:
[fluorine:/a/mw-log] $ field 7 AdHocDebug.log | sed 's/\.m\./\./' | sort |
dist | head
Key|Ct (Pct)Histogram
en.wiktionary.org|893075 (18.66
ori added a comment.
Distribution of (indirect) callers of `HTMLCacheUpdate::__construct` for the
past 20 minutes:
[fluorine:/a/mw-log] $ python /home/ori/cacheUpdateGrepper.py | dist
Key|Ct (Pct)
Histogram
Wikibase
ori added a comment.
In https://phabricator.wikimedia.org/T124418#1963710, @JanZerebecki wrote:
> https://grafana-admin.wikimedia.org/dashboard/db/tmp-t124418
What is that dashboard supposed to be showing? It is very hard to make sense of.
TASK DETAIL
https://phabricator.wikimedia.
ori added a comment.
https://phabricator.wikimedia.org/tag/wikidata/ folks (especially @daniel and
@Lydia_Pintscher): Just a quick note to apologize for my conduct on this task.
I think I was quick to escalate things, and I did it in a manner that probably
only succeeded at raising the stress
ori added subscribers: mobrovac, ori.
ori added a comment.
@daniel, could you please make sure to sync up with the Services team to see
how https://phabricator.wikimedia.org/T114443 could lay the groundwork for
solving this problem better? @mobrovac, could you please act as liaison /
point
ori added a blocked task: T118162: Wikibase dispatchChanges.php runs slow,
creates an absurd amount of database connections.
TASK DETAIL
https://phabricator.wikimedia.org/T48643
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: ori
Cc: Aklapper
ori added a comment.
In https://phabricator.wikimedia.org/T118162#1795369, @jcrespo wrote:
> - The cron jobs run as wikiadmin, which are on purpose not limited in
> execution time, so there is no protection against them overflowing a database
> server
In https://phabricator.wiki
ori removed a project: Patch-For-Review.
TASK DETAIL
https://phabricator.wikimedia.org/T118162
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: ori
Cc: ori, mobrovac, thiemowmde, aaron, jcrespo, gerritbot, daniel, aude, hoo,
Lydia_Pintscher, Addshore
ori added a blocking task: T48643: [Story] Dispatching via delayed jobs
(instead of cron script).
TASK DETAIL
https://phabricator.wikimedia.org/T118162
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: ori
Cc: ori, mobrovac, thiemowmde, aaron, jcrespo
ori removed a project: Performance-Team.
TASK DETAIL
https://phabricator.wikimedia.org/T116568
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: JanZerebecki, ori
Cc: Krinkle, gerritbot, thiemowmde, adrianheine, Addshore, JanZerebecki,
Lydia_Pintscher
ori added a subscriber: Performance-Team.
ori set Security to None.
TASK DETAIL
https://phabricator.wikimedia.org/T117398
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: ori
Cc: Performance-Team, Aklapper, jcrespo, Wikidata-bugs, aude, GWicke
ori closed this task as "Resolved".
ori claimed this task.
TASK DETAIL
https://phabricator.wikimedia.org/T114995
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: ori
Cc: gerritbot, faidon, Addshore, BBlack, Jdlrobson, daniel, Lydia
ori added a comment.
In https://phabricator.wikimedia.org/T114443#1701193, @GWicke wrote:
> @Nuria, see the task description, heading "Initial use cases".
Potential applications are one thing; a concise problem-statement another.
TASK DETAIL
https://phabricator.wikimedia.org/T
ori edited projects, added Performance; removed Performance-Team.
TASK DETAIL
https://phabricator.wikimedia.org/T113665
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: ori
Cc: adrianheine, Krenair, MaxSem, JeroenDeDauw, daniel, hoo, aude, ori
ori added a comment.
SiteList (why can't it just be an array?) extends GenericArrayObject which
extends ArrayObject. ArrayObject provides a `ksort()` method which would be
useful here, except that SiteList maintains its own mappings of offsets to
values in internal arrays.
TASK DETAIL
ori created this task.
ori added subscribers: ori, aude, hoo, daniel, JeroenDeDauw.
ori added projects: Performance-Team, Wikidata.
Herald added a subscriber: Aklapper.
TASK DESCRIPTION
Looking at performance data for `load.php` requests, I notice that we spend
quite a lot of time
ori changed the title from "SitesModuleWorker::getSitesHash()" to
"SitesModuleWorker::getSitesHash() is slow".
ori set Security to None.
TASK DETAIL
https://phabricator.wikimedia.org/T113665
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpref
ori added a subscriber: MaxSem.
ori added a comment.
@MaxSem looked at this code and instantly noticed that it is repeatedly sorting
the cached value whenever it is retrieved (actually, whenever the method is
called), and remarked that it would be far more sensible to do this once, when
ori added subscribers: greg, ori.
ori raised the priority of this task from "Normal" to "High".
ori added a comment.
This is *still* causing fatals in production. Can somebody fix this, please?
@greg, could you please look after this? Anomie's suggestion from
https://phabr
ori raised the priority of this task from High to Unbreak Now!.
ori added a comment.
Herald added a subscriber: Aklapper.
Every so often I crunch some statistics about memcached usage. I can't tell you
how demoralizing it is to find `sites/SiteList#2014-03-17+Site:2013-01-23` near
the top again
ori added a comment.
In https://phabricator.wikimedia.org/T58602#1463722, @hoo wrote:
@aude is going to poke at this when she's back from Wikimania.
Cool, thanks.
TASK DETAIL
https://phabricator.wikimedia.org/T58602
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel
ori added a comment.
Thanks for the quick response.
TASK DETAIL
https://phabricator.wikimedia.org/T58602
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: aude, ori
Cc: gerritbot, Aklapper, daniel, Wikidata-bugs, ori, JanZerebecki, aude,
faidon
ori added a subscriber: ori.
ori added a comment.
In https://phabricator.wikimedia.org/T88550#1395307, @MZMcBride wrote:
What replaced Titan?
Blazegraph http://www.blazegraph.com/
TASK DETAIL
https://phabricator.wikimedia.org/T88550
EMAIL PREFERENCES
https://phabricator.wikimedia.org
ori reopened blocking task T58602: avoid fetching SiteList object from
memcached as Open.
TASK DETAIL
https://phabricator.wikimedia.org/T76705
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: ori
Cc: Aklapper, daniel, Wikidata-bugs, aude, GWicke
ori reopened this task as Open.
ori added a comment.
`{$wgDBname}:SiteList:sites/SiteList#2014-03-17+Site:2013-01-23` items are at
or near the top of memcached keys sorted by bandwidth utilization on the
production memcached cluster. This really needs to be fixed and stay fixed.
TASK DETAIL
ori reopened blocking task T58602: avoid fetching SiteList object from
memcached as Open.
TASK DETAIL
https://phabricator.wikimedia.org/T76705
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: ori
Cc: Aklapper, daniel, Wikidata-bugs, aude, GWicke
ori reopened this task as Open.
ori added a comment.
`{$wgDBname}:SiteList:sites/SiteList#2014-03-17+Site:2013-01-23` items are at
or near the top of memcached keys sorted by bandwidth utilization on the
production memcached cluster. This really needs to be fixed and stay fixed.
TASK DETAIL
ori added a comment.
@daniel Can you explain why this work needs to be done synchronously, blocking
the user?
TASK DETAIL
https://phabricator.wikimedia.org/T86305
REPLY HANDLER ACTIONS
Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign
username.
EMAIL
Facebook just published this summary of a summit for database researchers
held at Menlo Park last September. I recommend it. It contains a clear and
concise description of Facebook's data infrastructure, and a description of
the open problems they are thinking about, which is even more
On Wed, Oct 1, 2014 at 2:46 PM, Daniel Kinzler daniel.kinz...@wikimedia.de
wrote:
We currently use memcached to share cached objects across wikis, most
importantly, entity objects (like data items). Ori suggested we should
look into
alternatives. This is what he wrote:
[21:15] ori I
In November of last year, Aaron noticed a spike in memcached traffic, which
we were eventually able to attribute to Wikibase client fetching the
SiteList on every request. When Katie fixed it, outbound memcached traffic
nearly halved.
We're now back to the same rate of outbound traffic as then,
See below for an extract of the discussion on the recurring disappearance
of interface messages recently. It was a mistake for the discussion to
unfold on an internal list, but it happened quite by chance, starting with
an incident report and developing from there.
---
Ori Livneh
o
. You can change it to:
if ( mw.config.get( 'wgCanonicalSpecialPageName' ) === 'Search' ) {
importScriptURI(//
en.wikipedia.org/w/index.php?title=MediaWiki:Wdsearch.jsaction=rawctype=text/javascript
);
}
Thanks!
Ori
___
Wikidata-l mailing
46 matches
Mail list logo
