3

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.

5
  • As in "I understand what it does, just not why I should care"?
    – bahamat
    Sep 27, 2012 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, 2012 at 21:13
  • I used to favor readahead or preload, until I got a SSD.
    – daisy
    Sep 28, 2012 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, 2012 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.
    – daisy
    Sep 30, 2012 at 23:55

2 Answers 2

Reset to default
4
+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.

3
  • 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, 2012 at 20:43
  • Unlike Windows Linux has no default tendency to clear the cache-area asap.
    – Nils
    Oct 2, 2012 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, 2012 at 0:09
2

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.

4
  • 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, 2012 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, 2012 at 21:06
  • Amazon and Google have both reported that even sub-second delays represent a significant drop in revenues.
    – bahamat
    Oct 2, 2012 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, 2012 at 0:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .