Running Apache in VM Guest

[danscotti]

I have several vm guests that are configured to run as apache web servers. The guest operating system is CentOS 5.4.

On 2 of them in the Apache logs this error message appears:

zend_mm_heap corrupted

A google search clearly indicates that this is a known bug with PHP. However my application folks don't seem to think that this applies to them because they have apache running on physical servers that do not display this condition. I do know however that the rpms on the physical systems are different than those on the virtuals.

I have increased the allocated memory on the guests to 4 gb (up from 2gb). The memory stats show that the system is using about half a gig of memory. My questions are:

Is there a specific guide for tuning ESX or the guest os for Apache?

I assume others are running apache in virtualized guests. Are you seeing a similar issue?

Are there any speific memory settings or ways that memory gets presented from the ESX host to a guest that could cause this?

Is there any other information I should provide to help trouble shoot this issue.

Is this the correct forum to post this message? If not I apologize.

thanks

Dan

[DSTAVERT]

I don't know that there would be any specific "tuning" that would apply to this issue. Any tuning would really be on an individual case basis.

I would try a P2V on the working physical servers to see if the problem is reproduced.

[jcwuerfl]

Would have to second that. P2V a working one and see if it happens again.

[jamesbowling]

I would verify the version of PHP running on the VM and make sure that they are running the same version. This bug was something found specifically with the str_ireplace function. Are they using that function in their code? Other than that, you can recompile PHP or do as the others have said and P2V a working machine.

If you found this at all helpful please award points by using the correct or helpful buttons! Thanks!

[danscotti]

Hi all,

Thanks for the helpful replies and I apologize for the delay in responding to you all.  The issue ultimiately was one on the application itself.  We ended up building a physical box and installing the application on it.  Turns out the thing performed exactly the same way on the physical machine as it did on the VM. So the apps team is now looking at their application code to see where they can improve it.

Glad to say that it isn't a Vmware issue.

Thanks again.