Видимость процесса Magento Partial Index

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

Будем весьма благодарны за любые предложения о том, как мне получить больше информации о процессе частичного индексирования, о том, что он в настоящее время делает, и о том, как он продвинулся / что еще предстоит проиндексировать!

4

Решение

Есть также некоторые другие таблицы, проверьте enterprise_mview_*,
Некоторое время не работал с корпоративными индексаторами, но в последний раз я настроил XDebug для консоли и проанализировал, что он делает. Или просто Mage::log() везде, но я не рекомендую это по-настоящему отладчик.

Надеюсь, вы попадете на правильный путь.

0

Другие решения

Других решений пока нет …