proses indeks mass_action

Kami mengalami masalah yang sepertinya tidak pernah dieksekusi oleh proses indeks mass_action. Ini memiliki efek samping bahwa data pekerjaan dari pekerjaan ini tumbuh secara substansial dari waktu ke waktu.

Dalam kasus kami selama beberapa hari, data pekerjaan bertambah menjadi beberapa 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 |
+-----------------------+--------------------------------+----------+-----------------------+-----------------------+

Karena data ini tidak di-serial dan kemudian diserialisasi untuk pembaruan serta ditransfer dari dan ke server DB, pembaruan untuk entri mass_action saat ini membutuhkan sekitar 3 detik untuk diselesaikan. Ini memengaruhi kode yang memicu pembaruan indeks ini.

Seperti yang saya pahami, memicu pembaruan indeks berikut ini akan memperbarui aksi massal

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

Kami memiliki semua indeks yang diatur ke manual dan menjalankan cronjobs pada berbagai waktu dalam sehari untuk memperbarui indeks.

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

Jadwalkan ulang jadwal 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

Pengaturan waktu indeks:

$ 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

Asumsi saya adalah menjalankan indeks ulang penuh akan memproses proses mass_action dan menghapusnya dari tabel. Sayangnya ini bukan masalahnya. Adakah yang tahu kondisi apa yang menjelaskan proses itu?

Apakah Anda memperhatikan waktu indeksasi pada beberapa indeks Anda? Ini bervariasi dari detik hingga sebagian besar jam. Bergantung pada bagaimana Anda mengkonfigurasi cronjobs Anda, toko Anda mungkin sibuk mengindeks sepanjang hari, terus menerus. Ini bisa menjadi masalah Anda karena tidak dapat menyelesaikan indeksasi atau setidaknya mengikutinya. Memiliki indeks yang terkunci setiap saat dapat menyebabkan beberapa masalah dan dikenal untuk jenis masalah ini.

Saya harus membuat beberapa asumsi di sini, koreksi saya jika perlu. Tentukan beberapa informasi lebih lanjut tentang pengaturan Anda jika Anda pikir ini mungkin terkait dengan masalah Anda. Saya telah mengerjakan proyek yang seharusnya membantu pengembang membersihkan core_url_rewritemeja mereka karena itu tumbuh secara substansial dari waktu ke waktu dalam skenario tertentu. Saya pikir Anda juga mengalami masalah ini karena sudah berjalan hampir 3 jam, dan masalah yang Anda uraikan bisa terkait dengannya. Saya melihat hal-hal yang serupa pada kasus uji.

Apakah masalah Anda khusus untuk mass_actionobjek acara saja? atau apakah itu terjadi dengan jenis acara lainnya juga? (simpan, hapus, indeks ulang dll. (Mage_Index_Model_Event)). Jika tidak, saya akan mengatakan itu terkait dengan indeks yang tidak diindeks dengan benar. Mengingat fakta bahwa mungkin ada kunci di atas meja, yang diperlukan untuk diproses, saya tidak yakin akan hal ini. Anda dapat dengan mudah memeriksa kunci aktif menggunakan sesuatu seperti:

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

Atau gunakan intisari saya, jangan lupa untuk menghapusnya setelah Anda selesai. Ini bukan untuk penggunaan produksi.

Indeks satu halaman & ikhtisar status kunci

Jadi saya pikir ketika Anda memperbaiki waktu indeks Anda, masalah Anda mungkin hilang dan toko bisa berjalan lebih lancar. Dalam kasus core_url_rewritetabel, overhead dihasilkan oleh Magento sendiri dalam upaya untuk memiliki URL unik tetapi akhirnya menduplikasi mereka. Ini memiliki komplikasi di sisi SEO dan kinerja. Solusi untuk masalah ini adalah membuat URL menjadi unik dan menghapus semua biaya overhead, tanpa merusak skor SEO Anda. Saat bersih, Anda akan melihat perbedaan besar dalam waktu indeks. Beberapa kasus saya mulai menghasilkan peta situs lagi setelah berbulan-bulan.

Membersihkannya bisa rumit tetapi bundel magerun yang saya kumpulkan dari skrip yang saya gunakan dapat membantu Anda dengan setidaknya menulis ulang tabel. Saat ini merupakan bukti konsep, jadi pastikan untuk memiliki cadangan. Ketika terbukti sesuatu yang bermanfaat saya akan membangunnya kembali.

Bundel magerun dengan perintah untuk membersihkan core_url_rewrite

Adapun tabel lainnya, saya harus berasumsi bahwa ada sesuatu yang menyebabkan overhead yang sama karena saya tidak punya info lain dari mana saya bisa mengaitkan masalah. Mungkin Anda bisa menambahkan lebih banyak info tentang hal-hal seperti ukuran katalog Anda, spesifikasi server, konfigurasi lingkup toko, semuanya terkait dengan kinerja indeks Anda. Anda mungkin juga ingin memeriksa meja Anda untuk memastikan tidak ada kendala dll.

Perbaikan Magento DB

Ada satu tumpukan posting yang berisi koleksi besar informasi tentang indeks Magento, kalau-kalau Anda belum melihatnya.

Stack post pada indeks

Saya harap ini bermanfaat bagi Anda, semoga sukses

Saya tidak tahu apakah Anda masih memiliki masalah ini, tetapi itu berkaitan dengan Anda menjalankan dalam mode MANUAL untuk semua pengindeks Anda.

Di Mage_Index_Model_Resource_Event Anda memiliki _beforeSave yang melakukan hal berikut:

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

Di sini $ object-> cleanNewData () akan memanggil 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;
}

Perhatikan bahwa $ newData tidak akan pernah diatur ulang jika status Index_Process tidak sama dengan Mage_Index_Model_Process :: EVENT_STATUS_DONE? Nah, dalam mode MANUAL untuk Pengindeks ini tidak akan pernah terjadi pada Daftar Acara Indeks.

Ini karena Mage_Index_Model_Process tidak akan pernah memproses Acara dalam mode MANUAL (yang seharusnya tidak dilakukan) dan karenanya tidak akan pernah mengatur status ke 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;
}

Jika Anda hanya ingin menurunkan ukurannya maka Anda dapat mengatur ulang acara atau hanya mengatur Pengindeks untuk menggunakan mode REAL_TIME dan indeks ulang semua melalui shell / reindexer.php. Lain kali Anda membuat tindakan yang membuat acara pengindeksan, data lama akan tidak disetel.