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.
Related
I have a php script that is not reacting to code changes that I make (I inserted a deliberate syntax error which is not be being picked up).
I am running php 8.1 on apache2 (on a local copy of ubuntu 22.04). The script is part of a drupal 9.4 custom module.
Running phpinfo now shows:
Opcode Caching Disabled
Optimization Disabled
SHM Cache Enabled
File Cache Disabled
JIT Disabled
Can someone shed any light on might be going on?
I have disabled opcaching and JIT (my understanding from what I read is that SHM cache is therefore irrelevant). I have checked the paths in the script and the code editor align. I have cleared drupal and browser caches (several times) and restarted php-fpm and apache2. From my research I had expected these to cure the problem.
I also rebuilt the whole thing to my retired dev server (the only difference is ubuntu 20.04) and after the first successful run of the script I observed the same behaviour when I make changes to the script.
Googling has not yielded a solution that helps me identify where the problem lies, though it points me at opcache rather than drupal.
Problem solved. Really basic - I should have spotted it earlier. I had a duplicate script in another directory in the website file system, which drupal was using in preference to the one it should have been using.
Apologies for wasting other people's time!
Good day,
We are currently running a fairly intensive system on PHP 5.5 connecting to a Redis database. The current setup has 6 Ubuntu 14.04 AWS instances dedicated to PHP and everything works fine. Due to some updated functionalities, we need to upgrade to PHP7 so I created a few Ubuntu 16.04 servers with PHP 7.0.28-0ubuntu0.16.04.1. We are using Predis (https://github.com/nrk/predis) to connect to the database but when I switch over to the 4 x PHP7 servers, I get random timeouts (not constant) - when these occur and because of the locking mechanism we have in place, the whole site becomes unresponsive for a few seconds.
So my question is mainly, has anyone ever got these issues? I think I have read some places that installing the phpredis extension helps, but that may have been a while back and I am not sure it's relevant here. Any insight on why I would need (or not) the extension would be useful.
I have copied the PHP settings from the old installation to the new one by comparing the INI and other configuration files but can post if needed.
I have a laravel 4 web project that implements a laravel command.
When running in the development homestead vm, it runs to completion (about 40 seconds total time).
However when running it on the production server, it quits with a 'killed' output on the command line.
At first i thought it was the max_execution_time in cli php.ini, so I set it to 0 (for unlimited time).
How can I find out what is killing my command?
I run it on ssh terminal using the standard artisan invokation:
php artisan commandarea:commandname
Does laravel 4 have a command time limit somewhere?
The vps is a Ubuntu 4.10 machine with mysql, nginx and php-fpm
So, firstly, thank you everyone who has pointed me in the right direction regarding PHP and laravel memory usage tracking.
I have answered my own question hoping that it will benefit laravel devs in the future, as my solution was hard to find.
After typing 'dmesg' to show system messages. I found that the php script was being killed by Linux.
So, I added memory logging calls into my script before and after each of the key areas of my script:
Log::Info('Memory now at: ' . memory_get_peak_usage());
Then I ran the script while watching the log output and also the output of the 'top' command.
I found that even though my methods were ending and the variables were going out of scope, the memory was not being freed.
Things that I tried, that DIDNT make any difference in my case:
unset($varname) on variables after I have finished with them - hoping to get GC to kick off
adding gc_enable() at beginning of script and then adding gc_collect_cycle() calls after a significant number of vars are unset.
Disabling mysql transactions - thinking maybe that is memory intensive - it wasnt.
Now, the odd thing was that none of the above made any difference. My script was still using 150mb or ram by time it killed!
The solution that actually worked:
Now this is definitely a laravel specific solution.
But my scripts purpose is basically to parse a large xml feed and then insert thousands of rows into mysql using Elequent ORM.
It turns out that Laravel creates logging information and objects to help you see the query performance.
By turning this off with the following 'magic' call, I got my script down from 150mb to around 20mb!
This is the 'magic;' call:
DB::connection()->disableQueryLog();
I can tell you by the time I found this call, I was grasping at straws ;-(
A process may be killed for several reasons:
Out of Memory
There are two ways to trigger this error: Exceed the amount of memory allocated to PHP script in php.ini, or exceed the available system memory. Check the PHP error log and php.ini file to rule out the first possibility, and use dmesg output to check for the second possibility.
Exceeded the execution time-out limit
In your post you indicate that you disabled the timeout via the max_execution_time setting, but I have included it here for completeness. Be sure that the setting in php.ini is correct and (for those using a web server instead of a CLI script) restart the web server to ensure that the new configuration is active.
An error in the stack
If your script is error-free and not encountering either of the above errors, ensure that your system is running as expected. When using a web server, restart the web server software. Check the error logs for unexpected output, and stop or upgrade related daemons and needed.
Had this issue on a Laravel/Spark project. just wanted to share if others have this issue.
Try a refresh/restart of your dev server if running Vagrant or Ubuntu before more aggressive approaches.
I accidentally ran install of dependency packages on a Vagrant server. I also removed and replaced a mirrored folder repeatedly during install errors. My error was on Laravel/Spark 4.~. I was able to run migrations on other projects; I was getting 'killed' very quickly, 300ms timeframe, on a particular project for nearly all commands. Reading other users, I was dreading trying to find the issue or corruption. In my case, a quick Vagrant reload did the trick. killed issue was resolved.
I need to install large sites locally on two developers workstations. The sites are written in php5 with parts in Zend 1.10 and the database is MySQL. The production server runs on windows server 2003 . The sites are already running on windows vista on a development station and on windows 7 on another one.
On two workstations where i have to install (a windows xp and a windows 7), the same strange phenomenon occurs: after a few successfull requests apache freezes and no longer responds to any query. The site does not work until a reboot of Apache that takes quite a long time (> 30 seconds) . There is nothing in Windows Event Viewer or in the apache logs. Handle.exe tells me nothing and even freezes when apache starts to hang. Windows tasks manager shows nothing unusual. I have compared the host file , php.ini , httpd.conf and httpd.vhost.conf with stations that work without finding any difference.
The configuration includes mod_rewrite , mod_proxy , apc , memcached. Apache version is 2.2 and PHP 5.3.x (thread safe). The code is under version control, database and data directories are synchronized.
Not familiar with windows , I'm looking for tools or assumptions to solve this problem .
I provide some information about a temporary solution I applied. I noticed that a fraction of the php code was executed before Apache freezes.
Execution stops within a Zend Class, Zend_Validate_Ip in the setOptions method. At this time, the file is locked for writing and held by httpd.exe.
I found that this file was slightly different from the original version (Zend 1.11.11) : the require_once have been removed. This is an acceptable optimization recommended by the official documentation.
However, restoring the require_once in that file, the problem is solved. Apache no longer freezes and everything works. So there must be a problem with class loading but I do not understand exactly what it is.
I run simpleSamlPHP 1.9 on a PHP 5.3.9 installation in EasyPHP, on a Windows XP machine. SimpleSamlPHP is serving as a SAML identity provider, fetching users in a local MySQL database.
My problem is that when requesting authentication against this IdP, Apache crashes throwing a "violation access" error, a.k.a. segfault. The problem is similar to this thread except that the child process exits with status 0 (but isn't this a Windows-specific feature of PHP regarding exit codes ?).
The common fix, copying libmysql.dll and php5apache2.dll in C:\Windows\system32, doesn't help.
Running VC++6 just-in-time debugger doesn't give me any information about which module is incriminated :'(
I tried to disable as much PHP extensions as I could. SimpleSamlPHP needs openSSL and PDO/MySQL, thus I kept only those 2 enabled, and crash happens anyway. I checked separately that using openSSL and MySQL works fine.
Finally I have to precise that the machine hosts 3 instances of PHP, including 2 in EasyPHP (2 separate installs), but only the concerned instance is active when the crash happens.
Any leads ?
Cheers
Did you run php with apache's mod_php? I had the same situation here. It always crashes when a sp authentication comes in. I have no idea how this happened. But at the end, I avoided the problem by running php in FastCGI mode.