процесс индекса массы

У нас проблема в том, что процесс индекса массы-действия никогда не выполняется. У этого есть побочный эффект, что данные работы этой работы существенно растут с течением времени.

В нашем случае в течение нескольких дней объем рабочих данных увеличивается до нескольких МБ.

mysql> select type, entity, count(*), avg(length(new_data)), max(length(new_data)) from index_event group by type, entity;
+-----------------------+--------------------------------+----------+-----------------------+-----------------------+
| type                  | entity                         | count(*) | avg(length(new_data)) | max(length(new_data)) |
+-----------------------+--------------------------------+----------+-----------------------+-----------------------+
| catalog_reindex_price | catalog_product                |     1368 |              442.7982 |                   443 |
| mass_action           | catalog_product                |        1 |          6176981.0000 |               6176981 |
| save                  | awaffiliate_withdrawal_request |        6 |              444.3333 |                   445 |
| save                  | cataloginventory_stock_item    |     4439 |              607.9685 |                   608 |
| save                  | catalog_category               |       71 |             1040.3662 |                  3395 |
| save                  | catalog_eav_attribute          |        3 |              424.6667 |                   476 |
| save                  | catalog_product                |     1368 |             1269.0899 |                  1922 |
+-----------------------+--------------------------------+----------+-----------------------+-----------------------+

Поскольку эти данные не сериализуются, а затем сериализуются для обновления, а также передаются с и на сервер БД, обновление записи mass_action в настоящее время занимает около 3 с. Это влияет на код, который запускает обновление этого индекса.

Как я понимаю, запуск обновления следующих индексов приведет к обновлению массового действия.

mysql> select ip.indexer_code, ipe.process_id, ipe.event_id, ipe.status, ie.type, ie.created_at from index_process_event as ipe left join index_event as ie on ipe.event_id = ie.event_id  left join index_process as ip on ip.process_id = ipe.process_id where ie.type  = 'mass_action';
+---------------------------+------------+----------+--------+-------------+---------------------+
| indexer_code              | process_id | event_id | status | type        | created_at          |
+---------------------------+------------+----------+--------+-------------+---------------------+
| catalog_product_attribute |          1 |     9074 | new    | mass_action | 2016-11-03 23:18:06 |
| catalog_product_price     |          2 |     9074 | new    | mass_action | 2016-11-03 23:18:06 |
| catalogsearch_fulltext    |          7 |     9074 | new    | mass_action | 2016-11-03 23:18:06 |
| cataloginventory_stock    |          8 |     9074 | new    | mass_action | 2016-11-03 23:18:06 |
| tag_summary               |          9 |     9074 | new    | mass_action | 2016-11-03 23:18:06 |
| catalog_product_flat      |         19 |     9074 | new    | mass_action | 2016-11-03 23:18:06 |
| catalog_category_product  |         21 |     9074 | new    | mass_action | 2016-11-03 23:18:06 |
+---------------------------+------------+----------+--------+-------------+---------------------+

У нас есть все индексы, установленные вручную, и мы запускаем cronjobs в разное время дня для обновления индексов.

mysql> select * from index_process;
+------------+-------------------------------+-----------------+---------------------+---------------------+--------+
| process_id | indexer_code                  | status          | started_at          | ended_at            | mode   |
+------------+-------------------------------+-----------------+---------------------+---------------------+--------+
|          1 | catalog_product_attribute     | require_reindex | 2016-11-15 00:40:10 | 2016-11-15 00:10:24 | manual |
|          2 | catalog_product_price         | require_reindex | 2016-11-15 00:45:09 | 2016-11-15 00:15:44 | manual |
|          7 | catalogsearch_fulltext        | require_reindex | 2016-11-14 23:51:23 | 2016-11-14 12:12:30 | manual |
|          8 | cataloginventory_stock        | require_reindex | 2016-11-15 00:47:01 | 2016-11-15 00:45:09 | manual |
|          9 | tag_summary                   | require_reindex | 2016-11-14 23:54:01 | 2016-11-14 23:54:01 | manual |
|         12 | awaffiliate_affiliate_balance | pending         | 2016-11-14 23:54:01 | 2016-11-14 23:54:03 | manual |
|         18 | catalog_url                   | require_reindex | 2016-11-14 23:54:03 | 2016-11-14 21:02:53 | manual |
|         19 | catalog_product_flat          | require_reindex | 2016-11-15 00:49:02 | 2016-11-15 00:10:10 | manual |
|         20 | catalog_category_flat         | pending         | 2016-11-15 00:51:01 | 2016-11-15 00:51:04 | manual |
|         21 | catalog_category_product      | require_reindex | 2016-11-15 00:53:01 | 2016-11-15 00:06:04 | manual |
|         22 | ampgrid_qty_sold              | require_reindex | 2016-11-15 00:06:04 | 2016-11-14 12:21:18 | manual |
+------------+-------------------------------+-----------------+---------------------+---------------------+--------+

Переиндексировать расписание cron:

0-59/15 *  *   *   *  cd html && /usr/bin/php  /www/sites/files/html/shell/indexer.php --reindex catalog_product_price > /dev/null 2>&1
2-59/15 *  *   *   *  cd html && /usr/bin/php  /www/sites/files/html/shell/indexer.php --reindex cataloginventory_stock > /dev/null 2>&1
4-59/15 *  *   *   *  cd html && /usr/bin/php  /www/sites/files/html/shell/indexer.php --reindex catalog_product_flat > /dev/null 2>&1
6-59/15 *  *   *   *  cd html && /usr/bin/php  /www/sites/files/html/shell/indexer.php --reindex catalog_category_flat > /dev/null 2>&1
8-59/15 *  *   *   *  cd html && /usr/bin/php  /www/sites/files/html/shell/indexer.php --reindex catalog_category_product > /dev/null 2>&1
10-59/15 *  *   *   *  cd html && /usr/bin/php  /www/sites/files/html/shell/indexer.php --reindex catalog_product_attribute > /dev/null 2>&1

10 4  *   *   *    cd html && /usr/bin/php  /www/sites/files/html/shell/indexer.php --reindex catalogsearch_fulltext > /dev/null 2>&1
20 4  *   *   *    cd html && /usr/bin/php  /www/sites/files/html/shell/indexer.php --reindex ampgrid_qty_sold > /dev/null 2>&1
30 4  *   *   *    cd html && /usr/bin/php  /www/sites/files/html/shell/indexer.php --reindex awaffiliate_affiliate_balance > /dev/null 2>&1
40 4  *   *   *    cd html && /usr/bin/php  /www/sites/files/html/shell/indexer.php --reindex tag_summary > /dev/null 2>&1

50  */6   *   *  *  cd html && /usr/bin/php  /www/sites/files/html/shell/indexer.php --reindex catalog_url > /dev/null 2>&1

Индекс времени:

$ time php shell/indexer.php --reindexall
Product Attributes index was rebuilt successfully in 00:00:21
Product Prices index was rebuilt successfully in 00:00:32
Search Index index was rebuilt successfully in 00:02:31
Stock Status index was rebuilt successfully in 00:00:00
Tag Aggregation Data index was rebuilt successfully in 00:00:00
Affiliates Balance index was rebuilt successfully in 00:00:02
Catalog URL Rewrites index was rebuilt successfully in 00:10:08
Product Flat Data index was rebuilt successfully in 00:01:54
Category Flat Data index was rebuilt successfully in 00:00:04
Category Products index was rebuilt successfully in 00:00:18
Qty Sold index was rebuilt successfully in 00:00:15

real    16m9.562s
user    8m23.551s
sys     0m19.705s

Я предполагаю, что выполнение полного переиндексации обработает процесс mass_action и удалит его из таблицы. К сожалению, это не тот случай. Кто-нибудь знает, в каких условиях проясняется этот процесс?

Вы заметили время индексации на некоторых из ваших индексов? Это варьируется от секунд до в основном часов. В зависимости от того, как вы настроили свои cronjobs, ваш магазин может быть занят индексацией весь день, непрерывно. Это может быть вашей проблемой, поскольку она не может завершить индексацию или, по крайней мере, идти в ногу с ней. Постоянный доступ к заблокированному индексу может вызвать некоторые проблемы и известен такими проблемами.

Я должен сделать некоторые предположения здесь, поправьте меня, если нужно. Укажите дополнительную информацию о настройке, если вы думаете, что это может быть связано с вашей проблемой. Я работал над проектом, который должен помочь разработчикам вычистить свою core_url_rewriteтаблицу, потому что в определенных сценариях она значительно увеличивается со временем. Я думаю, что у вас тоже есть эта проблема, так как она работала почти 3 часа, и проблема, которую вы описываете, может быть связана с ней. Я вижу похожие вещи в тестовых случаях.

Ваша проблема связана только с mass_actionобъектом события? или это происходит с другими типами событий? (сохранить, удалить, переиндексировать и т. д. (Mage_Index_Model_Event)). Если нет, я бы сказал, что это связано с неправильной индексацией индексов. Учитывая тот факт, что могут быть блокировки на таблицы, которые необходимы для обработки, я не уверен в этом. Вы можете легко проверить наличие активных блокировок, используя что-то вроде:

 $indexes = Mage::getSingleton('index/indexer')->getProcessesCollection()->load();
    foreach($indexes as $index){
        if($index->isLocked(){
            echo "Index" . $index->getIndexerCode() . " with state " . $index->getStatus() . " is locked since " . $index->getStartedAt() . "!";
        }
    }

Или используйте мою суть, не забудьте удалить ее, когда вы закончите. Это не для производственного использования.

Одностраничный индекс и обзор статуса блокировки

Поэтому я думаю, что когда вы исправите время индекса, ваша проблема может исчезнуть, и магазин сможет работать более плавно. В случае core_url_rewriteтаблицы накладные расходы генерируются самим Magento в попытке получить уникальные URL-адреса, но в итоге их дублируют. Это осложняет SEO и производительность. Решение этой проблемы заключается в том, чтобы сделать URL уникальным и очистить все накладные расходы, не нанося ущерба вашим SEO-оценкам. Когда они будут чистыми, вы заметите большую разницу во времени индекса. Некоторые из моих дел снова начали генерировать файлы Sitemap через несколько месяцев.

Очистить его может быть сложно, но набор magerun, который я собрал из скриптов, которые я использовал, может помочь вам по крайней мере с таблицей перезаписи. В настоящее время это подтверждение концепции, поэтому убедитесь, что у вас есть резервные копии. Когда будет доказано что-то полезное, я восстановлю это.

Magerun связка с командами для очистки core_url_rewrite

Что касается других таблиц, я должен предположить, что есть что-то похожее, что вызывает накладные расходы, поскольку у меня нет другой информации, из которой я могу связать проблему. Возможно, вы могли бы добавить больше информации о таких вещах, как размер вашего каталога, спецификации сервера, конфигурации области хранения, все они связаны с производительностью вашего индекса. Вы также можете проверить свою таблицу, чтобы убедиться, что в ней не пропущены ограничения и т. Д.

Magento DB Repair

Есть один стековый пост, содержащий большую коллекцию информации об индексах Magento, на тот случай, если вы еще этого не видели.

Стек пост по индексам

Я надеюсь, что это имеет какое-то значение для вас, удачи

Я не знаю, если у вас все еще есть эта проблема, но это связано с тем, что вы работаете в режиме MANUAL для всех ваших индексаторов.

В Mage_Index_Model_Resource_Event у вас есть _beforeSave, который выполняет следующие действия:

/**
 * Check if semilar event exist before start saving data
 *
 * @param Mage_Core_Model_Abstract $object
 * @return Mage_Index_Model_Resource_Event
 */
protected function _beforeSave(Mage_Core_Model_Abstract $object)
{
    /**
     * Check if event already exist and merge previous data
     */
    if (!$object->getId()) {
        $select = $this->_getReadAdapter()->select()
            ->from($this->getMainTable())
            ->where('type=?', $object->getType())
            ->where('entity=?', $object->getEntity());
        if ($object->hasEntityPk()) {
            $select->where('entity_pk=?', $object->getEntityPk());
        }
        $data = $this->_getWriteAdapter()->fetchRow($select);
        if ($data) {
            $object->mergePreviousData($data);
        }
    }
    $object->cleanNewData();
    return parent::_beforeSave($object);
}

Здесь $ object-> cleanNewData () будет вызываться в Mage_Index_Model_Event:

/**
 * Clean new data, unset data for done processes
 *
 * @return Mage_Index_Model_Event
 */
public function cleanNewData()
{
    $processIds = $this->getProcessIds();
    if (!is_array($processIds) || empty($processIds)) {
        return $this;
    }

    $newData = $this->getNewData(false);
    foreach ($processIds as $processId => $processStatus) {
        if ($processStatus == Mage_Index_Model_Process::EVENT_STATUS_DONE) {
            $process = Mage::getSingleton('index/indexer')->getProcessById($processId);
            if ($process) {
                $namespace = get_class($process->getIndexer());
                if (array_key_exists($namespace, $newData)) {
                    unset($newData[$namespace]);
                }
            }
        }
    }
    $this->setNewData(serialize($newData));

    return $this;
}

Обратите внимание, что $ newData никогда не будет сброшен, если состояние Index_Process не равно Mage_Index_Model_Process :: EVENT_STATUS_DONE? Что ж, в ручном режиме для индексаторов это никогда не произойдет в регистре событий индекса.

Это связано с тем, что Mage_Index_Model_Process никогда не будет обрабатывать событие в режиме MANUAL (чего не следует) и, следовательно, никогда не установит статус Mage_Index_Model_Process :: EVENT_STATUS_DONE.

/**
 * Process event with assigned indexer object
 *
 * @param Mage_Index_Model_Event $event
 * @return Mage_Index_Model_Process
 */
public function processEvent(Mage_Index_Model_Event $event)
{
    if (!$this->matchEvent($event)) {
        return $this;
    }
    if ($this->getMode() == self::MODE_MANUAL) {
        $this->changeStatus(self::STATUS_REQUIRE_REINDEX);
        return $this;
    }

    $this->_getResource()->updateProcessStartDate($this);
    $this->_setEventNamespace($event);
    $isError = false;

    try {
        $this->getIndexer()->processEvent($event);
    } catch (Exception $e) {
        $isError = true;
    }
    $event->resetData();
    $this->_resetEventNamespace($event);
    $this->_getResource()->updateProcessEndDate($this);
    $event->addProcessId($this->getId(), $isError ? self::EVENT_STATUS_ERROR : self::EVENT_STATUS_DONE);

    return $this;
}

Если вы просто хотите уменьшить размер, вы можете либо сбросить событие, либо просто настроить индексаторы на использование режима REAL_TIME и переиндексировать все через shell / reindexer.php. В следующий раз, когда вы выполните действие, которое создаст событие индексации, старые данные будут сброшены.