SQL Server 2019 (Centos 8) Non-Yielding Scheduler

We are running SQL Server 2019 (Linux) CU4 with the following server specs: * OS: Centos 8 * RAM: 32GB * HDD: 1TB SSD * CPU: 8 Core I-7 * SQL: Microsoft SQL Server 2019 (RTM-CU4) (KB4548597) - 15.0.4033.1 (X64) Standard Edition (64-bit) on Linux (CentOS Linux 8 (Core)) The SQL server becomes unresponsive after heavy loads (it appears) and has the following in the SQLDump file after a crash...

2020-04-09 02:38:11.48 spid12s     AppDomain 3 (mssqlsystemresource.dbo[runtime].2) is marked for unload due to memory pressure.
2020-04-09 02:38:11.48 spid12s     AppDomain 3 (mssqlsystemresource.dbo[runtime].2) unloaded.
2020-04-09 10:09:43.60 spid31s     AppDomain 2 (master.sys[runtime].1) is marked for unload due to memory pressure.
2020-04-09 10:09:43.61 spid31s     AppDomain 2 (master.sys[runtime].1) unloaded.
2020-04-10 11:52:15.26 Backup      Database backed up. Database: readyalert, creation date(time): 2020/02/11(08:19:22), pages dumped: 190987, first LSN: 67110:336:1, last LSN: 67110:360:1, number of dump devices: 1, device information: (FILE=1, TYPE=DISK: {'/var/opt/mssql/backup/readyalert_prod.BAK'}). This is an informational message only. No user action is required.
2020-04-10 11:52:15.28 Backup      BACKUP DATABASE successfully processed 190746 pages in 4.842 seconds (307.765 MB/sec).
2020-04-12 00:00:02.54 spid59      . Feature Status: PVS: 0. CTR: 0. ConcurrentPFSUpdate: 1.
2020-04-12 00:00:12.34 spid59      DBCC CHECKDB (readyalert) executed by NT AUTHORITY\NETWORK SERVICE found 0 errors and repaired 0 errors. Elapsed time: 0 hours 0 minutes 9 seconds.  Internal database snapshot has split point LSN = 00010627:00010e78:0001 and first LSN = 00010627:00010e68:0001.
2020-04-15 11:12:58.53 spid59      AppDomain 4 (mssqlsystemresource.dbo[runtime].3) created.
2020-04-15 11:16:28.21 spid88      AppDomain 5 (master.sys[runtime].4) created.
2020-04-15 14:39:02.71 Server      Using 'dbghelp.dll' version '4.0.5'
2020-04-15 14:39:02.76 Server      ***Unable to get thread context for spid 0
2020-04-15 14:39:02.76 Server      * *******************************************************************************
2020-04-15 14:39:02.76 Server      *
2020-04-15 14:39:02.76 Server      * BEGIN STACK DUMP:
2020-04-15 14:39:02.76 Server      *   04/15/20 14:39:02 spid 384
2020-04-15 14:39:02.76 Server      *
2020-04-15 14:39:02.76 Server      * Non-yielding Scheduler
2020-04-15 14:39:02.76 Server      *
2020-04-15 14:39:02.76 Server      * *******************************************************************************
2020-04-15 14:39:02.77 Server      Stack Signature for the dump is 0x0000000000000338

Any help would be appreciated as we tried updating to the latest CU4 and the problem still persists.