[Eisfair] [E1] zu hohe CPU-Auslastung nach einigen Tagen bei aktivem Apache2 und owncloud Nutzung, speziell Kalender / eisgraph-Installation

[Marcus Roeckrath]

Hallo Ansgar,

Ansgar Püster wrote:

> Der Kernel wird in der Tat größer:
> 
> eisgcc # ls -la /boot/kernel*
> -rw-r--r-- 1 root root 2777792 Sep 25 17:26 /boot/kernel
> -rw-r--r-- 1 root root 2281648 Sep 22 19:18 /boot/kernel.old
> 
> wobei diese größere Differenz meines Erachtens nicht
> ausschließlich aus dem Setzen der Optionen

Vielleicht sieht Toms Buildprozess ein wenig anders aus.

> CONFIG_TASKSTATS=y
> CONFIG_TASK_DELAY_ACCT=y
> CONFIG_TASK_XACCT=y
> CONFIG_TASK_IO_ACCOUNTING=y
> 
> kommen kann.
> 
> Ich finde die Vorgehensweise von Tom nicht alles einbauen, insbesondere
> bei EXPERIMENTAL Parametern, sondern Hinweis auf das Paket kernel-dev
> höchst sinnvoll.

Zu Zeiten einer SuSE 6.x/7.x habe ich mir auch immer eigene optimierte
Kernel gebaut, aber nun schon lange nicht mehr.

Wenn wir da auf eisfair auf breiter Linie dazu auffordern,

- kann das die Situation in /boot verschärfen, wenn dann in /boot weitere
Dateien hinzukommen, die originalen Bootdateien aber auch vorhanden sind.

- dieses dann auch ein Kernelupdate verhindern.

- der jetzige Kernelupdateprozess IMHO eigene Bootabschnitte der lilo.conf
nicht berücksichtigt; Tom mag mich hier berichtigen.

- ein eigener Kernelbuild im Modulverzeichnis des Originalkernels
"rumpfuscht".

- ein Kernelupdate vielleicht bei Antreffen eines nicht originalen
eisfair-Kernels das Update abbrechen sollte.

> Einem Eisfair-Anwender, besser Eisfair-Administrator, 
> der in der Lage ist einen eigenen Kernel zu bauen traue ich durchaus
> zu auch bei einem System/Kernel-Update zu differenzieren und ggf.
> vorab einen Rückbau seiner Änderungen vorzunehmen.

Zutrauen ja, dann daran im passenden Augenblick denken, ist eine andere
Sache.

Zudem sollte es ein HowTo dafür geben, damit sich eigene Kernelexperimente
bestmöglich in eisfair "integrieren".

-- 
Gruss Marcus