# Import / Speicher Fresser

**URL:** https://forum.shopware.com/t/import-speicher-fresser/65363
**Category:** Programmierung
**Created:** [9. März 2020 um 15:55 UTC](https://forum.shopware.com/t/import-speicher-fresser/65363 "2020-03-09T15:55:12Z")
**Posts on this page:** 1
**Showing post:** 19

<div class="post-metadata">

### Author: ![dweseom](https://avatars.discourse-cdn.com/v4/letter/d/e56c9b/32.png) [@dweseom](https://forum.shopware.com/u/dweseom)
#### Post date: [16. März 2022 um 07:44 UTC](https://forum.shopware.com/t/import-speicher-fresser/65363/19 "2022-03-16T07:44:13Z")

</div>

@dominikmank  
OK ist ja schon einmal schön, dass Shopware da dran arbeitet allerdings bringt die asynchrone Lösung einem größeren B2B-Shop überhaupt nichts - wenn dieser ständig mit SAP kommuniziert und ein Produkt 1,5GB Speicher frisst, brauchen wir bei 5000 Produkten ja Arbeitsspeicher im TB Bereich - ich bin wirklich großer Fan von SW6 aber an den Insert/Update/Upsert/Delete Befehlen ist noch viel Arbeit reinzustecken bevor größere Kunden damit arbeiten können.  
Generell führt der memory-Fresser dazu, dass es auch im Backend zu Fehlern beim Speichern/Löschen/Hinzufügen von Artikeln mit vielen Varianten kommt.  
Zum Beispiel sowas:

```auto
php.CRITICAL: Fatal Error: Out of memory (allocated 824180736) (tried to allocate 663552 bytes) {"exception":"[object] (Symfony\Component\ErrorHandler\Error\OutOfMemoryError(code: 0): Error: Out of memory (allocated 824180736) (tried to allocate 663552 bytes) at /home/meinedomain.com/apitest/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOStatement.php:262)"} [] [2022-01-10T12:33:26.426271+00:00] request.CRITICAL: Uncaught PHP Exception Symfony\Component\ErrorHandler\Error\OutOfMemoryError: "Error: Out of memory (allocated 824180736) (tried to allocate 663552 bytes)" at /home/meinedomain.com/apitest/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOStatement.php line 262 {"exception":"[object] (Symfony\Component\ErrorHandler\Error\OutOfMemoryError(code: 0): Error: Out of memory (allocated 824180736) (tried to allocate 663552 bytes) at /home/meinedomain.com/apitest/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOStatement.php:262)"} []
 https://meinedomain.com/api/_action/sync Payload: {key: "write", action: "upsert", entity: "product",…} action: "upsert" entity: "product" key: "write" payload: [{id: "c1000001070000000000000000086388", versionId: "0fa91ce3e96a4bc2be4bd9ce752c3425",…}] 0: {id: "c1000001070000000000000000086388", versionId: "0fa91ce3e96a4bc2be4bd9ce752c3425",…} description: "22x28cms" id: "c1000001070000000000000000086388" versionId: "0fa91ce3e96a4bc2be4bd9ce752c3425"

```

Wir sind jetzt bei 32 GB Arbeitsspeicher und es reicht immer noch nicht, um ein simples Update-Statement auszuführen für ein Lagerbestandsupdate.

Edit:  
Noch einmal um klar zu stellen, in welchen Dimensionen wir hier sprechen - ich habe soeben versucht ein Produkt mit 625 Varianten zu aktualisieren - also lediglich das:

```auto
$productData = [
                    'id' => $product->getId(),
                    'stock' => $stock,
                    'deliveryTimeId' => $deliveryTimeId,
                    'restockTime' => $restockTime
 ];

```

Für eine Variante hat es 1,3GB benötigt:  
ProductNumber: CGP9128234  
1028.5 megabytes  
2330.5 megabytes after productRepository-\>upsert

Es scheint so, als ob ein Update der anderen Varianten des Artikels dann keine gravierenden Folgen für den Arbeitsspeicher haben (da diese vermutlich durch ein Update der einen Variante bereits vorgemerkt für das Indexing sind)

Wenn ich aber 50 dieser Produkte mit einer Anzahl von 600+ Varianten habe, benötige ich mindestens 50\*1,3GB = **65GB** für das Lagerbestandsupdate von 5000 Produkten

Hinzu kommt, dass der Lagerbestand bei zwei unserer B2B-Kunden alle 30 Minuten aktualisiert werden müsste - hier könnte noch über 1 Stunde verhandelt werden - ist momentan unmöglich mit SW6

@Moritz_Naczenski  
Habt ihr ein Testsystem mit einer solchen Anzahl an Produkten und vor allem Produkten mit vielen Varianten (500+)? Ansonsten kann ich euch gerne eines von uns bereitstellen.

@dominikmank  
Vielen Dank für den Tipp.  
Ich habe jetzt die einzelnen Methoden einmal auskommentiert und es liegt definitiv an dieser Zeile:

> <https://github.com/shopware/platform/blob/trunk/src/Core/Content/Product/DataAbstractionLayer/ProductIndexer.php#L203>

```auto
if ($message->allow(self::SEARCH_KEYWORD_UPDATER)) {
                //$this->searchKeywordUpdater->update(array_merge($ids, $childrenIds), $context);
            }

```

Wenn ich diesen auskommentiere, kommt der gesamte Import mit 300MB RAM klar!

Ich habe das wieder aktiviert und bin ich die Datei [platform/SearchKeywordUpdater.php at eb827637a1bb6edd35487dfe59b2b761dcccf685 · shopware/platform · GitHub](https://github.com/shopware/platform/blob/eb827637a1bb6edd35487dfe59b2b761dcccf685/src/Core/Content/Product/DataAbstractionLayer/SearchKeywordUpdater.php)

Hier liegt das Problem am Iterator:

```auto
while ($products = $iterator->fetch()) {
            /** @var ProductEntity $product */
            foreach ($products as $product) {
                // overwrite fetched products if translations for that product exists
                // otherwise we use the already fetched product from the parent language
                $existingProducts[$product->getId()] = $product;
            }
        }

```

Bei diesen Zeilen wächst der RAM.  
Weiter geht es mit der Datei:

> <https://github.com/shopware/platform/blob/18004f806aec24c52c8ea2996b8afe371544848e/src/Core/Framework/DataAbstractionLayer/Dbal/Common/RepositoryIterator.php>

```auto
$result = $this->repository->search(clone $this->criteria, $this->context);

```

Und hier ist dann die nächste Ebene des Problems.

Damit landen wir dann hier:

> <https://github.com/shopware/platform/blob/18004f806aec24c52c8ea2996b8afe371544848e/src/Core/Framework/DataAbstractionLayer/EntityRepository.php>

796.5 megabytes repo search before → RepositoryIterator.php  
796.5 megabytes → EntityRepository.php  
Dispatched EventName product.search.result.loaded → EntityRepository.php  
830.5 megabytes after 3 → EntityRepository.php  
830.5 megabytes repo search after → RepositoryIterator.php

→ könnte also irgendein Problem beim Event „product.search.result.loaded“ sein?

EntityRepository.php:

```auto
public function upsert(array $data, Context $context): EntityWrittenContainerEvent
    {
        $affected = $this->versionManager->upsert($this->definition, $data, WriteContext::createFromContext($context));
        $event = EntityWrittenContainerEvent::createWithWrittenEvents($affected, $context, []);
        $this->eventDispatcher->dispatch($event);

        return $event;
    }

```

Ohne $this-\>eventDispatcher-\>dispatch($event); keine memory Probleme.  
Gleiche Probleme auch bei den Event dispatchern in den Methoden update(), create() - delete() vemutlich auch aber habe ich nicht getestet.

---

_[View the full topic](https://forum.shopware.com/t/import-speicher-fresser/65363)._
