10

I think since the update to Magento 2.3.1 I have problems with uncached page loads (during development).

I did a blackfire.io trace and it turns out that 42 seconds are spent in usleep here.

Now I am wondering what the purpose of this is. I guess I am running in some kind of race condition?

Did anybody experience something like this before?

EDIT: The call stack seems to involve commercebug.

7

Well that's a -- choice? -- the Magento engineers made.

This isn't an answer, but it looks like that function accepts a callback that's meant to load cached data. The callback checks if there's currently a lock in place. If not, it puts a lock in place, loads the data, and then releases the lock. If there is a block in place, it sleeps for 100,000 microseconds (.1 seconds), and then calls the loader again.

So, thinking out loud, my guess would be

  1. Maybe a more than normal number of requests to this function
  2. Higher than normal read times from your cache.
7

lockedLoadData mechanism needs to decrease the load on the server.

Previously when configuration cache is cleaned on hi-loaded sites all client has generated the same information that significantly increases cpu/io load.

With lockedLoadData only one client will generate cache and others will wait for it.

More details about how it works.

The first function call "get data" callback and if it gets the data than just return it (so if data in the cache, the code work like previous and do not use any locks).

If data is not available and the lock is locked, then in the loop we try to load data until data will gets or lock was removed.

If there is no lock then we create a lock and generate data in save it in the cache and remove the lock and return data

PS: We sent these changes like a patch for one of the clients with up to 20kRPM load and it works at least 3 months, without any problem. So maybe the problem in your customization/modules (for example if they broke the cache mechanism)

  • Interesting... Anyway in my case it runs nuts. I am debugging this with Alan, PulseStorm – Alex May 9 at 17:55
  • seems like a really poor solution, means all users waiting will keep their process alive.. why can't they just use table locks – OZZIE May 10 at 7:42
  • @OZZIE are you prefer that all user generate data, instead of sleeping until one is done? We don't have so math free CPU resources – KAndy May 11 at 2:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.