Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I am just going through the service-list of a server (CentOS 5) - the question will probably apply to other RedHat, Fedora, ... versions, too.

Note that my servers normally run in runlevel 3 (no GUI server processes started).

I stumbled across two services:

  • readahead_early
  • readhahead_later

These two services get their configuration from /etc/sysconfig/readahead.d

The purpose of these services seems to be to preload certain files into cache-memory.

Browsing through the config-files (left at the default contents) I see mostly X11-related files and some libraries.

What is the deeper sense of these processes? AFAIK every file will go into cache-memory after the first read-access. Why should I preload - and why should I preload all these unneeded files?

IMHO this is a useless waste of read-bandwidth during start-up of the operating system.

Update

I found that these readaheads will only cache the first inode-entries for the files listed (via the fstat system call). So it just speeds up finding these files...

Update 2012-10-02

The question boils down to: Can I safely disable these services on a server, or am I missing something important here?

I Updated the header of the question accordingly, since the given answers don`t hit the mark yet.

share|improve this question
    
As in "I understand what it does, just not why I should care"? –  bahamat Sep 27 '12 at 21:11
    
@bahamat I do not understand why these services are enabled by default. To me this seems to be from ancient times where disk access was very slow. –  Nils Sep 27 '12 at 21:13
    
I used to favor readahead or preload, until I got a SSD. –  warl0ck Sep 28 '12 at 10:06
    
@warl0ck did you use this readahead in a configured way for a special application? Was the startup of the app indeed faster? –  Nils Sep 30 '12 at 21:08
    
@Nils not very much, since Linux kernel itself caches file readings, I find it hard to do a benchmark. But a bit of slow down at boot, yes. –  warl0ck Sep 30 '12 at 23:55
add comment

2 Answers

up vote 2 down vote accepted
+50

The idea is to load these files into cache before they're needed, so that there is no need to wait for them when X is trying to start.

Obviously, there isn't much point in doing this for files that aren't actually needed in the system's day-to-day operation, so for example caching the X server itself is counterproductive in your case, yes; however, you might be surprised at what can get pulled in sometimes: it's quite possible that some programs your server runs actually do pull in X11 libraries, perhaps via Cairo, so don't be too hasty in dismissing this as useless!

It might be better if the system periodically traced itself at startup to figure out what to precache (and when); Windows does something of the sort. (It also does this on a per-exe basis for process startup; I've actually seen the kernel pulling stuff into cache early after consulting its records about a new process's executable!)

Again, this is all about reducing the time spent waiting for things to come in from storage.

Edit:

This is, of course, not essential. Nothing will break if it doesn't happen (barring stupid bugs); startup timing will just be different.

share|improve this answer
    
But once accessed these binaries and (shared) libraries will be in the cache any way - so what is the point? Storage is not that slow nowadays. Or do pre-cached objects stay longer in cache than not-pre-cached ones? –  Nils Sep 6 '12 at 20:43
    
Unlike Windows Linux has no default tendency to clear the cache-area asap. –  Nils Oct 2 '12 at 21:07
    
@Nils: The point is to convert serial waits to parallel ones. In other words, it's about reducing round trip times, not saving bandwidth. Ideally, this would mean the system never has to sit there spinning it's wheels (or HLT, whichever) while waiting for these pages to load. (Typically, there won't be enough RAM, and it will end up having to pull some back in. But better a bit at a time than all at once during startup/login; this way there's usually something that can run...) –  SamB Oct 3 '12 at 0:09
add comment

The thought process behind it is that end users are more likely to suffer a longer boot up time in favor of faster application launch times.

Boot times are tens of seconds to minutes, so extending this by a few seconds is barely noticeable. In any case the extra time preloading is a factor of less than 1x the boot time. On the other hand, firefox (just to pick an example app and dummy numbers) may launch in 15s uncached, but only 1.5s if cached. In this (purely fake) example, that's a speed up of 10x, which is certainly noticeable by users.

All in all, the total time is probably not significantly different. But it's a psychological trick for humans, not really about reducing wait time. Human perception of time is extremely malleable. This is why it takes longer to get to the store than it does to get home, and why a watched pot never boils.

share|improve this answer
    
I worked on a VOIP project once where the application we designed introduced an extreme amount of latency (close to 1s) and we thought users would never stand for that. We decided to go into testing anyway since we were bound by factors out of our control. As it turned out, nobody noticed the latency even when we explicitly instructed them to pay attention to it. It's all about perception management. –  bahamat Sep 27 '12 at 21:26
    
From what I have learned about software ergonomics one second is the maximum an end user will normally endure. –  Nils Sep 30 '12 at 21:06
    
Amazon and Google have both reported that even sub-second delays represent a significant drop in revenues. –  bahamat Oct 2 '12 at 0:02
    
Of course, this actually reduces the wait time if the user powers on the machine and then grabs a snack or something while it boots... –  SamB Oct 3 '12 at 0:18
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.