I'm using Codeigniter for my website. I have tried setup memcached to cache object from database and when its running i saw the warning like this:
ERROR - 2016-01-12 00:28:40 --> Severity: Warning --> Memcached::get(): could not read long value, too big /var/www/CodeigniterProject/system/libraries/Cache/drivers/Cache_memcached.php 149
How can i fix this?
I've seen this happen when values have been saved using the Memcache extension and then are retrieved with the Memcached extension - there's an incompatibility between the serialisation used in the two. Flushing the memcache server should solve the issue.
We had the same problem. To resolve it we have changed the package from php5-memcached to php5-memcache. It solved our problem.
You can try changing the Memcached serializer by:
$m->setOption(Memcached::OPT_SERIALIZER, Memcached::SERIALIZER_PHP);
(where $m is the Memcached instance).
Related
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 have a Laravel 3 project, running on a plesk 11.5 CentOS 4(dedicated). It used to be on an IIS server, but i had to migrate it to plesk, since the company i'm working for is dumping the IIS server. Everything seemed to be running smoothly, until i logged out from my application, at first i got a WSOD (white screen of death), then i enabled php error reporting, and this is the error that was displayed:
Fatal error: Cannot override final method Laravel\Database\Eloquent\Model::sync()
This is a very strange error, since i have no method called Sync in any of my classes, and needless to say that there was no such error while the project was running on IIS.
I tried several different combinations of session/cache drivers, the only one that seems to be working is the APC driver.
When i have the APC driver enabled for cache and session, the above Fatal error is not displayed and everything works correctly. The PROBLEM is that i have given the Session Lifetime a value of 60(minutes) but it is completely ignored, meaning that the user is logged out after 2 or 3 minutes.
I've been to the Laravel IRC channel with this issue, some people kindly suggested to tweak the APC memory and ttl (time to leave) settings, but with no luck unfortunately :(.
Here are some APC settings from my server configuration:
apc.gc_ttl 3600
apc.shm_size 1024M
apc.shm_strings_buffer 32M
I desperately need help if anyone has any to offer! This is for a live running project and i need to find a solution asap.
I had the exact same issue and couldn't find a solution. I was going round in circles trying to figure out what on earth was going wrong.
I finally came across this post:
Fatal error: Cannot override final method
You need to make sure that the apc.include_once_override setting is set to 0. In your apc.ini file set like so:
apc.include_once_override=0
This error seems to be caused by caching of included classes.
I solved the problem after looking around the plesk panel.
The problem was that i had "Run PHP as FastCGI application" selected.
I switched to "Run PHP as CGI application" and everything works perfectly.
I'm not sure what the exact source of the problem was, only that FastCGI triggered the error.
My website used CodeIgnter framework and host with iPage. Before, my PHP version is 5.2, then i update it to 5.3. After i updated to PHP 5.3 always get error as below:
- Got error 28 from storage engine
- Incorrect key file for table '/mysql-tmp/#sql_16c4_0.MYI'. try to repair it
- Got error -1 from storage engine
It's not a new question in StackOverflow, but I want to make sure that:
Does these error cause from my update from PHP 5.2 to 5.3?
Does it cause from my misconfiguration in php.ini?
From hosting? or any others?
Sounds like a disk space issue:
MySQL: #126 - Incorrect key file for table
Contact your hosting provider.
Also, this is a mysql issue, not a PHP issue; doesn't matter what version of php you are running.
Got error 28 from storage engine
Disk space problem..
Need space to save the data in the database
if it is loaclhost check your drive memory status if memory is full in that disk free some space.
if it is hosting contact your hosting provider
I am upgrading an existing magento website for 1.4 to 1.6.1.0.
I had dumped the existing database,
Copied all the required custom extension in the blank magento version 1.6.1.0
and after running the installation got the following error:
Error in file:
"/app/code/core/Mage/Customer/sql/customer_setup/mysql4-upgrade-1.5.9.9-1.6.0.0.php"
- SQLSTATE[HY000]: General error: 1025 Error on rename of './sales_flat_order' to './#sql2-3af-a7' (errno: 152)
How can I fix this issue?
Upgrading magento is very painful process. I suggest you to import-export data from old to new shop.
I just went through the same heartburn. I found that letting the page try to load until the script got an error or timed out and then trying again eventually worked. The upgrade script will attempt to start where it last stopped.
Before you do that, make a backup of you site and database. If it continually errors in the same spot, restore and try again.
These tips may help improve the odds of a quicker success:
Put the site in maintenance mode (by adding the maintenance.flag file
to the root directory) before starting.
Increase server and php timeouts by a very large amount (3-5minutes).
Cleanup temp and log database tables that you don't care about
(carefully, everybody has different needs here)
I tried several different methods and that is the only thing that worked. It took probably 10 reloads (waiting for a 3min timeout each time). In the end, everything upgraded correctly. No matter what method you choose, if you want to keep your store data, you will have to run the bulky db upgrade scripts that take forever.
I had similar issues when updating from 1.4.2 to latest.
I built a custom maintenance script included in my index.php that only allowes to access my ip. But the update process via shell replaced my index.php so it was accessible for everyone.
That was the cause that the final sql scripts where run by several clients and caused errors like "can't move table" etc. because those steps where already done.
--> Summing it up: Be sure that the site gets called only once, until the upgrade was successful!
The very best way to migrate magento in my opinion, is to import your entire db to an environment that you have your new magento. Then magento will run all scripts and updates and keep your data.
Maybe you find some problems on the upgrade scripts, but it's easier to fix them than fix the problems regarding model/eav's problems on the fly.
I have succeed by doing this on migrate from 1.4.1 to 1.8.1.
I started to mess around with the EC2 “Micro Instance” for a new site i’m working on. I put on an ubuntu lamp server and loaded up our favorite php framework and started along the coding path.
One frustrating thing i’m finding is whenever I make a mistake coding (which is rare! j/k), it gives my a “Server Error 500” and won’t display the php error line number or the helpful references to where the mistake might have happened.
Also when ever an error does appear and I try to fix the mistake it will remain the same for a couple of minutes. Its like its caching on my system or something. If I do something like this :
echo "test" //leaving off the semicolon
refresh the browser it comes up with the error. Then when I fix it:
echo "foo"; //corrected
I still get the Server Error 500. Not sure if anyone else has run in to these issues. Maybe its a php.ini configuration, .htaccess configuration (i’m using Paul Irish’s HTML5Boilerplate .htaccess code), or a LAMP configuration issue. Any pointers to where the problem might lie would be a huge help.
Thanks! Steve
this has nothing to do with ec2.
see php error directives in /etc/php5/apache2/php.ini