CloudLinux limits per virtual memory so if a process has more than 2GB virtual memory (as all litepspeed processes seem to share the same virtual memory) I guess that they could be hitting CloudLinux's per user memory limit.

If CloudLinux is a case, you should be able to see the limit hit with lveinfo command.

I have a feeling that the reason of the crash is new feature which supposed to perform cleanup against run away php processes. Check your log for incidents sequence. Mine indicates that first cleanup happens then suexec daemon gone.

Also please mind I run XCache Cacher v3.0.1 with LiteSpeed API V6.1 with out any issues.
With LiteSpeed API V6.2 I got a daemon crash every 10-12 hours.

I'm going to give our server a month without oopcode caching to see if it's Xcache the issue.

Are there any known issues with eAccelerator and Litespeed in suexec mode ? I'm now thinking about giving eAccelerator a try as there is now a version on GitHub that is compatible with PHP 5.4 and as we are currently running PHP 5.3.

eAccelerator has been the recommended oopcode cache system by cPanel for some time now, there must be a reason behind this and as APC isn't secure and xCache doesn't seem to be compatible with LSAPI 6.2 and Litespeed 4.2.3 I'm thinking about giving this a try.

Good question, so far since xCache has been disabled I haven't had any problems.

I am however thinking about a new strategy that doesn't envolve xCache. I want to try eaccelerator with PHP5.3 and keep PHP5.3 while it still gets security updates and then update directly to PHP 5.5 with Zend opcache.

I'm under the impression that xcache is good for a few sites but not for hundreds of sites and eaccelerator seems to have been tried and tested on large multi site servers.

I'll still have to test but I'm thinking about allowing 10 to 15GB (and maybe more if it takes it) of shm and disabeling disk cache. If I can't get a high SHM to work I will create a 20GB tempfs partition and set eaccelerator to use this.