Skip to content
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

Client windows long time too lauch with 85Go #3510

Closed
TimoPtr opened this issue Jul 28, 2015 · 12 comments
Closed

Client windows long time too lauch with 85Go #3510

TimoPtr opened this issue Jul 28, 2015 · 12 comments
Assignees
Milestone

Comments

@TimoPtr
Copy link

TimoPtr commented Jul 28, 2015

Hi,
I recently install the last version of owncloud 8.1.0 client (1.8.4) and i sync 85go off excel document. But now when i start the client it's take a long time to refresh list off file .... I'm asking if a solution exist to reduce this time ?
The long step is "preparing to sync"(more than 3hours), sync is pretty fast.

The server run in Intel Xeon 16Go (RAM), 2To RAID 1. No caching module, it's seem there are not a huge process run when i scan folder with the client.

I don't understand log (F12) so i paste some part of it 👎

07-28 11:57:08:216 0x3d4c790 unknown: Failed to resolve EGL function eglGetPlatformDisplayEXT (La procédure spécifiée est introuvable.)
07-28 11:57:08:226 0x3d4c790 unknown: static QWindowsEGLStaticContext* QWindowsEGLStaticContext::create(): Could not initialize EGL display: error 0x3001

07-28 11:57:08:226 0x3d4c790 unknown: static QWindowsEGLStaticContext* QWindowsEGLStaticContext::create(): When using ANGLE, check if d3dcompiler_4x.dll is available
07-28 11:57:24:252 0x3d4c790 OCC::ConnectionValidator::checkAuthentication: # Check whether authenticated propfind works.
07-28 11:57:24:252 0x3d4c790 OCC::AbstractNetworkJob::start: !!! OCC::PropfindJob created for "https://myURL.fr" + "/"
07-28 11:57:35:353 0x3d4c790 OCC::AbstractNetworkJob::start: !!! OCC::CheckQuotaJob created for "https://myURL.fr" + "/"
07-28 11:57:35:968 0x3d4c790 OCC::FolderMan::slotEtagPollTimerTimeout: void OCC::FolderMan::slotEtagPollTimerTimeout() No folders need to check for the remote ETag
07-28 11:57:56:001 0x62514a0 csync_statedb_get_below_path: 26 entries read below path COMMANDE/CLIMASOL from db.
07-28 11:57:56:001 0x62514a0 csync_walker: directory: ownclouds://myURL.fr/remote.php/webdav/COMMANDE/CLIMAVENETA [file_id=00001929ocslokqp3tx1]
07-28 11:57:56:011 0x62514a0 _csync_detect_update: Database entry found, compare: 1255335182 <-> 1255335182, etag: 55773778e33a3 <-> 55773778e33a3, inode: 0 <-> 22435300, size: 0 <-> 0, perms: RDNVCK <-> RDNVCK
07-28 11:57:56:011 0x62514a0 _csync_detect_update: Reading from database: COMMANDE/CLIMAVENETA
07-28 11:57:56:011 0x62514a0 _csync_detect_update: file: COMMANDE/CLIMAVENETA, instruction: INSTRUCTION_NONE <<=
07-28 11:57:56:251 0x3d4c790 OCC::ConnectionValidator::checkAuthentication: # Check whether authenticated propfind works.
07-28 11:57:56:251 0x3d4c790 OCC::AbstractNetworkJob::start: !!! OCC::PropfindJob created for "https://myURL.fr" + "/"

...

07-28 13:44:32:557 0x61e5520 unknown: void QHttpNetworkConnectionChannel::_q_error(QAbstractSocket::SocketError) QAbstractSocket::RemoteHostClosedError QSslSocket(0x61eadf8) QObject(0x0) 0 false 3 0 QAbstractSocket::ConnectedState
07-28 13:44:32:557 0x61e5520 unknown: void QHttpNetworkConnectionChannel::_q_disconnected() 0 QSslSocket(0x61eadf8) QObject(0x0) 0 false 3 0

If you need something else tell me.

@guruz
Copy link
Contributor

guruz commented Jul 28, 2015

What is 80Go or 85Go?

@TimoPtr
Copy link
Author

TimoPtr commented Jul 28, 2015

85Go of data sorry

@TimoPtr TimoPtr changed the title Client windows long time too lauch with 80Go Client windows long time too lauch with 85Go Jul 28, 2015
@tflidd
Copy link

tflidd commented Jul 28, 2015

Go is short for gigaoctet (octet=byte). 1Go = 1GB

@theCrazyBeard
Copy link

I too can confirm a similar issue. I have approximately 17GB of data in my user folder and the sync client slows to a crawl after parsing through the first several folders. As @Timo86 said, the sync itself happens rather quickly but the Discovery takes a long time. Up to 30-40 minutes in my case.

@dragotin
Copy link
Contributor

@theCrazyBeard @Timo86 could you guys count the number of files and directories that you sync and tell us?

@TimoPtr
Copy link
Author

TimoPtr commented Jul 29, 2015

53 000 files and 11 000 folders

@theCrazyBeard
Copy link

28,161 Files, 1,891 Folders

@guruz
Copy link
Contributor

guruz commented Aug 3, 2015

Have you guys tried one of the 2.0 nightly builds?
We have a different directory discovery code there, maybe it helps?

http://download.owncloud.com/desktop/daily/

@guruz guruz added this to the 2.0.1-next milestone Aug 3, 2015
@guruz guruz self-assigned this Aug 3, 2015
@theCrazyBeard
Copy link

Finally had a chance to get a nightly installed. Crawling seems better but the actual syncing is still taking a long time to complete. Most transfer speeds are running at less than 500 Bps.

@guruz guruz modified the milestones: 2.1-next, 2.0.1-next Aug 31, 2015
@ogoffart
Copy link
Contributor

the problem with the transfer speed is mostly a server problem.
The version 2.1 further imrpoves the discovery speed. How long does it takes with the last daily?

@ogoffart ogoffart assigned ogoffart and unassigned guruz Oct 23, 2015
@guruz
Copy link
Contributor

guruz commented Oct 28, 2015

@Timo86 Did you have a chance to test a daily/nightly build? How long does the discovery take? (with log disabled)

@guruz
Copy link
Contributor

guruz commented Nov 4, 2015

I'm closing this, please check if 2.1 is faster.

http://download.owncloud.com/desktop/daily/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants