Executable 'crc' and whole user experience very slow on macOS

[disposab1e]

General information

• OS: macOS
• Hypervisor: hyperkit
• Did you run crc setup before starting it (Yes/No)?: Yes (crc setup --vm-driver hyperkit)

CRC version

version: 1.0.0-rc.0+34371d3
OpenShift version: 4.2.0-0.nightly-2019-09-26-192831 (embedded in binary)

CRC status

CRC VM:          Running
OpenShift:       Running (v4.2.0-0.nightly-2019-09-26-192831)
Disk Usage:      13.92GB of 32.2GB (Inside the CRC VM)
Cache Usage:     11.71GB
Cache Directory: /Users/disposable/.crc/cache

CRC config

- cpus                                  : 4
- memory                             : 24000

Host Operating System

ProductName:    Mac OS X
ProductVersion: 10.15
BuildVersion:   19A583

Hardware

Processor: Quad-Core Intel Core i7 / 4 GHz
Memory: 32GB

Hyperkit Version (hyperkit -v)

hyperkit: v0.20190201-11-gc0dd46

Steps to reproduce

1. execute crc config view
2. or execute crc config set cpus 4
3. or crc setup or crc oc-env or...
4. any crc command

Expected

A more responsive crc command and user experience.

Actual

It takes nearly 17 seconds for the crc commands to start/finish

Sometimes the crc command freezes the whole system.

After the cluster has started the whole user experience is very slow and unresponsive. Many timeouts when talking to the api internally, slow pod creation...

I know it's all in an early stage, so no blame, just to give you some feedback.

Logs

Please let me know when I can search my logs for more details.

[gbraad]

17 seconds? Do understand you start a VM and a complete OpenShift Cluster. On Windows the experience takes over 2 minutes at least due to copy and boot up.

[gbraad]

Slow pod and API responsive sounds new to me, and might be related to using Catalina maybe. This needs us to look into, ...

[gbraad]

Also note, we do NOT use the hyperlink binaries as installed by docker desktop. Our versions lives in . crc/bin

[disposab1e]

@gbraad Not the creation of the cluster takes seconds, this would be fine :-) A simple command like crc --help takes this time. The creation of the cluster takes minutes.

[disposab1e]

I agree, for me this might be an macOS or especially a Catalina issue.

[disposab1e]

Sorry my mistake! Yes you do NOT use hyperkit from Docker Desktop!

hyperkit -v
hyperkit: v0.20180403-36-ge3b37f

[gbraad]

I still have to update to Catalina (purposely delay this), but perhaps @praveenkumar can chime in about his experience?

[praveenkumar]

@gbraad I am also planning to update to Catalina, some of the blogs I saw that talk about issues with Catalina so I am waiting it to become bit more stable.

[gbraad]

It has been one of the reasons why I am holding off.

[disposab1e]

Means.. sit and wait :-)

[gbraad]

Sometimes we have too. Not all users will upgrade. If Praveen upgrades, I'll stay on an older version to allow testing of multiple versions. It is already an immense effort to try and cover all versions of Windows, add this, and you might understand why someone rather 'sit and wait' ;-)

[disposab1e]

Yes of cource and I understan this! I do the same here... only on machine is upgraded... no worries.. all fine!! :-)

[geerlingguy]

I'm also experience this incredibly slow behavior:

$ time crc --help

It seems like immediately after I run any command, the spinning beachball appears over that Terminal window and the window itself locks up (can't even scroll up) until the moment the command outputs its result. And it's not just help, it seems every crc command is the same, for example:

$ time crc version
crc version: 1.1.0+95966a9
OpenShift version: 4.2.2 (embedded in binary)

real	37.42s
user	0.01s
sys	27.31s

[zeenix]

I'm on Catalina and couldn't reproduce this issue (i-e crc --help is super fast, as expected). FWIW, i tried it after working around #836.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[dictyo]

On Win10 (Behind proxy, firewall, Symantec Endpoint Protection) there are similar very long reaction times

$ time crc version
CodeReady Containers version: 1.19.0+94b0362
OpenShift version: 4.6.3 (embedded in executable)

real    0m35,899s
user    0m0,000s
sys     0m0,031s

With minikube however everything reacted quick and smoothely.

[dictyo]

May be that by doing a typo I catched a glimpse today what delays execution of CRC-commands drastically on Windows with heavy Antivir-tooling:

$ crc sonsole 
      0 [sig] bash 2182! get_proc_lock: Couldn't acquire sync_proc_subproc for(5,1), last 7, Win32 error 0    
    291 [sig] bash 2182! proc_subproc: couldn't get proc lock. what 5, val 1  
Error: unknown command "sonsole" for "crc" 
...

Having it run a second time with a prefixed "time"-command results in:

real    0m52,519s
user    0m8,250s
sys     0m9,281s

It seems that Stackoverflow is handling a similar Cygwin-issue here:
https://stackoverflow.com/questions/34765472/cygwin-error-for-make-couldnt-get-proc-lock-when-compiling-and-running-a-c-p

Hope that helps a bit to get this issue tackled. Can you make something out of this?

[guillaumerose]

We are now shipping a .pkg for macOS. The crc binary is now signed and notarized. The default link will be changed in couple of days.

https://mirror.openshift.com/pub/openshift-v4/clients/crc/latest/crc-macos-amd64.pkg

[guillaumerose]

Default link is now changed to the pkg