首页 注册 登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
wyxls
V2EX  ›  程序员

windows 下跑 Docker Nextcloud 在同步大量小文件和上传大文件出现效能问题

  •   
  •   wyxls · 2019-10-28 23:05:31 +08:00 · 5450 次点击
    这是一个创建于 1850 天前的主题，其中的信息可能已经有所发展或是发生改变。

    #680 This is relative issue but there're some differences.

    运行环境:
    Physical OS: Windows server 2019 Datecenter (v1809, 17763.805)
Docker: Docker for windows 2.1.0.4 (Engine: 19.03.4, Compose: 1.24.1, Hyper-V with 4 vCPUs and 4G vRAM)
MySQL: MySQL for winx64 8.0.18 Community Server
Nginx: Nginx for windows 1.16.1
Nextcloud: 17.0.0 (nextcloud:latest)

Additional Containers：
Onlyoffice-document-server： https://hub.docker.com/r/onlyoffice/documentserver, tag:latest
redis： https://hub.docker.com/_/redis, tag:latest
    docker-compose yml:
    version: '3'

networks:
  nextcloud:

services:

  redis:
    image: redis
    container_name: redis
    hostname: redis
    restart: always
    networks:
      - nextcloud
    expose:
      - 6379

  nextcloud:
    image: wyxls/nextcloud:full
    container_name: nextcloud
    restart: always
    depends_on:
      - redis
    environment:
      - NEXTCLOUD_TABLE_PREFIX=oc_
    volumes:
      - C:/Docker/nextcloud:/var/www/html
      - D:/Docker/nextcloud/data:/var/www/html/data
    ports:
      - 10000:80
    networks:
      - nextcloud

  onlyoffice:
    container_name: onlyoffice
    image: onlyoffice/documentserver:latest
    stdin_open: true
    tty: true
    restart: always
    depends_on:
      - nextcloud
    volumes:
      - C:/Docker/onlyoffice/document_data:/var/www/onlyoffice/Data
      - C:/Docker/onlyoffice/document_log:/var/log/onlyoffice
      - C:/Docker/onlyoffice/document_fonts:/usr/share/fonts/truetype/custom
      - C:/Docker/onlyoffice/document_forgotten:/var/lib/onlyoffice/documentserver/App_Data/cache/files/forgotten
    ports:
      - 10005:443
    networks:
      - nextcloud
    nginx.conf and nextcloud.conf:
    #user nobody;
worker_processes auto;
error_log  logs/error.log;
pid        logs/nginx.pid;


events {
        multi_accept on;
        worker_connections 1024;
}


http {
      include       mime.types;
      #include       naxsi_core.rules;
      default_type  application/octet-stream;

      access_log     off;
      charset        utf-8;
      #aio           threads;
      #directio      1000m;
      sendfile       on;
      tcp_nopush     on;
      tcp_nodelay    on;
      server_tokens  off;
      types_hash_max_size 2048;

      keepalive_timeout 65s;
      keepalive_requests 100;
      client_body_timeout 60s;
      client_header_timeout 60s;
      send_timeout 60s;
      reset_timedout_connection on;
      client_header_buffer_size 4k;
      large_client_header_buffers 4 16k;
      client_max_body_size 32m;
	  client_body_buffer_size 32m ;

      open_file_cache max=100000 inactive=20s;
      open_file_cache_valid    30s;
      open_file_cache_min_uses 2;
      open_file_cache_errors   on;

      fastcgi_connect_timeout 600s;
      fastcgi_send_timeout 600s;
      fastcgi_read_timeout 600s;

      gzip on;
      gzip_vary on;
      gzip_min_length 1k;
      gzip_buffers 8 32k;
      gzip_comp_level 4;
      gzip_types text/plain text/css text/xml text/x-component application/json application/javascript application/rss+xml application/xhtml+xml application/atom+xml image/svg+xml image/x-ms-bmp image/x-icon;
      gzip_disable "MSIE [1-6]\.(?!.*SV1)";

      include C:/nginx/appconf/*.conf;
}

    server {
    listen      10002 ssl;
    server_name example localhost 127.0.0.1;
    root        C:/Docker/nextcloud;
    index       index.php;

    ssl_certificate       C:/SSL-Certificates/cer.cer;
    ssl_certificate_key   C:/SSL-Certificates/key.key;
    ssl_protocols SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
    ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
    ssl_prefer_server_ciphers on;

    proxy_hide_header Strict-Transport-Security;
    proxy_hide_header X-Content-Type-Options;
    proxy_hide_header X-Robots-Tag;
    proxy_hide_header X-Frame-Options;
    proxy_hide_header X-Download-Options;
    proxy_hide_header X-Permitted-Cross-Domain-Policies;
    proxy_hide_header Referrer-Policy;
    proxy_hide_header X-XSS-Protection;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
    add_header X-Content-Type-Options nosniff;
    add_header X-Robots-Tag "none";
    add_header X-Frame-Options "SAMEORIGIN";
    add_header X-Download-Options "noopen";
    add_header X-Permitted-Cross-Domain-Policies "none";
    add_header Referrer-Policy "no-referrer";
    add_header X-XSS-Protection "1; mode=block";

    client_max_body_size 10G;
    fastcgi_buffers 64 4K;
    fastcgi_hide_header X-Powered-By;
    
    location / {
        proxy_pass http://127.0.0.1:10000/;
        proxy_set_header Host $http_host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_buffer_size 64k;
        proxy_buffers 8 64k;
        proxy_busy_buffers_size 64k;
        proxy_temp_file_write_size 64k;
    }

	location = /.well-known/carddav {
        return 301 $scheme://$http_host/remote.php/dav;
    }

	location = /.well-known/caldav {
        return 301 $scheme://$http_host/remote.php/dav;
    }

    location = /robots.txt {
        allow all;
        log_not_found off;
        access_log off;
    }

    location ~ ^\/(?:build|tests|config|lib|3rdparty|templates|data)\/ {
        deny all;
    }

    location ~ ^\/(?:\.|autotest|occ|issue|indie|db_|console) {
        deny all;
    }

}
    MySQL my.ini
    [mysqld]
port=3306
basedir=C:\mysql-winx64
datadir=C:\mysql-winx64\Data
max_connect_errors=10
character-set-server=utf8mb4
collation-server = utf8mb4_general_ci
default-storage-engine=INNODB
default_authentication_plugin=mysql_native_password

key_buffer_size = 128M
max_allowed_packet = 32M
bulk_insert_buffer_size = 32M
thread_stack = 256K
thread_cache_size = 16
table_open_cache = 1024
innodb_buffer_pool_size = 512M
innodb_log_buffer_size = 32M

[mysql]
default-character-set=utf8

[client]
port=3306

    在用 Nextcloud 的 windows 客户端同步大量小文件（ office 的小文档，图片之类的），显示“检查远程变更 '文件夹名'”，每检查几个文件夹后就卡住

    类似的情况发生在 web 端上传大文件的时候，上传跑满带宽每持续一段时间后就下降到 0，然后再恢复下载

    上面两种情况在卡住持续 60s 左右就会超时失败，同时会有以下提示

    Nginx 错误日志

    upstream timed out (10060: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond) while reading response header from upstream, client: x.x.x.x, server: example.com, request: "PROPFIND /remote.php/dav/files/wyxls/filename.xlsx HTTP/1.1", upstream: " http://127.0.0.1:10000/remote.php/dav/files/wyxls/filename.xlsx", host: "example.com:10002"

    Nextcloud 客户端

    Sync error

    Error transferring https://example.com:10002/remote.php/dav/files/filename.xlsx - server replied: 504 Gateway time-out

    与此同时，Nextcloud 的网页端疑似不能响应，但 Nextcloud 容器并没有崩溃

    后续我已经修改过很多相关的参数：

    增大 MySQL 的 buffer 的相关参数
增大 Nginx 跟反向代理 buffer 的相关参数
Nextcloud .user.ini 添加并增大上传下载和内存限制参数
……

    Google 了很多内容，但能尝试的都尝试了，都没有解决问题

    最神奇的是，在 Nextcloud 容器通过 compose 刚刚启动后的一段时间内是一切正常的，客户端 webdav 同步文件效率极高，大文件上传超级顺畅

    软路由上的 Nextcloud 环境，除了 PHP 是 php-fpm、没用 apache、redis、onlyoffice 之外，其他硬件性能都是现在的 windows x64 主机更强

    我现在真的抓狂了，个人不是程序员，Nextcloud 搭建也是边看边学边做，临时抱佛脚型，实在不知道哪里出问题了

    第 1 条附言  ·  2019-11-05 15:32:56 +08:00
    目前改用 seafile，文件数据处理效能比 nextcloud 高不少
  • nextcloud
  • onlyoffice
  • Docker
  • add_header
    21 条回复  •  2020-05-03 10:34:23 +08:00
    GoLDTiGEr404
        1
    GoLDTiGEr404  
       2019-10-28 23:10:57 +08:00
    WIN 下跑 docker 有点累，不懂帮顶
    locoz
        2
    locoz  
       2019-10-28 23:20:23 +08:00 via Android
    Nextcloud 小文件多了确实慢得一批…至今没找到解决方法
    wyxls
        3
    wyxls  
    OP
       2019-10-28 23:47:54 +08:00
    @locoz 慢还是小事，问题是超时失败
    oovveeaarr
        4
    oovveeaarr  
       2019-10-29 02:07:23 +08:00
    如果 LZ 只是想解决超时问题，就改 NGINX proxy timeout
    如果想查原因的话，就要从资源监控上入手了，看是哪里 Block 住了，有工具可以打印出耗时图的。
    seers
        5
    seers  
       2019-10-29 09:11:00 +08:00
    看样子像缓存写满了没自动释放
    seers
        6
    seers  
       2019-10-29 09:12:37 +08:00
    或者内存爆了？
    artandlol
        7
    artandlol  
       2019-10-29 11:36:02 +08:00 via Android
    最近有个 nextcloud 的 php 漏洞 是不是被利用了
    wyxls
        8
    wyxls  
    OP
       2019-10-29 12:10:24 +08:00
    @oovveeaarr 改 timeout 没用，容器运行持续一段时间后效率就会变成描述的那样，我问过朋友他也说从资源监控入手，但我除了会 docker stats 和容器内 top 之外，就不知道有什么办法了

    物理硬件性能应该是没有瓶颈的，毕竟是软路由的 N 倍； MySQL、Nginx 都在物理系统上跑，同理

    剩下的只有可能是虚拟机里的 Docker，但排查起来没有头绪无从下手，Hyper-V 虚拟机本身、Docker for windows 自身、Nextcloud 容器内还有内置的 PHP 和 Apache
    wyxls
        9
    wyxls  
    OP
       2019-10-29 12:19:22 +08:00
    @seers 我用 docker stats 看，4G 内存占用即使在正常运行的情况下都不超过 40%，倒是 CPU 能跑满，甚至超了 100%，很神奇

    我在容器内部用 top 看，正常工作时内存 free 只剩 200MB+，没怎么负载的时候是 1.4G free

    Nextcloud web 网页里的设置-系统监控内存固定的 1.7G 不变，没什么用

    对了，网页有点奇怪的现象，长时间不访问后再访问要等个 45s 左右才成功，第二次往后就异常地顺畅
    wyxls
        10
    wyxls  
    OP
       2019-10-29 12:53:48 +08:00
    通过数次观察，每次容器启动后效率开始降低超时的时机都是容器启动工作 20 分钟左右
    wyxls
        11
    wyxls  
    OP
       2019-10-29 13:15:58 +08:00
    摆乌龙了，改大了 Hyper-V 的内存，情况依然如此，只是 4G 的时候 12 分钟就不行，8G 的时候大概 20 分钟左右不行
    wyxls
        12
    wyxls  
    OP
       2019-10-29 14:42:46 +08:00
    @oovveeaarr
    docker logs 观察了好久，当网页和同步都卡住的时候，日志里也是没有任何反馈也没有 error

    我自己感觉也是某个地方碰到瓶颈，然后资源没有被释放出来，但我就是不知道应该监控哪些地方
    wyxls
        13
    wyxls  
    OP
       2019-11-05 15:32:37 +08:00
    暂时放弃了，等待有缘人解决了_(:з」∠)_

    目前改用 seafile，文件数据处理效能比 nextcloud 高不少
    ddup
        14
    ddup  
       2020-03-06 12:56:27 +08:00
    nextcloud 上传大文件，V 友有发帖分享过他的优化方法，他修改了 nextcloud 保存文件的代码，可以搜一下。
    ddup
        15
    ddup  
       2020-03-06 12:57:19 +08:00
    优化 PHP 大文件下载速度至万兆，让 Nextcloud 支持万兆网络
    https://www.v2ex.com/t/555144
    wyxls
        16
    wyxls  
    OP
       2020-03-07 12:56:56 +08:00
    @ddup
    感谢分享，万万没想到这个大佬直接 debug NextCloud 的源码优化效率，牛啊

    虽然我现在转用了 Seafile，但我发现可能是因为我没对 MySQL 调优，MySQL 的 windows 版默认只给 INNODB 引擎分配 512M 的内存，估计 NextCloud 是数据库爆了内存无法响应请求，导致的连接超时
    ddup
        17
    ddup  
       2020-03-08 08:04:44 +08:00
    @wyxls 我试过可以这样，nginx 限制一下并发数，就不会被撑爆导致无法处理了，只是会处理的慢一些。
    wyxls
        18
    wyxls  
    OP
       2020-03-15 15:09:24 +08:00   ❤️ 1
    @ddup 快 5 个月了，在调试中发现这是 Windows Docker 和 MySQL for Windows 之间的互访问题，我将数据库转移到 Docker 内部的 MariaDB 容器后，NextCloud 一切功能正常，效率还挺不错的
    ddup
        19
    ddup  
       2020-03-16 13:47:43 +08:00
    @wyxls soga，感谢分享。BTW，网盘服务端这种需要后台常驻&多线程的常见，nextcloud 用 PHP 来写也是蛮神奇的。
    NSDont
        20
    NSDont  
       2020-04-21 23:25:40 +08:00
    @wyxls #18 请问一下，目前 nextcloud 上传小文件的效率如何？我这边上传 20 w 的小文件，需要 20 天
    wyxls
        21
    wyxls  
    OP
       2020-05-03 10:34:23 +08:00
    @NSDont
    NextCloud 毕竟基于 PHP，通过上传或同步客户端处理大量文件到数据库和自身程序里是很吃力的（除非专门进行调优），官方也是知道自己的情况，所以服务端提供了一系列 occ 的指令操作，其中有一个 files:scan 是专门处理文件扫描的，你可以去服务端手册看一下

    ```
    sudo -u www-data php occ files:scan --help
    Usage:
    files:scan [-p|--path="..."] [-q|--quiet] [-v|vv|vvv --verbose] [--all]
    [user_id1] ... [user_idN]
    Arguments:
    user_id will rescan all files of the given user(s)
    Options:
    --path limit rescan to the user/path given
    --all will rescan all files of all known users
    --quiet suppress any output
    --verbose files and directories being processed are shown
    additionally during scanning
    --unscanned scan only previously unscanned files
    ```

    用其他手段传输好后直接扫描添加到数据库和 NextCloud 中，效率会高很多，最好的是物理手段，移动硬盘之类的。另外针对大量小文件，我建议在本地打包后放到 NextCloud 对应的路径后进行解压，再使用 occ files:scan 扫描添加
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   3288 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 22ms · UTC 11:47 · PVG 19:47 · LAX 03:47 · JFK 06:47
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.