processo di indice mass_action

Stiamo riscontrando il problema che il processo dell'indice mass_action non sembra mai eseguire. Ciò ha l'effetto collaterale che i dati di questo lavoro crescono sostanzialmente nel tempo.

Nel nostro caso nel corso di diversi giorni i dati del lavoro aumentano a diversi 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 |
+-----------------------+--------------------------------+----------+-----------------------+-----------------------+

Dato che questi dati non sono serializzati e quindi serializzati per un aggiornamento, nonché trasferiti da e verso il server DB, un aggiornamento alla voce mass_action richiede attualmente circa 3 secondi per essere completato. Ciò influisce sul codice che attiva un aggiornamento di questo indice.

A quanto ho capito, l'attivazione di un aggiornamento dei seguenti indici aggiornerà l'azione di massa

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

Abbiamo tutti gli indici impostati su manuali ed eseguiamo cronjobs in varie ore del giorno per aggiornare gli indici.

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

Reindicizza la pianificazione 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

Tempi dell'indice:

$ 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

La mia ipotesi è che l'esecuzione di un re-indice completo elaborerebbe il processo mass_action e lo cancellerebbe dalla tabella. Sfortunatamente non è così. Qualcuno sa quali sono le condizioni che chiariscono quel processo?

Hai notato il tempo di indicizzazione su alcuni dei tuoi indici? Varia dai secondi alle prevalentemente ore. A seconda di come hai configurato i tuoi cronjob, il tuo negozio potrebbe essere occupato a indicizzare tutto il giorno, continuamente. Questo potrebbe essere il tuo problema in quanto non è in grado di terminare le indicizzazioni o almeno di tenerne il passo. Avere un indice bloccato in ogni momento potrebbe causare qualche problema ed è noto per questo tipo di problemi.

Devo fare alcune ipotesi qui, correggermi se necessario. Specificare alcune ulteriori informazioni sulla configurazione se si ritiene che ciò possa essere correlato al problema. Ho lavorato su un progetto che dovrebbe aiutare gli sviluppatori a ripulire il loro core_url_rewritetavolo perché cresce sostanzialmente nel tempo in determinati scenari. Penso che anche il tuo abbia questo problema poiché è durato per quasi 3 ore e il problema che descrivi potrebbe essere correlato ad esso. Vedo cose simili in casi di test.

Il tuo problema è specifico solo mass_actiondell'oggetto dell'evento? o succede anche con altri tipi di eventi? (salva, elimina, reindicizza ecc. (Mage_Index_Model_Event)). In caso contrario, direi che è correlato agli indici che non vengono indicizzati correttamente. Dato che potrebbero esserci dei blocchi sui tavoli, necessari per l'elaborazione, non ne sono sicuro. Puoi facilmente verificare i blocchi attivi usando qualcosa come:

 $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() . "!";
        }
    }

O usa la mia sostanza, non dimenticare di rimuoverlo quando hai finito. Non è per l'utilizzo in produzione.

Indice di una pagina e panoramica dello stato di blocco

Quindi penso che quando si correggono i tempi dell'indice, il problema potrebbe scomparire e il negozio potrebbe funzionare in modo più fluido. Nel caso della core_url_rewritetabella, l'overhead viene generato dallo stesso Magento nel tentativo di avere URL univoci ma finisce per duplicarli. Ciò ha complicazioni dal punto di vista SEO e prestazionale. La soluzione a questo problema è rendere unico l'URL e cancellare tutto il sovraccarico, senza danneggiare i punteggi SEO. Quando sono puliti, noterai una grande differenza nei tempi dell'indice. Alcuni dei miei casi hanno iniziato a generare di nuovo sitemap dopo mesi.

Pulirlo può essere complicato, ma il pacchetto magerun che ho creato dagli script che ho usato può aiutarti con almeno la tabella di riscrittura. Attualmente è una prova di concetto, quindi assicurati di avere dei backup. Quando sarà dimostrato qualcosa di utile, lo ricostruirò.

Bundle Magerun con comandi per la pulizia di core_url_rewrite

Per quanto riguarda le altre tabelle, devo presumere che ci sia qualcosa di simile che causa un sovraccarico poiché non ho altre informazioni da cui posso riferire un problema. Forse potresti aggiungere qualche informazione in più su cose come le dimensioni del tuo catalogo, le specifiche del server, le configurazioni dell'ambito del negozio, sono tutte legate alle prestazioni del tuo indice. Potresti anche voler controllare la tua tabella per assicurarti che non manchino vincoli ecc.

Riparazione Magento DB

C'è un post dello stack che contiene una grande raccolta di informazioni sugli indici di Magento, nel caso in cui non l'avessi già visto.

Stack post su indici

Spero che questo abbia qualche valore per te, buona fortuna

Non so se hai ancora questo problema, ma ha a che fare con la tua esecuzione in modalità MANUALE per tutti i tuoi indicizzatori.

In Mage_Index_Model_Resource_Event hai un _beforeSave che effettua le seguenti operazioni:

/**
 * 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);
}

Qui $ object-> cleanNewData () invocherà in 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;
}

Notare che $ newData non verrà mai ripristinato se lo stato Index_Process non è uguale a Mage_Index_Model_Process :: EVENT_STATUS_DONE? Bene, in modalità MANUALE per gli indicizzatori ciò non accadrà mai nel registro degli eventi dell'indice.

Questo perché Mage_Index_Model_Process non elaborerà mai l'evento in modalità MANUALE (cosa che non dovrebbe) e quindi non imposterà mai lo stato su 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;
}

Se vuoi solo ridurre le dimensioni, puoi reimpostare l'evento o semplicemente impostare gli indicizzatori per utilizzare la modalità REAL_TIME e reindicizzare tutto tramite shell / reindexer.php. La prossima volta che si esegue un'azione che crea un evento di indicizzazione, i vecchi dati non verranno impostati.