Replies: 3 comments 5 replies
-
Hi there can be different things causing it. Can you check a similar environment but without a load where you can check whether sth is load related or not? What is worth mentioning is that due too magento architecture (eg usage of the foreign keys in index tables) that you have to analyze more then just this query and this table - as there are side effects like mysql locking rows when related table is modified. |
Beta Was this translation helpful? Give feedback.
-
have you tried out MySqls built in performance tooling for analyses? https://vladmihalcea.com/mysql-query-profiling-performance-schema/ can you share the performance_schema.events_stages_history_long for this query? |
Beta Was this translation helpful? Give feedback.
-
sorry for the late reply guys, I've tried multiple things but i'm not that much of a DBA so I've called Oli at FromDual (which I couldn't recommend more) and we've worked together to fix it. He changed some mariadb configurations, not exactly vitals to the specific problem, but that helped to have a more stable infrastructure. Then we debugged the reindex system a lot and turns out mariadb query optimizer doesn't always generate the right "path" to execute complex queries like the ones needed for the reindexing process. The optimizer usually generates the execution path based on table statistics so we tried to update the statistics with "persistant statistics" and "analyze table" but the are multiple problems with this approach so we ended up trashing it. Turns out that adding a "STRAIGHT JOIN" hint to some of the reindexing queries made the optimizer work correctly and a reindex process that was more than 1 hour long when to less than 20 minutes. Point is... modify the reindexing queries is not that easy... I didn't want to patch something like 10-20 core files so... long story short I ended up patching lib/Zend/Db/Adapter/Abstract.php in an ugly (but works perfectly, compared to before) way:
so that whatever query involving _index or _idx tables gets modified (I know it's damn ugly, suggestions are welcome). We've to disable the catalog_product_index_eav_idx table from this patch cause performance was actually worse than before (only for that query). |
Beta Was this translation helpful? Give feedback.
-
Hi everybody, in one of my OpenMage projects (140k SKUs, 4 stores, 8 store views) I'm having problems with reindexing since a while, the reindex queries (most of them actually) are really slow (full reindex takes 20-25 minutes) but I've notices a weird thing.
This is a price reindex query:
which takes minutes to run, but if I remove the "INSERT" part and extract only the "SELECT":
it takes less than a second to run!
I know writing is slower than reading and that indexes may have a role in this, but do you have any ideas how why this happens and if there's something that could help me debug where the heck is the problem (cause I don't think that's a normal behaviour).
Thanks everybody!
Beta Was this translation helpful? Give feedback.
All reactions