Les notifications Laravel mises en file d'attente restent bloquées sur AWS SQS

Quelle est la limite de mémoire actuelle attribuée à PHP? Vous pouvez le déterminer en exécutant cette commande:

php -i | grep php.ini

Vous pouvez augmenter cela en exécutant quelque chose comme:

sed -i -e 's/memory_limit = [current-limit]/memory_limit = [new-limit]/g' [full-path-to-php-ini]

Remplacez simplement [current-limit] par la valeur affichée dans la première commande et [new-limit] par une nouvelle valeur raisonnable. Cela peut nécessiter des essais et des erreurs. Remplacez [full-path-to-php-ini] par le chemin complet du php.ini utilisé par le processus qui échoue. Pour le trouver, exécutez:

php -i | grep memory_limit

Assurez-vous d'abord que vous avez augmenté max_execution_time et aussi memory_limit
Assurez-vous également que vous définissez l'option --timeout
Ensuite, assurez-vous de suivre les instructions pour Amazon SQS comme indiqué dans laravel doc

La seule connexion de file d'attente qui ne contient pas de valeur retry_after est Amazon SQS. SQS relancera la tâche en fonction du délai d'expiration de la visibilité par défaut qui est géré dans la console AWS.

Expirations et délais de travail

Si vous êtes sûr que certains des événements mis en file d'attente sont correctement reçus et traités par le worker Laravel, alors comme d'autres l'ont dit, il s'agit principalement d'un problème de mémoire PHP.

Sur beanstalk, voici ce que j'ai ajouté à mes ebextensions pour obtenir une plus grande mémoire pour PHP (c'était pour les problèmes de mémoire du compositeur):

Notez qu'il s'agit d'une instance t3.medium EC2 avec 4go, dédiée à l'API laravel uniquement.

02-environment.config
commands:
   ...

option_settings:
  ...

  - namespace: aws:elasticbeanstalk:container:php:phpini
    option_name: memory_limit
    value: 4096M
    
  - namespace: aws:ec2:instances
    option_name: InstanceTypes
    value: t3.medium

Vous pouvez donc essayer d'augmenter la limite en utilisant davantage de RAM max d'instance disponible, et déployer à nouveau afin que beanstalk reconstruise l'instance et configure PHP memory_limit .

Remarque: la configuration réelle contient d'autres fichiers de configuration et bien sûr des contenus plus tronqués.

Comme vous l'avez dit, vous envoyez juste un e-mail, donc ça devrait aller. Cela se produit-il lorsqu'il y a une rafale d'e-mails en file d'attente? Y a-t-il, à la fin, de nombreux événements dans le deadLetterQueue SQS? Si tel est le cas, cela peut être dû à une rafale d'e-mails en file d'attente. Ainsi, SQS "inondera" la route / worker pour exécuter vos travaux. Vous pouvez vérifier l'utilisation du serveur à partir de la console AWS, ou htop comme les outils CLI à surveiller, et également vérifier l'interface SQS pour voir si de nombreux travaux ayant échoué arrivent au même moment (rafale).

Edit: pour le beanstalk élastique, j'utilise dusterio / laravel-aws-worker , peut-être vous aussi car votre journal mentionne la route /worker/queue

Mémoire

La quantité de mémoire par défaut allouée à PHP peut souvent être assez petite. Lorsque vous utilisez EBS, vous voulez utiliser les fichiers de configuration autant que possible - chaque fois que vous devez SSH et changer des choses sur le serveur, vous allez avoir plus de problèmes lorsque vous devez redéployer. J'ai ceci ajouté à ma configuration EBS /.ebextensions/01-php-settings.config :

class LongRunningJob implements ShouldQueue
{
    use CanExtendSqsVisibilityTimeout;

    //...

    public function handle()
    {
        // some other processing, no loops involved

        // now the code that loops!
        $last_extend_at = time();
        foreach ($tasks as $task) {
            $task->doingSomething();

            // make sure the processing doesn't time out, but don't extend time too often
            if ($last_extend_at + $this->defaultBackoff - 10 > time()) {
                // "heartbeat" to extend visibility timeout
                $this->extendBackoff();
                $last_extend_at = time();
            }
        }
}

Cela a suffi lors de l'exécution d'un t3.micro pour faire tout mon traitement de notification et d'importation. Pour un traitement simple, il n'a généralement pas besoin de beaucoup plus de mémoire que la mémoire par défaut, mais cela dépend un peu de votre cas d'utilisation et de la façon dont vous avez programmé vos notifications.

Temps libre

Comme indiqué dans cette réponse , la file d'attente SQS fonctionne un peu différemment en ce qui concerne les délais d'expiration. Voici un petit trait que j'ai écrit pour aider à contourner ce problème:

<?php

namespace App\Jobs\Traits;

trait CanExtendSqsVisibilityTimeout
{
    /** NOTE: this needs to map to setting in AWS console */
    protected $defaultBackoff = 30;

    protected $backoff = 30;

    /**
     * Extend the time that the job is locked for processing
     *
     * SQS messages are managed via the default visibility timeout console setting; noted absence of retry_after config
     * @see https://laravel.com/docs/7.x/queues#job-expirations-and-timeouts
     * AWS recommends to create a "heartbeat" in the consumer process in order to extend processing time:
     * @see https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html#configuring-visibility-timeout
     *
     * @param int $delay  Number of seconds to extend the processing time by
     *
     * @return void
     */
    public function extendBackoff($delay = 60)
    {
        if ($this->job) {
            // VisibilityTimeout has a 12 hour (43200s) maximum and will error above that; no extensions if close to it
            if ($this->backoff + $delay > 42300) {
                return;
            }
            // add the delay
            $this->backoff += $delay;
            $sqs = $this->job->getSqs();
            $sqsJob = $this->job->getSqsJob();
            $sqs->changeMessageVisibility([
                'QueueUrl' => $this->job->getQueue(),
                'ReceiptHandle' => $sqsJob['ReceiptHandle'],
                'VisibilityTimeout' => $this->backoff,
            ]);
        }
    }
}

Ensuite, pour un travail en file d'attente qui prenait beaucoup de temps, j'ai changé un peu le code pour trouver où je pourrais insérer un «battement de cœur» sensible. Dans mon cas, j'avais une boucle:

option_settings:
  aws:elasticbeanstalk:container:php:phpini:
    memory_limit: 256M

Superviseur

Il semble que vous deviez peut-être examiner de manière un peu plus détaillée la manière dont vous exécutez vos collaborateurs.

Faire fonctionner Supervisor pour aider à redémarrer vos travailleurs est un must, je pense. Sinon, si le ou les travailleurs cessent de fonctionner, les messages mis en file d'attente finiront par être supprimés à leur expiration. C'est un peu compliqué de bien travailler avec Laravel + EBS - il n'y a pas vraiment beaucoup de bonne documentation autour de cela, c'est pourquoi ne pas avoir à le gérer est l'un des arguments de vente de Vapor!

Nous avons finalement découvert quel était le problème, et ce n'était ni la mémoire ni le temps d'exécution.

Dès le début, je trouvais étrange que la mémoire par défaut ou le temps d'exécution par défaut ne suffisent pas pour envoyer un e-mail ou deux.

Notre cas d'utilisation est le suivant: un nouvel Article est créé et les utilisateurs reçoivent une notification.

Quelques indices qui ont conduit à la solution:

• Nous avons remarqué que nous avons généralement des problèmes avec la première notification.
• Si nous créons 10 articles en même temps, nous manquons la première notification sur chaque article.
• Nous avons défini les connexions HTTP Max dans le Worker sur 1. Lors de la création simultanée de 10 articles, nous avons remarqué que seul le premier article manquait la première notification.
• Nous n'avons pas reçu de messages d'erreur utiles du Worker, nous avons donc décidé de configurer notre propre EC2 et d'exécuter manuellement la php artisan queue .

Ce que nous avons ensuite vu a tout expliqué: Illuminate\Database\Eloquent\ModelNotFoundException: No query results for model [App\Article]

Il s'agit d'une erreur que nous n'avons jamais reçue de EBS Worker / SQS et qui a rapidement conduit à la solution:

La notification est traitée avant que l'article n'atteigne la base de données.

Nous avons ajouté un délai au travailleur et n'avons pas eu de problème depuis. Nous avons récemment ajouté une transaction de base de données au processus de création d'un article, et la création de la notification se produit dans cette transaction (mais à la toute fin). Je pense que c'est pourquoi nous n'avons pas eu ce problème avant. Nous avons décidé de laisser la création de la notification dans la transaction et de gérer simplement les notifications avec un délai. Cela signifie que nous n'avons pas besoin de faire un correctif pour résoudre ce problème.

Merci à tous ceux qui se sont joints pour aider!