Horrible problem at 4:40AM with fc-cache idconfig...

[zAchAry]

At 4:40 Salix executes a few processes which are throttling the HDD I/O
It is not good for laptops with sensitive HDD.

The processes are: fc-cache idconfig gtk-icon-update housekeeping.

What was the reason to rush so fast with it? Make these processes to write in a rate of 10 or 20 KB per second instead of 10MB per second.
These few cron processes are running in the background and the user should not notice them.

I wanted to copy the name of the processes to mousepad and this is what happened at this critical time.


I believe that these should read/write to disk in the lowest rate possible (Salix is also aimed to old machines after all)

[gapan]

This comes from /etc/cron.daily/housekeeping, which is run once a day, not necessarily at 4:40AM. I'm not sure we still need it, maybe we'll remove it in the future. You can try deleting that file and see if any weird stuff appears with time concering fonts/icons.

[zAchAry]

This is not the issue.
If you want to make services or tasks to run in the background every now and then, then you should make these to run seamlessly with no interruptions, even if it will take 10 minutes instead of 2 minutes.

Some will ask "What if the user will shutdown the system?" then do not replace the original files. duplicate the current files, update these files (seamlessly and slowly) and at the end of the process replace the files.

[Shador]

No problems with performance nor character display here. You're welcome to suggest patches or to change it on your system. This doesn't seem crucial and therefor not worth the effort to me.

duplicate the current files, update these files (seamlessly and slowly) and at the end of the process replace the files.

That would need to be implemented upstream.

It is not good for laptops with sensitive HDD.

WTF!? What should be a sensitive HDD? They're meant to be written to and read from and the mechanical wear should be less than the one caused by keeping them running. For SSDs this might matter, but I'm quite sure that this is mostly reading anyway (repeatedly calling the script makes it run very fast --> previously read data is probably cached by the kernel now) so it matters even less for those. Apart from that laptop HDDs are actually more enduring and robust then desktop HDDs.

I believe that these should read/write to disk in the lowest rate possible (Salix is also aimed to old machines after all)

How would you go about defining lowest rate possible? 1B/s? Well you could also do 1B/d or 1B/y? There's always a smaller value, so where effectively converging towards zero.

If you want to make services or tasks to run in the background every now and then, then you should make these to run seamlessly with no interruptions, even if it will take 10 minutes instead of 2 minutes.

Now who's saying this? That's YOUR opinion.

[GJones]

The real problem is that the Linux kernel gives priority to I/O hogs by default. Try putting this in your sysctl.conf:

Code: Select all

vm.dirty_bytes=524288

This severely limit the amount of data that a given application can write to the disk at one time (in this case to 512 KB). In my experience the impact on throughput is not huge (only a few MB/s) but the impact on responsiveness under load is enormous.

This is of course a crude hack, but it works very well on the desktop.

A better solution might involve writing a kernel I/O scheduler that can assign different priorities for known processes. OTOH, this is exactly what the Windows Vista I/O scheduler does, and I think we've all seen how Vista performs under load!

[Shador]

A better solution might involve writing a kernel I/O scheduler that can assign different priorities for known processes. OTOH, this is exactly what the Windows Vista I/O scheduler does, and I think we've all seen how Vista performs under load!

I'm fairly sure that among the schedulers already exisiting there is one that can do this. There are many alternatives like Completely Fair Queuing, Budget Fair Queueing, Anticipatory, Deadline, NOOP and probably many more. If support for the desired scheduler is available in the currently running kernel you can even change it on the fly through the /sys/block/sdX/queue/scheduler files for that specific disk.

[thenktor]

It is not good for laptops with sensitive HDD.

WTF!? What should be a sensitive HDD? They're meant to be written to and read from and the mechanical wear should be less than the one caused by keeping them running. For SSDs this might matter, but I'm quite sure that this is mostly reading anyway (repeatedly calling the script makes it run very fast --> previously read data is probably cached by the kernel now) so it matters even less for those. Apart from that laptop HDDs are actually more enduring and robust then desktop HDDs.

+1