Unresponsive/Sluggish Toaster

[Sean Wheller]

Stefano Rivera wrote:
>>>Every time I do anything on our toaster, I'm appaled at how unresponsive
>>>it is.
>>
>>Ja, typical of most web apps... :(
>
>
> Yes, and it's a really decent machine, too - hardly an advert of the
> speed of linux :-)

I have just figured out a cause and potential solution to the
responsiveness problem:

Linux has a sophisticated scheduling algorithm that favours users. The
rationale is that if you are running a long-term batch job, a short
delay in that job is not going to make any difference compared to a few
seconds delay in responding to an interactive job (keypress in a shell
for e.g.).

The toaster has a user interactive front-end (firefox), but gets its
feed from apache running as a batch job. Linux, in its attempt to
appear responsive to the user (firefox), is putting the batch job
(apache) at the back of the queue.

A potential solution is to renice apache (or start it with suitably ugly
nice settings) to be more aggressive in grabbing CPU time. Naturally,
we wouldn't want to nice it ahead of cdrecord and growisofs for fear of
creating coasters.

Something to look at when we have the time.

[Stefano Rivera (stefanor)]

I'd argue a lot of this.

Linux makes no differentiation between interactive and batch jobs.

Also:
cdrecord and growisofs (if run through sudo) will renice themselves to realtime values. Otherwise, they will inherit apache's niceness.

[Charles Oertel (charles-finebushpeople)]

Hi Stefano

Stefano Rivera wrote:
> Linux makes no differentiation between interactive and batch jobs.

Disagree. The latest kernel scheduling algorithm is designed to improve
user responsiveness by progressively giving I/O bound processes more CPU
time than plain CPU-bound processes. There is a whole explanation of it
somewhere on learnlinux I think (and I used to teach it last year on
linux admin courses).

regards
Charles

[Stefano Rivera (stefanor)]

> Disagree. The latest kernel scheduling algorithm is designed to improve user responsiveness by progressively giving I/O bound processes more CPU time than plain CPU-bound processes.

You'd probably find that apache isn't particularly IO bound when serving freedom toaster stuff. It is all so small, that it is probably cached in RAM.

Especially when compared to the monster that is firefox :-)