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

Ansgar Püster ansgar.puester at netcologne.de
Sa Sep 26 09:42:33 CEST 2015


Hallo,

der wesentliche Unterschied zwischen iostat und iotop ist,
dass iostat Angaben _je Device_ anzeigt, während iotop,
wie top, Angaben _je Prozess_ (sogar je Thread) anzeigt.

Beispiel:

Total DISK READ :     400.10 K/s | Total DISK WRITE :      32.65 K/s
Actual DISK READ:     400.10 K/s | Actual DISK WRITE:       5.56 K/s
   TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
  1149 be/3 root        0.00 B/s   13.89 K/s  0.00 %  0.83 % [jbd2/hda3-8]
  1650 be/6 root      400.10 K/s    0.00 B/s  0.00 %  0.00 % xzcat -d 
linux-3.2.67.tar.xz
  1651 be/6 root        0.00 B/s   18.75 K/s  0.00 %  0.00 % tar tvf -
  1536 be/6 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % sshd: 
root at pts/0

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

CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y

kommen kann.

eisgcc # file /boot/kernel*
/boot/kernel:     Linux/x86 Kernel, Setup Version 0x20a, bzImage, 
Version 3.2.67-eisfair-1-SMP (root at eisgcc) #2 SMP Thu Sep 24 17:41:23 C, 
RO-rootFS, swap_dev 0x2, Normal VGA
/boot/kernel.old: Linux/x86 Kernel, Setup Version 0x20a, bzImage, 
Version 3.2.67-eisfair-1-SMP (root at kernel32) #1 SMP Thu May 21 22:07:35, 
RO-rootFS, swap_dev 0x2, Normal VGA

Ich finde die Vorgehensweise von Tom nicht alles einbauen, insbesondere
bei EXPERIMENTAL Parametern, sondern Hinweis auf das Paket kernel-dev
höchst sinnvoll. 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.

So weit erst mal.
Gruß,
Ansgar

Am 18.09.2015 um 14:59 schrieb Marcus Roeckrath:
> Hallo Stefan,
>
> Stefan Welte wrote:
>
>>> Warum soll ich den Kernel für _alle_ mit Features aufblähen,
>> ist abzuwägen. Wieviel würde er hierdurch aufgebläht? Gibt es ausser der
>> Aufblähung andere Nachteile? Ich kenne keine Desktop-/Server Distribution,
>> die iotop nicht anbietet. Mir ist natürlich auch ein schlankes System
>> lieber. iotop finde ich ein nützliches Tool für einen Server, gibt es eine
>> Alternative?
>
>> [1] beschreibt eine Lastdiagnose, komischerweise ohne iotop, stattdessen
>> [wird iostat erwähnt. Aber
>> vermutlich braucht das auch dieselben Kerneloptionen und kann womöglich
>> weniger als iotop.
>
> Das ist die Homepage:
> http://sebastien.godard.pagesperso-orange.fr/man_iostat.html
>
> Da ist nirgendwo (auch nicht im Sourcecode-Archiv) von speziellen
> Kerneloptionen die Rede.
>
> iostat benutzt das proc-Subsystem; ob das gegenüber iotop ähnliche
> Informationen liefert, kann ich nun aber nicht sagen.
>
>>> Es existiert ein Paket kernel-dev, welches es Jedem erlaubt, sich auf der
>>> Basis des eisfair-Kernels einen weiter angepassten Kernel zu bauen und
>>> diesen einzusetzen.
>> nicht jedem; nur denen, die einen eisfair-dev besitzen/am Laufen haben.
>> Ich habe derzeit keinen. Gibt es einen (nicht-/halb-)öffentlichen, den man
>> ein paar Stunden nutzen kann dafür?
>
> Du brauchst keinen speziellen Server zum Kompilieren, mache ich auch alles
> auf meinem Produktivsystem; developer-Paket und natürlich die Kernelsourcen
> müssen vorhanden sein.
>
> Allerdings würde es mich nicht begeistern, wenn eisfair-anwender nun dazu
> angeleitet werden, sich eingene Kernel zu basteln; das läßt sich nicht
> supporten und gibt uns bei System/Kernel-Updates nur Unwägbarkeiten.
>



Mehr Informationen über die Mailingliste Eisfair