To clarify the issues referred to in this thread:
LeMarque provided two ticket numbers, unfortunately both tickets are quite outdated - one from mid-March, another from mid-April. Due to the amount of time passed since tickets were created it is quite hard to provide any specific assistance as most of the logs were rotated already. Based on the information from "ps" output provided in both tickets LA numbers pretty much corresponded to number of Apache processes that were in the "R" (running) state. According to LeMarque there were no really active sites on the VPS at that time however something still triggered Apache being in the "R" state but what exactly - impossible to find out due to amount of time passed.
Aussie_Boy's ticket is a totally different story and quite many hours were spent investigating and monitoring the problem. In reality two problems happened at about the same time:
1. Slow sites, high load, high CPU usage. After extensive monitoring this was tracked down to MySQL database queries, one being extremely resource (read CPU and disk i/o) intensive and was taking up to 200+ seconds at times to be executed, other was lighter but still taking its toll. Before I started to look at Aussie_Boy's ticket the support pointed the reason for high load to the very same account and database operations. It is my understanding that Aussie_Boy disabled the resource intensive query and trimmed huge table in the database to reduce amount of time required for other queries to run;
2. Network connectivity problems - occasional timeouts were reported. Based on the information about IPs of users who was having problems the possible source well outside of any of our networks was found - packet loss somewhere between SingTel and OPTUS INTERNET networks on the other side of the ocean. Ping to SingTel's hop doesn't show any packet loss, ping to the very next hop which belongs to Optus's network shows up to 30% packet loss. Sorry but there isn't much we can do with this.
Also, taking in account Aussie_Boy's constant complains about network stability in San Jose and SLA request tickets I still remain very wondered why would the customer continue to ignore the possibility to move to a more stable network. Complains and refusal for better change is a bit beyond of my understanding.
Aussie_Boy - also, it would be much appreciated if at least some feedback would be posted as a follow up to the public complain after all the work that was done to address your initial concern in this thread. Apparently based on follow ups from other customers everyone remains under the impression that we just deliver poor service and don't care about our customers and/or service we deliver.
sorry man...