PHP APC uptime problem - php

I am on LAMP with Alternative PHP Cache (APC). It worked fine until yesterday when I updated the website and changed a few MySQL queries (I don't see how it would affect the APC opcode cache.)
Today I see that the load has increased on the server and I see in Alternative PHP Cache, that the uptime of APC is somewhere around 15 minutes and then it gets restarted.
At this point the APC cache is only about 20% full of the available 30 MB. Using for opcode cache only. During this 15 minutes the cache works fine (99,8% cache hits). After this unwanted restart the APC cache is empty. Why is it restarting? Where can I find the logs for it?

It was a cPanel update that caused Apache to restart gracefully every 15 minutes.

Related

PHP-FPM slows down after a while - Opcache File Cache

My set up is a large drupal website with 50,000 requests per day. My main issue is that Php-fpm slows down after 10-15 minutes of a restart (1500+ code files). Cache is only full 40% (174mb of 512mb). Initial server response time is over 700ms but goes down to 170ms for first few minutes of a restart as per Google site speed testing.
I found this answer with similar issue and have added Opcache file cache with some improvement.
https://forums.cpanel.net/threads/php-fpm-restart-necessary-for-site-speed.650549/#post-2654105
Current Opcache Settings
[opcache]
opcache.enable=1
opcache.memory_consumption=512
opcache.interned_strings_buffer=64
opcache.max_accelerated_files=50000
opcache.max_wasted_percentage=15
opcache.validate_timestamps=0
opcache.revalidate_freq=0
opcache.mmap_base=0x20000000
opcache.file_cache='var/www/cache'
opcache.file_cache_fallback=1
Any other ideas on how to optimise the above to achieve consistent php-fpm performance. (Set up is Php-fpm 7.2, Nginx, Drupal, Mariadb on AWS server with 64G memory)
Tried adding File cache. It has shaved off 100ms but probably a lot more can be done.

Neither load front end nor back-end in Magento 2.2.3

I have installed Magento-2.2.3 in windows personal computer and after the installation it loaded first time well but after that it is not responding since an hour. Actually, I am new to Magento and anybody can tell about this problem?
Follow the below points this may help you.
enable all cache may help you. Full page cache .
MySQL 5.6 has some memory issues where a defaul config will use
about 500mb of ram, to fix set performance_schema = off in your
my.cnf and restart MySQL. Also make sure you have opcache turned on
and set to at least 64mb of ram and 10000 files cached, preferable
128mb. If you tune your config you can run on a 512mb vps but it's
tricky and you won't have enough ram for fpc on varnish and reddis
sessions. 1 gb vps with the above MySQL fix should work like a champ
out of the box on a vps.
There are lots of potential reasons why, but the most common is
around file system performance. In non-production mode especially,
we hit the disk pretty hard (lots of different files). E.g. in
developer mode we generate files on the fly (CSS etc). But without
more details (PHP version? using Vagrant? VM? Docker? OS? Memory? is
machine thrashing? etc), it is pretty hard to suggest something. Its
certainly not taking any where near that long on my laptop. Can you
provide any information about your setup? (But my first
investigation would be around I/O performance - for example using
Docker/VirtualBox with file syncing back to Windows is a dog -
because the file syncing is very slow.)

TYPO3 6.2 suddenly extreme slow (only frontend!)

We run several TYPO3 websites on Apache (Linux 3.16, mysql 5.6, PHP 5.6). One of our websites (TYPO3 6.2.19) is suddenly extremely slowly but only the frontend. Loading time is always more than 60s but maximum 1.8 min. Site did always run smooth and fast. No changes in server settings were made since the past days.
I already tried to restart apache and sql server, cleared all TYPO3 caches... no changes in frontend.
Any ideas what could cause this error?
Can you activate the scheduler extension and execute garbage collection tasks?
Then see, if that helps
Do you have access to the server and can you restart services?
Then try restarting apache
I had a similar situation once, the issue was based on wrong permissions and php session files that could not be deleted. Switching to memcache session handling for php solved the issue.

Drupal Site Crashing Constantly - Help Debugging

So we have a site running Drupal 7.41 on apache and it crashes constantly (multiple times a week). When it crashes we just restart the VM and the page start working again until the next crash. I installed New Relic in hope that it will help pin point what are some of the reasons why the site is crashing but I'm new to Drupal and maintaining it that I'm not sure where to start.
I've went to the 'Recent logs messages' section in Drupal but that doesn't seem to help. The last has been offline for some time since the last time I restarted it and the log messages don't show anything critical... just 'Notices':
On New Relic I can see that the CPU and Memory are maxed out precisely when the site crashes which gives the impression that this might be the error. Initially the site had 1GB of RAM and that was increased to 2GB when we thought this might be the problem. However, we see that it keeps maxing out so we're not sure if there really needs to be more RAM installed to avoid these crashes or if its just Apache (httpd) that tends to use that much RAM even if its not needed?
As you can see, as I restart the server, everything seems to go back to normal.
Can anyone recommend a way to help me understand what might be the problem? Is it just that 2GB is not enough RAM? If so, how do I know how much RAM might be needed?
Thanks in advance!
UPDATE#1:
I was reading this article: http://fuseinteractive.ca/blog/drupal-performance-tuning-0 on some performing techniques on Apache specifically. The first thing they mentioned was to disable modules that you might not need in order to save memory and improve performance. Upon checking the Apache configuration directory (/etc/httpd/conf.d for CentOS) I found only a few modules enabled:
Should I disable any of those?
The second point they mentioned was to update some of Apache's Default Configuration Settings. I've set mines to these:
Timeout 30
MaxKeepAliveRequests 100
KeepAliveTimeout 5
UPDATE#2: MPM Settings Updated to these values:
StartServers 5
MinSpareServers 10
MaxSpareServers 20
ServerLimit 256
MaxClients 200
MaxRequestsPerChild 0
UPDATE#3: I increased the RAM to 4GB last night and so far the physical memory usage has been steady at ~2GB for the last 12 hours. It's a weekend so there's not much traffic to the site so let's see how this behaves in the next couple of days.
First of all, I would duplicate the environment to try several things in a non-production environment. Here are some ideas of what I would do:
Install the latest version of the Drupal core
Have a look at the contributed modules you are using. Make sure you have the latest version installed.
One by one, uninstall the contributed modules and verify whether the error keeps appearing. Try to do the same with the installed themes.
I have had some problems with cron tasks. You can use the Cron Debug module to isolate the cron tasks running from each module and try to identify the problem.
Just to discard an attack, use the Hacked! module to confirm that the code you have installed in your server matches the code of the core and contributes modules available on Internet.
There are two potential problems here:
Your traffic/complexity of your site are not match for your hardware
Your drupal core using more resources than should
Your hardware looks good for average drupal site so i would go for other option. Also in your graphic you can see that CPU is 100% used before crash which means either your site is under spam attack or some module causing the problem.
Go on admin/config/system/statistics and enable access log
Go on /admin/reports/pages and /admin/reports/visitors and check number of hits per page/user on crash time.
Go on admin/config/system/cron and disable cron to see if the problem
is on some of the cron tasks.
Also it is the best practice to use latest module releases. You can easily see that on admin/reports/updates/update (you should have update manager module enabled for this). Make sure you backup potential customization on current modules before you update them.

Symfony2.5 slow Initialization time compared to Symfony2.4

I just installed both Symfony2.4.4 and Symfony2.5.1 and set up a hello world page + some basic things I use (assetic js/css management etc). Configuration and setup for both projects are exactly the same.
I noticed that in app_dev the Symfony2.5.1 needs around 1100ms to generate the page, while Symfony2.4.4 only needs around 130ms to generate the same page. Both numbers come from the Symfony debug toolbar.
When I take a look at the profiler's timeline I noticed Symfony2.5.1 uses around 900-1000ms for something called "Initialization time", while with 2.4.4 that only takes 50-60 ms.
Symfony2.5.1
Symfony2.4.4
Does anyone have an idea why it takes Symfony2.5.1 so much longer to initialize the project? I've checked the changelog for 2.5.x but haven't found anything so far. (https://github.com/symfony/symfony/blob/master/CHANGELOG-2.5.md)
Edit: Apparently the 2.5.1 rebuilds the entire dev cache on each page load, while the 2.4.4 does not. Not sure why.
Edit2: Noticed the chromehelper on my mac was running rogue (eating CPU), so I restarted the browser. Afterwards 2.5.1 doesn't rebuild dev cache anymore and load times are similar to 2.4.4. I don't get how it can be related though, how can a rogue browser influence the rebuilding of dev cache? FYI: The 2 projects are running on a virtualbox with centOS on that same mac.
The initialization time difference between both version was happening because Symfony2.5.1 was completely rebuilding its dev cache every time I loaded the page. I 'solved' it by killing off my mac/chrome browser which was running rogue.
After browser restart, 2.5.1 cache behaved the same as 2.4.4, with loading times around 130ms.
How a rogue browser can influence dev cache, I have no clue though.

Categories