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

[Ansgar Püster]

Moin,

um die Linux-Welt wieder in Ordnung zu bringen.

Da ich den Kernel während einer Busreise in einer virtuellen
Maschine erstellt habe, für die ich zu wenig Memory
konfiguriert hatte, hatte ich zusätzlich

CONFIG_KERNEL_LZMA ausgeschaltet und statt dessen
CONFIG_KERNEL_GZIP eingeschaltet

lzma benötigt beim Compress mehr Memory als gzip und brachte
daher einen Fehler:
  lzma: (stdin): Cannot allocate memory

Der jetzt gem. dot-config-smp mit
  CONFIG_KERNEL_LZMA=y
erzeugte Kernel, Erweiterung nur noch
  CONFIG_TASKSTATS=y
  CONFIG_TASK_DELAY_ACCT=y
  CONFIG_TASK_XACCT=y
  CONFIG_TASK_IO_ACCOUNTING=y
sieht wie folgt aus:

eisgcc # ls -la /boot/ker*
-rw-r--r-- 1 root root 2285728 Sep 28 15:09 /boot/kernel
-rw-r--r-- 1 root root 2281648 Sep 22 19:18 /boot/kernel.old

und ist damit nur um 0,18% größer als Tom's Original.

Ich benutze (natürlich) keinen anderen Buildprozess.
Sorry, dass ich euch unnötige Arbeit gemacht habe.

War mir auch nicht so klar, dass zwischen lzma und gzip
so ein großer Unterschied besteht. Ich habe meine letzten
Kernel bei den Analysen für des Paket power_button (ACPID)
und davor beim "Basteln" mit einem Adaptek AHA-1542 gemacht.
Ist also ewig her. Ich bitte euch daher um Nachsicht ;-)

Gruß,
Ansgar

Am 28.09.2015 um 09:22 schrieb Marcus Roeckrath:
> Hallo Thomas,
>
> Thomas Bork wrote:
>
>>>> 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.
>>
>> Das halte ich für unwahrscheinlich, wenn Ansgar nicht sehr exotisch
>> vorgegangen ist.
>>
>>>> CONFIG_TASKSTATS=y
>>>> CONFIG_TASK_DELAY_ACCT=y
>>>> CONFIG_TASK_XACCT=y
>>>> CONFIG_TASK_IO_ACCOUNTING=y
>
> Interessant, dass diese Optionen den Kernel um ca. 20% aufblähen.
>
>> Mit der selben Begründung könnte man nämlich auch x Treiber fest (und
>> nicht als Modul) in den Kernel integrieren, die aber 90% aller Anwender
>> gar nicht benötigen, weil sie die entsprechende Hardware nicht besitzen...
>
> Ganz Deiner Meinung und wenn obige Optionen den Kernel wirklich so groß
> werden lassen, lassen wir es besser.
>
> Da es ja darum ging, einem Problem auf die Spur zu kommen, aber die Optionen
> nicht für den normalen Betrieb notwendig sind, wäre in diesem Fall dann
> doch dazu angeraten, sich einen eigenen Kernel zu bauen, den man ja nach
> Abschluss der Tests wieder entfernt.
>