https://bugzilla.wikimedia.org/show_bug.cgi?id=56602
--- Comment #16 from Faidon Liambotis <[email protected]> --- This causes: https://ganglia.wikimedia.org/latest/graph.php?r=year&z=xlarge&h=mc1005.eqiad.wmnet&m=network_report&s=by+name&mc=2&g=network_report&c=Memcached+eqiad https://ganglia.wikimedia.org/latest/graph.php?r=year&z=xlarge&h=mc1011.eqiad.wmnet&m=network_report&s=by+name&mc=2&g=network_report&c=Memcached+eqiad https://ganglia.wikimedia.org/latest/graph.php?r=year&z=xlarge&h=mc1014.eqiad.wmnet&m=cpu_report&s=by+name&mc=2&g=network_report&c=Memcached+eqiad Top keys are: enwiki:sites/SiteList#2014-03-17+Site:2013-01-23 (54MB/s) wikidatawiki:sites/SiteList#2014-03-17+Site:2013-01-23 (20MB/s) commonswiki:sites/SiteList#2014-03-17+Site:2013-01-23 (18MB/s) This has been pointed out as early as September 2013, and again March 2014 and again September 2014 and is still happening. Having e.g. 80% of mc1005's total network bandwidth being a single wikidata key, or SiteList keys being consistently on the top of memcached bandwidth output by multiple factors compared to the rest, is frankly indicative of a serious design failure and unacceptable. I don't understand why this bug was closed either. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
_______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
