Berry: [Question] Is there anything that could block the event loop?

[AdrianSkierniewski]

Hi,

First of all, I'd like to say that I really like the new yarn :)
Since I started using it I experienced one issue that might be related to the upgrade. I'm serving static files using the Hapi.js server. There is nothing fancy there, I'm requiring things like path, zlib, fs (to read one file synchronously at the beginning of the file), @hapi/hapi, @hapi/inert.
I'm deploying to the k8s cluster and I noticed that sometimes the container is crashing a couple of times before it actually starts. After spending some time I discovered that it's because of the health check issue. In logs there is nothing, everything looks normal. One of the potential reasons could be that the HTTP server starts immediately and then later there is something that can lock the event loop for some time causing some delays on health check response.

I was able to debug it a little bit by using node --trace-sync-io flag. I've got something like this:

(node:7686) WARNING: Detected use of sync API
    at lstatSync (fs.js:1031:25)
    at lstatSync (.../.pnp.js:43875:24)
    at findZip (.../.pnp.js:47775:30)
    at makeCallPromise (.../.pnp.js:47742:26)
    at openPromise (.../.pnp.js:47094:23)
    at openPromise (.../.pnp.js:44509:24)
    at openPromise (.../.pnp.js:44509:24)
    at .../.pnp.js:44884:9
    at processTicksAndRejections (internal/process/task_queues.js:75:11)

I'm getting this multiple times almost every time when the server serves a static file through the browser. I don't know if this could cause the issue, so that is why I decided to create this ticket.

Is there something that could block the event loop on runtime?

[arcanis]

The findZip function does a few synchronous calls to check for file existence, but that shouldn't have any real impact on your application 🤔 Are you working within Docker? Does the same happen outside a container?

[merceyz]

The amount of work done by the PnP runtime was reduced a lot in https://github.com/yarnpkg/berry/pull/1474 but it hasn't been released yet, could you try with the latest changes from master using yarn set version from sources and see if that helps?

[AdrianSkierniewski]

@arcanis I've tested it outside the docker to figure out what could lead to the health check not responding issue. This is my only trace for now. I do agree that this shouldn't have a real impact since it's just a lstatSync. Is there anything else that could block event loop for some time? Maybe some big portion of synchronous code execution or something. I'm using monorepo concept so at the and there is a lot of node_modules, but during the deployment, I get rid of all unnecessary stuff so it shouldn't matter.

[merceyz]

As mentioned in https://github.com/yarnpkg/berry/issues/1555#issuecomment-654946654, please try with master.

[AdrianSkierniewski]

thank you @merceyz I will do that and post the results here

[alubbe]

Just to make sure, that was not released with yarn 2.1.1, even though it's on master?

[merceyz]

It was released with 2.1.1

[merceyz]

Closing this as the answer to the question is: yes, but it shouldn't do it as much anymore. If you're able to provide a repro with the latest version of Yarn that shows a slowdown I can profile it and see if there is something that can be optimized.