mass_actionインデックスプロセス

mass_actionインデックスプロセスが実行されないように見えるという問題があります。これには、このジョブのジョブデータが時間とともに大幅に増加するという副作用があります。

私たちの場合、数日の間にジョブデータは数MBに増加します。

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 |
+-----------------------+--------------------------------+----------+-----------------------+-----------------------+

このデータはシリアル化解除されてから更新のためにシリアル化され、DBサーバーとの間で転送されるため、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プロセスが処理され、テーブルから消去されます。残念ながらそうではありません。誰がそのプロセスをクリアする条件が何であるか知っていますか？

一部のインデックスのインデックス作成時間に気付きましたか？それは、数秒からほとんどの時間まで変化します。cronジョブの構成方法によっては、ストアが1日中連続してインデックスを作成している可能性があります。これは、索引付けを完了できないか、少なくともそれに対応できないため、問題になる可能性があります。インデックスが常にロックされていると、問題が発生する可能性があり、この種の問題で知られています。

ここでいくつかの仮定をしなければなりません。必要に応じて修正してください。これが問題に関連していると思われる場合は、セットアップに関する詳細情報を指定してください。私は開発者が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() . "!";
        }
    }

または、私の要点を使用して、完了したらそれを削除することを忘れないでください。本番用ではありません。

1ページのインデックスとロックステータスの概要

したがって、インデックス時間を修正すると、問題が解消され、ストアがよりスムーズに実行されるようになると思います。core_url_rewriteテーブルの場合、オーバーヘッドはMagento自体によって生成され、一意のURLを作成しようとしますが、結果として重複します。これは、SEOとパフォーマンスの面で複雑になります。この問題の解決策は、SEOスコアを損なうことなく、URLを一意にし、すべてのオーバーヘッドを取り除くことです。それらがクリーンな場合、インデックス時間に大きな違いがあることに気付くでしょう。私のケースのいくつかは、数ヶ月後に再びサイトマップを生成し始めました。

クリーンアップは難しいかもしれませんが、私が使用したスクリプトからまとめたmagerunバンドルは、少なくとも書き換えテーブルで役立ちます。現在、これは概念実証であるため、必ずバックアップを作成してください。それが何か有用であることが証明されたら、私はそれを再構築します。

core_url_rewriteをクリーニングするコマンドを含むMagerunバンドル

他のテーブルについては、問題を関連付けることができる他の情報がないため、オーバーヘッドを引き起こす同様の何かがあると想定する必要があります。おそらく、カタログのサイズ、サーバーの仕様、ストアスコープの構成などの情報を追加できます。これらはすべて、インデックスのパフォーマンスに関連しています。また、テーブルをチェックして、制約などが欠落していないことを確認することもできます。

Magento DBの修復

Magentoのインデックスに関するすばらしい情報を含むスタックポストが1つあります。

インデックスにスタックポスト

これがあなたにとってどんな価値でもあることを願っています

それでもこの問題が発生するかどうかはわかりませんが、すべてのインデクサーを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;
}

Index_ProcessステータスがMage_Index_Model_Process :: EVENT_STATUS_DONEと等しくない場合、$ newDataは決してリセットされないことに注意してください。まあ、インデクサーの手動モードでは、これはインデックスイベントレジスターでは発生しません。

これは、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を介してすべてのインデックスを再作成します。次にインデックス作成イベントを作成するアクションを実行すると、古いデータは設定解除されます。