AppDomain is marked for unload due to memory pressure.

32-bit or 64-bit?  Have you tried tweaking the -g startup option for
sqlservr.exe?  That option configures the mem-to-leave area, which is where
SQLCLR pulls its memory from... It defaults to 256 MB on 32-bit systems, so
it might need a tweak.  Also, how are you doing the string concatenation in
your function?  Are you using StringBuilder, or the concatenation operator
(+)?  The latter could be causing part of your problem if it's what you're
using, as a lot more objects have to be allocated and deallocated than with
StringBuilder...

With regard to perf counters, the .NET counters are the most useful; there
are also a handful of DMVs you can use.  Check out Kimberly Tripp's white
paper, which talks about some of this towards the end:

http://www.sqlskills.com/resources/Whitepapers/SQL%20Server%20DBA%20Guide%20to%2
0SQLCLR.htm

 

 

-------------------------------

The amount of memory on the SQL Server would be my first concern.  1GB of RAM just isn't very much.  The OS alone can consume that relatively quickly, especially with IIS running the server as well.  Hyperthreading isn't generally recommended with SQL Server however, it has nothing to do with your problem currently, which is all memory based.  If anything having a true second core may make the Memory bottleneck that much more visible, as the processors may process faster than the memory can keep up and paging to disk begins to occur.

 

 

-------------------------------

 

You have to have significant memory issues to have both of these events happen together.  The proc cache is Bpool, and the CLR is MTL/VAS.  If you are on 32 bit SQL, then you need to set the -gparameter with 512 and it should resolve the issue with the app domain unload.  What else is running on the SQL Server?  Full Text Indexing/Integration Services/Reporting Services/IIS?  External Memory Pressure can easily trigger internal memory pressure in SQL.  If you have things other than just the SQL Database Engine running, then you may need to scale back your max server memory setting to 6GB or less, and you might consider removing the /3GB to give the 2GB  of VAS to the kernel mode since your bpool is being allocated in AWE.

 

Xprocs, Large Query Plans, connetions with a network packet size > 8060 bytes, SQLCLR, OLE Automation calls, all run in the MTL/VAS allocation taken by SQL Server.  What does your CLR Assembly do?  That is one question I have yet to see posed on this post?  Have you considered that you might have placed your CLR in the wrong place putting it in SQL Server?  What is the PermissionSet for the Assembly?  If it is UNSAFE then I would definately begin to consider that it might be doing the wrong thing inside of SQL Server.  Also check if you use XML documents in SQL that you are destroying the handles on them as this can leak memory, and if you are using OLE Automation calls that you destroy those objects properly as well.