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 Viruseater
    I've been getting the same error, and it's NOT load, or server.

    I've got one site, and one forum, on a dual xeon 3.0 Ghz server with 2Gb of RAM and dual 100MB uplinks running Redhat enterprise 3.0

    This is a production server and is being geared up for my customer.

    I'm getting a LOT of complaints about this.

    Same here, one forum in an entire server. I started this thread over a year go.

    Still getting the same error.
    Sebastián J. Bianchi

    Comment


    • So was the fix to this to increase both the php.ini memory and the my.cnf memory. I just moved servers from a dedicated RH3.0 ES server to a RH9 with Plesk and i'm getting this error.

      During reindex of search index in the maintenance section of the admin

      Processing: 916537 ... Querying first post of thread... Done
      Processing: 916538 ... Querying first post of thread... Done
      Processing: 916540 ...
      Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 1 bytes) in /home/httpd/vhosts/offshoreonly.com/httpdocs/forums/includes/functions.php on line 1507
      Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 15 bytes) in Unknown on line 0

      -------------------------------------------
      When you search for "Boat Loan" in the forums
      Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 4 bytes) in /home/httpd/vhosts/offshoreonly.com/httpdocs/forums/search.php on line 834
      Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 45 bytes) in /home/httpd/vhosts/offshoreonly.com/httpdocs/forums/includes/functions.php on line 479
      -------------------------------------------
      After increasing the memory limit in php.ini to 16MB
      Fatal error: Allowed memory size of 16777216 bytes exhausted (tried to allocate 35 bytes) in /home/httpd/vhosts/offshoreonly.com/httpdocs/forums/search.php on line 971
      Fatal error: Allowed memory size of 16777216 bytes exhausted (tried to allocate 0 bytes) in Unknown on line 0

      RH9
      3.0Ghz PIV
      1GB RAM
      Server load is 0.35
      40 users online
      happens consistently when searching for the phrase "boat loan" for the forum home
      http://www.offshoreonly.com/forums

      Comment


      • updated php.ini from 8MB to 16MB and added max packet size of 16MB to my.cnf, it wasn't set before. restarted apache and mysql.

        Still got the same errors

        Increased both php.ini and my.cnf to 32MB, error went away. restarted apache and mysql. I'm reindexing the search index now, we'll see if it makes it through this time.

        Comment


        • I started this thread I don't know how long ago, and I still never got an answer or any support on the issue
          Sebastián J. Bianchi

          Comment


          • It has been explained in this thread quite a few times, you need to up php's memory limit

            Comment


            • And Scott did tell you how to fix this in post #4 in this thread. If 16M isn't working, then increase the allowed mem limit to 32M.
              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


              • The amount of memory you guys are asking for a script to consume is absurd !!! Sure, might be fine for ONE search (where I'm having problems, even with 48MB per page limit) -- what happens when you have 700+ users online and 20 of them do a search? This is indeed a problem with the way VB is written -- if the query needs to be revised to segment the dataset, then that's what needs to be done. You can't ask someone with a large forum to allocate as much necessary as a flawed script wants.. Seriously, what happens with a site with 3mil+ posts? I'm only at just over 2 mil, which IMHO isn't THAT big.

                Comment


                • Alot of sites that are large have either disabled the standard vB search, oir have moved to use mysql's FullText searching.

                  Try raising mysqls max_packet_size


                  http://www.vbulletin.com/forum/showp...2&postcount=31

                  Also read this

                  http://www.vbulletin.com/forum/showp...4&postcount=51

                  Its not a bad coded script in anymeans, it needs to scan a huge table which will consume lots of memory, no matter how well coded it is.

                  Comment


                  • Disabling search entirely isn't an option for me -- its actually heavily used on my forum, and the source of quite a bit of performance headaches. Due to the nature of the site, search is not only widely used, its heavily encouraged.

                    The SQL side is fat and happy -- load on the SQL box stays well below 1.00 nearly 100% of the time.

                    The web side is experiencing some growing pains. I can reliably support ~600 to 700 concurrent users, up until the point I get a few hits to the search functionality. Initially I tried increasing the packet size, with no joy. I then switched to full text indexing (thanks for the links) and can now easily fit quite complex searches along with very simple common-word searches into the 8M max script size. The web server thanks you, and I thank you When the site gets busy tomorrow, we'll see where we are. I'm getting the feeling I may not be able to support 700+ users with a single 2.4GHz P4 web server box. Without search maybe, with search its tough.

                    FWIW my current hardware config (just the basics):
                    DB - 1 x dual XEON 2.4 w/ 2GB
                    Web - 1 x single P2.4 w/ 1GB
                    2.03 million posts, 238k threads, 31k members, avg. 600 online users during "business hours"

                    Another interesting thing to note -- I had mysql pconnect turned on, and I was hovering right around 180 concurrent connections with ~625 users online. When a couple searches were entered, it'd back up and climb over 250+ connections, the load average on the web server would shoot up over 100 and the site became more or less unresponsive. The database server kept a very low load avg. the whole time.

                    Comment


                    • Originally posted by Brains
                      The amount of memory you guys are asking for a script to consume is absurd !!!
                      Originally posted by Brains
                      The web side is experiencing some growing pains. I can reliably support ~600 to 700 concurrent users, up until the point I get a few hits to the search functionality.

                      FWIW my current hardware config (just the basics):
                      DB - 1 x dual XEON 2.4 w/ 2GB
                      Web - 1 x single P2.4 w/ 1GB
                      2.03 million posts, 238k threads, 31k members, avg. 600 online users during "business hours"
                      Forgive my ignorance but why is allocating 16 or 32 MB 'absurd' on a server with 2 GB mem and running 600-700 concurrent users?
                      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


                      • lol

                        Comment


                        • 32MB simply wasn't enough.. I didn't stop getting errors on an average search until 64MB !! Lets say the MOST you'll ever see is 700 users, and the MOST you'll ever see is 5% of those doing a search. Lets say since the search was generating page errors at 48MB, but not at 64MB, that the avg. page was consuming 56MB (right in the middle). 700 * .05 = 35 users x 56MB = 1960MB I may not be the smartest guy on the block, but that doesn't leave much for the system itself, other daemons running (ala the kernel, sendmail, apache itself, etc.) Not to mention those folks running on a single server where MySQL might like a little memory. Sure, it'll allocate the memory some way or another, but we all know the effects of paging

                          Comment


                          • Okay, but I still don't undersrtand or agree with the 'absurd' part. After all this is a server with 600+ people online and with 2Gb mem. Has your server suffered any ill-effects after upping this to 64M?
                            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


                            • Originally posted by Steve Machol
                              Okay, but I still don't undersrtand or agree with the 'absurd' part. After all this is a server with 600+ people online and with 2Gb mem. Has your server suffered any ill-effects after upping this to 64M?
                              It helped for a little while, but unfortunately it spiralled down horribly within an hour.. It was doing fine with a small handful of searches, but once I got a few big ones it started chewing up memory faster than it could release it -- and then came the paging... I literally watched the server load (via top) go from ~2.5 and free memory jump from 220MB w/0MB swap used, to a server load of over 100 and free memory drop to 0 with 400MB swap used.. At that point I killed and restarted Apache. The whole time, the load on the SQL server never went over 0.40

                              I'm getting the impression you want to point fingers at either an improper configuration, or lack of server hardware, or some other thing -- but the fact remains that this amount of memory used per process is going to really chew up resources faster than you can give them back.. With a small site with relatively few posts, I suppose it really wouldn't be a big deal because the returned dataset would be smaller. Kinda common sense also that your users' search utilization wouldn't be as high either, no? With larger sites, this doesn't work well -- search is used to pull up historical data that isn't fresh in folks' minds. I've even considered a separate indexing of the site content, ala a Google search or something similar. The brunt of it is I MUST have search available to my users, and the standard VB search just couldn't handle the load with the setup I currently run. You may have a different answer and that's fine, but I don't see throwing server hardware at the problem as being the "right" decision.

                              FWIW the full text search appears to be working significantly better. Memory utilization is staying very solid, averaging ~100MB free. Searches also return faster, which helps with the scripts giving back memory faster obviously.

                              Comment


                              • I have no intention of 'pointing fingers'. As I said I may not fully understand the problem which is why I asked you if your server suffered any ill-effects.

                                I'll let the Developers answer further questions regarding memory usage.
                                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