Closed dmth closed 11 years ago
chrisfiesta
commented
11 years ago Hello, I've got the same problem on Mint 13 with Mate and OC-Client 1.2.5. My PC has got 16GB RAM installed and one FX-8150. Your Client need after some time all RAM(!) and round about 200% CPU-Usage. Can you help us?
raid1
commented
11 years ago I know this problem since OC 4.x. My workaround is to restart the client at least every day. I'd really like to see a fix for this issue. Let me know if I can be of any help.
lukasbisdorf
commented
11 years ago I have the same issue on Mac OS X, the cliente uses up to 100%.
dragotin
commented
11 years ago It would help if somebody could provide a log file of the client while its going wild. So if it runs crazy, don't stop it, but open a console and call owncloud --logwindow and after a while (one or two sync runs), click save in the logfile window.
lukasbisdorf
commented
11 years ago Sorry, my bad. I was in a hurry this morning. Opening the logwindows succeeds, the first messages appear in the window, but then the process freeze. The CPU usage of the Client increases to above 100%. Is there an other way to see what's going on? Direct loging to file?
homann
commented
11 years ago I get the same symptoms on 1.2.5. Ubuntu 12.04, amd64. Just killed and starteed with --logfile. Will get back tomorrrow (I hope).
raid1
commented
11 years ago The logfiles get huge really fast. I cut out the last 500000 lines. That's where those "sqlite_step error: disk I/O error" lines start. Hope that's enough to find the problem.
As I don't think there's a way to attach the logfile, I put it there: http://spiegl.de/public/owncloud-client-crash.log.bz2
Thanks, Andy.
dmth
commented
11 years ago I tried to use use --logwindow, unfortunately the window gets unusable when the error occurs, as CPU-Load goes "BOOM" as well does ram-use.
nevertheless: sqlite_step_error and I/O error stuff
will try --logfile now
homann
commented
11 years ago I have a couple of lines with sqlite_step_error in my log file... The log files i 2.6 GB after 24 hours. A bit unwieldy. ;) Tried running strace -p, but didnÀt manage to pipe the output. Copied 500 lines from the console, and there's alot of:
poll([{fd=6, events=POLLIN}], 1, -1) = 1 ([{fd=6, revents=POLLIN}]) recvfrom(6, "\1\1l\230\0\0\0\0\0\0\0\0D\0\374\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 4096, 0, NULL, NULL) = 32 recvfrom(6, 0x1dfdf24, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=6, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=6, revents=POLLOUT}]) writev(6, [{"(\3\4\0a\2\0\0\5\0\0\3\306\5\24\0", 16}, {NULL, 0}, {"", 0}], 3) = 16 poll([{fd=6, events=POLLIN}], 1, -1) = 1 ([{fd=6, revents=POLLIN}]) recvfrom(6, "\1\1m\230\0\0\0\0\0\0\0\0\16\0\24\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 4096, 0, NULL, NULL) = 32 recvfrom(6, 0x1dfdf24, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable) recvfrom(6, 0x1dfdf24, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=6, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=6, revents=POLLOUT}]) writev(6, [{"(\3\4\0a\2\0\0pQ\0\3\306\5\24\0", 16}, {NULL, 0}, {"", 0}], 3) = 16 poll([{fd=6, events=POLLIN}], 1, -1) = 1 ([{fd=6, revents=POLLIN}]) recvfrom(6, "\1\1n\230\0\0\0\0\0\0\0\0D\0\374\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 4096, 0, NULL, NULL) = 32 recvfrom(6, 0x1dfdf24, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable) recvfrom(6, 0x1dfdf24, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable)
Any more specific debugging hints? I'd like to help.
dmth
commented
11 years ago since 4 hours I have run into 7.6 GB logfile... last 100 lines repeat:
05-02 22:35:03:642 csync_statedb_query: sqlite3_compile error: no such table: metadata - on query SELECT * FROM metadata WHERE phash='1226921628055589682' 05-02 22:35:03:643 csync_statedb_query: sqlite3_compile error: no such table: metadata - on query SELECT * FROM metadata WHERE inode='133658' 05-02 22:35:03:643 _csync_detect_update: file: pppppp/.git/objects/9b/431fad0d4079afd902592878894a32b623a159, instruction: INSTRUCTION_NEW 05-02 22:35:03:643 csync_statedb_query: sqlite3_compile error: no such table: metadata - on query SELECT md5 FROM metadata WHERE phash='1226921628055589682' AND modtime=1363615054
blackdot
commented
11 years ago Same here :-(
05-03 15:35:26:142 csync_ftw: Uniq ID read from Database: folder/file.xls ->
Server configuration Operating system: Debian squeeze Web server: apache2 (2.2.16-6+squeeze11) Database: php5 (5.3.3-7+squeeze15) PHP version: mysql-server-5.1 (5.1.66-0+squeeze1) ownCloud version: version 5.0.6 (versionstring 5.0.5)
Client configuration Client version: 1.2.5-0 Operating system: Debian wheezy (fully updated) OS language: English Installation path of client: /usr/bin/owncloud
homann
commented
11 years ago I compiled the code from git, and have run 12 hours without problems. Will report back in 36 hours.
Edit: I got the same EAGAIN errors, but no mem or cpu load.
w41l
commented
11 years ago Same here, cpu gets very high after runs in few hours. I'm using mirall 1.2.5 with ocsync 0.7.0.7.
homann
commented
11 years ago My homebuilt binary did not seem to exhibit this problem:
"Byggd frÄn Git revision 105c76 pÄ May 3 2013, 12:46:48 anvÀnt OCsync 0.70.9 och Qt 4.8.1."
It says 1.2.9 as version.
dschmidthawk
commented
11 years ago Having the same issue also. Couldn't figure out why my system slowed down to a crawl until I looked at the resource monitor and filtered owncloud. Shut it down and my system was blazing fast. Working on a Win7 pro pc. Everything else about the sync seems to work fine.opened with the log file for about 10 minutes and the txt file was about 2.4MB. Is there anything that I can do to optimize? Happy to provide the log file.
ogoffart
commented
11 years ago a backtrace sampling at the moment of the 100% CPU usage would be usefull.
run mirall with gdb. when the bug occurs, press ctrl+c, then enter:
thread apply all backtrace
dschmidthawk
commented
11 years ago As a newbie, what is mirall with gdb?
bra-tak
commented
11 years ago Same Problem here, on a Windows 7 x64 Machine. The SyncClient causes an average CPU-Load of 30% (!!!) all the time, while NOT Synchronising (no blue circle in the Taskbar). While Syncronising the CPU Load went down to 0-1%.
CPU: Intel Core i5 760 @3,6GHz RAM: 8GB DDR-1866
lluuuuuK
commented
11 years ago I have the same problem here and here is a part of the log:
05-14 15:25:26:406 oc_module: Authentication required
05-14 15:25:26:406 oc_module: Call the csync callback for ownCloud
05-14 15:25:26:490 oc_module: Neon error code was 1
05-14 15:25:26:490 oc_module: WRN: propfind named failed with 1, request error: 503 Service Unavailable
05-14 15:25:26:490 oc_module: Errno set to 10014
05-14 15:25:26:490 csync_ftw: opendir failed for ownclouds://cloud.ifisc.uib-csic.es/owncloud/remote.php/webdav/clientsync - Unknown error: 10014 (errno 10014)
05-14 15:25:26:491 csync_update: Update detection for remote replica took 0.19 seconds walking 0 files.
05-14 15:25:26:491 #### ERROR during csync_update : "CSync failed to find a specific file.
Backend Message: 503 Service Unavailable"
05-14 15:25:26:491 CSync run took 274 Milliseconds
05-14 15:25:26:684 status.php returns: "{"installed":"true","version":"5.0.8","versionstring":"5.0.6","edition":""}" 0 Reply: QNetworkReplyImpl(0x101581d40)
05-14 15:25:26:684 #-------# oC found on "https://cloud.ifisc.uib-csic.es/owncloud"
05-14 15:25:26:691 -> CSync Finished slot with error true
05-14 15:25:26:691 * error Strings: ("CSync failed to find a specific file.
Backend Message: 503 Service Unavailable")
05-14 15:25:26:691 \ owncloud csync thread finished with error
I wish i could have this solved since I cant work with owncloud sync client open on my desktop, as it overloads my CPU and RAM usage :(
chrwen81
commented
11 years ago I'd like to provide a gdb backtrace for the "sqlite_step error: disk I/O error".
Client environment: Debian wheezy, owncloud-client 1.2.5-0, libocsync-plugin-owncloud 0.70.7-, libsqlite3-0 3.7.13-1+deb7u1, libqt4-sql-sqlite 4:4.8.2+dfsg-11 Hardware is a Lenovo T520 with Intel Core i5-2520M CPU, 8 Gigs RAM with plenty of it unused
Server is ownCloud 5.0.5 on a QNAP TS-219P+ (Marvell 6282 1.6GHz ARM-CPU, 512MB RAM), 2.6.33.2 Linux kernel, PHP 5.3.14
^C Program received signal SIGINT, Interrupt. 0x00007ffff7795dec in QPlainTextDocumentLayout::blockBoundingRect(QTextBlock const&) const () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4 (gdb) thread apply all backtrace
Thread 464 (Thread 0x7fffddfcb700 (LWP 8087)):
Thread 8 (Thread 0x7fffdb8d2700 (LWP 24508)):
Thread 6 (Thread 0x7fffdedf7700 (LWP 24502)):
Thread 4 (Thread 0x7fffdffff700 (LWP 24500)):
---Type
Thread 3 (Thread 0x7fffe5605700 (LWP 24499)):
Thread 2 (Thread 0x7fffe5e06700 (LWP 24498)):
---Type
Thread 1 (Thread 0x7ffff7fba760 (LWP 24495)):
chrwen81
commented
11 years ago Here's another backtrace of owncloud-client, which this time actually seems to be stuck in sqlite:
^C Program received signal SIGINT, Interrupt. 0x00007ffff659fb65 in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4 (gdb) thread apply all backtrace
Thread 270 (Thread 0x7fffddfcb700 (LWP 30898)):
Thread 8 (Thread 0x7fffd79ef700 (LWP 19392)):
Thread 6 (Thread 0x7fffdedf7700 (LWP 19386)):
---Type
Thread 4 (Thread 0x7fffdffff700 (LWP 19384)):
Thread 3 (Thread 0x7fffe5605700 (LWP 19383)):
---Type
Thread 2 (Thread 0x7fffe5e06700 (LWP 19382)):
Thread 1 (Thread 0x7ffff7fba760 (LWP 19379)):
chrwen81
commented
11 years ago Another backtrace, with some debugging symbols installed now...
the mentioned file "/home/cw/ownCloud/.csync_journal.db.ctmp-journal" does not exist, but there are following dot files present in that directory:
cw@hex:~ -> ll /home/cw/ownCloud/.*
-rw-r--r-- 1 cw cw 202K Mai 16 14:43 /home/cw/ownCloud/.csync_journal.db
-rw-r--r-- 1 cw cw 202K Mai 16 14:43 /home/cw/ownCloud/.csync_journal.db.ctmp
^C Program received signal SIGINT, Interrupt. QTextDocument::documentMargin (this=0x83b3c0) at text/qtextdocument.cpp:740 740 text/qtextdocument.cpp: No such file or directory. (gdb) thread apply all backtrace
Thread 39 (Thread 0x7fffddfcb700 (LWP 12837)):
self=<error reading variable: Unhandled dwarf expression opcode 0xfa>) at /tmp/buildd/glib2.0-2.33.12+really2.32.4/./glib/gmain.c:3146Thread 8 (Thread 0x7fffdb8d2700 (LWP 10796)):
at /tmp/buildd/glib2.0-2.33.12+really2.32.4/./glib/gmain.c:3440at /tmp/buildd/glib2.0-2.33.12+really2.32.4/./glib/gmain.c:3141---Type
Thread 6 (Thread 0x7fffdedf7700 (LWP 10790)):
Thread 4 (Thread 0x7fffdffff700 (LWP 10788)):
at .moc/release-shared/moc_qhttpthreaddelegate_p.cpp:127self=<error reading variable: Unhandled dwarf expression opcode 0xfa>) at /tmp/buildd/glib2.0-2.33.12+really2.32.4/./glib/gmain.c:3146---Type
Thread 3 (Thread 0x7fffe5605700 (LWP 10787)):
at /tmp/buildd/glib2.0-2.33.12+really2.32.4/./glib/gmain.c:3141Thread 2 (Thread 0x7fffe5e06700 (LWP 10786)):
at /tmp/buildd/glib2.0-2.33.12+really2.32.4/./glib/gmain.c:3141Thread 1 (Thread 0x7ffff7fba760 (LWP 10783)):
---Type
self=<error reading variable: Unhandled dwarf expression opcode 0xfa>) at /tmp/buildd/glib2.0-2.33.12+really2.32.4/./glib/gmain.c:3146
davidak
commented
11 years ago high cpu-load (mostly 100%) while having lots of small files
05-21 12:02:15:578 csync_propagate: Propagation for local replica took 11.72 seconds visiting 3980 files.
05-21 12:02:17:937 csync_destroy: Writing the statedb of 3980 files to disk took 1.80 seconds
05-21 12:02:18:031 CSync run took 43031 Milliseconds after deleting lots of them, its only a short peek with 100%
05-21 12:08:10:296 csync_propagate: Propagation for local replica took 0.16 seconds visiting 40 files.
05-21 12:08:12:046 csync_destroy: Writing the statedb of 40 files to disk took 1.75 seconds
05-21 12:08:12:046 CSync run took 3546 Milliseconds client log: https://gist.github.com/davidak/5618863
hefax
commented
11 years ago Hi,
I am experiencing similar behavior as well. I have Ubuntu 13.04 installed. uname -a : Linux Reah 3.8.0-19-generic #30-Ubuntu SMP Wed May 1 16:35:23 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
top - 09:45:28 up 9 days, 55 min, 10 users, load average: 1,45, 1,25, 1,19 Tasks: 303 total, 2 running, 300 sleeping, 0 stopped, 1 zombie %Cpu(s): 23,0 us, 13,4 sy, 0,0 no, 52,1 id, 10,7 wa, 0,0 hi, 0,9 si, 0,0 st KiB Mem 16426672 total, 16020876 used, 405796 free, 4360 buffers KiB Swap 47925244 total, 10907728 used, 37017516 free, 138044 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 25655 hefa 20 0 22,0g 12g 2944 S 133,6 81,2 1040:29 owncloud
So 133% of cpu and 81% of my ram. The client works fine for a while but after some time is just starts consuming cpu and memory like crazy. The only way to recover is to kill the process.
cthielen
commented
11 years ago I'm experiencing high RAM usage as well using the sync client v1.2.5 on Fedora 18. It seems to be a real memory leak and not related to the amount of syncing activity or number of files in the repository.
stevedowe
commented
11 years ago Adding my "me too" to the list. Debian 7 (Wheezy) and owncloud-client (1.2.5). A quick "top" revealed:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
7817 steve 20 0 7537m 6.1g 2444 S 2.3 78.9 460:55.47 owncloud
jinnko
commented
11 years ago I managed to workaround this issue by increasing the poll intervals in the config file, then re-launching.
localPollinterval=600000
remotePollinterval=600000I am syncing several large folders and the client seemed to get into a race condition resulting in the high CPU load.
Built from Git revision b4e2e5 on Apr 22 2013, 16:57:46 using OCsync 0.70.6 and Qt 4.8.4.
Cadair
commented
11 years ago I am also having this issue. I am running Arch and version 1.2.5-3 from the AUR.
I notice it use a lot of CPU useage, not too much RAM, when it is scanning local files for changes. I have quite a large directory of file I am scanning.
raid1
commented
11 years ago I confirm that the problem went away after setting localPollinterval and remotePollinterval to 600000. --> https://github.com/owncloud/mirall/issues/591#issuecomment-19509289
Thanks, jinnko!
Cadair
commented
11 years ago I also tried the pollinterval fix and it has not worked :(
danimo
commented
11 years ago Everyone, please give 1.3.0 a try.
1of16
commented
11 years ago you're kidding, right? 1.3.0 isn't better, its worse. constant 100% cpu usage on ubuntu 13.04 not even the tweaks (localPollinterval=600000 - remotePollinterval=600000) are helping....
lukasbisdorf
commented
11 years ago I totally agree with 1of16! 1.3.0 is even worse. During the sync, the CPU usage goes down to a normal value. But if it's watching the folder, the usage goes up to 100%. Is it so hard to find out, which loop causes the huge load???
jinnko
commented
11 years ago I have upgraded to 1.3.0 on OSX, without changing my poll intervals away from the 600000 and it has continued to work fine without high CPU usage, at least during the first cycles after the upgrade.
1of16 & inf1832, it's a good idea to see if the devs are able to reproduce the problem as that's the only way it's gonna get fixed. Remember this is OSS and people work on it with good will.
lukasbisdorf
commented
11 years ago Of curse I remember that it's only the good will of the devs. :-) I am a software developer too, and I thought of setting up an owncloud dev environment for further debugging... But until I know how the client works and where the bug is or could be, it could take me a month or two. Currently there are finals at my university so time is a bit rare :D so don't expect to much from my approaches...
Cadair
commented
11 years ago I have tried 1.3.0, it seems that it does suffer from the same problem. It does a load of sync then starts eating CPU. I can't workout if it is doing anything useful while it is eating the CPU or if it is just going round in pointless circles.
Is there any further info I can provide to help you debug this?
DanScharon
commented
11 years ago I experienced the same issues like 1of16. After the upgrade to 1.3.0 it got even worse, i.e. cpu was at 100% immediately on all cores (before the upgrade it took some time...). what I tried just now is the following: I deleted the configuration in ~/.local/share/data/ownCloud and the .csync_journal.db witihin each shared folder. Afterwards I had to reconfigure everything of course, but the issue has seemed to disappear.
(for the record: I'm using Debian Squeeze with backports kernel)
danimo
commented
11 years ago There is now a button called "Reset" which resets the journal and spares you the reconfiguration. It should do the same, please give it a try.
raid1
commented
11 years ago I can NOT confirm the above posts. I updated yesterday and the CPU+Memory problems have disappeared! owncloud-client 1.3.0 has been running for almost a day without noticeable problems.
lama:~> uname -a Linux lama 3.8.0-25-generic #37-Ubuntu SMP Thu Jun 6 20:47:07 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux lama:~> lsb_release -a LSB Version: core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch Distributor ID: Ubuntu Description: Ubuntu 13.04 Release: 13.04 Codename: raring
1of16
commented
11 years ago indeed...today the problems are gone and I haven't done anything. no (extreme) high cpu load on my 13.04 and 12.04 clients.
I have to apologise, it seems you fixed it! good work!
danimo
commented
11 years ago @1of16 Pheew, that probably was our "detect broken database and rebuild it"-Algorithm working its wonders (hence the added spikes after installation of 1.3). Glad it worked :-)
danimo
commented
11 years ago @Cadair @inf1832: Can you try to either wait some more or try the reset button if rebuilding fails?
davidak
commented
11 years ago the ui of the client 1.3.0 on windows 7 hangs while it syncs, i cant move the window or click a button. 1.2.5 doesn't do that
it also has 100% usage of 1 cpu core.
on a pc with only 1 core (win xp) it uses all cpu ressources and the pc is not usable anymore. the ui freezes also.
it uses 85 - 92 MB RAM, i think that is ok.
lukasbisdorf
commented
11 years ago ok, I have tested a bit around. The Solution with the Reset Button works for me on one Machine... On the other (MacBookPro 2009) it doesn't work. So I decided to reset the whole thing. I deleted everything related to owncloud, (Library, Application, SyncDB). Now the Issue with the high CPU usage seems to be resolved...
I'm syncing two different folders, each to an other Directory in my Folder Structure. Both are larger than 1GB and with more than 10K files.
One of the Folders is also synced via Dropbox, it could be, that Dropbox messed up the Database, because its much faster. For Testing I turned off the Dropbox.
For me the CPU issue is resolved, but now I ran in another issue, that it will not sync anything (I'm going to search the Tickets if someone else had a similar Problem).
Short Notice about my OS config: Mac OS X 10.8.4 (both) CPU: i7 3770 and Core2Duo @2.4 Ghz RAM 16GB and 6 GB
Thanks to all developers and Bug reporters helping to get a better software ;)
inf1832
danimo
commented
11 years ago @inf1832 You can't sync a folder with Dropbox and ownCloud at the same time. The results are unpredictible.
lukasbisdorf
commented
11 years ago Yes that was my fault. I have forgotten to turn it off (It is now off, since the hint with the reset button yesterday). Now only owncloud is running...
The last hour everything went well (expect some delays in syncing), but now again: 100% CPU - with short intervals of 0-4% usage.
homann
commented
11 years ago This version seems to work for me. Thanks to the devs for keep improving owncloud.
danimo
commented
11 years ago @inf1832: "At the same time" was meant as an absolute statement. You cannot alternate the two either.
Closing since it seems to work for the others.
Cadair
commented
11 years ago I am sad to report that the upgrade does not seem to have fixed this for me either.
I updated the client, and completely rest the database and the client. It has taken it a while to rebuild and sync, but it does still seem to be running two processes at 100% cpu. I will leave it for a couple of hours to see if it is just transient.
monreal
commented
11 years ago I needed to kill the client (latest stable version) today because it was taking 100% of one core.
Good Morning,
occasionally my OC-Client on my arch-linux box starts freaking out. It starts to eat up RAM (Top was aroung 6 GB) and creates massive CPU-Load (continous load of 60% on a Dualcore-Machine).
The client has to sync 3 folders, with 150 files, total. This is less than 600 MB
Any ideas how to improve this?
BR