Bug 224815 - Virtuoso Frozen due to large log file
Summary: Virtuoso Frozen due to large log file
Status: RESOLVED WAITINGFORINFO
Alias: None
Product: nepomuk
Classification: Unmaintained
Component: general (show other bugs)
Version: 4.4
Platform: Compiled Sources Linux
: NOR crash
Target Milestone: ---
Assignee: Nepomuk Bugs Coordination
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-01-29 21:03 UTC by Michał Kudła
Modified: 2013-05-28 15:26 UTC (History)
13 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michał Kudła 2010-01-29 21:03:20 UTC
Version:            (using Devel)
Compiler:          gcc 4 
OS:                Linux
Installed from:    Compiled sources

nepomuk+strigi+virtuoso+updatedb frozen my system
I can't normaly using mouse, windows, etc. System load 100%. System is completely not usable

Is there any workaround without disabling this features?
Mayby some high nice, low priority, kernel config (?), etc, for this processes?
Comment 1 Sebastian Trueg 2010-01-29 22:08:33 UTC
This is way too little information. What do you base your claim on? What processes are using up the CPU and what did trigger the problem?
Comment 2 Daniel Laidig 2010-01-31 13:43:30 UTC
Since updating to 4.4 RC2 and enabling nepomuk again I notice the same or a related issue.

Every few minutes, my system becomes almost completely unresponsive for a few seconds. Keeping iotop open for some time has confirmed that "/usr/bin/virtuoso-t +foreground +config /tmp/virtuoso_hX2550.ini +wait" is doing some heavy i/o during that time and my system doesn't react very well to that.
Comment 3 Daniel Laidig 2010-01-31 18:03:49 UTC
Looking closer, I find that in iotop the "DISK READ" and "DISK WRITE" values are 0 or quite low when the freezes happen, but the "IO" column ("the percentage of time the thread/process spent while waiting on I/O" if I understand the manpage correctly) is 99.99% for virtuoso_t and [md2_raid].
Comment 4 Sebastian Trueg 2010-02-01 11:24:34 UTC
Please give details on your system config. Do you use any network hosted partitions? Which folders are indexed by Strigi?
And what does updatedb have to do with this?
What kind of CPU do you have? How much RAM?
Comment 5 Michał Kudła 2010-02-04 22:05:20 UTC
> Please give details on your system config. 
> Do you use any network hosted partitions? 
No
> Which folders are indexed by Strigi?
./Documets 337 files
./Projekty 801798 files
> And what does updatedb have to do with this?
reading from the same hard disk
> What kind of CPU do you have? 
intel core duo 2GHz
> How much RAM?
2 GiB
Comment 6 Christian Lichtsinn 2010-02-13 09:54:27 UTC
I'm using KDE 4.4.0 from Chakra/KDEmod with Arch Linux. Strigi/virtuoso uses about 100% (1 core) to 200% (2 cores) of my cpu (AMD X2 4800+ Dualcore, 2.5 GHz) and I had a memory leak, I guess (strigi used my full 2GB RAM and my 1GB Swap, while indexing my full home-directory, until my screen went black and I could only reboot the system).

Had about 100.000 files indexed (from my home-directory) until I stopped strigi.
Comment 7 Paul 2010-02-17 02:31:29 UTC
I am using Gentoo Linux. Same problem here, but I don't need additional processes to completely freeze my system - *if* i am waiting a couple of minutes to get alt+ctrl+f1 working (~3 mins), then if I can log it (~1 min), then if i can run htop and kill nepomuk* processes I can use system again. Help me provide needed information please.
Comment 8 Paul 2010-02-17 02:37:18 UTC
Also, I have 3ggz core 2 duo, 2gb of ram, separate hdd for root and home, I have mixed different variants of hdd's to exclude hdd problem. htop shows me 'empty' cpu most of the time with low load average, cpu monitoring applets showing me full iowaiting. I have issue with kde 4.3.5, and on kde 4.4, cannot provide info about earlier versions of kde. Also if I have some heavy applications running - rendering, games, etc - most probably I have to push reset button. Also it looks like not 100% related to strigi because I saw good behavior of pc even strigi is scanning files.
Comment 9 Daniel Laidig 2010-02-17 14:18:59 UTC
My system is a X2 6000+ with 8 GB RAM. I indexed my whole home directory, which is a lot, and indexing wasn't finished yet. For now, I disabled Nepomuk and the problems stopped.
Comment 10 uprooter 2010-03-19 13:17:18 UTC
I just saw that I had 20GB!! Log file at ~/.kde4/share/apps/nepomuk/repository/main/data/virtuosobackend/soprano-virtuoso.log 
Removed that crap and the system is running fine again. I guess it was eating all free space on my /home partition.
LOG ROTATION !!!! kids
Comment 11 Fedotov Ilya 2010-06-12 01:19:23 UTC
*** This bug has been confirmed by popular vote. ***
Comment 12 Sebastian Trueg 2010-07-27 13:52:39 UTC
can everybody confirm that removing the log solved the problem?
Comment 13 BartOtten 2011-10-04 20:16:07 UTC
I don't have the enormous logfile (0bytes) but I recognize the behaviour.
Comment 14 RussianNeuroMancer 2013-02-25 00:42:52 UTC
Does it still reproducible for you with KDE 4.10?
Comment 15 Vishesh Handa 2013-05-28 15:13:45 UTC
There has been confirmation for over 2 years now. I'm marking this as RESOLVED - WAITING FOR INFO. Please feel free to reopen this bug if it still happens with KDE 4.10