Announcement

Collapse
No announcement yet.

Fatal error: Allowed memory size of 8388608 bytes exhausted

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Originally posted by buro9 View Post
    It is 8Mb, I just upgraded my PHP and got it by it. Took down half of my forum.

    Changed to 16Mb, but I can't recall what I had it at before.
    Seems to be a common theme. I had never seen this error before today with settings at 8mb. After upgrading to php 5.2 I started to get memory exhausted errors.

    Is PHP 5 that much more inefficient?

    Comment


    • PHP5's base memory should be 16mb.

      Comment


      • I got lots of these errors in various scripts,
        after upgrading from php 4.4.4 to 5.2.4
        right now i'm downgraded the things back, and everything is happy with 8Mb in php.ini

        Comment


        • PHP 5.2 and beyonds mininum memory is 16mb, and honestly 16mb is not that much memory.

          Comment


          • Originally posted by Zachery View Post
            PHP 5.2 and beyonds mininum memory is 16mb, and honestly 16mb is not that much memory.
            You're setting the maximum amount of memory that each php process (in a typical configuration this is each apache child) can use. I've been through this before in this thread. Let's do some math assuming 50 concurrent requests:

            50 * 16MB = 838,860,800 bytes

            I was having a major problem with this until somewhat recently. I'm betting it was my switch to using the fulltext mysql index for search that fixed it (all of my user reports of the problem were happening during searches). I've been running a memory_limit of 16MB for a while now and no reported problems from my users.

            Comment


            • Originally posted by bigbadbob0 View Post
              You're setting the maximum amount of memory that each php process (in a typical configuration this is each apache child) can use. I've been through this before in this thread. Let's do some math assuming 50 concurrent requests:

              50 * 16MB = 838,860,800 bytes

              I was having a major problem with this until somewhat recently. I'm betting it was my switch to using the fulltext mysql index for search that fixed it (all of my user reports of the problem were happening during searches). I've been running a memory_limit of 16MB for a while now and no reported problems from my users.
              Yes, for each php process that should exsist for less than a few seconds.

              Comment


              • Your comments scare the crap out of me. Do you understand what happens when an OS runs out of physical memory to use? Do you know what the OS needs to do when there are ~100MB free on a system and this sudden DOS attack comes along and exploits a bug in vBulletin to take ~32MB per process * 100?

                The first few requests will get their memory. Quickly we exhaust the 100MB and the OS starts paging. It starts taking processes that aren't running "right now" and pushes their image from memory onto the nice, slow disk. If you're lucky this won't be the apache processes being pushed to disk. If the system is really being pushed the apache processes -will- be pushed to disk.

                Once this happens the OS needs to go to disk to pull in the process image of a process every single time it wants to give it its quantum of CPU time. So you spend 1/2 sec going to disk (The disk will be operating incredibly slowly as it gets hammered with seek requests all over the pagefile) to pull in a process to let it run for ~10 microseconds. Overtime requests are going to take longer and longer. The listen queue for the apache listen socket will back up to the point that it's full at which point the OS stops accepting new connections. The box is, for all intents and purposes, offline.

                This is a very -very- serious problem because it becomes possible to completely kill a beefy server with just a single DSL connection. And I cannot stress enough how badly it scares me that you, a developer?, simply don't understand this.

                Comment


                • Actually, as much as I hate to violate the "Customer is always right rule", I'm afriad you're a little bit off.

                  While PHP 4 defaults it to 8M, PHP 5's default value for memory_limit in php.ini is 128M. This can be confirmed in their documentation manual:
                  http://www.php.net/manual/en/ini.php
                  http://www.php.net/manual/en/ini.core.php

                  Now, let's discuss the DDoS issue you mentioned.

                  Most of the time, PHP is ran in fcgi mode because of most of the added benefits from fast cgi. One of the biggest benefit is the fact that they run presistent, and you can define the amount of child processes. On my server, I set that to 6, because I have < 1GB ram available. In the case of 30 people requesting the a php page concurrently, and should each of them require 128MB, what will happen is this (in a nut shell, a whole lot more is happening in the background):
                  All 30 will ping Apache at seemingly the same time, but Apache will know which one came in first, even down to the milliseconds. They will be sorted in a queue like fashion, and the first 6 will get a session w/ one of the php fcgi child process.
                  PHP while running presistent will check if there's optimizers or alike application available, and fetch optimized information from it as needed. In vBulletin's case, we also support APC for added opcode caching.
                  The 6 requests gets processed very quickly -- if you enable debug mode, you will find that for most requests, page are generated in < 1 second (hiting refresh here a few time, my average is arond 0.15 seconds) -- and fast cgi returns result back to apache for returning info to client. PHP's job is done, and next 6 sessions gets to connect and repeat the process.
                  For 30 people, on my 6 child process configuration, I'd see a spike of 6*128=768MB RAM spike for at most of 5 * <1 second; if we use the 0.15 seconds value from above, it works out to not even 1 second.

                  If you believe such stress -- which is significantly worser than the 32mb child process you mentioned -- will cause your server to have problem, then I think you should consider additional servers to house your busy forum... If you feel that your server is suited for more traffic than you are currently thinking, then please feel free to file a server optimization request in the forum below named server configuration: http://www.vbulletin.com/forum/forumdisplay.php?f=14

                  Edit:
                  Oh, by the way, Zach isn't a devvie. Most of us with chat bubble avatars are customer service
                  Best Regards,
                  Andy Huang

                  Comment


                  • You have a maximum concurrency level of 6, my server is at 150 and under nominal conditions will average 30 requests in flight at any one moment; we're talking about different things here.

                    The "down to the milliseconds" thing you talk about is called the listen queue of a socket, apache doesn't do this, the operating system does. The listen queue, even in your example, is not of infinite length. On my machine its set to 128 (netstat -aL). Once 128 connection requests get behind those initial 6 on your server connection requests will be denied.

                    This memory problem I'm talking about is fairly irrelevant since you say your server has a max concurrency level of 6. I cannot set my server to 6.

                    I guess my point is that you and I are operating at different levels of understanding how the operating system, apache and php interact. Excessive memory usage by a PHP process is a threat.

                    Comment


                    • Not Impressed

                      Well, I'm shocked to see that 12 pages of posts here and still the problem persists.

                      I just bought VB 3.7.0 the other day, and finally go the CompleteVB forum template installed. Then started to get some forums and sub forums up. All went well. And has the VBSEO Mod installed.

                      Brand new vanilla install. All seems ok, UNTIL... I make my first post...

                      Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 77824 bytes) in /home/myfolder/public_html/forum/includes/class_dm_user.php on line 2261

                      I for one am not too happy with this and I would like to see a PERMANENT fix to this problem rather than asking people to up their memory temporally.

                      It's quite clear it has nothing to do with the amount of posts like some support guys have been saying here in this thread then ignoring this thread without a real solution.

                      How can 3.7.0 be having these problems, I thought you guys did all the testing. PHPBB3 works just fine no matter what version one uses and problems if any found are fixed immediately and not all this arguing with CUSTOMERS who fork out $160+ for this software.

                      Sorry to rant, but I'm a bit ticked off.

                      I don't want work arounds, I want a permanent fix ASAP please.

                      Apache version 2.2.8 (Unix)
                      PHP version 5.2.5
                      MySQL version 4.1.22-standard


                      Cheers

                      Loz
                      SEO Revolution Blog - SEO Forum - SEO website Builder Pro - Video Guide To Profits

                      Comment


                      • I had a same problem as you and it had nothing to do with Vbulletin.

                        Let me explain:

                        I was suspecting the error you described coud be caused by VBSEO, but I didn't want to uninstall it simply because it was a hassle and most importantly, also because most of my traffic came from search engines to indexed vbseo urls.

                        Anyhow, I decided to delete VBSEO installation anyways, that is how frustrated I was with these errors and crashing.
                        And it was a good decision,... those people who were directed from search engines to then missing vbseo pages, I've re-directed using htaccess to main page and again... the best thing I could do.

                        Forum is now much faster, never had a same error again.

                        In all honesty, if I had to recap: VBSEO wasn't doing anything for my forum. Now with it being uninstalled, my forum was quickly reindexed by search engines and I am getting even more hits than ever before, and without this bloating VBSEO behemoth sitting on my forum installation, causing problems.

                        While I don't want to hurt VBSEO reputation and some of its great features, in two years it didn't do anything for my forum other than creating major problems.

                        GET RID OF IT!

                        Comment


                        • Your PHP does not have enough memory allocated to it to complete this operation. Ask your host to increase the 'memory_limit' variable in php.ini to at least 32M.

                          To temporarily up your limits edit your includes/config.php file and add these lines right under the <?php line:

                          ini_set('memory_limit', 32 * 1024 * 1024);

                          Anyone having this issue needs to start their own support thread.
                          Steve Machol, former vBulletin Customer Support Manager (and NOT retired!)
                          Change CKEditor Colors to Match Style (for 4.1.4 and above)

                          Steve Machol Photography


                          Mankind is the only creature smart enough to know its own history, and dumb enough to ignore it.


                          Comment

                          widgetinstance 262 (Related Topics) skipped due to lack of content & hide_module_if_empty option.
                          Working...
                          X