About a week ago I sat down and installed a fresh version of Movable Type Open Source 4.1 to my server. After getting through the configuration process and setting up my SQL database and the whole 9 yards, I finally find myself logging in for the first time. As I'm asked and enter my login information, and I notice that the system....seems to.......be........running..........sortof......................slow. I didn't think much of it at the time, because sometimes my internet gets slow, or my host can get a little laggy. No big deal, I ignored it.

But then the lag continued... and not for a little while. Which each click inside the interface (to look at the options, to create a new post, to select the skin I want..... anything) I noticed that things simply were not speeding up. After checking my other sites (on the same server), and checking my internet connection (on other websites in general) I determined that there was something laggy about the software itself. However, I put the issue aside for a moment and got ready to write up my first blogpost... a few paragraphs. Nothing big, nothing extravagant... not even any pictures. SIMPLE stuff.

Imagine my surprise when I tried to save the document (before publishing), and found myself faced with an *extraordinarily* long lag, and then getting slapped in the face with this:
"Out of memory during "large" request for 69632 bytes, total sbrk() is 25042944 bytes at lib/MT.pm line 1916."

Oh, an error. That's odd. Let me try again. Nope, still broke. Let me try again. What? a 500 error? Okay one more time.......nope, still not working.

"Let me go google it," I thought. Surely there would be a quick fix. It's not like I have any weird plugins or anything.

I search Google, and find other people with the same problem.

I find these forums, and find SEVERAL threads with the same issue.

I find other forums with people asking questions.


No solution that I can use. At all.


The closest I get: someone actually has the nerve to say that it's a problem with MY SERVER because my host won't allow anything more than 16MB on RLimitMem directive (translated: Please be aware that our servers are configured to allow only 16MB of memory for processing and 8MB for uploads via PHP).

I'm publishing text here... I am not calculating PI to the 10^64 decimal, nor am I part of SETI@Home.......... why in the world would I need more than 16 MEGS to process a blog? Can someone answer me this, please?


So essentially, what I'm stuck with is a FRESH version of Movable Type that DOES NOT WORK. And this isn't due to some easily fixable problem, but (apparently) some memory leak or loop that people happened to overlook when releasing the software??? Excuse me, but that doesn't seem like a professional job AT ALL. This is Movable Type, one of the premiere blog publishing platforms, not some random application I installed a beta for off of Sourceforge. I'm severely disappointed.

I'm sorry if I come off sounding a bit upset about this whole thing, but frankly I've poured more than a few hours into researching this issue, and to no avail. I hope I'm wrong, but as far as I can tell this has been an ongoing problem with Movable Type for quite awhile, and I can find no appropriate fix, anywhere, short of "blaming the problem on my host." I pay good money for my host, and I've never had a problem like this before. Do bad programmers get to blame Windows when their software doesn't run? I don't think so. Fix the bug.


Someone tell me there is a patch for this issue, because my only other options seem to be Get Another Host or Get Another Piece of Blogging Software.

Given that.... which do you think I'll choose?

Get another host, then come back and tell us how it works without the nasty, unnecessary attitude when you're complaining to what is a free copy of very powerful content management software. Lots (lots) of us use MT with absolutely no memory or server issues. The problem really sounds like it's your underpowered server. And btw, the activities your describing aren't just "publishing text" -- the system is wholly more complicated than that and your rant here shows that your hours of research haven't been enough to show you what Movabletype really is.

All threads I can find referencing this error are so old as to be irrelevant. You're barely using the same application as those people.
Unless you're dealing with an extremely underpowered host, which despite your pre-emptive protest has not been ruled out(see below), there's no reason a fresh install of MT should do this. MT4 does have some resource usage issues that are the primary focus for the next release expected soon, though not like this. But unless you stop assuming that your host couldn't possibly be at issue, you're not going to get very far.


I'm not aware of anyone saying anything about your server, unless there's a prior thread directly involving you and your server which you are not referencing here. That said, yes, it could be your server. Or a botched installation. Or lots of other things.
PHP upload limits have absolutely nothing to do with this.


And who exactly is the host? Your prior experiences, presumably with other software, aren't necessarily relevant here, by the way, especially when we don't know where the software isn't being installed.

All that said...

Memory leaks are not a factor in CGI applications, as I understand it, so what makes you bring it up? Are you running MT under FastCGI? If so, have you tried using it without? Are you sure it's properly configured?
EDIT A memory leak issue is generally not going to make much of itself in a CGI setup, where the issue is flushed away each page load. Either way, it's highly unlikely that's what's going on here, unless you're doing something bizarre with templates, and you've given the impression this is a stock install so far.

It's not quite clear what action you were taking before the "extraordinarily long lag"(how long?), but it seems you were saving a post? Did you try doing other things to see if the behavior is the same, like rebuilding only a single index template? Also try one that doesn't even pull content like the RSD or Stylesheet ones.

I don't think it's the server. But you know what? Fair enough, let's consider it. What specific stats on my server should I ask my host about?

By the way, this is where I'm getting my perspective from. I was hoping to side-step the whole "maybe you're server is an Apple II GS" attitude. I found that highly unwarranted.
http://forums.sixapart.com/index.php?showt...mp;#entry148354



The host I'm using is Globat.com.



After searching around the web for awhile I found some references to memory leaks in Movable Type 4. Most notably I saw a mention of this in the release notes: http://www.movabletype.org/documentation/a...ease-notes.html However...



...I am not using Daemon mode or FastCGI as far as I am aware.



Anything, really. mt.cgi takes a good 9-10 seconds to just load the dashboard. If I click Manage --> entries it takes another 9-10 seconds. If I click to edit my blog entry (the one that's a few paragraphs), the blog hangs for another 8-10 seconds and then errors out. If I click design --> blog templates I get a similar lag. Same if I click Preferences --> General settings. Basically ANYTHING I click on within mt.cgi takes an extraordinarily long time. This is just navigating the interface--not even publishing anything.



Yes, when I tried to save the post it began to give me the memory error consistently. Before that, I would get the memory error intermittently. Now, every time I try to click on that blog post I get the error again. I cant edit it, I cant access it, it just sits there in limbo draft mode.



Publishing (ironically) is not really a problem. It's just using the interface which is giving me this giant headache.

And what plan are you using? Anytime I see something like "Only $6.95/mo for a gazillion features and GB of storage space" I start to suspect that the host is involved. The reason? In order to get you those kinds of prices, they need to jam as many users (read: cattle) onto each server (read: cattlecar) in order to pay for it and then, to keep all of the users sort of happy, they need to implement very strict restrictions on what each user can do. This often takes the form of process killing daemons who monitor several different statistic (run time, memory usage, CPU usage, etc) killing any process that strays outside of the boundaries (read:electric barbed-wire and cattle guards).

That, combined with the particular error -- which is absolutely the error thrown by Apache when you hit one of those pre-configured limits makes me zero in on the issue: You're doing something that some process on your host doesn't want you doing.

Now here's the thing: It could be a haywire reaper process on the host. It might be that your host has ridiculously low limits. It might be that that process was killed for a whole host of reasons that are currently completely opaque to you or I. If you use a remote database (where you set DBHost) it may have even been that the database host was overloaded from all of the requests of the other users that yours exceeded the allotted percentage of available memory which could have been infinitesimally small because of the pounding.

Given that, the best thing for you to do is to first inquire with your host what happened. With that information, you are better equipped to take care of it one way or another. Movable Type can and does run on restrictive hosts for a great number of people so talk to your host and let's figure out where the true bottleneck is before pointing fingers and assuming anything about anything or anyone, you, your host or Movable Type.

Also note that an overloaded database will make the admin UI crawl.

And as Su said, memory leaks wouldn't be affecting you. They only really affect persistent environments where such things build up over time making the application size in memory very bloated. When running under CGI as you are, the application never has a chance to bloat because the RAM allocated to the process is wiped out after each request.

Jay - I'm having very similar issues with 4.1 - hosted at RackSpace on my managed / dedicated server. I have about 10 blogs (5,000 entries / 8,000 comments) in one database that ran famously on MT 3.3. Posting an entry seems to work OK, but the UI and rebuilds are horrible! (to the point that I am stuck).

I played with 4.1 in a test environment (fresh install worked fine with test posts) for a month or so, then put it to the test when I upgraded my 3.3 install. I imported the templates from my test environment to the main blog and things started downhill from there.

I tried MT-Hacks Cache Block - which seemed to help the rebuilds - but I had several other strange issues that started to show up, so I abandoned Cache Block (for now).

So, I then suspected that perhaps 4.1 didn't like all the old code of 3.3 hanging around. So I started to copy templates and and install them on the other blogs (4 of 10 complete). Proved to not be a good idea. Now one of my new blogs with just 50 posts will not rebuild.

Any suggestions?

I paid for the version, so I guess I could start a support ticket - just not sure what to even ask for...

Oh, the install is pretty basic - mostly stock - I tweaked a few templates with some Include Modules and Widget Sets. A couple of plugins (approved for MT4)

PLUGINS:
BFU2.2
Pagination (not working)
Cache Block (disabled)
FastSearch (Installed to try and relieve some stress on mt-search.cgi)
VisitorsStats Pro
Template Exporter
Template Installer

I think that's it. The blog is at http://thefuntimesguide.com

Any suggestions would be apprecitated

Actually, that sounds like exactly the opposite problem. The poster above said that rebuilds were fine but that navigation inside of the app was slow. Perhaps you should start a different thread?



Which would indicate to me that you've got something in your templates that is dog slow. Since you mentioned the Pagination plugin, I'm assuming that you haven't heretofore been very concerned about your rebuild performance because it's one of the most devastating plugins in that regard. So I'd definitely look at your templates for inefficiency.

As to why it seems much slower under 4.x, that may very well be a plugin interaction. (Why do you still have the Pagination plugin installed?) Are *all* of your plugins built specifically for MT 4.x? etc etc.



That's also an excellent idea. This sort of thing sometimes takes some time and effort to discover through reduction and testing. It's something that's very difficult to do remotely with only limited information and the support team is good at it. Your other option is to contract with someone like me or the other MT consultants to get in their and solve the problem. When actually working directly with an install, the problems are usually very quickly evident to us.

In any case, you should probably move over to another thread for your problem.

jimwalczak, you may also want to try turning on 'DebugMode 8' and watch your webserver error log. See here for more.

Also, eventually you (and just about everyone) should really use Publishing Queue but that's best done after you're sure you've gotten rid of any plugin/template problems.

I wasn't clear in my previous quote - I am also have problems with the UI - it can take several minutes to switch between blogs or template screens.

Per your suggestion I will remove Pagination from my templates to give that a try (although I never experience an issue with 3.3).

The difference that I see is that my 3.3 templates bascially had each "module" (left column / right cloumn, etc) built as an index and output to a .php file. I think did a SSI to include them where needed. I am assuming (maybe I shouldn't) that MTInclude Module name= works the same as an SSI? Or not?

I am uping my PHP ini mempry to 32MB as a test

Not at all. Modules are included at template compile time and evaluated in the context of the point at which they are included. Index template SSIs/php includes are built once, output to the filesystem and then inserted into the place where they are called by Apache at request time. Totally different animals for totally different needs. Because of the contextual interpolation, modules are much more powerful but much less performant. If you're just trying to include a block of code/text that never changes from page to page, you would be better off using SSI/php includes.

Then that is def. where my problem lies... I've got too much traffic to be playing that game.

Now the problem is I can't get into mt.cgi script - RackSpace says Apache is overloaded. We have restarted Apache and shut down MYSql - I still can't get in...

How do I move forward from here? Must I edit my templates through the database? How do I rebuild the site once I edit these templates?

damn me for trying to get too fancy

Traffic has nothing to do with it unless you're using dynamic publishing. Is this the case? If so, then yes, absolutely, you either need to publish some of your higher traffic pages statically or streamline your templates/publishing.



Did you start MySQL back up? That would be one definite reason why you can't get in.

In any case this would be a good point to start a new topic, as this has gone far astray of the original posters question.

I learned under 3.3 that my site wasn't a good candidate for dynamic publishing.



MySQL has been restarted - I still get an internal server error. My tech support says that Apache is being overloaded by what appears to be legit SQL queries. The hope was that we would shut down Apache and MySQl and then restart and get access to mt.cgi. But as soon as we restarted - queries jumped up and Apache is seeing a heavy load. Mind you the whole time the site's appear to be working OK.

agree - I'll start another

Confirmed, process being killed by host. I was given the following link by Globat support, which contains a bunch of information about the servers.
http://gilligan.globat.com/phpinfo.php

memory_limit is listed as 16 megabytes. Does this seem to be unreasonably small to run a system like Movable Type? Does anything else inside of here look suspect?

16M seems reasonably ... for small sites. If you have a large/complex/busy CMS/Blog/website and you use caching, you'll easily max it out.
So when using MT4 with 1 or more caching modules/mechanismes enabled and you have a lot of - different - content being requested you'll be seeing the error soon.