Paperclip Nginx 504 Gateway Time-out

Question

J'ai une application Rails 4 qui permet de télécharger des vidéos en utilisant le plugin jQuery Dropzone et la gemme trombone. Chaque vidéo mise en ligne est encodée en plusieurs formats et téléchargée en arrière-plan sur Amazon S3 à l'aide des gemmes delayed_paperclip, av-transcoder et sidekiq.

Tout fonctionne correctement avec la plupart des vidéos, mais avec une taille plus élevée de 1,1 Go après que le téléchargement atteigne la fin de la barre de progression du plugin dropzone, il renvoie un délai d'attente de la passerelle Nginx 504.

En ce qui concerne le serveur, l'application rails est exécutée sur Nginx + Passenger sur deux serveurs qui se trouvent derrière un équilibreur de charge (Nginx utilisé ici aussi). Je n'ai pas de délais d'attente définis dans la section amont de l'équilibreur de charge, le client_max_body_size est réglé sur 2000M (à la fois sur l'équilibreur de charge et les serveurs), j'ai essayé de définir passenger_pool_idle_time sur une valeur élevée (600), cela n'a pas aidé , J'ai également essayé de mettre send_timeout (600s), rien n'a fait de différence.

Remarque: Lors de ces modifications, je les ai effectuées sur les fichiers hôte des deux serveurs ainsi que sur l'équilibreur de charge et j'ai toujours redémarré nginx par la suite.

J'ai lu aussi plusieurs réponses concernant des problèmes similaires comme this one et this one mais je n'arrive toujours pas à comprendre cela, google n'était pas beaucoup plus utile non plus.

Quelques notes supplémentaires pour ceux qui ne connaissent pas l'ensemble du processus paperclip/delayed_paperclip, le fichier est téléchargé sur le serveur puis l'opération est effectuée pour l'utilisateur, en arrière-plan le post-traitement des vidéos (encodage/uploading to S3) est envoyé à Redis en tant que travail et Sidekiq le traite chaque fois qu'il dispose de temps/ressources.

Ce qui pourrait être à l'origine de ce problème? Comment puis-je déboguer cela et le résoudre?

MISE À JOUR

Merci à la réponse de Sergey j'ai pu résoudre le problème. Comme je me limitais à une version spécifique de Paperclip, je ne pouvais pas la mettre à jour avec la nouvelle version qui a le correctif, donc je vais laisser ici ce que j'ai fini par faire.

Dans le moteur que je l'utilise pour gérer les ajouts que j'ai ajouté le code suivant dans le fichier engine_name.rb pour remplacer les méthodes de Paperclip qui avaient besoin de fixation:

Paperclip::AbstractAdapter.class_eval do 
    def copy_to_tempfile(src) 
     link_or_copy_file(src.path, destination.path) 
     destination 
    end 

    def link_or_copy_file(src, dest) 
     Paperclip.log("Trying to link #{src} to #{dest}") 
     FileUtils.ln(src, dest, force: true) # overwrite existing 
     @destination.close 
     @destination.open.binmode 
    rescue Errno::EXDEV, Errno::EPERM, Errno::ENOENT => e 
     Paperclip.log("Link failed with #{e.message}; copying link #{src} to #{dest}") 
     FileUtils.cp(src, dest) 
    end 
    end 

    Paperclip::AttachmentAdapter.class_eval do 
    def copy_to_tempfile(source) 
     if source.staged? 
     link_or_copy_file(source.staged_path(@style), destination.path) 
     else 
     source.copy_to_local_file(@style, destination.path) 
     end 
     destination 
    end 
    end 

    Paperclip::Storage::Filesystem.class_eval do 
    def flush_writes #:nodoc: 
     @queued_for_write.each do |style_name, file| 
     FileUtils.mkdir_p(File.dirname(path(style_name))) 
     begin 
      move_file(file.path, path(style_name)) 
     rescue SystemCallError 
      File.open(path(style_name), "wb") do |new_file| 
      while chunk = file.read(16 * 1024) 
       new_file.write(chunk) 
      end 
      end 
     end 
     unless @options[:override_file_permissions] == false 
      resolved_chmod = (@options[:override_file_permissions] &~ 0111) || (0666 &~ File.umask) 
      FileUtils.chmod(resolved_chmod, path(style_name)) 
     end 
     file.rewind 
     end 

     after_flush_writes # allows attachment to clean up temp files 

     @queued_for_write = {} 
    end 

    private 

    def move_file(src, dest) 
     # Support hardlinked files 
     if File.identical?(src, dest) 
     File.unlink(src) 
     else 
     FileUtils.mv(src, dest) 
     end 
    end 

    end 

Answer 1

Je fait face à la même question il y a un certain temps. Peut-être, mon expérience aidera.

Nous avions m3.medium instance sur Amazon avec 4 Go de mémoire. L'utilisateur pourrait télécharger de gros fichiers vidéo. Nous avons rencontré un problème d'erreur 504 lors du téléchargement de fichiers supérieurs à 400 Mo.

Lors de la surveillance et de la consignation du processus de téléchargement, il est apparu que Paperclip crée 4 fichiers par pièce jointe et que toutes les ressources d'instance fonctionnent donc sur un système de fichiers. Ici, il y a une description de ce problème

https://github.com/thoughtbot/paperclip/issues/1642

et a proposé une solution - utiliser des liens plutôt que des fichiers lorsque cela est possible.Vous pouvez voir le code approprié change ici

https://github.com/arnonhongklay/paperclip/commit/cd80661df18d7cd112944bfe26d90cb87c928aad

Cependant il y a 2 jours Paperclip a été mis à jour pour la version 5.2.0 et ils ont mis en œuvre une solution similaire. Donc, pour l'instant, il ne crée qu'un fichier par pièce jointe. Ainsi, notre système de fichiers n'est pas surchargé et après la mise à jour vers la version 5.2.0, nous avons cessé de recevoir l'erreur 504.

Conclusion:

1. Utiliser patch singe à partir du lien ci-joint ci-dessus si vous êtes limité dans la version Paperclip pour une raison
2. Mise à jour Paperclip à la version 5.2.0. Devrait aider. Juste pour essayer de sortir de l'équation.