Hot answers tagged memory
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.
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.
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 ...
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
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 ...
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.
@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 ...
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 ...
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 ...
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 ...
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 ...
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.
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.
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 ...
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, ...
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 ...
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.
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 ...
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.
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 ...
There is a very nice plugin called P3 (Plugin Performance Profiler). Give it a try! This plugin creates a profile of your WordPress site's plugins' performance by measuring their impact on your site's load time. Often times, WordPress sites load slowly because of poorly configured plugins or because there are so many of them. By using the P3 ...
Stumbled upon this while researching the memory issue pointed out here. In this case, you can use get_the_id instead of using buffering to capture the id, and you could narrow the queried fields to only include ids.
Many Related Posts-type Plugins are notoriously resource-hogging, due to ineffecient (or frequent) SQL querying. Of your installed Plugins, I would first investigate your "Related Post" Plugin.
In your example, you are getting all the fields in the get_users call, but you are only really using the ID and display_name fields. So you can save some memory by forcing get_users to only get the fields you need. $users = get_users(array( 'role'=>'s2member_level3', 'fields'=>array('ID', 'display_name'), )); That will help reduce your memory ...
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 ...
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 ...
Unless some user or robot is accessing your server, the files will sit there inert, consuming nothing besides disk space. The web server needs some trigger to access those files, so even WordPress cron jobs won't run unless somebody visits your blog. That's why there exist instructions on triggering wp-cron manually, ie. through a system cron job.
$query->the_post; should be: $query->the_post(); The first is trying to fetch a property named the_post rather than invoking the function so the post never advances, and your loop is infinite.
It might also be a good idea to implement caching. Depending on how often those archives and category pages will be updated, you can save the output in a cache, and only allow it to be updated after say, 15 minutes. Although you write the high memory consumption was due to a specific file, it can be recommended to cache the more query-heavy pages for ...
Only top voted, non community-wiki answers of a minimum length are eligible