Hot answers tagged

23

Not worth the trouble. WordPress doesn't eat a lot of memory just-because. It eats a lot of memory because it runs a lot of functionality under the hood. It is far more easier and efficient to cache results (page generated) with static cache plugin and serve that. That way most visitor will not even hit WP itself.


22

And this is why I think WordPress is in serious need of a rewrite. You can no longer blame its memory consumption on sheer complexity of what it does. It simply does things wrong. What a naive conclusion. Read Things You Should Never Do, Part I. Thanks for the memory usage plots, though. Much later edit: Autommatic has released a library ...


16

How can we make Wordpress initialize its environment in memory only once, and then reuse it many times for each hit? It's called opcode-caching. http://en.wikipedia.org/wiki/PHP_accelerator


16

Starting with WordPress 3.2, PHP 5.2 will be the minimum requirement. I think with that under our belts, bits of the core can start to be restructured, and use classes with auto-loading. This would let us avoid loading some chunks of code unless they were actually needed. For example, if there were no embeds or galleries in a page view, we might be able to ...


11

Theoretically, editing your config.php and add this line before wp-settings.php inclusion. define('WP_MEMORY_LIMIT', '256M'); should raise your memory limit for WordPress to 256MB or whatever value you set. And this will work sitewide. However, as sorich87 pointed out, there are few functions that will alter this setting with hard coded 256 MB limit. To ...


10

Excellent responses on WP Hackers: http://lists.automattic.com/pipermail/wp-hackers/2012-June/043213.html What you're doing with that query, is loading EVERY matching post into memory, including the full post contents. As you can imagine, this is probably quite a lot of items. You can pass 'fields' => 'ids' into WP_Query to simply return a list ...


8

You can try a trick with querying post data directly and setting filter field of post objects to sample before passing it to get_permalink() to reduce memory usage. See get_permalink memory usage issue for detailed reasoning behind it.


7

Use the fields argument to grab just the ID - will save you a ton of memory ;) $product_ids = get_posts( array( 'posts_per_page' => -1, 'post_type' => array( 'product', 'product_variation' ), 'fields' => 'ids', ) );


7

@Tal, Generally speaking you should only be using one caching plugin. WP Super Cache, W3 Total Cache, Hyper Cache and DB Cache Reloaded all drop files directly in your wp-content directory and they would conflict with each other and cause errors if you were using more than one. I would recommend using W3 Total Cache because it gives you the option of ...


5

It's not likely an unused site is using mach resources except for harddrive space. There may be something left in memory but on a typical server thats doubtfull. google bots trigger the site exactly the same as a regular user except it doesnt load unnessasary files like javascript, css or images (except maybe for image search). wp-cron I believe can be ...


5

you probably won't manage to reduce ram usage that much. But if you're using mod_php, you may want to switch to mod_fcgid instead. while mod_php is slightly slower, it loads php even when it doesn't need to, such as serving images, static files, or even caching. If you have lot of requests, this is lot of ram. using fcgid will reduce this a lot. also, ...


4

You're looking at the problem the wrong way. The error you're seeing isn't an error coming from WordPress, it's a PHP error. Somehow, somewhere, something is limiting the memory limit to 96M, and it ain't WordPress that's doing it. Here's the thing: WordPress can't actually limit the memory on most servers. I know that it attempts to increase the limit ...


4

The posts are still held in memory under WordPress' cache mechanism (even though you replace $posts on every loop) - delete each one after operating on it: # do some echoing with the $post # wipe post from memory wp_cache_delete( $post->ID, 'posts' ); wp_cache_delete( $post->ID, 'post_meta' ); Pro tip: save some needless queries with no_found_rows ...


4

You might try adding this to your array: 'nopaging' => true, 'no_found_rows' => true, 'update_post_meta_cache' => false, 'update_post_term_cache' => false It seems pretty self-explanatory, but essentially you're not querying all post variables and just the stuff you need.


4

It's hard to answer this given that each site is most likely different and each server is also configured differently. If these sites are individual WordPress installs then 1GB /30 sites is normal, an absolute bare minimum per site would be 32MB for apc.shm_size, this equals 960MB with no overhead. 32MB is in my opinion way to low, it's impossible to tell ...


4

Yes, a lot of information gets loaded. I just put print_r in my header.php on 3.5.1 and got nowhere near 70000 lines though. I got about 2110 and that includes some post body content. Also, print_r or var_dump are formatted representations, remember. Things are not actually stored in memory that way. I doubt you could remove much this stuff without breaking ...


4

Your installation might be … less than optimal. Using my Mini Theme, no plugins and the following code on the front page right after the opening body tag … print count( $GLOBALS ) . ' $GLOBALS<br>'; print @count( get_defined_vars(), 1 ) . ' variables<br>'; print count( get_defined_constants( TRUE )['user'] ) . ' constants'; … I get: 158 ...


4

The apache process memory amount you talk about (80 to 120 MB per process) can be split into two reasons. Apache Wordpress Apache You can optimize apache by only loading the number of modules you need and other optimization tweaks that will reduce the memory. If you have not optimized that yet, give it some tweaks. Wordpress Wordpress just consumes a ...


4

Ha. I'm working on a web app now that I fully intend to overload with data and usage beyond what my shared hosting account can handle, so I decided - while it would have been super easy to build in WP - to try working from BackPress as a framework and build out only what I needed for my specific use-cases. So I've been able to reduce my core environment ...


4

The amount of memory that is allocated to PHP is insufficient. Add this to your wp-config.php file: define('WP_MEMORY_LIMIT', '64M'); If that doesn't work, the chances are your host has this locked down and you can't change it, in which case you either need to simplify your site, or move hosts.


4

The problem comes from the fact that, in order to display pages and their hierarchy, WP has to load all of them and then build the tree in memory. So, you are saved if you can convert most of those pages into one or several non-hierarchical custom post types. The permalink structure can be emulated.


4

The number of sites is unrelated to the amount of memory required. The amount of required memory is (if you are using Apache) the amount of memory required to serve the most memory intensive page * the number of requests you want to serve simultaneously Both numbers vary based on the way you set your server and the themes and plugins you use.


4

The actual RAM you need depends on many factors: plugins theme installed extensions (server and PHP) the current operation (editing images needs the most) translation, some translation files are really heavy In a multisite, some resources are shared, the server setup for example is not duplicated each time you create a new site. You can save some ...


4

There are approx. 10,000 items returned by the query. That's your problem right there. No matter what you do inside the loop, WordPress is still loading 10,000 post objects into memory. Batch it up and sprinkle a little magic in your query arguments: $args = array( 'fields' => 'ids', // MAGIC! Just get an array of id's, no objects ...


3

wp-config.php sets the memory limit for the specific WordPress site which has that file. php.ini will effect your whole server. The php.ini is the parent setting, and so you can set WP to whatever you want within php.ini's range. It's also importan to note there is a WP_MAX_MEMORY_LIMIT where you can define a max amount of memory WP should use, especially ...


3

Using FTP, try increasing the memory for PHP and Wordpress by editing the memory_limit line in your php.ini (if you have access to it) to 64M or 128M, which should be fine for non-multisite installs. memory_limit = 64M; If you can't get to the php.ini file, add this line at the top of your .htaccess file: php_value memory_limit 64M If that doesn't work ...


3

a few basic suggestions : w3 total cache plugin for caching.. get memcache installed and enabled, also enable from w3 total cache settings (opcode cache is a good option too but it doesn't go well with w3 total cache plugin) minimize queries to direct links in theme files.. Disable all extra unused plugins and remove. optimize Database. i am running a ...


3

Yes, WordPress loads up everything first and then does what we ask it to do. I can recall somewhere that we can create a virtual pool in RAM where we can put in files. I had the idea of putting the whole WordPress in memory (<10MB) & then we can save a lot of I/O which alone should give a speed boost. But I never got the chance to try it and moreover ...


3

The WordPress Memory is something not easy to deal with. If the standard way is not helping (don't rely on the WP_MEMORY_LIMIT constant, it's conceptually broken, use ini_set in wp-config.php instead), then you can only throw hardware on it or hack the core. Please check if you're using a recent PHP version on your system. If that's something with PHP 4 ...


3

No and even if you could, if the plugin ran out of available memory then the entire page generation would stop due to the fatal error. You're better off fixing the plugin itself to not use as much memory or to just further increase the total memory allocated to WordPress/PHP.



Only top voted, non community-wiki answers of a minimum length are eligible