You’d need to selectively deactivate suspect plugins and do without it for a while until you can see if memory usage creeps up or not. The trouble is it’s normal for usage to swing up and down, you need to wait long enough to see a general trend. I have a hunch (with no supporting evidence) that it’s not WordFence, but it is conceivable for a page caching scheme to consume more memory. If so, memory would become available again once you flush its cache.
Thank you for your reply. The free memory started out last night at 2G and went down to 130M overnight. By itself it has gone back up to 628M in the last 2 hours. I started out with a fresh AMI of bitnami wordpress that came with W3 Total Cache preinstalled. I have not activated it yet because I am aware of how difficult it is to remove. I have previously tested it and was not successful with Woocommerce. It appears that something is creating a cache as 831M shows up as buff/cache with free -m. I do not have any other caching plug ins installed. Does WordPress cache by default? If so, how can I access/disable it?
Found
LoadModule socache_shmcb_module modules/mod_socache_shmcb.so
in httd.conf
and
zend_extension = opcache
session.cache_expire = 180
soap.wsdl_cache_enabled=1
[opcache]
; Determines if Zend OPCache is enabled
opcache.enable = 1
; Determines if Zend OPCache is enabled for the CLI version of PHP
opcache.enable_cli = 0
; The OPcache shared memory storage size.
opcache.memory_consumption = 192
; The amount of memory for interned strings in Mbytes.
opcache.interned_strings_buffer = 16
; The maximum number of keys (scripts) in the OPcache hash table.
; Only numbers between 200 and 1000000 are allowed.
opcache.max_accelerated_files = 4000
; The maximum percentage of "wasted" memory until a restart is scheduled.
;opcache.max_wasted_percentage=5
; When this directive is enabled, the OPcache appends the current working
; directory to the script key, thus eliminating possible collisions between
; files with the same name (basename). Disabling the directive improves
; performance, but may break existing applications.
;opcache.use_cwd=1
; When disabled, you must reset the OPcache manually or restart the
; webserver for changes to the filesystem to take effect.
;opcache.validate_timestamps=1
in php.ini
So it looks like my AWS bitnami WordPress AMI came with some caching turned on and some turned off right out of the box. I absolutely don’t know what I am doing so I think I will start reading documentation before I touch any of these settings. I am tempted to reduce the cache duration from 180 down to 120 and the max number of files down to 1000, but again I am terrified. It may be worth me setting up a ‘test’ site and playing around with it and see if I can duplicate the issue.
I found a plug in called WPopcache settings. It is showing that only 192 megabytes are being used for opcache and that it is getting a 98% hit rate.
It has to be a plugin that is using memory. I will try turning off each one, one at a time.
Thanks
The opcache actually belongs to PHP, not WP. It should stay in its allocated “sandbox” of memory. WP does have an object cache, but unless you use a plugin that leverages it, by default it is not persistent. It’s typically for storing data that might be re-used within a single request. Both of these are very stable, long used schemes that I’d be very surprised if they are responsible for the memory creep you are seeing.
As you’ve surmised, the problem is almost surely due to a plugin.
