"find" Service Heavily Loads My Hdd

Hi, I have default Suse 10.1 installed on my desktop. The problem is that Cron frequently runs "Find" service with root privileges, so my hdd gets heavily loaded, and the system is experiencing the severe slowdown. I got tired of killing the find service each time it runs. How can I cancel it forever? I heard that it is insufficient simply to delete the corresponding Cron task, and that some rpm package must be removed. What should I do? Thank you!

Are you sure it is "find" and not beagle indexing your drive? If it is beagle, turn it off in Yast -> System -> Runlevel Editor.

Are you sure it is "find" and not beagle indexing your drive? If it is beagle, turn it off in Yast -> System -> Runlevel Editor.
[/b]

I am sure it is find. Ksysguard shows that find is running with root privileges. Sometimes it is running together with sort.

Hi, I have default Suse 10.1 installed on my desktop. The problem is that Cron frequently runs "Find" service with root privileges, so my hdd gets heavily loaded, and the system is experiencing the severe slowdown. I got tired of killing the find service each time it runs. How can I cancel it forever? I heard that it is insufficient simply to delete the corresponding Cron task, and that some rpm package must be removed. What should I do? Thank you!
[/b]

That is probably the cron job updating the database for locate (updatedb).

You can do two or three things to ameliorate.

In Yast, System, /etc/sysconfig editor, System, Cron, DAILY TIME, you can change the time when daily cron jobs start. Set the time, e.g., to 04:00.

In file /etc/cron.daily/suse.de-updatedb, change the nice value of the job from -19 to 20, in the line:

eval nice -n 19 ionice -c 3 /usr/bin/updatedb $PARAMS 2> /dev/null


You can also move the file from the directory cron.daily to cron.weekly, but I haven't tested that.

That is probably the cron job updating the database for locate (updatedb).

You can do two or three things to ameliorate.

In Yast, System, /etc/sysconfig editor, System, Cron, DAILY TIME, you can change the time when daily cron jobs start. Set the time, e.g., to 04:00.

In file /etc/cron.daily/suse.de-updatedb, change the nice value of the job from -19 to 20, in the line:

eval nice -n 19 ionice -c 3 /usr/bin/updatedb $PARAMS 2> /dev/null
You can also move the file from the directory cron.daily to cron.weekly, but I haven't tested that.
[/b]

Thank you very much, I performed all your recommendations. Let's see if it helps

Thank you very much, I performed all your recommendations. Let's see if it helps
[/b]

Please let us know the results, after maybe several days. I am interested in consequences of moving to weekly.

In even modestly poweful computers, find doesn't slow down the computer noticeably.

>Please let us know the results, after maybe several days. I am interested in consequences of moving to weekly.
OK

>In even modestly poweful computers, find doesn't slow down the computer noticeably.
Sempron overclocked to 2.2 GHz, 512 Mb of memory, 300GB Seagate 7200.8 hdd.
With find running, the cursor hardly moves on the screen, and any application takes no less than 20 second to start. My friends have same problems on more powerful configurations. The slowdown, therefore, is more than just noticeable.

>Please let us know the results, after maybe several days. I am interested in consequences of moving to weekly.
OK

>In even modestly poweful computers, find doesn't slow down the computer noticeably.
Sempron overclocked to 2.2 GHz, 512 Mb of memory, 300GB Seagate 7200.8 hdd.
With find running, the cursor hardly moves on the screen, and any application takes no less than 20 second to start. My friends have same problems on more powerful configurations. The slowdown, therefore, is more than just noticeable.
[/b]

Yes, the reason is in "Sempron". Also, verify that you have DMA enabled for the hard drive.

Yes, the reason is in "Sempron". Also, verify that you have DMA enabled for the hard drive.
[/b]

1. Sorry, I disagree. If the processor of 2.2 GHz is insufficient to perform basic desktop operations with reasonable speed, these are definetely the problems of the distribution, rather than of the hardware. Also, the main reason for the slowdown seems to be the intense use of hdd. Dma is of course enabled.
2. My friends experience the same problem on two configurations, Athlon64 3500+ 1Gig memory, 3 sata hdds in raid5, and overclocked AthlonX2 4600+, 2Gb memory, 2 sata hdds in raid0. Despite the fact that these configurations can hardly be called outdated, the slowdown due to find is non-acceptable.

Moreover, as discussions on linux.org.ru show, this is a common problem that people meet with Suse 10.1, in essence, independently of the hardware they use.

1. Sorry, I disagree. If the processor of 2.2 GHz is insufficient to perform basic desktop operations with reasonable speed, these are definetely the problems of the distribution, rather than of the hardware. Also, the main reason for the slowdown seems to be the intense use of hdd. Dma is of course enabled.
2. My friends experience the same problem on two configurations, Athlon64 3500+ 1Gig memory, 3 sata hdds in raid5, and overclocked AthlonX2 4600+, 2Gb memory, 2 sata hdds in raid0. Despite the fact that these configurations can hardly be called outdated, the slowdown due to find is non-acceptable.

Moreover, as discussions on linux.org.ru show, this is a common problem that people meet with Suse 10.1, in essence, independently of the hardware they use.
[/b]

That updatedb used to slow PCs several years ago. Currently, I manage several medium to powerful PCs purchased in recent two years. None shows substantial slowdown, and the mouse never freezes.

Also, I haven't noticed substantial change in changing from version to version, including to 10.1, of SUSE.

I am surprised to learn that this happens on the Athlon PC you described.

But I see some reasoning when you say

this is a common problem that people meet with Suse 10.1, in essence, independently of the hardware they use.
[/b]

In all cases, the OS evidently allows some set of processes to take over almost all resources. Hence, even a powerful PC may slow down. And the degree of slowing down depends on what resources are left available to the user's processes. Conclusion is, that the hardware alone is not the only determining factor.

In my opinion, the slowdown occurs because of unfortunate combination of HD read, HD write, find, and sort.

Ultimately, you can get rid of automatic updating of the database - remove the script. You will, however, benefit substantally from the ability to issue "locate some_file". For that, just issue "updatedb" once a while, when the PC is free. You can even say:

updatedb; shutdown -h +10

if the PC is going to be switched off.


However, if you say that even a powerful PC is slowed down, then maybe the updatedb is not the culprit. Maybe it is, still, the beagle, which caused lots of trouble to many users. In my desktop, I have uninstalled that unfortunate package, which caused effects similar to what you are experiencing. There is one more update running from time to time - a process that updates the list of installed packages, but I don't know much about it.

Probably it is worth looking at the modification date of the database before and after the slowdown; this may yield some answers. If I am not mistaken, the file is /var/lib/locatedb