Magento Enterprise 1.13+ использует процесс ‘частичного индекса’, который выполняется в фоновом режиме как часть задания cron Magento. В настоящее время я изо всех сил пытаюсь понять, что делает этот процесс.
Я понимаю, что частичный индексатор работает, отслеживая сущности для повторного индексирования через таблицы ‘changelog’ в базе данных (catalog_category_flat_cl
, catalog_category_product_cat_cl
и т. д.), а затем переиндексирует эти конкретные элементы при запуске cron.
Cron Magento в настоящее время работает на моем сервере (тот же процесс cron работает около 3 часов). cron_schedule
таблица указывает на то, что enterprise_refresh_index
находится в процессе и начался одновременно с началом вышеупомянутого процесса cron.
Однако, когда я считаю строки в таблицах изменений, значения всегда одинаковы; количество строк в этих таблицах не уменьшается (что я ожидал бы, если бы их обрабатывал частичный индексатор?). Утилита n98-magerun перечисляет индексы, но ни один из них в настоящее время не обрабатывается:
$ n98-magerun.phar index:list
+------------------------------+-----------------+------+
| code | status | time |
+------------------------------+-----------------+------+
| catalog_product_attribute | require_reindex | 28m |
| catalog_product_price | pending | 0 |
| catalog_url | pending | 0 |
| catalog_product_flat | pending | 0 |
| catalog_category_flat | pending | 0 |
| catalog_category_product | pending | 0 |
| catalogsearch_fulltext | pending | 0 |
| cataloginventory_stock | pending | 0 |
| tag_summary | require_reindex | 1s |
| url_redirect | pending | 0 |
| catalog_url_category | pending | 0 |
| catalog_url_product | pending | 0 |
| catalog_category_product_cat | pending | 0 |
| targetrule | pending | 0 |
+------------------------------+-----------------+------+
var/locks
каталог, кажется, имеет активные блокировки для каждого индексатора, что не имеет смысла (конечно, файлы блокировки должны быть удалены после завершения процесса индексирования ?:
$ ls -lah
total 64K
drwxrws--- 2 www-data www-data 4.0K Sep 23 22:56 .
drwxrws--- 8 www-data www-data 4.0K Sep 10 07:12 ..
-rw-rw-r-- 1 www-data www-data 31 Sep 24 00:10 index_process_10.lock
-rw-rw-r-- 1 www-data www-data 31 Sep 24 00:10 index_process_11.lock
-rw-rw-r-- 1 www-data www-data 31 Sep 24 00:10 index_process_12.lock
-rw-rw-r-- 1 www-data www-data 31 Sep 24 00:10 index_process_13.lock
-rw-rw-r-- 1 www-data www-data 31 Sep 24 00:10 index_process_14.lock
-rw-rw-r-- 1 www-data www-data 31 Sep 23 22:20 index_process_1.lock
-rw-rw-r-- 1 www-data www-data 31 Sep 23 17:53 index_process_2.lock
-rw-rw-r-- 1 www-data www-data 31 Sep 24 00:10 index_process_3.lock
-rw-rw-r-- 1 www-data www-data 31 Sep 24 00:10 index_process_4.lock
-rw-rw-r-- 1 www-data www-data 31 Sep 24 00:10 index_process_5.lock
-rw-rw-r-- 1 www-data www-data 31 Sep 24 00:10 index_process_6.lock
-rw-rw-r-- 1 www-data www-data 31 Sep 24 00:10 index_process_7.lock
-rw-rw-r-- 1 www-data www-data 31 Sep 24 00:10 index_process_8.lock
-rw-rw-r-- 1 www-data www-data 31 Sep 24 00:10 index_process_9.lock
Будем весьма благодарны за любые предложения о том, как мне получить больше информации о процессе частичного индексирования, о том, что он в настоящее время делает, и о том, как он продвинулся / что еще предстоит проиндексировать!
Есть также некоторые другие таблицы, проверьте enterprise_mview_*
,
Некоторое время не работал с корпоративными индексаторами, но в последний раз я настроил XDebug для консоли и проанализировал, что он делает. Или просто Mage::log()
везде, но я не рекомендую это по-настоящему отладчик.
Надеюсь, вы попадете на правильный путь.
Других решений пока нет …