Jump to content
Welcome to our new Citrix community!
  • 0

Heavy IOPs - Google Chrome


Marco Polo

Question

Hi there,

 

In my production environment randomly Google Chrome starts producing heavy IOPs under the users' sessions. I have been in contact with Google's support team, what they have suggested so far is the removal of certain extensions and delete/recreate the Chrome's profile, none of these have worked.

 

This issue goes away right after closing Chrome.

 

This is reproducible on RDSH and VDI sessions.

 

OS: Windows 10 Enterprise 1607 LTSB | Windows Server 2012 R2

VDA: 7.15 CU1

Storage: pure SSD

FSLogix Profile Container (latest build)

Google Chrome x64 (latest build)

 

 

Any thoughts ?

 

Please refer to the attached screenshot (ControlUp) for details.

Capture.PNG

Link to comment

8 answers to this question

Recommended Posts

  • 0
2 hours ago, Marco Polo said:

Hi Blair,

 

The users' profiles are located on a network share (10GB network) using FSLogix Profile containers.

 

In my experience with redirected Chrome user data, the bottleneck will not end up being network but the rate of change on the file server. Hundreds of users using Chrome simultaneously can crush an ordinary file server due to the incredible amount of tiny changes to files in Chrome's cache. If the file server isn't responding as fast as Chrome expects that could explain the strange disk behavior from the Chrome executable. I would test setting Chrome's user data directory to a local path and see if you can eliminate that as a possibility.

Link to comment
  • 0
3 hours ago, Blair Williams said:

 

In my experience with redirected Chrome user data, the bottleneck will not end up being network but the rate of change on the file server. Hundreds of users using Chrome simultaneously can crush an ordinary file server due to the incredible amount of tiny changes to files in Chrome's cache. If the file server isn't responding as fast as Chrome expects that could explain the strange disk behavior from the Chrome executable. I would test setting Chrome's user data directory to a local path and see if you can eliminate that as a possibility.

Thank you for your suggestion.

 

This particular environment is a POC with only a few users and plenty of resources on the filer.

 

According to Google's engineer assigned to this support case, this is a known issue, it seems a fix is planned to land on Chrome Version 66.

 

https://bugs.chromium.org/p/chromium/issues/detail?id=754213

 

 

 

 

Link to comment
  • 0
On 3/1/2018 at 9:10 AM, Blair Williams said:

 

In my experience with redirected Chrome user data, the bottleneck will not end up being network but the rate of change on the file server. Hundreds of users using Chrome simultaneously can crush an ordinary file server due to the incredible amount of tiny changes to files in Chrome's cache.

 

I've personally seen Chrome take down storage arrays due to this. We had active write back enabled and had UPM set to save chrome user data. Once around 900-1000 user threshold was reached the array was overwhelmed and the CPU's pegged.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...