Warum rattert meine festplatte, wenn ich auf einem remotehost im vi/less scrolle?

[Andreas Leitgeb]

Ist mir in der vergangenheit immerwiedermal aufgefallen:

ich bin per *gnome-terminal* und ssh auf einem remote-host eingeloggt,
und betrachte z.b. mit less eine große datei, und scrolle zeilenweise
runter, und mit jeder neuen Zeile oder Seite der Datei rödelt die lokale
platte... wenn Cursor-down für autorepeat gehalten wird, rödelt es
genausolange im takt mit - taste los: sofort kein rödeln mehr.

Der less bzw vi läuft dabei im sogenannten "priv" modus, es ist also
terminal-seitig gar kein scrollen möglich, also sehe ich keinen grund,
warum der gnome-terminal irgendwas auf die platte schreiben sollte,
wenn ich auf der remote-maschine was scrolle.

Frage 1: kennt jemand (der nicht komplett mit SSD ausgestattet ist,
der also die platte prinzipiell schon hören würde) das Symptom, oder ist
das nur bei mir so?

Frage 2: (falls allgemeines Problem): was will der gnome-terminal da genau
speichern, oder könnte es mit swap-bedarf zu tun haben?

PS: beim klassischen xterm ist bei gleichen remote-aktionen keine aktivität
auf der platte zu vernehmen.

[Johann Mayerwieser]

Am Mon, 21 Jun 2021 10:39:50 +0000 schrieb Andreas Leitgeb:

> Ist mir in der vergangenheit immerwiedermal aufgefallen:
>
> ich bin per *gnome-terminal* und ssh auf einem remote-host eingeloggt,
> und betrachte z.b. mit less eine große datei, und scrolle zeilenweise
> runter, und mit jeder neuen Zeile oder Seite der Datei rödelt die lokale
> platte... wenn Cursor-down für autorepeat gehalten wird, rödelt es
> genausolange im takt mit - taste los: sofort kein rödeln mehr.

Ich denke, du solltest einmal dein System genau beschreiben Motherboard,
Prozessor, Speicher, Grafikkarte, Festplatte. Eine Harddisk lässt in mir
den Verdacht aufkeimen, dass der Rest auch nicht mehr in den vorderen
Ligen spielt



--
Mailadresse ist gültig Mails werden nur gelesen, wenn im Betreff [usenet]
steht

[Andreas Leitgeb]

Johann Mayerwieser <johann.ma...@gmail.com> wrote:
> Am Mon, 21 Jun 2021 10:39:50 +0000 schrieb Andreas Leitgeb:
>> Ist mir in der vergangenheit immerwiedermal aufgefallen:
>> ich bin per *gnome-terminal* und ssh auf einem remote-host eingeloggt,
>> und betrachte z.b. mit less eine große datei, und scrolle zeilenweise
>> runter, und mit jeder neuen Zeile oder Seite der Datei rödelt die lokale
>> platte... wenn Cursor-down für autorepeat gehalten wird, rödelt es
>> genausolange im takt mit - taste los: sofort kein rödeln mehr.
> Ich denke, du solltest einmal dein System genau beschreiben Motherboard,
> Prozessor, Speicher, Grafikkarte, Festplatte. Eine Harddisk lässt in mir
> den Verdacht aufkeimen, dass der Rest auch nicht mehr in den vorderen
> Ligen spielt

Das ist vollkommen richtig.

Ich bin eigentlich froh, dass ich die Festplatte rödeln höre, *wenn*
sie aktiv ist, denn eine SSD ist zwar lautlos, aber wenn ohne berechtigen
Anlass sinnlos auf ihr rumgeschrieben wird, ist sie noch schneller hin
als eine HD.

Noch häufiger rödelt die platte, wenn ein tab im firefox ein paar
gigabyte als RSS zu brauchen glaubt. Dann schieß ich den tab weg,
starte ihn neu, und das werkl rennt wieder brav & schnell.

Ich suche keine Lösung gegen den rödel-lärm, sondern gegen den konkreten
Auslöser für den rödel-lärm, wenn lediglich im gnome-terminal gearbeitet
wird. Theoretisch könnte das ja auch heissen, dass alle ein- und ausgaben
im terminal mitprotokolliert werden ... - dann wäre ich sehr froh, wenn
ich es zumindest hörte, und vielleicht (mit eurer hilfe) abdrehen könnte.

[Johann Klammer]

Top oder htop koennen dir sagen wieviel speicher er frisst (virt und mem).
Vermutlich hat's aber irgendwas mit den konfigurations files zu tun.
Die gnome sachen lesen gern irgendein zeugs aus tausenden xml files die
auf der platte verteilt sind.
In /proc/<pid> herumzugraben kann auch aufschlussreich sein
fd
fdinfo
smaps

[Andreas Leitgeb]

Danke für die Tipps!

Der lsof zeigt mir für den prozess "gnome-terminal-server" ein paar
fd für bereits gelöschte Dateien in /tmp/ an, a la:
lrwx------ 1 avl avl 64 Jul 5 10:06 26 -> '/tmp/#1966388 (deleted)'
lrwx------ 1 avl avl 64 Jul 5 10:06 25 -> '/tmp/#1966396 (deleted)'
lrwx------ 1 avl avl 64 Jul 5 10:06 24 -> '/tmp/#1966816 (deleted)'

Über z.B. /proc/<pid>/fd/24 kann man diese dateien zwar lesen, aber
der Inhalt ist binär und erschließt sich mir (auch mit einem hexdump)
nicht so ohne weiteres.
Auffälligkeit:
- Es sind große 0-byte blöcke drin - anfangs, zwischendrin und auch am ende,
- Nach jedem 0er block fängt es an einer "runden" adresse (64k-alignment)
an mit einer 8byte gruppe, a la "CE 1C 00 00 01 00 00 00" was wohl zwei
little-endian ints sind, und (0x1cce + 24) bytes später fangen wieder die
nullen an. Die erste int dürfte also eine längenangabe sein, die um 16
kleiner ist, als die nach der 8byte-sequenz folgenden "zufallsdaten"
bis zum nächsten 0er-block.

Ob das aber schon die Dateien sind, in die geschrieben wird, kann ich
noch nicht sicher sagen, weil wenn ich im gnome-terminal einfach am
(lokalen) shellprompt die Return-taste auto-repeaten lasse, dann rattert
es auch auf der platte, aber diese dateien ändern nicht ihr mod-datum.
Erst ein eingegebenes kommando (a la "ls -l") bringt neueren Zeitstempel
auf einer (oder mehreren) dieser Dateien.

(Eigentlich sollte ja bei open-source so ein reverse-engineering nicht
nötig sein ;-) Werd dann auch mal googeln, aber jetzt schick ich das hier
mal ab...

[Stephan Weinberger]

On 05.07.21 11:11, Andreas Leitgeb wrote:

> Ob das aber schon die Dateien sind, in die geschrieben wird, kann ich
> noch nicht sicher sagen, weil wenn ich im gnome-terminal einfach am
> (lokalen) shellprompt die Return-taste auto-repeaten lasse, dann rattert
> es auch auf der platte, aber diese dateien ändern nicht ihr mod-datum.
> Erst ein eingegebenes kommando (a la "ls -l") bringt neueren Zeitstempel
> auf einer (oder mehreren) dieser Dateien.

Könnte man aber recht einfach testen, indem man /tmp als tmpfs/ramfs
mountet.

[J. Kubiak]

Am 21.06.21 um 12:39 schrieb Andreas Leitgeb:
> [...]

> Der less bzw vi läuft dabei im sogenannten "priv" modus, es ist also
> terminal-seitig gar kein scrollen möglich, also sehe ich keinen grund,
> warum der gnome-terminal irgendwas auf die platte schreiben sollte,
> wenn ich auf der remote-maschine was scrolle.
>
> Frage 1: kennt jemand (der nicht komplett mit SSD ausgestattet ist,
> der also die platte prinzipiell schon hören würde) das Symptom, oder ist
> das nur bei mir so?
>
> Frage 2: (falls allgemeines Problem): was will der gnome-terminal da genau
> speichern, oder könnte es mit swap-bedarf zu tun haben?
>
> PS: beim klassischen xterm ist bei gleichen remote-aktionen keine aktivität
> auf der platte zu vernehmen.

> [...]

Hallo,

ich würde auch mal nachschauen, ob aus dem Memory was auf die Platte
rausgeswapt wird, mit anderen Worten die Speicherauslastung mal anschauen.

Kommando:
free -h

Bei mir sieht es zum Beispiel so aus (also wird nix rausgeswapt, man
sollte auch nicht zu viel SWAP anbieten, weil das quasi das Swapen
provoziert - habe ich jedenfalls mal so vor ca. 25 Jahren irgendwo
gelesen ;-)

free -h
total used free shared buff/cache available
Mem: 3,8Gi 754Mi 1,5Gi 103Mi 1,5Gi 2,7Gi
Swap: 7,7Gi 0B 7,7Gi

-cu at the bitstream, Juergen

[Stephan Weinberger]

On 11.07.21 20:00, J. Kubiak wrote:

>
> Bei mir sieht es zum Beispiel so aus (also wird nix rausgeswapt, man
> sollte auch nicht zu viel SWAP anbieten, weil das quasi das Swapen
> provoziert - habe ich jedenfalls mal so vor ca. 25 Jahren irgendwo
> gelesen ;-)

Man kann auch die "swappiness" konfigurieren.

[Johann Klammer]

Inzwischen (seit gefuehlt ver 4.irgendwas) swappt er fast gar nicht mehr, egal wie die swappiness konfiguriert ist..
Bei dir das 'used 0B' in der zweiten zeile.
(weiss auch nicht was das soll.)

Hier isses:

total used free shared buffers cached
Mem: 500M 475M 25M 9.3M 404K 305M
-/+ buffers/cache: 169M 331M
Swap: 1.2G 80M 1.1G

Und die 80M aendern sich auch nicht wenn die OOMs kommen.(swappiness ist auf 60)

Software sells Hardware.