CMS Made Simple Forums

Hello all,

I installed cmsms on my local machine (Atlon64, Suse Linux 9.1 professional, 1 Gbytesof memory running apache, php etc.) but at a certain moment I get the following error message:

Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 7680 bytes) in /home/roel/www/html/cmsmadesimple-0.11.2/lib/adodb/adodb-datadict.inc.php on line 387

Any idea how to solve this?

Thanks,

  Ryde

What modules do you have installed, or is it just a standard CMSMS install?

PHP by default is set to use 8M, which is kind of low in reality  however, CMSMS 0.11.2 in it's default form uses about 6-6.5 without any additional modules installed.

If it really is just a standard install and it's using that much, you might want to bump up the memory limit in php.ini.

That worked out!

Thanks!

By default it was set to 8 MB, I moved it up to 32 MB and I got a smooth ride....

Since this was my first installation of cmsmadesimple (and definately not the last!), it was a complete default install.

I also installed it at the site of my service provider and did not experience any problems!

Thaks again!

wishy wrote: If it really is just a standard install and it's using that much, you might want to bump up the memory limit in php.ini.

This can NOT be the right way in future - only a little part of CMSms users have access to php.ini.

CMSms must save more memory, CMSms must run on a standard php installation WITHOUT problems.

I agree it should.

However, modules and plugins and other things are going to take space.  Current svn is using 4-5.5 megs of ram with default modules and plugins installed.  If you install a lot of stuff, it's going to go up.  There is no choice for that.

We will get our usage down more and more to compensate for this, but it just takes time.

Patricia wrote: must => should

I agree with cyberman, that unfortunately, some host providers will keep that low limit...

... very much providers in germany .

wishy wrote: However, modules and plugins and other things are going to take space.  Current svn is using 4-5.5 megs of ram with default modules and plugins installed.  If you install a lot of stuff, it's going to go up.  There is no choice for that.

I'm using bigger CMS than CMSms with the 8 MBs default and it works  ...

Well, keep in mind that I don't claim to be a php expert.  I'm learning as we go here, as much as everyone else.

I think 4-5.5 megs is more than enough to claim as "working" to me.

After 0.12 comes out, I'm going to start looking at the adodb lite thing and try and make it work without breaking anything in the process.  It's going to take some time, unfortunately.  But, in the meantime, I think I made some great strides in reducing the memory usage this time around and hopefully it continues to go in the right direction...

Well, last night I took a stab at adodb lite and right now it's in svn.  There are still some issues, but I worked through most of them last night.

Basically, using adodb lite saves about 400-500k per page load.  Not too bad.  That puts us in the 3.75 range on a cached page, uncached it's at like 4.3-4.5.

It required some tweaking of copying some missing functions regarding sequences over from adodb.  I did it for mysql, but it still needs to be done for postgres and mysqli.

I'm not totally sure if I'm going to keep it there as default, or find some way to run either.  Have to play for another evening to decide that, I suppose.

I've found a workaround for people who's provider has limit PHP to 8mb.

Just add the following line to config.php.

ini_set('memory_limit','32M');

It worked for me.

Nice, had the same problem and ur solution worked a treat

ID2020 wrote: Just add the following line to config.php.

ini_set('memory_limit','32M');

Hmm, I'm wondering that php.ini can overwrite with this simple line. It's a security risk I think ...

Hmmm, this could be a config thing, and possibly something in site preferences  so though we allow the admin to set the memory limit, it is nice and clear and obvious that we are doing so.

Setting a limit for application is not the problem  , the problem is a application can overwrite server preferences. The application can also be a worm or other ugly things ...

... I think too it must be a lightheaded server configuration.