I tried running the following query against testwiki to see if it returns the right data:

SELECT up_property, SUM(up_value), count(qcc_title)
FROM user_properties
LEFT JOIN user ON up_user = user_id
LEFT JOIN querycachetwo ON user_name = qcc_title AND qcc_type = 'activeusers' AND up_value = 1
WHERE up_property LIKE 'gadget-%'
GROUP BY up_property;

All the data looks legit. No 2300s to be found. Very mysterious. When I load Special:GadgetUsage locally, it also reports the right data.

This is because we were previously storing the value of the Gadget namespace in that field, which is always 2300. We just need to regenerate the data rather than loading from cache.

Regenerating all the Special:GadgetUsage pages now.

@NiharikaKohli: So I started regenerating all the stats yesterday. For most wikis, it took a fraction of a second. For German Wikipedia it took 30 minutes, and for Commons, it took an hour. For English Wikipedia, however, the query never finished. At the 24-hour mark it spit out the following:

enwiki:  GadgetUsage    [QueryPage] [Sat Dec 12 00:16:20 2015] [hphp] [19781:7fd6a869ad00:0:000001] [] SlowTimer [86399998ms] at runtime/ext_mysql: slow query: SELECT ...

It didn't spit out a result, however, and the special page still has the old data: https://en.wikipedia.org/wiki/Special:GadgetUsage. At that point, I just killed the script as I think 24 hours is probably too long for a query to be running (even if it is a designated expensive query).

What's your opinion on this @jcrespo? If 24+ hours is too long, I guess we'll need to create a config variable for the active users feature and disable it on English Wikipedia.

@kaldari: there is a 24-hour query limit on terbium, while it could be increased, I would strongly suggest dividing the query in smaller chunks-24 hour queries should be avoided. Disable it until that is fixed (that is my suggestion).