gitlab lent lors de l'exécution sur le sous-domaine nginx

10

J'essaie d'exécuter gitlab sur un sous-domaine. J'ai installé la dernière version de gitlab à l'aide du programme d'installation omnibus sur mon vserver (exécutant Ubuntu 14.04.1) et désactivé le nginx groupé et configuré le nginx dégroupé avec la configuration publiée ici Comment configurer un sous-domaine sur nginx?

/ etc / nginx / sites-available / gitlab

upstream gitlab {
    server unix:/home/git/gitlab/tmp/sockets/gitlab.socket;
}

server {
listen 80 default_server;         # e.g., listen 192.168.1.1:80; In most cases *:80 is a good idea
server_name git.domain.com;     # e.g., server_name source.example.com;
server_tokens off;     # don't show the version number, a security best practice
root /home/git/gitlab/public;
client_max_body_size 500m;

# individual nginx logs for this gitlab vhost
access_log  /var/log/nginx/gitlab_access.log;
error_log   /var/log/nginx/gitlab_error.log;

location / {
  # serve static files from defined root folder;.
  # @gitlab is a named location for the upstream fallback, see below
  try_files $uri $uri/index.html $uri.html @gitlab;
}

# if a file, which is not found in the root folder is requested,
# then the proxy pass the request to the upsteam (gitlab unicorn)
location @gitlab {
  proxy_read_timeout 300; # https://github.com/gitlabhq/gitlabhq/issues/694
  proxy_connect_timeout 300; # https://github.com/gitlabhq/gitlabhq/issues/694
  proxy_redirect     off;

  proxy_set_header   X-Forwarded-Proto $scheme;
  proxy_set_header   Host              $http_host;
  proxy_set_header   X-Real-IP         $remote_addr;

  proxy_pass http://gitlab;
}

Je peux visiter la page, mais il faut 30 secondes et plus pour charger la page. Cela ne prend pas si longtemps lorsque j'utilise le serveur nginx fourni, donc je ne pense pas que ce soit un problème de mémoire (et freeme dit que 1,4 Go sont disponibles)

Le journal des erreurs me dit quelque chose comme ceci:

/var/log/nginx/gitlab_error.log

server: git.mydomain.de, request: "GET /assets/application-c4186ca579dd09b3e48eaf1b5a3e4434.js HTTP/1.1", upstream: "http://unix:/var/opt/gitlab/gitlab-rails/sockets/gitlab.socket:/assets/application-c4186ca579dd09b3e48eaf1b5a3e4434.js"

Merci beaucoup pour votre aide!

smoking
la source
Avez-vous déjà compris cela? Je fais face à ce même problème en ce moment.
Vidur

Réponses:

1

Mise à jour : la mise à niveau vers Gitlab 8.x a résolu ce problème pour moi


Réponse originale :

J'ai eu ce même problème et l'ai résolu en copiant directement la configuration nginx générée à partir de l'installation de gitlab dans mon répertoire de configuration nginx.

J'ai trouvé ma configuration gitlab nginx sur: /var/opt/gitlab/nginx/conf/gitlab-http.conf

Le coller ici pour la postérité:

# This file is managed by gitlab-ctl. Manual changes will be
# erased! To change the contents below, edit /etc/gitlab/gitlab.rb
# and run `sudo gitlab-ctl reconfigure`.

## GitLab
## Contributors: randx, yin8086, sashkab, orkoden, axilleas, bbodenmiller
##
## Modified from https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/support/nginx/gitlab-ssl & https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/support/nginx/gitlab
##
## Lines starting with two hashes (##) are comments with information.
## Lines starting with one hash (#) are configuration parameters that can be uncommented.
##
##################################
##        CHUNKED TRANSFER      ##
##################################
##
## It is a known issue that Git-over-HTTP requires chunked transfer encoding [0]
## which is not supported by Nginx < 1.3.9 [1]. As a result, pushing a large object
## with Git (i.e. a single large file) can lead to a 411 error. In theory you can get
## around this by tweaking this configuration file and either:
## - installing an old version of Nginx with the chunkin module [2] compiled in, or
## - using a newer version of Nginx.
##
## At the time of writing we do not know if either of these theoretical solutions works.
## As a workaround users can use Git over SSH to push large files.
##
## [0] https://git.kernel.org/cgit/git/git.git/tree/Documentation/technical/http-protocol.txt#n99
## [1] https://github.com/agentzh/chunkin-nginx-module#status
## [2] https://github.com/agentzh/chunkin-nginx-module
##
###################################
##         configuration         ##
###################################

upstream gitlab {
  server unix:/var/opt/gitlab/gitlab-rails/sockets/gitlab.socket fail_timeout=0;
}


server {
  listen *:80;
  server_name git.mydomain.com;
  server_tokens off; ## Don't show the nginx version number, a security best practice
  root /opt/gitlab/embedded/service/gitlab-rails/public;

  ## Increase this if you want to upload large attachments
  ## Or if you want to accept large git objects over http
  client_max_body_size 250m;


  ## Individual nginx logs for this GitLab vhost
  access_log  /var/log/gitlab/nginx/gitlab_access.log;
  error_log   /var/log/gitlab/nginx/gitlab_error.log;

  location / {
    ## Serve static files from defined root folder.
    ## @gitlab is a named location for the upstream fallback, see below.
    try_files $uri $uri/index.html $uri.html @gitlab;
  }

  location /uploads/ {
    ## If you use HTTPS make sure you disable gzip compression
    ## to be safe against BREACH attack.
    gzip off;

    ## https://github.com/gitlabhq/gitlabhq/issues/694
    ## Some requests take more than 30 seconds.
    proxy_read_timeout      300;
    proxy_connect_timeout   300;
    proxy_redirect          off;

    proxy_set_header    Host                $http_host;
    proxy_set_header    X-Real-IP           $remote_addr;
    proxy_set_header    X-Forwarded-Ssl     on;
    proxy_set_header    X-Forwarded-For     $proxy_add_x_forwarded_for;
    proxy_set_header    X-Forwarded-Proto   $scheme;
    proxy_set_header    X-Frame-Options     SAMEORIGIN;

    proxy_pass http://gitlab;
  }

  ## If a file, which is not found in the root folder is requested,
  ## then the proxy passes the request to the upsteam (gitlab unicorn).
  location @gitlab {
    ## If you use HTTPS make sure you disable gzip compression
    ## to be safe against BREACH attack.


    ## https://github.com/gitlabhq/gitlabhq/issues/694
    ## Some requests take more than 30 seconds.
    proxy_read_timeout      300;
    proxy_connect_timeout   300;
    proxy_redirect          off;

    proxy_set_header    Host                $http_host;
    proxy_set_header    X-Real-IP           $remote_addr;
    proxy_set_header    X-Forwarded-For     $proxy_add_x_forwarded_for;
    proxy_set_header    X-Forwarded-Proto   $scheme;
    proxy_set_header    X-Frame-Options     SAMEORIGIN;

    proxy_pass http://gitlab;
  }

  ## Enable gzip compression as per rails guide:
  ## http://guides.rubyonrails.org/asset_pipeline.html#gzip-compression
  ## WARNING: If you are using relative urls remove the block below
  ## See config/application.rb under "Relative url support" for the list of
  ## other files that need to be changed for relative url support
  location ~ ^/(assets)/ {
    root /opt/gitlab/embedded/service/gitlab-rails/public;
    gzip_static on; # to serve pre-gzipped version
    expires max;
    add_header Cache-Control public;
  }


  error_page 502 /502.html;


}
Vidur
la source
Cela n'explique pas réellement quelle est la partie de la configuration qui fait la différence. C'est également contre les commentaires des fichiers de configuration: les modifications manuelles seront effacées! Vous devez spécifier quelle option à votre avis a affecté les performances et réduire votre publication à cela.
Esa Jokinen
Ouais, je sais que c'est une réponse paresseuse. Je n'ai pas eu le temps de comprendre quel était le problème à l'époque et de le déposer pour plus tard. Cette information aidera une future personne à mieux déboguer le problème. La mise à niveau vers la dernière version de Gitlab a résolu cela pour moi de manière permanente (jusqu'à présent).
Vidur