My nginx server is running with pagespeed but every day I have some problems with cache. The problem is that after some time the scripts loaded in my site returns 404 error. When i look into the cache directory I find a new file named !clean!time!, I supose, like the name suggest, that the cache need to be cleaned. After manual clean and restart server all comes to work. Some one can explain me this behavior? Can I set an "auto-clean cache" on nginx configuration? Thanks
Related
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 have a CodeIgniter setup that has been running fine for the past 2 months and recently I keep getting:
CodeIgniter error- unable to connect to database using the provided settings
I've recently added a new domain that has a landing page for the database login (zPanel), but I don't see how that could have caused a problem--maybe the page keeps getting directory attacked or something, but I'm not sure.
Is there a way to check if this is the problem through logs? I'm at dead ends with this problem, as when I restart the server (DigitalOcean) it works fine again.
Really not sure. If anyone else has had a similar problem, I'd love to hear your solution.
Thanks.
I think your mysql is going down so Codeigniter can't connect to your database settings.
Please login to SSH and check processes by "TOP" comment. See what is using resources ram or cpu.
And check your mysql conf settings, be sure that everything written if its empty it will cause alot of problems.
Some example :
http://www.maxwhale.com/how-to-optimize-mysql-for-1gb-memory-vps/
I am new to symfony and am responsible for a site that I didn't build. For some reason the site is on a live server but running in dev mode. - Im not sure why??
That aside - The website keeps writing _sess files to my /tmp directory. The contents of each _sess file is exactly the same. See below:
_symfony2|a:3:{s:10:"attributes";a:0:{}s:7:"flashes";a:0:{}s:6:"locale";s:2:"en";}
Do I really need all of these files? Can anyone suggest a way of disabling this feature?
Thanks in advance
The default session storage of Symfony2 writes the session information to file(s). The location these files are written to is determined by the config parameter framework.session.save_path. The default value for this is %kernel.cache.dir%/sessions. This means that in a default installation of symfony the session files would be written to the cache directory for the environment.
However, this can be a problem as the cache directory has to be cleared each time an app is deployed, thus logging all the users out. Therefore presumably your app has been configured (most likely in config.yml) to store the session files in /tmp.
As I understand it, sessions that have expired should be garbage-collected at some point. Symfony also has some config params that affect this - see the FrameworkBundle Configuration. I don't know how much traffic your website has but obviously you do need the session files for active sessions. If you think you have a lot of expired sessions you could try tweaking the gc config params.
Alternatively, if having the session files in /tmp is specifically the problem you could relocate them (by changing the value of the framework.session.save_path) or use PDOSessionHandler to store sessions in the database.
I have this problem with symfony 1.4.20 on a web site I inherited.
It is writing files to
/var/lib/php/sessions
every second, until the server runs out of iNodes.
I've tried changing settings in settings.yml. app.yml and PHP session variables.
Nothing sees to be working though, the only way I can stop it is to change the ownership of /var/lib/php/sessions to root and that prevents any session files being created.
EDIT - HUGE ERROR ON MY PART
I found another site that had the issue that I knew was not on the same server. Then I realized that the original site with the issue was also on a different server and had not been moved over completely yet. The server in question was actually a Plesk Parallels' server and the issue was caused by a patch applied to the server over the weekend due to a security update. This server did have the file path and I just had to chmod it to 777 instead of 77x for it to work. I apologize for the confusion and thank everyone for trying to help. +'s for all. :)
Original Post
I have a website on a shared hosting server (also mine) that since yesterday started giving me this error:
Warning: session_start() [function.session-start]: open(/var/lib/php/session/sess_678cf69f0f17b87c52136ee0280d23cc, O_RDWR) failed: Permission denied (13) in /var/www/vhosts/domain.net/httpdocs/index.php on line 1
I've checked /usr/lib/php.ini and /usr/local/lib/php.ini to see where it is set and both say it is set to the /tmp directory, which is where it should be set and always has been. The /var/lib/php/session directory never even existed. I did create it and give it 777 permissions but that did not help. Though the bigger issue here is why did it change to begin with. There is no .htaccess file for this site and I cannot find this being set anywhere on the site itself either.
This is the ONLY site on this server with this issue, telling me its something local to the website. I just cannot figure out what. So my question is this: what should I look for to check the session save path settings for an individual site on a shared hosting environment to find out why it suddenly changed for this one client?
FYI, I am running a WHM server.
Thanks
session_save_path(realpath(dirname($_SERVER['DOCUMENT_ROOT']) . '/../tmp'));
You need to add the above code before starting the session.
You don't appear to have write permission to the /var directory on your server. This is a bit weird, but you can work around it. Before the call to session_start() put in a call to session_save_path() and give it the name of a directory writable by the server. More details here
I found another site that had the issue that I knew was not on the same server. Then I realized that the original site with the issue was also on a different server and had not been moved over completely yet. The server in question was actually a Plesk Parallels' server and the issue was caused by a patch applied to the server over the weekend due to a security update. This server did have the file path and I just had to chmod it to 777 instead of 77x for it to work. I apologize for the confusion and thank everyone for trying to help. +'s for all. :)
I've been running on a problem for about two weeks.
I Have a magento which is configured to use a memcache server.
Recently, I got to change the server storing my magento application.
I installed my new server, and just get my magento app up and running on the new server, with one change : I changed the database user and password used to connect to the database server.
I changed from userold to usernew.
This change takes place in my local.xml file.
But now, when I active the magento cache, Magento tries to connect to my database with the old username : userold.
I've tried all things :
rm -fR var/
/etc/init.d/memcache restart
killall memcached
reboot the entire server running memcached!
I still have my cache problem ! I can't get my
Where does this "userold" value is fuc*** stored ?
Any help would really be appreciated ! :)
Hugues.
telnet into the memcache instance and issue a flush_all command. Restarting the memcache server should have already flushed it, but sometimes its worth a try...
Magento uses TwoLevels backend for caching.
Cache stores to both of them.
And according to Zend's code, Magento reads from fast, and then from slow, if nothing returns.
You have to flush memcache and remove /var/cache at the same time.
start a new instance of memcache on a new port eg 11212
now specify this new port in local.xml
that should ensure that it is talking to a new instacne not the old.. or
use htop / top find find the psid of memcache and kill xxxx