When I use the search function on my website, it shows results with old content. I tried to clear all caches but it doesn't solve the issue.
I am not sure if I should truncate some tables in the DB and how safe this is.
By the way I don't have any "indexed search" option in the Backend under "Info".
Which TYPO3 Version are you using? With TYPO3 8.7 (not sure if also with 7.6) the module moved to an own one called "Indexing".
Anyway you shouldn't get any problem truncating the indexed_search tables in the DB as they get shipped without data when you install indexed_search.
To be sure, just make a backup of the tables.
Related
I am using magento 1.7.0.2 Community Edition , in my catalog I have 28000 products.
I do reindexing from shell using following command
php indexer.php --reindexall
It shows all indexes have been reindexed.but with in moment if I check
php indexer.php --status
It shows all indexes require reindexing even after full reindexing has been done.
How to fix this reindexing problem?
Try doing it once from magento backend also.It might solve your problem.
1) I'm having the same issue - in the backend it constantly states that one or more of the indexes are not up to date. Magento 1.7.02
2) If I reindex from the back end, everything is reported as good, but the message remains
3) If I use ssh - indexer.php --status shows all pending.
4) If I then reindex individually, I get the message that each index was rebuilt successfully.
5 Back in admin it says that one or more of my indexes is out of date!
So, I'm not in a position to answer why its happening, but can I make a suggestion?
If it takes too much time to index from the backend, this might suggest that your database is too big. Have you cleaned up the log tables, etc in the database?
Have you tried ssh reindexing individually? --reindexall can take too much memory/slow your site down. Reindexing individually can also highlight which index has problems.
Cheers,
Had exact problem. After many attemps, my solution was to "Optimize" all tables via PHPMyAdmin (guessing that this problem was caused due to large innodb tables).
We have solr installed as a tomcat application. With the default installation of EE magento with sample data all runs perfect.
However, with a couple of our stores running the index does not touch the /solr/data folder. Normally when a reindex is called all files in /data are cleared and repopulated. However, on the live site this does not happen.
I have stipped back a lot of extesnions and run the index again.. this time the files are recreated but almost no data is captured... even less than the sample stores despite a much larger database.
Anyone any clues as to where we should be looking?
I'm trying to compare the performance of different Solr queries. In order to get a fair test, I want to clear the cache between queries.
How is this done? Of course, one can restart the server, I was curious if there is a quicker way.
I'm using version 4.2.1 and even with autowarmCount="0" the cache is not updated after doing a Dataimport.
In that case, on Solr Admin (usually http://localhost:8983/)
Go to Core Admin and click Reload.
When refreshed, you should see a green check mark on the "current" field.
Disable all the caches from solrconfig.xml.
Note that the Lucene FieldCache will still be enabled.
Just for thorough details
If you want to disable a cache (or all), comment out those sections in solrconfig.xml and restart solr.
example diable queryResultCache
<!--
<queryResultCache class="solr.LRUCache"
size="5000"
initialSize="5000"
autowarmCount="2000"/>
-->
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 am using memcache.
I want to understand what is stored in Magento cache and how?
Do magento stores cache variable with website scope or store scope?
I have googled and greped the code but couldnt conclude anything,
Please if someone can direct me to correct links and path
Thanks & Regards,
Saurabh
If you go to the Cache Management section of the admin area you can see what it caches (configuration, layout configuration, block html output, translations, eav types, etc). I am no expert on Magento's caching mechanisms but here are a few random tidbits that might be helpful (maybe). (Also note that I am only familiar with Magento 1.3.x, not 1.4.x so things could have changed).
The caching is actually stored in the var/cache directory. There are a ton of directories in there (mage--0, mage--1, mage--2) and each directory has the cache files. Do a ls var/cache/mage*/* to see all the files.
Configuration - This source for the configuration is varied. Your app/etc/local.xml, and all of the config.xml files (that are in each module's etc dir) are combined together to make one big configuration object. Then Magento reads from the core_config_data table to update the configuration object. Then the configuration is written to a cache file so that next time a request is made it doesn't need to open a ton of config files and hit the database. Somehow this info gets stored in a bunch of files under var/cache. For some insight do a ls var/cache/mage*/*CONF*.
Layout - This is a lot like the configuration... there are a bunch of xml files in the app/design/frontendOrAdminhtml/yournamespace/layout/ directory and all these are merged into one layout configuration object, then cached in the cache directory.
Block HTML - The actual html generated by a block is cached. Each block is able to decide how long it is going to be cached.
Lastly, to (not really) answer your question about if the cache is per website or store, I can't really say since I haven't had the need to setup a multi-website/multi-store shop yet. It looks like there may be some store/website-specific files, but I can't see that they are really organized in a logical way. For example, in one of my instances I see a var/cache/mage--f/mage---LAYOUT_FRONTEND_STORE0_DEFAULT_BLANK_SEO file and a var/cache/mage--f/mage---LAYOUT_FRONTEND_STORE1_DEFAULT_BLANK_SEO... but then again, I only have one store configured and those two files have the same contents. Good luck with that!
You could also use some of the very great memcached analysis and reporting tools available
http://code.google.com/p/memcached/wiki/Tools
The best solution I have come up with is to use a two level cache.
Consult app/etc/local.xml.additional to see how to put memcached server nodes in there. Note that within the <servers> tag you will have to have tags like <server1> and <server2> encapsulating each memcached node's settings.
<cache>
<backend>memcached</backend>
<slow_backend>database</slow_backend>
</cache>
In this way all cache is shared.
To clear it the way I do it is to:
1. shut down apache
2. connect to mysql and connect to the magento db and run truncate core_cache; truncate core_cache_tag.
3. I then bounce the memcached nodes.
4. I restart apache but I keep it out of the load balancer until I have hit it at least once to generate the APC opcode cache. Otherwise the load can shot up through the roof.
This all seems extreme but I have found it works for me. Clearing cache using the backend is REALLY slow. I have around 100k entries in the core_cache table and close to 1 million entries in core_cache_tag. If I don't do it this way sometimes I get strange behavior.
Your Memcache configuration in ./app/etc/local/xml will dictate what Memcache is actually caching.
If you are only using a the single-level cache (without ), then Magento will store its cache (in its entirety) in Memcache.
HOWEVER without the slow_backend defined - it is caching content, without cache_tags - ie. without the ability to differentiate cache items
Eg. configuration, block, layouts, translations etc.
So, without the defined, you cannot refresh caches individually, in-fact, you'll almost always have to rely on "Flush Cache Storage" to actually see updates take effect.
We wrote a nice article here which covers your very issue - http://www.sonassi.com/knowledge-base/magento-knowledge-base/what-is-memcache-actually-caching-in-magento/
Memcached is a distributed memory caching system. It speeds up websites having large dynamic databases by storing database objects in Dynamic Memory to reduce the pressure on a server whenever an external data source requests a read. A Memcached layer reduces the number of times database requests are made.
The caching is actually stored in the var/cache directory. There are a ton of directories in there (mage--0, mage--1, mage--2) and each directory has the cache files. Do a ls var/cache/mage*/* to see all the files.
Configure Memcache Magento 2
Magento 2 also supports Memcached for caching objects but it isn’t enabled by default. You need to make simple changes to the $Magento2Root/app/etc/env.php file to enable it.
In env.php, you will see a large number of PHP arrays with different settings and configurations. Open the file in your favorite code editor and locate the following code:
array (
session' =>
'save' => 'files',
),
Modify this chunk as:
'session' =>
array (
'save' => 'memcached',
'save_path' => '<memcache ip or host>:<memcache port>'
),
Note that the default value for memcache ip is 127.0.0.1:11211. Similarly, the default value for memcache port is 11211.
For complete manual please look into it:
https://www.cloudways.com/blog/magento-2-memcached/
https://devdocs.magento.com/guides/v2.4/config-guide/memcache/memcache_magento.html