Question

We are using an old version of TinyMCE (MoxieCode)'s ImageManager on a sites that has been moved to a server running Cloud Linux.

Unfortunately our hosting didn't inform us that there is a hard Virtual Memory restriction for each account of 1,048,576 KB, which didn't exist on the previous server.

This sounds like a lot, but ImageManager now randomly produces Internal Server Error 500's, and a random selection of only about one in every six thumbnails are successfully loading.

In the server error log I find the following message recurring very frequently, again randomly for different index.php's in different folders, mostly in the image manager / stream folder but also in the language folder, the js folder and the rpc folder:

Cannot allocate memory: couldn't create child process: /opt/suphp/sbin/suphp

And lo and behold, if I refresh the CPanel page for the website in which I'm currently refreshing ImageManager, I can see that the Virtual Memory usage has maxed out to 1,048,576 KB. (Normally it sits well below 10% of that.)

I am somewhat baffled why loading a theme, some stylesheets, a language pack and six thumbnails would require this huge amount of memory.

Especially as I can see from phpinfo that output_buffering is set to 0, and ob_start is not called anywhere in the ImageManager code.

I thought perhaps the thumbnails were being created from scratch each time instead of being loaded from the mcith folder, but this is not the case, as I can see from the dates on the thumbnail files.

In fact, if I delete the thumbnails, the thing hangs up completely (thumbnail.auto_generate is set to true).

Sure, we could upgrade to the latest ImageManager (now called MoxieManager), which we've used on other sites, and works fine, but since the user interface and the session authentication have changed significantly, this would involve a lot of work both coding and retraining the client, who doesn't really want the upgrade.

If anyone has an ideas on how to solve this problem that would be much appreciated.

Was it helpful?

Solution

the best you can do is to use the following statements in the ImageManager's source code after each line which looks like it could eat up your memory

error_log("current memory usage: ".memory_get_usage()." on line: ".__LINE__);

once you found the buggy line(s) you can start looking for alternatives

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top