Hello! Sorry to use that channel, I know that this kind of question should go to Discourse, but I received no answer there (see thread: https://discourse.phabricator-community.org/t/deleting-transforms-and-stale-files/1713)
Unable to connect to MySQL!
Unable to establish a connection to any database host (while trying "phabricator_config"). All masters and replicas are completely unreachable.
AphrontConnectionQueryException: Attempt to connect to root@localhost failed with error #1698: Access denied for user 'root'@'localhost'.
Make sure Phabricator and MySQL are correctly configured.
I strongly suspect that the answer for this exists already, but I've failed in Googling for it. I have a instance running on <thing>.phacility.com. I have a repository in diffusion. The repository has one active URI that is observing a Github repo. My colleague created a Diff. I accepted. He landed it. In the Differential UI, it shows that the Diff has a commit. However, the Diff remains in the "Accepted" state. It doesn't show as landed/closed/whatever the state should be given that it has a commit associated with it. Halp?
From what I read here https://secure.phabricator.com/book/phabricator/article/arcanist_diff/#pushing-and-closing-revi, it would seem that the implicity arc close-revision call isn't being made for some reason.
[xxx]# bin/storage upgrade;
[2018-11-14 10:10:36] PHLOG: 'UNSAFE: Raw string ("") passed to query ("SELECT * FROM %s WHERE namespace = %s AND isDeleted = 0 %Q") for "%Q" conversion. %Q should be passed a query string.' at [/libphutil/src/xsprintf/qsprintf.php:404]
[2018-11-14 10:10:36] PHLOG: 'UNSAFE: Raw string ("") passed to query ("SELECT * FROM %s WHERE namespace = %s AND isDeleted = 0 %Q") for "%Q" conversion. %Q should be passed a query string.' at /libphutil/src/xsprintf/qsprintf.php:404]
after git pull to latest version i am getting lots of errors like `[31-Jan-2019 16:49:52 UTC] PHP Fatal error: Call to undefined method ManiphestTransactionEditor::getTitleForHTMLMail() in /opt/phabricator/phabricator/src/applications/transactions/editor/PhabricatorApplicationTransactionEditor.php on line 3315
Hey guyw ist there any chance to get help with something like this: https://discourse.phabricator-community.org/t/arc-patch-fails-with-git-lfs-files/2447 ? I really can't figoure out if there is something wrong with our phabricator environment, the window clients working with arc, or something else.
i'm trying to reproduce a problem on our instance we've had for a while (through multiple phabricator versions). Our phabricator box uses huge amounts of memory when browsing repository commits. Our box has 32G mem and still sometimes OOM's if i open a dozen commits simultaneously.
I'm suspecting the graph cache at the moment but still have to dig deeper.
I've traced the request and can see the the cache entry (in general_cache) is ~60M large (compressed) and the diffusion.lastmodifiedquery takes ~5seconds. I haven't traced the memory usage yet though. Still 5s for viewing a commit diff is very slow.
Any idea how i can find out what's wrong with this cache? Dump/show the graph in some kind of readable way? Or is this kind of size normal for it? (we host ~70 repos totalling 10g of data)
Am i correct that it is a single cache for all repositories? (at least there's only one cache key and the problem is not repo specific)
ok, after a bit more digging i can see that the buckets of the graph cache are quite unbalanced. i can see ~20 buckets each having between 100 - 400kb. Then one with 1.7mb, 24mb & 60mb each. There might be a commit that basically changed everything in a repo and creates a very large cache entry because of it? (sth like committing a big bunch of external dependencies)
i'm not sure why the diffusion browser actually needs this information to simply show a single commit diff (not browsing through the tree)
ok, found it. we had some devs use a branch in a repo committing & pushing full rebuilds of stuff. so lot's of commits changing > 1000 files (170.000 to be exact :/ )
in our case i was able to not import this branch. if i wanna view those commit's in phabricator i can't and get the "> 1000 files affected" message. so i think the graph cache should probably ignore those commits as well. i'm not sure though how the frontend would handle cache misses like that, although the cache code states it might happen for recent commits. in our case a single cache bucket needed >2gb of memory to decompress, unserialize and parse. and then obviously didn't fit into the apc cache as well.
simply skipping commits in the graph bucket rebuild having > 1000 paths changed would be easy to add. judging what the consequences in the frontend might be is not ^^ (at least not for me)