-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Synchronizing small files = very slow #7072
Comments
Or, sync with multiple threads and split the work. Much more easy. |
@dragotin did you guys have plans looking into uploading multiple files through the same connection ? |
I used the IP directly (or rather a name, but one which is taken from /etc/hosts, not looked up via DNS). I can reproduce your results when uploading locally. Unfortunately fast local performance is academic as the usual case will be a server somewhere on the internet. |
It still feels a bit slow, this is about 41 M which I'd expect to be uploaded much faster. |
I tried with the tar file without compression (bunzip2) which is 11Mb big, it took less than a second to upload. I'd almost think that before uploading many files those could be tar'ed together, uploaded then untarred on the server... |
Yes I was thinking about something like that when I said "multiple files per request". I think the issue is really delay somehwere on the way. However It seems to be not only the round-trip time. A ping to my server says roundtrip is only 6 miliseconds, so I am wondering where the rest of the time is spent. My accesslog looks like:
Load on both client and server are negligible. Still only 1 file in two seconds. The results are reproducable on a second server (also ubuntu 12.04, but apache instead of lighttpd). Round trip (ping) for the second server is 14ms. Uploading several files at once might also allow to add several files to the database at once, in case that is the bottleneck. |
@PVince81 Are you sure it is several files a second locally? The timestamp in the image you posted are in hours:minutes. |
@gluap hmm right. I was actually looking at the progress bar and saw the file name changing 3-4 times within a second and thought the log would reflect that. |
You might also want to check one of this reported issues: owncloud/client#331, #5084, #3118, owncloud/client#209 and many more of the same/similar reports. |
@RealRancor: thanks for the hint. Apparently my search before creating the issue was not thorough enough. My apologies. |
We are in the same boat (and have filed #6937 ). I have traced the application with New Relic and I see hundreds of SELECTs for every file uploaded - that slows the processing down considerably. |
@jcfischer Would it be correct to summarize the current results of #6937 as "The main delay of transferring a small file comes from the fact that |
I can't say conclusively yet. Yes, there are a ton of SQL requests which cost time. Yes, every HTTP request incurs startup cost (I measure 60ms as the baseline for ownCloud - this is the time it takes status.php to load and I assume that this is loading and initializing the complete ownCloud stack. I don't know if there are more time sinks involved. Sent from my iPhone
|
I´m using the OwnCloud Sync Tool for windows to sync about 100.000 files. |
@bantu @DeepDiver1975 @karlitschek @icewind1991 any idea ? |
Having worked with a variety of backup transfer products professionally for some years I am afraid to say there appears to be a fundamental problem with the methodology being used for Client syncing. Without going into the specifics of how OC is working it clearly should not rely on sequential transfer of individual files when 'adding' a new folder and yet it appears to be issuing multiple queries to the server before even considering uploading each file. Clearly this type of activity should be handled in a batch fashion - perhaps by allowing the client to toggle a setting - or simply warning that the number of 'new' files means it will work in batch mode only until the new folder sync is completed. As an example, Batch Mode could mean that all files from the 'New Folder' are uploaded to a temporary location on the server, the server resources are then used to 'Scan' the folder and create records for each of the new files, setting timestamps etc and migrating the files to their proper place. At the end of the process Batch Mode is turned off and a consistency check is performed. After tweaking MySQL settings and cache and so forth I have got to a situation where OC running on Ubuntu 12.04, with 1.5.1 on Windows 7 works well enough to be usable for general day to day updates but if you need to include another folder; do it like this:- Use Filezilla or similar to copy the original files to the correct location on the Server. Change the permissions on the uploaded files to match the rest of the OC files. Add the folder to Owncloud at the Client side. Wait while the Client syncs all the 'New Files' down from the server. [It still takes a while, but hours rather than weeks]. This project has fantastic potential, but the fundamental architecture just doesn't appear to scale, sadly. |
@sunny-user I experienced this as well and tracked it down to the oc_jobs table - as the number of jobs increases the cost of adding a new one increases as well, leading to higher web transactional latency and cpu% on the DBMS getting higher and higher. Turns out the cron job which processes scheduled jobs wasn't running. This made a huge difference right away. But... I have other problems. Specifically, discovering that sync performance scales linearly with # of directories. |
Migrating to ownCloud from Dropbox, and currently feeling the pain of this issue as well :( |
@RealRancor Yep. Still no luck. Still extremely slow. Here's a video to illustrate the pain with small files (less than 100k). https://dl.dropboxusercontent.com/u/47777/slow_own_cloud.mov |
Hi, Posting a video is probably not very useful in this case as it don't say anything about your environment. If you're running SQLite you might want to try to change your environment to a "real" Database like MySQL or PostgreSQL. |
@RealRancor the reason I posted the video is because there was confusion about timestamps in the activity pane earlier in the thread and the video provided a much better visual of the problem -- but to answer your question, I'm running ownCloud 6.0.2 on my Netgear ReadyNAS connected to my local network, and it's configured to use MySQL. |
I am facing the same problem while trying to sync a large netbeans project which includes a .git repository. It takes ownCloud around 2-3 seconds for each file and most of them are less than 1kb. Sync'ing 20,000 files (~200mb in total) takes me almost a day.. |
I have the same problem, users with many files are waiting many time. I tested on MySQL 5.5 and PostgreSQL 9.2, same problem (it's database clusters, optimized for performance) |
I'm experiencing exactly the same issue; I keep a backup copy of my Aperture library in Dropbox and have been attempting to sync it to my server with ownCloud. Many small files in there. Using the current 1.6.0rc2 client on OS X, connecting to ownCloud on Ubuntu 14.04 (Apache 2.4, MySQL 5.5) and the small files are taking forever - very similar performance as shown by the @ralphholzmann video (approximately 1 file per second, usually around 2-3KB each). Destination server is a dedicated 2GHz Intel Atom box in a data centre with solid 100Mbps connection, client machine is on JANET, so bandwidth is no issue. Individual large files transfer extremely quickly. |
@Tralapo @batamire I just tested to sync the Stress Test package with 10 300 files of 3 b each, and it took me 8 minutes with 2.0.2 testpilot version: https://download.owncloud.com/desktop/daily/testpilotcloud-2.0.2.5525-nightly20151008-setup.exe Package: https://www.en0ch.se/stress-test/ Look in previous comments for server setup. Now using server 8.1.3 and PHP 5.6 |
@enoch85 Thanks for the tip. I installed the 2.0.2 Testpilot and it indeed seems to perform a lot better then 2.0.1. I don't get the stress test done in 8 minutes, it expects around 8-10 hours. But that's because of the hardware (RaspberryPi) I would say. The 2.0.1. gives me a expectation of several days(!), so an improvement for sure. |
For future testing, here are the latest daily builds: https://download.owncloud.com/desktop/daily/ |
Using Desktop App 2.1.0 and Owncloud 8.2.2 on a Ubuntu 14.04 LTS Server running on my Cubietruck, backend is MYSQL 5.5.47. I am using APCu and static assets with Apache 2.4.7 and PHP 5.5.9. I now get 2 days!!! for 92 MBs in 4370 files. The Sync activity does not even bottleneck anything. The Network connection is wifi and the machines are in the same network. The HDD is directly accessed via SATA. The only possible bottleneck is the CPU, it experiences spikes for some seconds and then goes back to idling for several seconds. |
I increased a lot my speed with this methode, but I don't understand really. Somebody can explain to me please? http://forum.owncloud.org/viewtopic.php?f=3&t=6621#p14737 Thank you! |
Hi! I have installed php 7.0.4 on my home server because all the praises about being fast. I installed it on my Ubuntu Server 14.04.4 LTS with ispConfig. The installation went just fine, and I also managed to enable PHP-FPM 7.0.4 on an apache virtual host subfolder only (yes, I have php 5.5.9 on virtualhost and in /cloud subfolder PHP 7.0.4 FPM) . Despite of this, my OC 2.1.1 sync client tells me that the sync of the stress test files will take above 3 hours! Copying the stress test files through CIFS to my server takes about 3 to 5 minutes, maybe less. This is not the first time I try to tackle this issue so I have prepared a very detailed bug report for @enoch85, @ApolloLV, @gluap, @PVince81 and @guruz so they can take a look at it. For you guys, basically I was able to setup PHP 7.0.4 with PHP-FPM on apache 2.4 virtualhost subfolder and seems to be woking right, I was also able to setup APCu 5.1.3 and seems to be caching ok (see details of apcu stats). Maybe you can take a look at my PHP-FPM pool config to optimize it a bit. I have to mention that my sync client seems to sync 3 files then do a little sleep and then another 3 files, and so on...¿¿?? That being said, lets start to report this bug (or enhancement, as you like)... Steps to reproduce
Expected behaviourI expected that the sync will last less time! Actual behaviourThe sync process is very slow! Server configurationOperating system: Ubuntu Server 14.04.4 LTS (Linux lucas 3.13.0-83-generic #127-Ubuntu SMP Fri Mar 11 00:25:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux) Web server: Server version: Apache/2.4.7 (Ubuntu) - Server built: Jan 14 2016 17:45:23 Database: MySQL 5.5.47-0ubuntu0.14.04.1 PHP version: 7.0.4 (Server API: FPM/FastCGI) ownCloud version: 9.0 Updated from an older ownCloud or fresh install: Updated from an older ownCloud Where did you install ownCloud from: Manual Install Apache virtual host PHP-FPM config:
PHP-FPM pool config:
APCu 5.1.3 stats:
Server hardwareCPU: Intel(R) Core(TM) i7 860 @ 2.80GHz Motherboard: Gigabyte P55M-UD2 RAM: 12GB 1333 MHz Server System HDDs: SSD Samsung 840 120Gb Server Storage HDDs: 2x WD Green WD20EARX 2TB (software RAID1 with mdadm) Network: (LAN) 1000 Mbit/s down / 1000 Mbit/s up Stress Test InfoStress Test Files: https://www.en0ch.se/stress-test/ Client: 2.1.1 Top:
Signing status (ownCloud 9.0 and above):
List of activated apps:
The content of config/config.php:
Are you using external storage, if yes which one: Nope Are you using encryption: no Are you using an external user-backend, if yes which one: Nope Client configurationBrowser: Firefox 45.0 Operating system: Ubuntu 16.10 LogsWeb server error log
ownCloud log (data/owncloud.log)
|
@ghiamar PHP-FPM is not as fast as CLI for some reason. For me with almost the same setup (CLI) it takes 4-5 minutes. |
Hi @enoch85! Would you please disclose your detailed apache/php/apcu config so I can try that? Thanks! |
My setup involves a NGINX reverse proxy, Apache 2.4, MySQL 5.5, Redis cache, and a regular core i5 processor (3570K) clocked at 4.2 Ghz. My network is 100/100 Mb Swedish fiber and performs very good. #20963 (comment) It would be eaiser for you of you want to test "my system" to download this VM: https://www.techandme.se/pre-configured-owncloud-installaton/ You could also connect to my demoserver: https://owncloudphp7.techandme.se |
Ok @enoch85, so if I got this right, I shoud try your vm and check the config there to try to figure it out best config for me, that's right? Thanks! |
@ghiamar I would leave PHP-FPM if possible. There are no special config tweaks or so, just a basic install really, but with CLI and not FPM. Then it could be so many different factors to your slowness than just your conifg, network, server, and so on... Here are the script(s) I use for installing: https://github.com/enoch85/ownCloud-VM/blob/master/production/owncloud_install_production.sh |
Thanks @enoch85, will check that script and let you know |
Hi @enoch85! I want to report that following your VM scripts installation I finally got the speed desired for the stress test (around 5 minutes). I did clean install Ubuntu Server 14.04.4, and manually followed your scripts commands and got it just fine. Now I will try to replicate that on my production server to see if I can get that speed. Maybe the REDIS cache will do the trick, will check and let you know. |
Well, after the whole day testing, I may say that maybe is something wrong with my server config/setup, because trying the VM methox from here https://github.com/enoch85/ownCloud-VM/blob/master/production/owncloud_install_production.sh it works just fine and synces all small files in about 5 minutes and on my real server it takes about 1 hour!, at least I was able to reduce it from 3 hours! Thanks a lot for all the support! |
the problem's still present. |
hi @divinity76!, Where should I add that exactly? By the way, I have tested in three scenarios, one VM installed with https://github.com/enoch85/ownCloud-VM/blob/master/production/owncloud_install_production.sh, a second VM using a fresh Ubuntu Server 14.04.4 installing ISPConfig and a third scenario using a owncloud docker image, in all of them, the file syncing goes just fine, the only slow thing is my real LAN server. I really don't know what can be causing the slowness, but I really don't care now, because I know that is my server, will waith till Ubuntu Server 16.04 releases so I can test in that new version... |
do i look like an ownCloud Client dev? :p or to say it another way, i don't know, but my best guess is |
If you don't have issues with server performance/load I suggest to try a nightly build of oC client 2.2.x |
Nope...installed Revisión Git 173056 en Mar 30 2016 but the slowness persists. I really don't care now, because I was able to check that is an issue on my 2 years old server installation, maybe in that time, I setup something that causes the pauses for security. Anyway, will wait to Ubuntu Server 16.04 release an try again. Will let you know then. |
@ghiama why do you think this is an OS issue? |
Hi @divinity76. I think of it because the test I've made, in three different VM scenarios, using my Laptop connected to my WiFi LAN the stress test files sync is really quick, but testing to my real LAN server, the stress test files sync take a very long time to sync compared to the other scenarios. As you can see on my previous posts here, you can check my server specs and realize that is solid rock, but still OC is slow, so, in my opinion, maybe there's something I installed on my server on this two years run that maybe, got this slowness with OC, maybe it's a security measure, because the files sync very fast, but by batches of three. Thanks in you interest. |
@guruz; |
Sure, here is the centos 7 nightly: http://download.opensuse.org/repositories/isv:/ownCloud:/community:/nightly/CentOS_7/ |
I must be going blind... |
Why is this closed if it's not fixed? There is still issue with small file uploading - even on 9.0.2. - as mentioned above, bigger file upload is not the problem, but small file upload. I've tried to upload through my linux network drive, mapping the same in windows machine, WinSCP - it's slow, very slow. There are no errors in logs, just slow speed - in bytes!!! I've created few hundred of files of size in range of 10-1000kB and always the same problem. I've also tried setting as suggested "innodb_flush_log_at_trx_commit = 2" but that didn't help. We also changed disks, also no luck. Any idea how to proceed? It's making a huge problem for us/clients. |
@mislav-eu it's likely closed because the slowness is on a case by case basis. For one person it can be environment issue A. For another it's environment issue B. For some people and environments it's not a problem at all. In your case need to find out what environment you are using so best would be to make a new report using the issue template: https://raw.githubusercontent.com/owncloud/core/master/issue_template.md I assume that you already checked https://owncloud.org/support/ or the forums for known environment issues that would cause upload slowness ? |
I will open then new report. But yes, mostly people have the same problem: I've tried mentioned things, but no result. |
During the upload of small files there is no chunking involved, so no chunk assembly. This means that in most cases the file is directly streaming by Apache to PHP and PHP passes it to the ownCloud code which stream-copies it into a part file. Then the part file gets renamed to the final file. So the part where the bytes are copied should be optimal. So the slowness could be due to the stream copying from the web server to PHP being slow. Some web servers even create a temporary file before streaming the file to ownCloud (seen it happening with some nginx settings). Then the other part which could be slow is setting up the network connection and later on PHP setting up its internal filesystem, but this happens before the stream copy. So the question is whether the transfer speed values are based on the stream copy part or whether they look lower (averaged?) because the start of the transfer was slower. Also to check if whether the target folder is a received shared folder, and whether that one was reshared. If the target folder is on external storage, it will likely be much slower due to the extra upload to the external storage. |
@mislav-eu thanks! |
Expected behaviour
Files sync at about the speed of the broadband connection, independent of size unless limited by CPU or IO on client or server.
Actual behaviour
Synchronizing a folder with many small files is terribly slow. For instance a test folder with 10k 3-byte-files synchronizes with a speed of about 1 file per second over a broadband connection. The load on both client and server while doing this is negligible. Tested with server running
Ubuntu 12.04
with currentowncloud 6.0.1-1
, client current Linux or Macos clients. The transfer rates on the broadband connection are very low as well, so this is not the bottleneck.Steps to reproduce
Server configuration
Operating system: Ubuntu 12.04
Web server: lighttpd
Database: mysql
PHP version: PHP 5.3.10-1ubuntu3.9
ownCloud version: 6.0.1-1
Updated from an older ownCloud or fresh install: Updated from ownCloud 5
The content of config/config.php:
$CONFIG = array ( 'instanceid' => 'removed', 'passwordsalt' => 'removed', 'datadirectory' => '/var/www/owncloud/data', 'dbtype' => 'mysql', 'version' => '6.0.0.16', 'dbname' => 'dropbox', 'dbhost' => 'localhost', 'dbtableprefix' => 'removed', 'dbuser' => 'removed', 'dbpassword' => 'removed', 'installed' => true, 'theme' => '', 'maintenance' => false, );
no external storage used.
Log files do not show error messages or warnings that seem related.
Client configuration
Both MacosX and Ubuntu 13.10 running current owncloud versions are affected. Browser was not used.
Why I think this is an issue
I regularly sync folders with several thousands of files. I think I am not the only one.
What I think is the reason
I am guessing that owncloud does at least one if not several http requests per file sent. It works sequentially, so the next file can only be sent when the last file is acknowledged. Therefore while preparing the request takes no time and effort, and storing the file does not either, the network delay comes into play: For each file to be sent you have to wait at least one if not several round-trip times.
Another indication is that syncing the folder on the local network or between two VMs on the same machine is much faster. This emphasizes the network delay being of importance in this scenario.
How I think it could be circumvented
Sync not file-by-file but instead several files per request, at least if the files are small.
The text was updated successfully, but these errors were encountered: