[18:48:50] Talk by Rasmus about modern PHP, at minute 15 he demoes phpspy. I was aware of this as a low overhead profiler not unlike our own excimer. I didn't really see that much value in running or over standalone scripts per-se in its commonly shown invocation pattern, but Rasmus is showing here how you can run it like "top" and have it find/poll other php processes including php-fpm or a CLI script like phan, and then see how it's time is spent [18:48:50] cumulatively. That's quite a lot of value with little effort. / https://youtu.be/Hc4S74LCXHo [20:32:31] I took a look, it looks like it uses ptrace, which is not low-overhead [20:32:34] https://github.com/adsr/phpspy/blob/master/phpspy.c#L512 [20:34:44] excimer's approach of using the zend_interrupt_function VM hook is a lot more efficient [20:37:56] huh, I should have checked. Right, we discussed ptrace already when thinknig about excimer originally. [20:38:12] one of you should give a talk about excimer at one of the php conferences [20:38:21] * ori generously volunteers your time [20:38:25] I believe the main benefit w.r.t "low overhead" is that it has no overhead when the profiler doesn't run, and verifably so as phpsy doesn't install anything at runtime. [20:38:43] but yeah, there's plenty of other ways to introduce overhead [20:38:51] on a moderately related note I tried to test out PHP >= 8's perf map support on the parserTests suite, but haven't yet gotten a really usable result [20:39:17] the symbol mapping seems to work but the stacks make little sense, probably will need to recompile php with -fno-omit-frame-pointer and give it another go [20:39:31] parser tests also complete surprisingly quickly so may need a meatier benchmark [20:39:39] like Barack Obama in a loop [20:39:41] the fact that its close to zero-config , though, does make it attractive for non-prod use cases. I wonder to what extend phpsy is or is not similar to tideways and xdebug in terms of not just being slow but being slow in ways that makes the data non-useful. [20:39:53] I would hope that phpsy doesn't include its own time spent in scheduling its interrupt [20:40:43] php8 has perf maps? nice [20:40:51] yeah, via opcache.jit_debug [20:40:59] https://wiki.php.net/rfc/jit [20:41:18] Krinkle: that would give you 'perf top' for a top-like tool [20:41:25] https://timotijhof.net/posts/2020/profiling-php-at-scale/#fn4 [22:24:13] Krinkle: I see you cherry-picked the DependencyStore::renew change [22:25:57] TimStarling: yeah, intending to deploy in a bit, in a meeting atm [22:27:22] shall I also cherry-pick to wmf.20 and get a config patch ready? [22:29:54] RE: mysql tmpfs - I'm asking to undertand rather than suggest anything, but would that not result in loss on restart? I suppose we could puppetise the masters and replicas differently, e.g. still have disk backed on replicas and somehow switch between the two. But then my mostly non-existent understanding of linux fs cache tells me that would be kind of re-inventing what linux could perhaps be configured to do automatically under the [22:29:54] hood by keeping it in memory if it fits, possibly through some mariadb settings to also discriminate less about what it caches and perhaps flush less often somehow. [22:30:03] TimStarling: no train this week, wmf.21 next week. [22:31:45] I did notice yesterday on the host overview that memory use was steadily increasing, but only in the "cached" bucket, which afaik is essentially disk page cache that will yield to anything mariadb or other procs allocate themselves, presumably all taken up by the binlog file and nothing competing for it yet? [22:32:07] rouhgly matching hte binlog size (300G both for the file and the fscache RAM) [22:33:22] if mariadb crashes, you would still have all the data in the tmpfs. If you restart the server, you could recover from another server by rsync or whatever [22:33:44] the failure scenario in which starting from scratch would be needed is if power was lost to both datacentres [22:34:54] even then, you could replay the binlogs which would be stored on disk