| Summary: | Virtuoso Frozen due to large log file | ||
|---|---|---|---|
| Product: | [Unmaintained] nepomuk | Reporter: | Michał Kudła <m1k0> |
| Component: | general | Assignee: | Nepomuk Bugs Coordination <nepomuk-bugs> |
| Status: | RESOLVED WAITINGFORINFO | ||
| Severity: | crash | CC: | bartotten, cruzki123, deadbabylon, Der_L, fedotov.i.f, goodhabit, heri+kde, laidig, m.debruijne, me, nepomuk-bugs, trueg, uprooter |
| Priority: | NOR | ||
| Version: | 4.4 | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Michał Kudła
2010-01-29 21:03:20 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? 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. 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].
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? > 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 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. 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. 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. 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. 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 *** This bug has been confirmed by popular vote. *** can everybody confirm that removing the log solved the problem? I don't have the enormous logfile (0bytes) but I recognize the behaviour. Does it still reproducible for you with KDE 4.10? 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 |