using Eval.Jit=1 does actually seem faster on deployment-tin, anyway

[thcipriani@deployment-tin ~]$ export PHP='hhvm -vEval.Jit=1'
[thcipriani@deployment-tin ~]$ time sudo -E -u www-data -- mwscript rebuildLocalisationCache.php --wiki=enwiki --outdir=/tmp/thcipriani-l10nupdate --threads=6
[...]
real    16m27.911s
user    11m36.524s
sys     4m44.920s
[thcipriani@deployment-tin ~]$ export PHP='hhvm -vEval.Jit=0'
[thcipriani@deployment-tin ~]$ time sudo -E -u www-data -- mwscript rebuildLocalisationCache.php --wiki=enwiki --outdir=/tmp/thcipriani-l10nupdate --threads=6
[...]
real    28m56.778s
user    23m21.984s
sys     5m18.964s

Workaround for this seems to work fine, thanks!

In T191921#4147196, @Krinkle wrote:

@thcipriani Hm.. these are seconds though, as opposed to minutes. Is there something different about these commands?

This uses the value from /etc/hhvm/php.ini: hhvm.jit = false.

Looks like you all were able to recreate the issue \o/

Changed priority to UBN! since I set as a train blocker.

Lowering priority since I removed as a train blocker (thanks @Reedy!)

Adding as train blocker for 1.31.0-wmf.30, setting as UBN!

Deployed a revert of adding quibble to mediawiki gate-and-submit so lowering priority

This would also give us a place to test various mwscripts used by scap with php7

I managed to grab a better perf report by using PHP='hhvm -vEval.PerfPidMap=true'. Then I waited for beta-scap-eqiad to start rebuildLocalisationCache and I recorded the event via: sudo perf record -g --call-graph dwarf -p $PID

lgtm!

In T183969#4140589, @Aklapper wrote:

https://phabricator.wikimedia.org/T192488 might also be a candidate?: Anchors in resulting URLs don't work after performing a section edit

From scap today: 19:37:56 Finished l10n-update (duration: 39m 12s)
30-40 minutes beta-scap-eqiad runs: https://integration.wikimedia.org/ci/job/beta-scap-eqiad/buildTimeTrend

Also adding @Jdlrobson since he was the author according to https://gerrit.wikimedia.org/r/#/c/424164/3 (not sure why rMW46a7aa7e3e8e shows something different)

Seems like a small visual regression. Should this block train? Adding @Konfused-Kitten as the author and @Krinkle as committer.

restored deployment-mediawiki-07 as appserver backend. It seems the ferm service is having trouble starting on that machine, so the previous varnish 503s were just varnish giving up trying to reach deployment-mediawiki-07.

This is hard to explain. So when deployment-cache-text-04 used deployment-mediawiki-07 as a backend this page was coming back with a 503:

Well the deployment-mediawiki-07 backend was the cause of 503s today. I changed the appserver backend in hiera to deployment-mediawiki05 via https://horizon.wikimedia.org/project/prefixpuppet/?tab=prefix_puppet__puppet-deployment-cache-text and beta came back. Changing priority back to normal.

hrm, everything from load.php is failing. Don't know if this is necessarily deployment-cache-text-04's problem since IIRC that's just a varnish machine. The backends sending back 503 could be the real culprit, looking now.

As suggested in IRC, I ran perf record for rebuilding only the English language cdb in beta (since perf requires root).

Looks resolved in prod. Thanks for the patch @aaron !

fwrite is definitely different in hhvm -- accounts for all the lseek in the hhvm output: https://gist.github.com/thcipriani/6c8c7b13fe31df644bd8b7f8ee52b383

In T191921#4121932, @mmodell wrote:

What could it be wait4ing for?

Profiling info for rebuilding a single file via the command:

Adding @aaron because it's database related

Added at 1.31.0-wmf.29 blocker, setting to UBN!

I added users chelsyx and bearloga to the deployment-prep project. ssh to deployment-prep/beta should authenticate you now.

In D1025#20520, @demon wrote:

I disagree with making it a config variable. We should support the env variable, yes, but otherwise we should expect the system we're on to do the right thing. Configuring this feels like it's just gonna bite us later.

Looks to be working, thanks @herron!

nitpick: mixed underscores with camelCase gives me the jeebies.

Looks good, works for me. Double unmarshall makes the most sense for the version field as we talked about in IRC.

Looks good. You should update the blubber.example.yaml to include version: v1 as well :)

In T191154#4097292, @Ottomata wrote:

Hm actually, I don't seem to have access to the deployment-prep project in Horizon anymore. I don't see it in the project drop down menu. Anyone know why?

wfm

@fgiunchedi you should have access and be a projectadmin now.

Tests look good. Patch is pretty light weight. Does what it says :)

Works. Refactor makes building a CopyAs cleaner than having 2 embedded structs.

Looks good to me! Nice work.

Thanks for the merge @akosiaris !

In P6875#39128, @hashar wrote:

The power of bash:

VBoxManage list vms | grep -i "$vm"

Seems to work well, code looks fine to me (My browser really hates this diff though :)).