I have a website running on Wordpress. I am running the website on Amazon EC2 web servers, with t2.micro instance. (1CPU and 1GB RAM).
I have installed a few plugins and one of them is leaking memory and overloading the main memory of the system and also the swap space of the system. I am unable to determine which plugin is leaking the memory.
Is there a way to determine what wordpress plugin is leaking memory? or if anyone is familiar with plugins listed below that have cause the same problem for you?
ubuntu#sdf:/var/www/html/wordpress/wp-content/plugins$ ls
360-product-rotation cm-map-locations
hello.php live-composer-page-builder
revslider store-locator-le
woocommerce_events wp-mail-smtp
wysija-newsletters akismet
contact-form-7 html5-responsive-faq
mailpoet-woocommerce-add-on shortcodes-ultimate
the-events-calendar woocommerce-menu-bar-cart
wpmandrill yith-woocommerce-zoom-magnifier
breadcrumb-navxt ds-live-composer index.php
market-360-viewer showcase-visual-composer-addon
Ultimate_VC_Addons wordpress-seo wp-post-formats-develop
breadcrumbs flexi-pages-widget js_composer _notes
smart-product-viewer woocommerce wpglobus wp-super-cache
You can use this plugin, it will show you your answer: p3 profiler
Related
I am running a web-application on 2 servers, but get strange performance problem.
server 1:
Core i5-4770 3.40GHz with 8gig DDR3 running ISPConfig server with PHP/Mysql.
server 2:
Core i7-5930K 3.50GHz with 64gig DDR4 running directadmin with PHP/Mysql
the new server (2) is more powerful, but it get slower page results than the old server.
any suggestions how to find the problem?
I think you are not getting this issues due to Directadmin server. You will have to optimize your Apache and MySQL for the better performance. I will suggest you please enable some php cache modules on your server.
What version of PHP do you use and how it's connected to apache:
PHP:FPM
MOD-PHP
etc...
You probably whould like to use PHP:FPM from the security and performance reasons.
One more suggestion. Default my.cnf config file has no additional configuration on DA. So MySQL performance could be really bad because of that. Please add you my.cnf file here and share info how much RAM do you have. With that I could try to pump your config.
I just had my server people install APC to try to decrease the amount of memory that my server uses per person.
I went into my local.xml and entered in the following within the Global mark.
<cache>
<backend>apc</backend>
<slow_backend>database</slow_backend>
<prefix>MYSTORE_</prefix>
</cache>
</global>
I then reset apache.
Then in my php.ini file I have the following:
;APC SETTINGS
apc.enabled=1
apc.shm_size=512M
apc.num_files_hint=10000
apc.user_entries_hint=10000
apc.max_file_size=10M
apc.stat=0
apc.optimization=0
apc.shm_segments=1
apc.enable_cli=1
apc.cache_by_default=1
apc.include_once_override=1
I was able to increase the size and actually enter in these settings buy updating the master php.ini on my server (rather than the local one).
However, when I go into system cached entires it only shows hidden/apc.php and on the dashboard it only shows the 1 file.
Can you guys please help me figure this out? I'm running magento 1.9.1, PHP 5.4.35, APC 3.1.13, Apache 2.2.29.
Thanks!
You're missing
extension=apc.so
Also APC is at the server/php level. The cache block in the XML is to configure higher level caching systems such as Redis.
I am getting errors on my website and my website inodes count is overload. The hosting inodes limit is 200,000 but my website inodes count is 909,496 and I can't even open phpMyAdmin. The hosting support asked me to remove unused files. How can I decrease the inodes count and which files are unused in Magento based website?
Usually an indicator that you need a more capable hosting provider.
The major places that Magento creates files during operation are in the var/ folder and your product image cache.
If you've never checked before, the following areas can accumulate a phenomenal amount of detritus. Using an ftp client, check the following areas in your var/ folder:
Check that you don't have a bazillion sessions files in var/session, remove anything older than current date
Check that there aren't an excessive amount of files in var/report, you might want to find out why Magento is generating them and fix the issue. Delete them all.
Logging will generate over time several huge files in var/log, delete them and then look at the new ones to find out what errors are being generated.
Imports and other stuff can cause temporary files to accumulate in var/tmp, delete them. Also check in var/import for old imports that can be deleted
Stored database backups are kept in var/backup, using the admin backend System > Tools > Backups:
Download the latest database backups to a local workstation and delete all backups.
Magento uses a lot of caching to store information, the biggest will be the Image Cache if you have a large catalog, and it will contain cached images from the beginning of time, and lots of useless ones if you've deleted product over time. Using the Admin backend, go into System > Cache Management:
Clear the Magento Cache.
Flush Catalog Images Cache.
Magento does not delete product images when you delete product. In fact Magento would be a prime candidate for appearing on one of those Hoarder programs that were prevalent on TV there for a while.
After you get the site working, consider installing ImageClean.
Hopefully this will have reduced your inode count enough to carry out the following operations. Before proceeding, do a couple database backups and store off server!!!
Next step is to ask your hosting provider if they include your database in that inode table count. If they do, you are kind of stuck as Magento uses innodb and likely, they've cheaply not set up MySQL to use files-per-table so you can resize the innodb file size by optimizing each table. Ask them if they use files-per-table when they set up MySQL, if they don't know what it is, develop that sinking feeling in the pit of your stomach.
Some tables that get excessively huge, especially if you've haven't properly set set up the Magento master cron job trigger in your cPanel and checked to make sure log table cleaning is enabled in System > Configuration > Advanced > System > Log Cleaning. These tables are as follows:
'dataflow_batch_export',
'dataflow_batch_import',
'log_customer',
'log_quote',
'log_summary',
'log_summary_type',
'log_url',
'log_url_info',
'log_visitor',
'log_visitor_info',
'log_visitor_online',
'index_event',
'report_event',
'report_viewed_product_index',
'report_compared_product_index',
'catalog_compare_item',
'catalogindex_aggregation',
'catalogindex_aggregation_tag',
'catalogindex_aggregation_to_tag'
Magento has a built-in script to clean the logs. If running this crashes with a memory error because you've never set the cron job up and there's too much bloat to clean out, Crucial Web Host has a script that can be run to manually delete all log file contents. including the dataflow tables which won't be cleaned out by the Magento log cleaning process. If you use dataflow import/export a lot, Nexcess has a script that can check on the dataflow tables size and clear them as well.
After cleaning the database, you will need to use phpMyAdmin to optimize each table in your Magento database. If the hosting provider hasn't set up files-per-table in MySQL, it will do squat for reducing your inode count.
After all that, don't bother messing with deleting application files or anything else Magento uses. It doesn't really accumulate that much aside from the var/ folders and the Image cache and you likely will end up with a dead website.
At this point, you're at the mercy of a shared server hosting plan that has decided to be fair to everyone by limiting what can be done in each account and doesn't allow enough resources to run Magento. Start looking for a hosting provider that supports Magento, often they don't bother limiting your inode count (a cheap trick to allow too many people to share a hard drive) as they offer plenty of disk space for you to run your e-commerce website.
I have been developing a web page named: directorioelectronico.com and I have specially issues now, I will be very grateful that someone can be help me.
The web page is loading very slow in the first loading (5,000ms - 20,000ms) (latest are speeded normally) I tried to install APC module but my host is shared and the administrator can not install it, so I resize realpath_cache_size to 2M and the performance is now better (4,000 - 16,000 ms) somebody knows how I can perform it much more?
In advance, Thank you very much for you help.
My issue was that my share host haven't APC cache and for symfony2 is mandatory have it for have a good load so I change my host provider and now I have a VPS where I can install APC and now it is very fast.
The first time a Symfony program is run with env=prod, it has to create a significant amount of cached code - parsing the routes, annotations, converting configurations files and preparing CSS and Javascript.
It will always be a lot slower the first time, so that the rest of the time it will be fast. If you can run it before the website goes live (eg, with app/console), then that work can happen offline.
After clear:cache the next call on the application will have to rebuild a number cached files. That can be slow - so why make a site visitor trigger it?
If you're clearing the cache in production, try using the cache:warmup command to pre-build the the cache. It will mean the next visitor won't have to wait while the heavy lifting is done.
Something like this should help:
$ php ./app/console clear:cache --env=prod
$ php ./app/console clear:warmup
More info in the Symfony documentation.
I'd also suggest to enable query and result caches for doctrine (did you install/active apc cache for your php installation?). This might further reduce the loading time. Just have a look here :-)
Also try to use a deployment script to automatically trigger the cache clear/warmup, mentioned above. This way you won't forget to call those.
Do you use assetic for css/js? Then combine those files, minify them via assetic filters
Good candidates for deployment scripts are ansible, capifony or just a simple shell script.
I am using memcache.
I want to understand what is stored in Magento cache and how?
Do magento stores cache variable with website scope or store scope?
I have googled and greped the code but couldnt conclude anything,
Please if someone can direct me to correct links and path
Thanks & Regards,
Saurabh
If you go to the Cache Management section of the admin area you can see what it caches (configuration, layout configuration, block html output, translations, eav types, etc). I am no expert on Magento's caching mechanisms but here are a few random tidbits that might be helpful (maybe). (Also note that I am only familiar with Magento 1.3.x, not 1.4.x so things could have changed).
The caching is actually stored in the var/cache directory. There are a ton of directories in there (mage--0, mage--1, mage--2) and each directory has the cache files. Do a ls var/cache/mage*/* to see all the files.
Configuration - This source for the configuration is varied. Your app/etc/local.xml, and all of the config.xml files (that are in each module's etc dir) are combined together to make one big configuration object. Then Magento reads from the core_config_data table to update the configuration object. Then the configuration is written to a cache file so that next time a request is made it doesn't need to open a ton of config files and hit the database. Somehow this info gets stored in a bunch of files under var/cache. For some insight do a ls var/cache/mage*/*CONF*.
Layout - This is a lot like the configuration... there are a bunch of xml files in the app/design/frontendOrAdminhtml/yournamespace/layout/ directory and all these are merged into one layout configuration object, then cached in the cache directory.
Block HTML - The actual html generated by a block is cached. Each block is able to decide how long it is going to be cached.
Lastly, to (not really) answer your question about if the cache is per website or store, I can't really say since I haven't had the need to setup a multi-website/multi-store shop yet. It looks like there may be some store/website-specific files, but I can't see that they are really organized in a logical way. For example, in one of my instances I see a var/cache/mage--f/mage---LAYOUT_FRONTEND_STORE0_DEFAULT_BLANK_SEO file and a var/cache/mage--f/mage---LAYOUT_FRONTEND_STORE1_DEFAULT_BLANK_SEO... but then again, I only have one store configured and those two files have the same contents. Good luck with that!
You could also use some of the very great memcached analysis and reporting tools available
http://code.google.com/p/memcached/wiki/Tools
The best solution I have come up with is to use a two level cache.
Consult app/etc/local.xml.additional to see how to put memcached server nodes in there. Note that within the <servers> tag you will have to have tags like <server1> and <server2> encapsulating each memcached node's settings.
<cache>
<backend>memcached</backend>
<slow_backend>database</slow_backend>
</cache>
In this way all cache is shared.
To clear it the way I do it is to:
1. shut down apache
2. connect to mysql and connect to the magento db and run truncate core_cache; truncate core_cache_tag.
3. I then bounce the memcached nodes.
4. I restart apache but I keep it out of the load balancer until I have hit it at least once to generate the APC opcode cache. Otherwise the load can shot up through the roof.
This all seems extreme but I have found it works for me. Clearing cache using the backend is REALLY slow. I have around 100k entries in the core_cache table and close to 1 million entries in core_cache_tag. If I don't do it this way sometimes I get strange behavior.
Your Memcache configuration in ./app/etc/local/xml will dictate what Memcache is actually caching.
If you are only using a the single-level cache (without ), then Magento will store its cache (in its entirety) in Memcache.
HOWEVER without the slow_backend defined - it is caching content, without cache_tags - ie. without the ability to differentiate cache items
Eg. configuration, block, layouts, translations etc.
So, without the defined, you cannot refresh caches individually, in-fact, you'll almost always have to rely on "Flush Cache Storage" to actually see updates take effect.
We wrote a nice article here which covers your very issue - http://www.sonassi.com/knowledge-base/magento-knowledge-base/what-is-memcache-actually-caching-in-magento/
Memcached is a distributed memory caching system. It speeds up websites having large dynamic databases by storing database objects in Dynamic Memory to reduce the pressure on a server whenever an external data source requests a read. A Memcached layer reduces the number of times database requests are made.
The caching is actually stored in the var/cache directory. There are a ton of directories in there (mage--0, mage--1, mage--2) and each directory has the cache files. Do a ls var/cache/mage*/* to see all the files.
Configure Memcache Magento 2
Magento 2 also supports Memcached for caching objects but it isn’t enabled by default. You need to make simple changes to the $Magento2Root/app/etc/env.php file to enable it.
In env.php, you will see a large number of PHP arrays with different settings and configurations. Open the file in your favorite code editor and locate the following code:
array (
session' =>
'save' => 'files',
),
Modify this chunk as:
'session' =>
array (
'save' => 'memcached',
'save_path' => '<memcache ip or host>:<memcache port>'
),
Note that the default value for memcache ip is 127.0.0.1:11211. Similarly, the default value for memcache port is 11211.
For complete manual please look into it:
https://www.cloudways.com/blog/magento-2-memcached/
https://devdocs.magento.com/guides/v2.4/config-guide/memcache/memcache_magento.html