Linux - ServerThis forum is for the discussion of Linux Software used in a server related context.

Notices

Welcome to LinuxQuestions.org, a friendly and active Linux Community.

You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!

Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.

If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.

Having a problem logging in? Please visit this page to clear all LQ-related cookies.

Introduction to Linux - A Hands on Guide

This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.

The server is a tiny embedded single-core ARM, but this shouldn't matter. On some other servers with identical hardware, the same request runs fine.
The distri ist Debian Squeeze.

I have the gut-feeling that the high system-load is somehow caused by Apache, but can't strengthen this thesis. The apache error.log shows nothing...
How to find the process causing this??

Edit: The best explanation for high %sy in top I found is:
"having higher numbers here may indicate a problem with kernel configs, a driver issue, or any number of other things" here
But this don't help...

I have the gut-feeling that the high system-load is somehow caused by Apache, but can't strengthen this thesis. The apache error.log shows nothing...

Unlikely. I'd be guessing a driver issue.
Very hard to track down - never looked at embedded. Have a look at /proc/interrupts for hints on what may be playing up.
vmstat might indicate abnormal context switches - also a clue that driver/interrupt is the problem.

Hi all,
the load is not consistently high, it alternates between 2%sy and 90%sy and it looks like it somehow depends from the apache process.
If it is restarted, the %sy is very low for a while, after some hours of requests to apache it will come up more and more on each request and therefore the response become much slower - until it is uselsess. A simple apache restart will than bring back the system to be responsive again... so i Guess it have something to do with PHP or Apache.

Thanks for the good hint with vmstat, here is some output:

The first output was made after Apache processes have been running since several days during a single request which took about 100s:

A "vmstat -d" running during a request only returns zeros
and "iostat" I can't find for my Debian distribution, it seems not to be available, also not in sysstat, but hopefully it's covered in the output above.

The /proc/interrupts look OK, the imx-i2c is due to a sensor polled regulary via i²c:

Is anybody able to see the reason for the problem in above output???
What also is suspicious: I have several of these systems running, same hardware, same processes, hopefully identically installed (never 100% sure, because it is done manually), but this one is so slow by having such high %sy load...

As per the top output the load is not high & %sys utilization is very high if it is possible to you to install pkg in that box & get the sar report that will give you all essential date to fetch the problem

Meanwhile I came to the idea comparing an OK system with the NOK one, because they have really the same hardware, running the same software, only a different machine. Here is an output responding on exactly the same request within 6s, seen in log from line 4 to 6 marked in red:

I was also able to install iostat, but without result. It seems that the kernel is not maintaining the statistics for the flash devices. So "iostat -kdx" shows nothing, even "iostat -kdx ALL" shows only 0s

sar was running successfully, but I don't see the high load there. In the output below the red colored times are during a slow access, see:

Hmmm, it is running on some other systems with 64MB well (so at least much faster). If I look to vmstat I see plenty of inactive and free memory...

Usually there is only 1 user logged in, the parameter MaxCients is configured away from default 150 to 4 only, the StartServer is reduced to 2. Apache is what I know best, that's the reason why I started with it also on the small embedded machine (400MHz, 64MB RAM). You are right, maybe it is time now to switch to a more lightweight server like LIGHTTPD.
But I have th gut-feelingm that there is another problem laying below, because on other systems it is running well. Maybe with the reduced ressource need of LIGHTTPD the problem is only delayed by some days and at the end being on the same state like now :-(

Edit: It seems the problem is solved. By accident I saw three processes in top running with NICE=-6
These self-made processes run regularly and often need top cpu resources. After chenging the back to -1 to be still a little bit better prioritized, everything works fine. Now the %sy is down to about 10 and the system is much more responsive again.