-
Notifications
You must be signed in to change notification settings - Fork 667
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
1.2.5-1 high CPU and RAM usage #591
Comments
Hello, |
I know this problem since OC 4.x. My workaround is to restart the client at least every day. |
I have the same issue on Mac OS X, the cliente uses up to 100%. |
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 |
Sorry, my bad. I was in a hurry this morning. |
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). |
The logfiles get huge really fast. I cut out the last 500000 lines. As I don't think there's a way to attach the logfile, I put it there: Thanks, Andy. |
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 |
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. ;) poll([{fd=6, events=POLLIN}], 1, -1) = 1 ([{fd=6, revents=POLLIN}]) Any more specific debugging hints? I'd like to help. |
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' |
Same here :-( Server configuration Client configuration |
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. |
Same here, cpu gets very high after runs in few hours. I'm using mirall 1.2.5 with ocsync 0.7.0.7. |
My homebuilt binary did not seem to exhibit this problem: "Byggd från Git revision 105c76 på May 3 2013, 12:46:48 It says 1.2.9 as version. |
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. |
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 |
As a newbie, what is mirall with gdb? |
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 |
I have the same problem here and here is a part of the log: 05-14 15:25:26:406 oc_module: Authentication required 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 :( |
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 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 Thread 464 (Thread 0x7fffddfcb700 (LWP 8087)): Thread 8 (Thread 0x7fffdb8d2700 (LWP 24508)): Thread 6 (Thread 0x7fffdedf7700 (LWP 24502)): Thread 4 (Thread 0x7fffdffff700 (LWP 24500)): Thread 3 (Thread 0x7fffe5605700 (LWP 24499)): Thread 2 (Thread 0x7fffe5e06700 (LWP 24498)): Thread 1 (Thread 0x7ffff7fba760 (LWP 24495)): |
Here's another backtrace of owncloud-client, which this time actually seems to be stuck in sqlite: ^C Thread 270 (Thread 0x7fffddfcb700 (LWP 30898)): Thread 8 (Thread 0x7fffd79ef700 (LWP 19392)): Thread 6 (Thread 0x7fffdedf7700 (LWP 19386)): Thread 4 (Thread 0x7fffdffff700 (LWP 19384)): Thread 3 (Thread 0x7fffe5605700 (LWP 19383)): Thread 2 (Thread 0x7fffe5e06700 (LWP 19382)): Thread 1 (Thread 0x7ffff7fba760 (LWP 19379)): |
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/.* ^C Thread 39 (Thread 0x7fffddfcb700 (LWP 12837)): Thread 8 (Thread 0x7fffdb8d2700 (LWP 10796)): Thread 6 (Thread 0x7fffdedf7700 (LWP 10790)): Thread 4 (Thread 0x7fffdffff700 (LWP 10788)): Thread 3 (Thread 0x7fffe5605700 (LWP 10787)): Thread 2 (Thread 0x7fffe5e06700 (LWP 10786)): Thread 1 (Thread 0x7ffff7fba760 (LWP 10783)): |
high cpu-load (mostly 100%) while having lots of small files
after deleting lots of them, its only a short peek with 100%
client log: |
Hi, I am experiencing similar behavior as well. I have Ubuntu 13.04 installed. top - 09:45:28 up 9 days, 55 min, 10 users, load average: 1,45, 1,25, 1,19 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 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. |
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 |
I managed to workaround this issue by increasing the poll intervals in the config file, then re-launching.
I 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 |
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. |
I confirm that the problem went away after setting localPollinterval and remotePollinterval to 600000. Thanks, jinnko! |
I also tried the pollinterval fix and it has not worked :( |
Everyone, please give 1.3.0 a try. |
you're kidding, right? 1.3.0 isn't better, its worse. constant 100% cpu usage on ubuntu 13.04 |
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%. |
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. |
Of curse I remember that it's only the good will of the devs. :-) |
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? |
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...). (for the record: I'm using Debian Squeeze with backports kernel) |
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. |
I can NOT confirm the above posts. lama: |
indeed...today the problems are gone and I haven't done anything. I have to apologise, it seems you fixed it! good work! |
@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 :-) |
@Cadair @inf1832: Can you try to either wait some more or try the reset button if rebuilding fails? |
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. |
ok, I have tested a bit around. 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: Thanks to all developers and Bug reporters helping to get a better software ;) inf1832 |
@inf1832 You can't sync a folder with Dropbox and ownCloud at the same time. The results are unpredictible. |
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. |
This version seems to work for me. Thanks to the devs for keep improving owncloud. |
@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. |
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. |
I needed to kill the client (latest stable version) today because it was taking 100% of one core. |
@monreal Please try with 1.4.0rc1, available at owncloud.org/sync-clients/#testing. |
What is the sollution for the high CPU problem? |
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
The text was updated successfully, but these errors were encountered: