Ich nutze Tumbleweed in aktuelle Version. Als CPU habe ich einen i7 6700k und 16GB Hauptspeicher. Das Problem ärgert mich schon sehr lange. Wenn ich mit Handbrake einen Film konvertiere oder eine größere Datei entpacke scheint es so, als ob ich ein extrem langsame System habe. Während dieser Zeit kann ich keine weitere Anwendung öffnen oder schließen. Die Anwendungen reagieren einfach nicht. Heute habe ich mal wieder VirtualBox gestartet. Ich habe mich schon daran gewöhnt, dass während Windows10 startet mit Linux nicht mehr viel anzufangen ist. Aber heute hat sich gerade noch das Fenster von Windows10 geöffnet (noch keine Anmeldung) und dann hat irgendwer, weit über eine Stunde die Festplatte zum glühen gebracht. Kein Fenster hat mehr reagiert. lediglich ein Konsole konnte ich noch öffnen und habe dann aus Frust VirtBox samt Windows10 mit kill ins Nirvana geschickt. Gerade habe ich den 2 Versuch auf gleiche Weise abgebrochen. Habt ihr eine Idee wo ich ansetzen kann. Die Probleme mit VirtBox und Windows10 sind erst einmal völlig nebensächlich. Mir würde es schon reichen, wenn ich auch unter Linux spüre, dass ich ein (hoffentlich) leistungsfähiges System habe. Mit freundlichem Gruß Karl Brandt -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 03.09.2018 um 16:57 schrieb Karl Brandt:
Ich nutze Tumbleweed in aktuelle Version.
Als CPU habe ich einen i7 6700k und 16GB Hauptspeicher.
Das Problem ärgert mich schon sehr lange.
Wenn ich mit Handbrake einen Film konvertiere oder eine größere Datei entpacke scheint es so, als ob ich ein extrem langsame System habe. Während dieser Zeit kann ich keine weitere Anwendung öffnen oder schließen. Die Anwendungen reagieren einfach nicht.
Heute habe ich mal wieder VirtualBox gestartet. Ich habe mich schon daran gewöhnt, dass während Windows10 startet mit Linux nicht mehr viel anzufangen ist. Aber heute hat sich gerade noch das Fenster von Windows10 geöffnet (noch keine Anmeldung) und dann hat irgendwer, weit über eine Stunde die Festplatte zum glühen gebracht. Kein Fenster hat mehr reagiert. lediglich ein Konsole konnte ich noch öffnen und habe dann aus Frust VirtBox samt Windows10 mit kill ins Nirvana geschickt. Gerade habe ich den 2 Versuch auf gleiche Weise abgebrochen.
Habt ihr eine Idee wo ich ansetzen kann. Die Probleme mit VirtBox und Windows10 sind erst einmal völlig nebensächlich. Mir würde es schon reichen, wenn ich auch unter Linux spüre, dass ich ein (hoffentlich) leistungsfähiges System habe.
Mit freundlichem Gruß
Karl Brandt
Hi, ich habe ähnliche Probleme. Das System geht täglich mehrmals in einen Status wo es auf nichts mehr reagiert. Manchmal fängt es sich nach einiger Zeit, aber oft muss ich es einfach abschiessen. Kein Plan was da Probleme macht und keine Ahnung wo ich suchen kann. zur Info: 42.3, VirtualBox und Filme im Browser sind meist involviert. Ich hatte schon den Verdacht dass es irgendwie mit der Nutzung der Festplatten zusammenhängt. Dies könnte auch bei Dir der Fall sein (Virtualbox mit seiner VIrtuellen Platte, Handbrake und große Dateien). Wie kann man prüfen ob Dateioperationen das System zum Freeze bringen? Gruß, Karl -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo Karl, Am Montag 03 September 2018 schrieb Karl Brandt:
Ich nutze Tumbleweed in aktuelle Version.
Als CPU habe ich einen i7 6700k und 16GB Hauptspeicher.
Das Problem ärgert mich schon sehr lange.
Wenn ich mit Handbrake einen Film konvertiere oder eine größere Datei entpacke scheint es so, als ob ich ein extrem langsame System habe. Während dieser Zeit kann ich keine weitere Anwendung öffnen oder schließen. Die Anwendungen reagieren einfach nicht.
[...]
Habt ihr eine Idee wo ich ansetzen kann.
Das hier? https://www.pro-linux.de/news/1/26259/meltdown-amp-co-leistungsverluste-mess... Ansonsten fällt mir da nur Deine restliche Hardware ein. Je nachdem, was Du da benutzt, mag es durchaus noch den ein oder anderen Flaschenhals geben. Helga -- ## Technik: [http://de.opensuse.org] ## Privat: [http://www.eschkitai.de] -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 03.09.2018 um 18:38 schrieb Helga Fischer:
Hallo Karl,
Am Montag 03 September 2018 schrieb Karl Brandt:
Ich nutze Tumbleweed in aktuelle Version.
Als CPU habe ich einen i7 6700k und 16GB Hauptspeicher.
Das Problem ärgert mich schon sehr lange.
Wenn ich mit Handbrake einen Film konvertiere oder eine größere Datei entpacke scheint es so, als ob ich ein extrem langsame System habe. Während dieser Zeit kann ich keine weitere Anwendung öffnen oder schließen. Die Anwendungen reagieren einfach nicht. [...]
Habt ihr eine Idee wo ich ansetzen kann. Das hier?
https://www.pro-linux.de/news/1/26259/meltdown-amp-co-leistungsverluste-mess...
Ansonsten fällt mir da nur Deine restliche Hardware ein. Je nachdem, was Du da benutzt, mag es durchaus noch den ein oder anderen Flaschenhals geben.
Helga
Hallo Helga, und wie kommt man den "Flaschenhälsen" auf die Spur? Gruß, Karl -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo, On Mon, 03 Sep 2018, Karl Sinn wrote:
und wie kommt man den "Flaschenhälsen" auf die Spur?
konsole: dd if=/dev/zero of=/mnt/festplatte_mit_deinen_daten.img bs=10M # tritt hier das Problem auf? => Festplatte, Datenzugriff dd if=/dev/urandom | bzip2 | bzip2 | bzip2 | bzip2 > /dev/null # tritt hier das Problem (nach einiger Zeit) auf? => CPU zu warm / Lüftung unzureichend tritt das Problem bei keinem der Befehle oben auf, solltest du u.U. Richtung Graphik weiter suchen. Greetings Daniel -- Wenn Du denkst, Du bist unersetzbar, dann schau auf den Friedhof, der ist voll davon! -- unknown -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 04.09.2018 um 20:06 schrieb Daniel Lord:
Hallo,
On Mon, 03 Sep 2018, Karl Sinn wrote:
und wie kommt man den "Flaschenhälsen" auf die Spur? konsole:
dd if=/dev/zero of=/mnt/festplatte_mit_deinen_daten.img bs=10M # tritt hier das Problem auf? => Festplatte, Datenzugriff
selbst wenn ich vier dieser Prozesse auf 4 Festplatten gleichzeitig laufen lasse führt dies nicht zum Freeze, Das System reagiert ein wenig langsam aber ich kann jederzeit zwischen Fenstern wechseln und selbst ein Video läuft nebenbei ohne Probleme (klar, der Prozessor ist auch nicht ausgelastet)
dd if=/dev/urandom | bzip2 | bzip2 | bzip2 | bzip2 > /dev/null # tritt hier das Problem (nach einiger Zeit) auf? => CPU zu warm / Lüftung unzureichend
führt auch zu keinem Problem, allerdings werden meine 6 Kerne im Schnitt nur unter 30% belastet mit dem Befehl. Ich hatte allerdings gestern eine Statistisk am laufen die alle Kerne auf über 80% bringt und das für 3h ca. Dabei gab es auch keine Probleme.
tritt das Problem bei keinem der Befehle oben auf, solltest du u.U. Richtung Graphik weiter suchen.
Greetings Daniel
bleiben im Moment drei mögliche Übeltäter: - Graphik - Swap - Virtualbox Wie kann ich das testen? Gruß, Karl2 p.S.: ich unterschreibe jetzt mal mit Karl2, um Verwechslungen mit dem OP zu vermeiden ;) -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Karl Sinn wrote:
Am 04.09.2018 um 20:06 schrieb Daniel Lord:
Hallo,
On Mon, 03 Sep 2018, Karl Sinn wrote:
und wie kommt man den "Flaschenhälsen" auf die Spur? konsole:
dd if=/dev/zero of=/mnt/festplatte_mit_deinen_daten.img bs=10M # tritt hier das Problem auf? => Festplatte, Datenzugriff
selbst wenn ich vier dieser Prozesse auf 4 Festplatten gleichzeitig laufen lasse führt dies nicht zum Freeze, Das System reagiert ein wenig langsam aber ich kann jederzeit zwischen Fenstern wechseln und selbst ein Video läuft nebenbei ohne Probleme (klar, der Prozessor ist auch nicht ausgelastet)
dd if=/dev/urandom | bzip2 | bzip2 | bzip2 | bzip2 > /dev/null # tritt hier das Problem (nach einiger Zeit) auf? => CPU zu warm / Lüftung unzureichend
führt auch zu keinem Problem, allerdings werden meine 6 Kerne im Schnitt nur unter 30% belastet mit dem Befehl. Ich hatte allerdings gestern eine Statistisk am laufen die alle Kerne auf über 80% bringt und das für 3h ca. Dabei gab es auch keine Probleme.
tritt das Problem bei keinem der Befehle oben auf, solltest du u.U. Richtung Graphik weiter suchen.
Greetings Daniel
bleiben im Moment drei mögliche Übeltäter: - Graphik - Swap - Virtualbox
Wie kann ich das testen?
Gruß, Karl2
p.S.: ich unterschreibe jetzt mal mit Karl2, um Verwechslungen mit dem OP zu vermeiden ;)
Ich habe die Test ebenfalls durchgeführt und komme, bezüglich der CPU-Auslastung und Nutzbarkeit des Systems, zu ähnlichen Ergebnissen. Mit freundlichem Gruß Karl Brandt -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo, On Wed, 05 Sep 2018, Karl Brandt wrote:
Karl Sinn wrote:
Am 04.09.2018 um 20:06 schrieb Daniel Lord:
und wie kommt man den "Flaschenhälsen" auf die Spur? konsole: [...]
On Mon, 03 Sep 2018, Karl Sinn wrote: tritt das Problem bei keinem der Befehle oben auf, solltest du u.U. Richtung Graphik weiter suchen.
bleiben im Moment drei mögliche Übeltäter: - Graphik - Swap - Virtualbox [...] Wie kann ich das testen? Ich habe die Test ebenfalls durchgeführt und komme, bezüglich der CPU-Auslastung und Nutzbarkeit des Systems, zu ähnlichen Ergebnissen
Graphik (bin ich nicht so der Held :-) - glxgears fällt mir dazu erstmal ein, alternativ remote X siehe unten Swap: (füllen wir mal den RAM, swappen wird er dann alleine...) entweder dd if=/dev/zero of=/dev/shm/fillmyram-with-zeros.img bs=100M oder sudo mkdir -p /mnt/ram sudo mount -o size=17000M -t tmpfs none /mnt/ram virtualbox: von einem anderen Rechner (PC2) aus per ssh auf deinem Rechner (PC1) einloggen ssh -X -Y -C user@deineipvonPC1 dann aus dieser konsole auf dem PC2 virtualbox auf deinem PC1 starten. die GUI wird dann auf PC2 dargestellt, und Graphikprobleme sollten (wenn das im LAN ist) dann nicht auftreten. => wenn Virtualbox dort sauber läuft hast du u.U. ein Graphikproblem. Wenn Dinge klemmen ist dmesg sonst noch ein guter Befehl, der PC motzt u.U. auch mal über IRQs, lange Wartezeiten, Blocking IO... Das kann helfen. D.h. die Ausgabe von dmesg vor und nach dem Problem mal anschauen. Greetings Daniel -- Please tell me more lies -- Believe -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo, On Wed, 05 Sep 2018, Daniel Lord wrote:
entweder dd if=/dev/zero of=/dev/shm/fillmyram-with-zeros.img bs=100M oder sudo mkdir -p /mnt/ram sudo mount -o size=17000M -t tmpfs none /mnt/ram den Befehl hatte ich vergessen... dd if=/dev/zero of=/mnt/ram/fillmyram-with-zeros.img bs=100M
Greetings Daniel -- Eigentlich bin ich ja ganz anders... ...ich komme nur so selten dazu. -- unknown -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Graphik (bin ich nicht so der Held :-) - glxgears fällt mir dazu erstmal ein, alternativ remote X siehe unten
Auf der Suche nach glxgears bin ich zuerst auf die Info gestossen, dass dies kein Benchmark ist und wurde auf Unigine_Valley-1.0 aufmerksam gemacht. Ich hab das ne Weile rennen lassen und stosse dabei in der Tat an die Leistungsgrenze meiner Grafikkarte. Ich erkenne auch das Ruckeln wieder, die GraKa ist also definitiv ein Flaschenhals bei mir. Allerdings hat das Programm auch nach längerem Lauf nicht dazu geführt dass der Rechner unresponsiv wurde. Ich konnte jederzeit relativ zügig auf die Konsole switchen und dort gegebenenfalls etwas killen. Die GraKa ist also Flaschenhals, aber führt nicht zu den Freezes.
Swap: (füllen wir mal den RAM, swappen wird er dann alleine...) entweder dd if=/dev/zero of=/dev/shm/fillmyram-with-zeros.img bs=100M oder sudo mkdir -p /mnt/ram sudo mount -o size=17000M -t tmpfs none /mnt/ram
spannend :) beim ersten Lauf hat XFCE4 sich verabschiedet und ich bin sofort auf den Anmeldebildschirm zurückgekommen. Scheinbar hat da irgendein Sicherungsmechanismus gegriffen, der den Prozess beendet hat. Bei jedem weiteren Versuch wurde auf der Konsole einfach nur angezeigt, dass der Prozess einfach gekillt wurde. Also auch nicht das, was den Rechner komplett lahmlegt. Eine andere Idee wie ich den Swap ans Limit bringen kann?
virtualbox: von einem anderen Rechner (PC2) aus per ssh auf deinem Rechner (PC1) einloggen ssh -X -Y -C user@deineipvonPC1 dann aus dieser konsole auf dem PC2 virtualbox auf deinem PC1 starten. die GUI wird dann auf PC2 dargestellt, und Graphikprobleme sollten (wenn das im LAN ist) dann nicht auftreten.
=> wenn Virtualbox dort sauber läuft hast du u.U. ein Graphikproblem.
mangels 2tem PC werde ich das im Moment nicht testen können.
Wenn Dinge klemmen ist dmesg sonst noch ein guter Befehl, der PC motzt u.U. auch mal über IRQs, lange Wartezeiten, Blocking IO... Das kann helfen. D.h. die Ausgabe von dmesg vor und nach dem Problem mal anschauen.
Greetings Daniel
-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 2018-09-06 17:40 schrieb Karl Sinn:
Graphik (bin ich nicht so der Held :-) - glxgears fällt mir dazu erstmal ein, alternativ remote X siehe unten
Auf der Suche nach glxgears bin ich zuerst auf die Info gestossen, dass dies kein Benchmark ist und wurde auf Unigine_Valley-1.0 aufmerksam gemacht. Ich hab das ne Weile rennen lassen und stosse dabei in der Tat an die Leistungsgrenze meiner Grafikkarte. Ich erkenne auch das Ruckeln wieder, die GraKa ist also definitiv ein Flaschenhals bei mir. Allerdings hat das Programm auch nach längerem Lauf nicht dazu geführt dass der Rechner unresponsiv wurde. Ich konnte jederzeit relativ zügig auf die Konsole switchen und dort gegebenenfalls etwas killen. Die GraKa ist also Flaschenhals, aber führt nicht zu den Freezes.
Swap: (füllen wir mal den RAM, swappen wird er dann alleine...) entweder dd if=/dev/zero of=/dev/shm/fillmyram-with-zeros.img bs=100M oder sudo mkdir -p /mnt/ram sudo mount -o size=17000M -t tmpfs none /mnt/ram
spannend :) beim ersten Lauf hat XFCE4 sich verabschiedet und ich bin sofort auf den Anmeldebildschirm zurückgekommen. Scheinbar hat da irgendein Sicherungsmechanismus gegriffen, der den Prozess beendet hat.
Bei jedem weiteren Versuch wurde auf der Konsole einfach nur angezeigt, dass der Prozess einfach gekillt wurde. Also auch nicht das, was den Rechner komplett lahmlegt.
Eine andere Idee wie ich den Swap ans Limit bringen kann?
virtualbox: von einem anderen Rechner (PC2) aus per ssh auf deinem Rechner (PC1) einloggen ssh -X -Y -C user@deineipvonPC1 dann aus dieser konsole auf dem PC2 virtualbox auf deinem PC1 starten. die GUI wird dann auf PC2 dargestellt, und Graphikprobleme sollten (wenn das im LAN ist) dann nicht auftreten.
=> wenn Virtualbox dort sauber läuft hast du u.U. ein Graphikproblem.
mangels 2tem PC werde ich das im Moment nicht testen können.
Wenn Dinge klemmen ist dmesg sonst noch ein guter Befehl, der PC motzt u.U. auch mal über IRQs, lange Wartezeiten, Blocking IO... Das kann helfen. D.h. die Ausgabe von dmesg vor und nach dem Problem mal anschauen.
Greetings Daniel
Hast Du meinen Tip mit "iotop" schon probiert? Wenn ja, was hat das ergeben? -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 06.09.2018 um 17:47 schrieb Norbert Zawodsky:
Am 2018-09-06 17:40 schrieb Karl Sinn:
Graphik (bin ich nicht so der Held :-) - glxgears fällt mir dazu erstmal ein, alternativ remote X siehe unten
Auf der Suche nach glxgears bin ich zuerst auf die Info gestossen, dass dies kein Benchmark ist und wurde auf Unigine_Valley-1.0 aufmerksam gemacht. Ich hab das ne Weile rennen lassen und stosse dabei in der Tat an die Leistungsgrenze meiner Grafikkarte. Ich erkenne auch das Ruckeln wieder, die GraKa ist also definitiv ein Flaschenhals bei mir. Allerdings hat das Programm auch nach längerem Lauf nicht dazu geführt dass der Rechner unresponsiv wurde. Ich konnte jederzeit relativ zügig auf die Konsole switchen und dort gegebenenfalls etwas killen. Die GraKa ist also Flaschenhals, aber führt nicht zu den Freezes.
Swap: (füllen wir mal den RAM, swappen wird er dann alleine...) entweder dd if=/dev/zero of=/dev/shm/fillmyram-with-zeros.img bs=100M oder sudo mkdir -p /mnt/ram sudo mount -o size=17000M -t tmpfs none /mnt/ram
spannend :) beim ersten Lauf hat XFCE4 sich verabschiedet und ich bin sofort auf den Anmeldebildschirm zurückgekommen. Scheinbar hat da irgendein Sicherungsmechanismus gegriffen, der den Prozess beendet hat.
Bei jedem weiteren Versuch wurde auf der Konsole einfach nur angezeigt, dass der Prozess einfach gekillt wurde. Also auch nicht das, was den Rechner komplett lahmlegt.
Eine andere Idee wie ich den Swap ans Limit bringen kann?
virtualbox: von einem anderen Rechner (PC2) aus per ssh auf deinem Rechner (PC1) einloggen ssh -X -Y -C user@deineipvonPC1 dann aus dieser konsole auf dem PC2 virtualbox auf deinem PC1 starten. die GUI wird dann auf PC2 dargestellt, und Graphikprobleme sollten (wenn das im LAN ist) dann nicht auftreten.
=> wenn Virtualbox dort sauber läuft hast du u.U. ein Graphikproblem.
mangels 2tem PC werde ich das im Moment nicht testen können.
Wenn Dinge klemmen ist dmesg sonst noch ein guter Befehl, der PC motzt u.U. auch mal über IRQs, lange Wartezeiten, Blocking IO... Das kann helfen. D.h. die Ausgabe von dmesg vor und nach dem Problem mal anschauen.
Greetings Daniel
Hast Du meinen Tip mit "iotop" schon probiert? Wenn ja, was hat das ergeben?
ja, hab ich, ich hab noch nichts dazu geschrieben, weil es noch nichts ergeben hat. iotop und htop laufen in zwei Fenstern im Moment immer mit. Das eine mal, dass es seitdem passiert ist, konnte ich da leider nichts sehen, weil das System eben komplett in den Freeze gegangen ist und die beiden Prozesse nicht aktualisiert hat. D.h. was ich da gesehen habe während und nach dem Freeze war ganz normal. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 06.09.2018 um 17:40 schrieb Karl Sinn:
Graphik (bin ich nicht so der Held :-) - glxgears fällt mir dazu erstmal ein, alternativ remote X siehe unten
Auf der Suche nach glxgears bin ich zuerst auf die Info gestossen, dass dies kein Benchmark ist und wurde auf Unigine_Valley-1.0 aufmerksam gemacht. Ich hab das ne Weile rennen lassen und stosse dabei in der Tat an die Leistungsgrenze meiner Grafikkarte. Ich erkenne auch das Ruckeln wieder, die GraKa ist also definitiv ein Flaschenhals bei mir. Allerdings hat das Programm auch nach längerem Lauf nicht dazu geführt dass der Rechner unresponsiv wurde. Ich konnte jederzeit relativ zügig auf die Konsole switchen und dort gegebenenfalls etwas killen. Die GraKa ist also Flaschenhals, aber führt nicht zu den Freezes.
Swap: (füllen wir mal den RAM, swappen wird er dann alleine...) entweder dd if=/dev/zero of=/dev/shm/fillmyram-with-zeros.img bs=100M oder sudo mkdir -p /mnt/ram sudo mount -o size=17000M -t tmpfs none /mnt/ram
spannend :) beim ersten Lauf hat XFCE4 sich verabschiedet und ich bin sofort auf den Anmeldebildschirm zurückgekommen. Scheinbar hat da irgendein Sicherungsmechanismus gegriffen, der den Prozess beendet hat.
Bei jedem weiteren Versuch wurde auf der Konsole einfach nur angezeigt, dass der Prozess einfach gekillt wurde. Also auch nicht das, was den Rechner komplett lahmlegt.
Eine andere Idee wie ich den Swap ans Limit bringen kann?
Eventuell hilft dir da das Paket stress-ng weiter. Damit lässt sich so ziemlich alles testen Gruß Manfred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Eine andere Idee wie ich den Swap ans Limit bringen kann?
Eventuell hilft dir da das Paket stress-ng weiter. Damit lässt sich so ziemlich alles testen
Gruß Manfred
uh, nice!! :) "stress-ng -all 1" hat das System in Sekundenschnelle zum Erliegen gebracht. Ich muss mir das in Ruhe ansehen und schrittweise testen. Ich melde mich wenn ich durch bin -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Karl Sinn schrieb:
Eine andere Idee wie ich den Swap ans Limit bringen kann?
Eventuell hilft dir da das Paket stress-ng weiter. Damit lässt sich so ziemlich alles testen
Gruß Manfred
uh, nice!! :) "stress-ng -all 1" hat das System in Sekundenschnelle zum Erliegen gebracht. Ich muss mir das in Ruhe ansehen und schrittweise testen. Ich melde mich wenn ich durch bin
stress-ng -r 256 und es passiert nichts. 100% CPU-Auslastung, aber es läuft alles, auch über einen Zeitraum von 30 Minuten. Mit freundlichem Gruß Karl Brandt -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 07.09.2018 um 08:55 schrieb Karl Brandt:
Karl Sinn schrieb:
Eine andere Idee wie ich den Swap ans Limit bringen kann?
Eventuell hilft dir da das Paket stress-ng weiter. Damit lässt sich so ziemlich alles testen
Gruß Manfred
uh, nice!! :) "stress-ng -all 1" hat das System in Sekundenschnelle zum Erliegen gebracht. Ich muss mir das in Ruhe ansehen und schrittweise testen. Ich melde mich wenn ich durch bin
stress-ng -r 256 und es passiert nichts. 100% CPU-Auslastung, aber es läuft alles, auch über einen Zeitraum von 30 Minuten.
Mit freundlichem Gruß Karl Brandt
Ich habs jetzt nur einmal probiert, dabei ist bei mir das System sofort weg gewesen. Das Problem ist, dass random Stresstests ausgeführt werden und ich keine Ahnung habe welcher das Problem getriggert hat. Um das Problem zu finden muss man die Tests Schritt für Schritt durchgehen. Ich gehe gerade nach dieser Seite vor: https://wiki.ubuntu.com/Kernel/Reference/stress-ng Ich gehe Schritt für Schritt die Liste unter "Classes" durch mit z.B.: stress-ng --class cpu --seq 0 -t 30 -v Damit startet er 6 Prozesse (für meine 6 Kerne) für jeden Stresstest der zur Klasse cpu (aus der Liste von der Website) gehört sequentiell hintereinander für jeweils 30sec und zeigt mir dabei an welchen Test er gerade macht. Damit sehe ich bei welchem Test die Dinge durcheinandergeraten. Gruß, Karl2 -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Karl Sinn schrieb:
Am 07.09.2018 um 08:55 schrieb Karl Brandt:
Karl Sinn schrieb:
Eine andere Idee wie ich den Swap ans Limit bringen kann?
Eventuell hilft dir da das Paket stress-ng weiter. Damit lässt sich so ziemlich alles testen
Gruß Manfred
uh, nice!! :) "stress-ng -all 1" hat das System in Sekundenschnelle zum Erliegen gebracht. Ich muss mir das in Ruhe ansehen und schrittweise testen. Ich melde mich wenn ich durch bin
stress-ng -r 256 und es passiert nichts. 100% CPU-Auslastung, aber es läuft alles, auch über einen Zeitraum von 30 Minuten.
Mit freundlichem Gruß Karl Brandt
Ich habs jetzt nur einmal probiert, dabei ist bei mir das System sofort weg gewesen. Das Problem ist, dass random Stresstests ausgeführt werden und ich keine Ahnung habe welcher das Problem getriggert hat. Um das Problem zu finden muss man die Tests Schritt für Schritt durchgehen.
Ich gehe gerade nach dieser Seite vor: https://wiki.ubuntu.com/Kernel/Reference/stress-ng
Ich gehe Schritt für Schritt die Liste unter "Classes" durch mit z.B.: stress-ng --class cpu --seq 0 -t 30 -v
Damit startet er 6 Prozesse (für meine 6 Kerne) für jeden Stresstest der zur Klasse cpu (aus der Liste von der Website) gehört sequentiell hintereinander für jeweils 30sec und zeigt mir dabei an welchen Test er gerade macht. Damit sehe ich bei welchem Test die Dinge durcheinandergeraten.
Gruß, Karl2
So zum Spaß habe ich mal stress-ng --mq 0 -t 30s --times --perf So etwas wird ausgegeben (drastisch gekürzt). Für mich ist das keine Hilfe, sondern stress. Da muss ich wohl noch lesen, lesen. .... bevor ich die Ausgaben zielführend interpretieren kann. stress-ng: info: [10760] dispatching hogs: 8 mq stress-ng: info: [10760] successful run completed in 30.87s stress-ng: info: [10760] mq: stress-ng: info: [10760] 798.083.948.512 CPU Cycles 25,85 B/sec stress-ng: info: [10760] 298.478.080.536 Instructions 9,67 B/sec (0,374 instr. per cycle) ......... stress-ng: info: [10760] 96 SKB Kfree 3,11 /sec stress-ng: info: [10760] 0 IOMMU IO Page Fault 0,00 /sec stress-ng: info: [10760] 0 IOMMU Map 0,00 /sec stress-ng: info: [10760] 0 IOMMU Unmap 0,00 /sec stress-ng: info: [10760] for a 30,87s run time: stress-ng: info: [10760] 246,99s available CPU time stress-ng: info: [10760] 37,56s user time ( 15,21%) stress-ng: info: [10760] 178,76s system time ( 72,38%) stress-ng: info: [10760] 216,32s total time ( 87,58%) stress-ng: info: [10760] load average: 5,71 1,56 0,63 Mit freundlichem Gruß Karl Brandt -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 07.09.2018 um 12:22 schrieb Karl Brandt:
Karl Sinn schrieb:
[ ...]
So etwas wird ausgegeben (drastisch gekürzt). Für mich ist das keine Hilfe, sondern stress. Da muss ich wohl noch lesen, lesen. .... bevor ich die Ausgaben zielführend interpretieren kann.
stress-ng: info: [10760] dispatching hogs: 8 mq stress-ng: info: [10760] successful run completed in 30.87s stress-ng: info: [10760] mq: stress-ng: info: [10760] 798.083.948.512 CPU Cycles 25,85 B/sec stress-ng: info: [10760] 298.478.080.536 Instructions 9,67 B/sec (0,374 instr. per cycle)
.........
stress-ng: info: [10760] 96 SKB Kfree 3,11 /sec stress-ng: info: [10760] 0 IOMMU IO Page Fault 0,00 /sec stress-ng: info: [10760] 0 IOMMU Map 0,00 /sec stress-ng: info: [10760] 0 IOMMU Unmap 0,00 /sec stress-ng: info: [10760] for a 30,87s run time: stress-ng: info: [10760] 246,99s available CPU time stress-ng: info: [10760] 37,56s user time ( 15,21%) stress-ng: info: [10760] 178,76s system time ( 72,38%) stress-ng: info: [10760] 216,32s total time ( 87,58%) stress-ng: info: [10760] load average: 5,71 1,56 0,63
Hmmm, ich hätte wohl erwähnen sollen, dass der Einsatz dieses Pakets leider kein Selbstläufer ist, wie ich selbst auch aus eigener Erfahrung berichten kann. Viel Glück und Erfolg trotzdem Gruß Manfred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Manfred Kreisl schrieb:
Am 07.09.2018 um 12:22 schrieb Karl Brandt:
Karl Sinn schrieb:
[ ...]
So etwas wird ausgegeben (drastisch gekürzt). Für mich ist das keine Hilfe, sondern stress. Da muss ich wohl noch lesen, lesen. .... bevor ich die Ausgaben zielführend interpretieren kann.
stress-ng: info: [10760] dispatching hogs: 8 mq stress-ng: info: [10760] successful run completed in 30.87s stress-ng: info: [10760] mq: stress-ng: info: [10760] 798.083.948.512 CPU Cycles 25,85 B/sec stress-ng: info: [10760] 298.478.080.536 Instructions 9,67 B/sec (0,374 instr. per cycle)
.........
stress-ng: info: [10760] 96 SKB Kfree 3,11 /sec stress-ng: info: [10760] 0 IOMMU IO Page Fault 0,00 /sec stress-ng: info: [10760] 0 IOMMU Map 0,00 /sec stress-ng: info: [10760] 0 IOMMU Unmap 0,00 /sec stress-ng: info: [10760] for a 30,87s run time: stress-ng: info: [10760] 246,99s available CPU time stress-ng: info: [10760] 37,56s user time ( 15,21%) stress-ng: info: [10760] 178,76s system time ( 72,38%) stress-ng: info: [10760] 216,32s total time ( 87,58%) stress-ng: info: [10760] load average: 5,71 1,56 0,63
Hmmm, ich hätte wohl erwähnen sollen, dass der Einsatz dieses Pakets leider kein Selbstläufer ist, wie ich selbst auch aus eigener Erfahrung berichten kann.
Viel Glück und Erfolg trotzdem
Gruß Manfred
Letzte Meldung von mir zum Thema: ich habe gerade noch einmal kpat gestartet. Und dann das: 100%-CPU-Auslastung, 98,6% Mem und Swap mit 10% (5GB ????) belegt. Kpat abgeschossen und alles hat sich beruhigt. Auch andere Anwendungen wie z.B. seamonkey erzeugen manchmal CPU-Lasten von > 20% über einen längeren Zeitraum. Für mich ist das Problem vermutlich nicht lösbar. Danke für die bisherigen Beiträge. Mit freundlichem Gruß Karl Brandt -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Helga Fischer wrote:
Hallo Karl,
Am Montag 03 September 2018 schrieb Karl Brandt:
Ich nutze Tumbleweed in aktuelle Version.
Als CPU habe ich einen i7 6700k und 16GB Hauptspeicher.
Das Problem ärgert mich schon sehr lange.
Wenn ich mit Handbrake einen Film konvertiere oder eine größere Datei entpacke scheint es so, als ob ich ein extrem langsame System habe. Während dieser Zeit kann ich keine weitere Anwendung öffnen oder schließen. Die Anwendungen reagieren einfach nicht.
[...]
Habt ihr eine Idee wo ich ansetzen kann.
Das hier?
https://www.pro-linux.de/news/1/26259/meltdown-amp-co-leistungsverluste-mess...
Ansonsten fällt mir da nur Deine restliche Hardware ein. Je nachdem, was Du da benutzt, mag es durchaus noch den ein oder anderen Flaschenhals geben.
Helga
Hallo Helga und Karl erst einmal vielen Dank für Eure Beiträge. Meltdown könnte sein, aber ich glaube es nicht. Ich ärgere mich schon sehr lange über die unzureichende Performance. Vermutlich schon vor meltdown&co. Karls Ansatz ist auch mir schon durch den Kopf gegangen. Ich habe auch das Gefühl, dass von den Prozessorkernen immer nur einer wirklich arbeitet. Alles das könnte auch mit irgendwelchen BIOS-Einstellungen zusammenhängen. Bei VirtualBox hatte ich mal probiert von Chipsatz PIIX3 auf ICH9. Beim ersten Versuch glaubte ich auch, zumindest für VirtualBox, die Lösung gefunden zu haben. Aber es war nicht die Lösung. Als sinnvoll erscheint mir erst einmal die BIOS-Einstellungen auf Vordermann zu bringen. Mit alles auf Standard hatte ich es vor längerer Zeit schon einmal probiert. Das war aber auch nicht hilfreich. Kennt ihr irgend eine Quelle wo auch der laie sinnvolle Hinweise für die Einstellungen im BIOS bekommt? Mit freundlichem Gruß Karl -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo Karl, Am Montag 03 September 2018 schrieb Karl Brandt:
Am Montag 03 September 2018 schrieb Karl Brandt:
[...]
Beim ersten Versuch glaubte ich auch, zumindest für VirtualBox, die Lösung gefunden zu haben. Aber es war nicht die Lösung.
Hast Du ein Mainboard, das Virtualisierung unterstützt? Hab' mir zwar sagen lassen, die neuen Mainboards würden das alle können, aber wer weiß? Was sagt Dein Mainboard-Handbuch (oder das BIOS)?
Als sinnvoll erscheint mir erst einmal die BIOS-Einstellungen auf Vordermann zu bringen. Mit alles auf Standard hatte ich es vor längerer Zeit schon einmal probiert. Das war aber auch nicht hilfreich.
Arbeitest Du mit einer oder zwei Festplatten. Mein Rechner ist schon etwas in die Jahre gekommen, den will ich also jetzt nicht als Beispiel nehmen. Damals war es allerdings richtig schwierig, ein Mainboard bzw. Prozessor zu bekommen, der Virtualisierung unterstützt. Habe einen i5. Außerdem zwei Festplatten. Auf einer sitzt das Betriebssystem, auf der anderen ua das Virtualisierungsverzeichnis. Dein gewähltes Dateisystem könnte auch noch eine Rolle spielen.
Kennt ihr irgend eine Quelle wo auch der laie sinnvolle Hinweise für die Einstellungen im BIOS bekommt?
*puuuh* Nein. Meine auch, das war früher relevanter, ich kann mich aber täuschen. Bin nicht so der Hardwareschrauber und habe eher harmlose Anforderungen. (Nur die alten Feuerfüchse haben meine Kiste hin und wieder stillgelegt, wenn ich den Braten nicht rechtzeitig gerochen habe). Helga -- ## Technik: [http://de.opensuse.org] ## Privat: [http://www.eschkitai.de] -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 2018-09-03 16:57, schrieb Karl Brandt:
Ich nutze Tumbleweed in aktuelle Version.
Als CPU habe ich einen i7 6700k und 16GB Hauptspeicher.
Das Problem ärgert mich schon sehr lange.
Wenn ich mit Handbrake einen Film konvertiere oder eine größere Datei entpacke scheint es so, als ob ich ein extrem langsame System habe. Während dieser Zeit kann ich keine weitere Anwendung öffnen oder schließen. Die Anwendungen reagieren einfach nicht.
Heute habe ich mal wieder VirtualBox gestartet. Ich habe mich schon daran gewöhnt, dass während Windows10 startet mit Linux nicht mehr viel anzufangen ist. Aber heute hat sich gerade noch das Fenster von Windows10 geöffnet (noch keine Anmeldung) und dann hat irgendwer, weit über eine Stunde die Festplatte zum glühen gebracht. Kein Fenster hat mehr reagiert. lediglich ein Konsole konnte ich noch öffnen und habe dann aus Frust VirtBox samt Windows10 mit kill ins Nirvana geschickt. Gerade habe ich den 2 Versuch auf gleiche Weise abgebrochen.
Habt ihr eine Idee wo ich ansetzen kann. Die Probleme mit VirtBox und Windows10 sind erst einmal völlig nebensächlich. Mir würde es schon reichen, wenn ich auch unter Linux spüre, dass ich ein (hoffentlich) leistungsfähiges System habe.
Kannst du mal schauen ob ein dienst mit btrfs und/oder transacti läuft? In KDE mittels Strg+ESC -- Regards Eric -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Eric Schirra wrote:
Am 2018-09-03 16:57, schrieb Karl Brandt:
Ich nutze Tumbleweed in aktuelle Version.
Als CPU habe ich einen i7 6700k und 16GB Hauptspeicher.
Das Problem ärgert mich schon sehr lange.
Wenn ich mit Handbrake einen Film konvertiere oder eine größere Datei entpacke scheint es so, als ob ich ein extrem langsame System habe. Während dieser Zeit kann ich keine weitere Anwendung öffnen oder schließen. Die Anwendungen reagieren einfach nicht.
Heute habe ich mal wieder VirtualBox gestartet. Ich habe mich schon daran gewöhnt, dass während Windows10 startet mit Linux nicht mehr viel anzufangen ist. Aber heute hat sich gerade noch das Fenster von Windows10 geöffnet (noch keine Anmeldung) und dann hat irgendwer, weit über eine Stunde die Festplatte zum glühen gebracht. Kein Fenster hat mehr reagiert. lediglich ein Konsole konnte ich noch öffnen und habe dann aus Frust VirtBox samt Windows10 mit kill ins Nirvana geschickt. Gerade habe ich den 2 Versuch auf gleiche Weise abgebrochen.
Habt ihr eine Idee wo ich ansetzen kann. Die Probleme mit VirtBox und Windows10 sind erst einmal völlig nebensächlich. Mir würde es schon reichen, wenn ich auch unter Linux spüre, dass ich ein (hoffentlich) leistungsfähiges System habe.
Kannst du mal schauen ob ein dienst mit btrfs und/oder transacti läuft? In KDE mittels Strg+ESC
Hallo Eric, ich habe mal geschaut, weder btrfs noch transacti erscheinen in irgend einer Form in der Liste. Mit freundlichem Gruß Karl Brandt -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 2018-09-03 19:04 schrieb Karl Brandt:
Eric Schirra wrote:
Am 2018-09-03 16:57, schrieb Karl Brandt:
Ich nutze Tumbleweed in aktuelle Version.
Als CPU habe ich einen i7 6700k und 16GB Hauptspeicher.
Das Problem ärgert mich schon sehr lange.
Wenn ich mit Handbrake einen Film konvertiere oder eine größere Datei entpacke scheint es so, als ob ich ein extrem langsame System habe. Während dieser Zeit kann ich keine weitere Anwendung öffnen oder schließen. Die Anwendungen reagieren einfach nicht.
Heute habe ich mal wieder VirtualBox gestartet. Ich habe mich schon daran gewöhnt, dass während Windows10 startet mit Linux nicht mehr viel anzufangen ist. Aber heute hat sich gerade noch das Fenster von Windows10 geöffnet (noch keine Anmeldung) und dann hat irgendwer, weit über eine Stunde die Festplatte zum glühen gebracht. Kein Fenster hat mehr reagiert. lediglich ein Konsole konnte ich noch öffnen und habe dann aus Frust VirtBox samt Windows10 mit kill ins Nirvana geschickt. Gerade habe ich den 2 Versuch auf gleiche Weise abgebrochen.
Habt ihr eine Idee wo ich ansetzen kann. Die Probleme mit VirtBox und Windows10 sind erst einmal völlig nebensächlich. Mir würde es schon reichen, wenn ich auch unter Linux spüre, dass ich ein (hoffentlich) leistungsfähiges System habe.
Kannst du mal schauen ob ein dienst mit btrfs und/oder transacti läuft? In KDE mittels Strg+ESC
Hallo Eric, ich habe mal geschaut, weder btrfs noch transacti erscheinen in irgend einer Form in der Liste.
Mit freundlichem Gruß Karl Brandt
Hallo Karl, ich hattte dieses Problem auch schon mal. Es ist aber schon soooo lange her, ich kann mich absolut nicht mehr erinnern was die Lösung war. mir fiele ein, einen Blick auf das gesamte I/O zu werfen. Mach ein Konsolenfenster auf und starte dort "iotop" (bei mir war's standardmäßig nicht installiert, ist aber in einem standard-repo vorhanden) Und während es läuft starte einer Deiner bekannten Bremsen (handbrake, ...) und beobachte iotop. vielleicht siehst Du etwas Auffälliges... mehr fällt mir im Moment auch nicht ein Gruß Norbert -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Norbert Zawodsky wrote:
Am 2018-09-03 19:04 schrieb Karl Brandt:
Eric Schirra wrote:
Am 2018-09-03 16:57, schrieb Karl Brandt:
Ich nutze Tumbleweed in aktuelle Version.
Als CPU habe ich einen i7 6700k und 16GB Hauptspeicher.
Das Problem ärgert mich schon sehr lange.
Wenn ich mit Handbrake einen Film konvertiere oder eine größere Datei entpacke scheint es so, als ob ich ein extrem langsame System habe. Während dieser Zeit kann ich keine weitere Anwendung öffnen oder schließen. Die Anwendungen reagieren einfach nicht.
Heute habe ich mal wieder VirtualBox gestartet. Ich habe mich schon daran gewöhnt, dass während Windows10 startet mit Linux nicht mehr viel anzufangen ist. Aber heute hat sich gerade noch das Fenster von Windows10 geöffnet (noch keine Anmeldung) und dann hat irgendwer, weit über eine Stunde die Festplatte zum glühen gebracht. Kein Fenster hat mehr reagiert. lediglich ein Konsole konnte ich noch öffnen und habe dann aus Frust VirtBox samt Windows10 mit kill ins Nirvana geschickt. Gerade habe ich den 2 Versuch auf gleiche Weise abgebrochen.
Habt ihr eine Idee wo ich ansetzen kann. Die Probleme mit VirtBox und Windows10 sind erst einmal völlig nebensächlich. Mir würde es schon reichen, wenn ich auch unter Linux spüre, dass ich ein (hoffentlich) leistungsfähiges System habe.
Kannst du mal schauen ob ein dienst mit btrfs und/oder transacti läuft? In KDE mittels Strg+ESC
Hallo Eric, ich habe mal geschaut, weder btrfs noch transacti erscheinen in irgend einer Form in der Liste.
Mit freundlichem Gruß Karl Brandt
Hallo Karl,
ich hattte dieses Problem auch schon mal. Es ist aber schon soooo lange her, ich kann mich absolut nicht mehr erinnern was die Lösung war.
mir fiele ein, einen Blick auf das gesamte I/O zu werfen. Mach ein Konsolenfenster auf und starte dort "iotop" (bei mir war's standardmäßig nicht installiert, ist aber in einem standard-repo vorhanden) Und während es läuft starte einer Deiner bekannten Bremsen (handbrake, ...) und beobachte iotop. vielleicht siehst Du etwas Auffälliges...
mehr fällt mir im Moment auch nicht ein
Gruß Norbert
Hallo Norbert, vielen Dank für den Hinweis. Ich habs mal installiert. Morgen werde ich mich weiter ärgern. Mit freundlichem Gruß Karl -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo Karl, probier doch mal während das Problem ansteht top zu starten, da siehts Du dann, was gerade die CPU dicht macht - der Prozess steht dann ganz oben. Wenn top läuft, kannst mit <shift><m> nach dem Speicherverbrauch sortieren lassen, damit solltest rauskriegen, was Dich da ärgert. Falls Du eine SSD mit btrfs hast - läuft ca. 1mal die Woche ein trim bzw. balance - der macht zumindest meine Kiste dicht! Grüße Mike Am Montag, 3. September 2018, 16:57:03 CEST schrieb Karl Brandt:
Ich nutze Tumbleweed in aktuelle Version.
Als CPU habe ich einen i7 6700k und 16GB Hauptspeicher.
Das Problem ärgert mich schon sehr lange.
Wenn ich mit Handbrake einen Film konvertiere oder eine größere Datei entpacke scheint es so, als ob ich ein extrem langsame System habe. Während dieser Zeit kann ich keine weitere Anwendung öffnen oder schließen. Die Anwendungen reagieren einfach nicht.
Heute habe ich mal wieder VirtualBox gestartet. Ich habe mich schon daran gewöhnt, dass während Windows10 startet mit Linux nicht mehr viel anzufangen ist. Aber heute hat sich gerade noch das Fenster von Windows10 geöffnet (noch keine Anmeldung) und dann hat irgendwer, weit über eine Stunde die Festplatte zum glühen gebracht. Kein Fenster hat mehr reagiert. lediglich ein Konsole konnte ich noch öffnen und habe dann aus Frust VirtBox samt Windows10 mit kill ins Nirvana geschickt. Gerade habe ich den 2 Versuch auf gleiche Weise abgebrochen.
Habt ihr eine Idee wo ich ansetzen kann. Die Probleme mit VirtBox und Windows10 sind erst einmal völlig nebensächlich. Mir würde es schon reichen, wenn ich auch unter Linux spüre, dass ich ein (hoffentlich) leistungsfähiges System habe.
Mit freundlichem Gruß
Karl Brandt
-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 03.09.18 um 16:57 schrieb Karl Brandt:
Ich nutze Tumbleweed in aktuelle Version.
Als CPU habe ich einen i7 6700k und 16GB Hauptspeicher.
Das Problem ärgert mich schon sehr lange.
Wenn ich mit Handbrake einen Film konvertiere oder eine größere Datei entpacke scheint es so, als ob ich ein extrem langsame System habe. Während dieser Zeit kann ich keine weitere Anwendung öffnen oder schließen. Die Anwendungen reagieren einfach nicht.
Hallo, darf ich mal fragen, wie groß Deine swap Partition ist? Ich hatte bis vor ca drei Wochen openSuSE leap15.0 64bit, xfce Desktop, 8GB Arbeitsspeicher und 4GB swap Partition. Wenn ich mehrere Fotos (ca 7-10) gleichzeitig mit Gwenview offen hatte und andere Software (Firefox, Thunderbird, LibreOffice, Franz, etc.), hatte ich dieselben Probleme, die HD LED leuchtete ständig und manchmal konnte ich die Maus bewegen und manchmal nicht ein mal das. TVBrowser konnte ich nicht verwenden, im Absturzbericht lass ich immer was von Speicherproblemen, auch wenn bloß TVBrowser lief. Dann habe ich den Arbeitsspeicher auf 16GB gehoben und die swap Partition auch auf 16 GB und openSuSE tumbleweed. Seither gibt es keine Probleme mehr. Es kann jetzt natürlich der größere Arbeitsspeicher sein, oder aber auch die größere swap Partition, oder aber auch der Systemwechsel von leap15 zu tumbleweed sein. Gruß Hugo Egon Maurer -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hugo Egon Maurer wrote:
Am 03.09.18 um 16:57 schrieb Karl Brandt:
Ich nutze Tumbleweed in aktuelle Version.
Als CPU habe ich einen i7 6700k und 16GB Hauptspeicher.
Das Problem ärgert mich schon sehr lange.
Wenn ich mit Handbrake einen Film konvertiere oder eine größere Datei entpacke scheint es so, als ob ich ein extrem langsame System habe. Während dieser Zeit kann ich keine weitere Anwendung öffnen oder schließen. Die Anwendungen reagieren einfach nicht.
Hallo,
darf ich mal fragen, wie groß Deine swap Partition ist?
Ich hatte bis vor ca drei Wochen openSuSE leap15.0 64bit, xfce Desktop, 8GB Arbeitsspeicher und 4GB swap Partition.
Wenn ich mehrere Fotos (ca 7-10) gleichzeitig mit Gwenview offen hatte
und andere Software (Firefox, Thunderbird, LibreOffice, Franz, etc.), hatte ich dieselben Probleme, die HD LED leuchtete ständig und manchmal konnte ich die Maus bewegen und manchmal nicht ein mal das.
TVBrowser konnte ich nicht verwenden, im Absturzbericht lass ich immer was von Speicherproblemen, auch wenn bloß TVBrowser lief.
Dann habe ich den Arbeitsspeicher auf 16GB gehoben und die swap Partition auch auf 16 GB und openSuSE tumbleweed.
Seither gibt es keine Probleme mehr.
Es kann jetzt natürlich der größere Arbeitsspeicher sein, oder aber auch die größere swap Partition, oder aber auch der Systemwechsel von leap15 zu tumbleweed sein.
Gruß
Hugo Egon Maurer
Hallo Egon, ich war erschrocken, keine Angaben zu swap mit df bzw. di. Aber es gibt eine Swap-Partition mit ca. 53GB. In der etc/fstab ist sie auch korrekt eingetragen und im KDE-Infozentrum erscheint sie auch mit der entsprechenden Größe. Mit freundlichem Gruß Karl Brandt -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 03.09.2018 um 22:34 schrieb Karl Brandt:
Hugo Egon Maurer wrote:
Am 03.09.18 um 16:57 schrieb Karl Brandt:
Ich nutze Tumbleweed in aktuelle Version.
Als CPU habe ich einen i7 6700k und 16GB Hauptspeicher.
Das Problem ärgert mich schon sehr lange.
Wenn ich mit Handbrake einen Film konvertiere oder eine größere Datei entpacke scheint es so, als ob ich ein extrem langsame System habe. Während dieser Zeit kann ich keine weitere Anwendung öffnen oder schließen. Die Anwendungen reagieren einfach nicht.
Hallo,
darf ich mal fragen, wie groß Deine swap Partition ist?
Ich hatte bis vor ca drei Wochen openSuSE leap15.0 64bit, xfce Desktop, 8GB Arbeitsspeicher und 4GB swap Partition.
Wenn ich mehrere Fotos (ca 7-10) gleichzeitig mit Gwenview offen hatte
und andere Software (Firefox, Thunderbird, LibreOffice, Franz, etc.), hatte ich dieselben Probleme, die HD LED leuchtete ständig und manchmal konnte ich die Maus bewegen und manchmal nicht ein mal das.
TVBrowser konnte ich nicht verwenden, im Absturzbericht lass ich immer was von Speicherproblemen, auch wenn bloß TVBrowser lief.
Dann habe ich den Arbeitsspeicher auf 16GB gehoben und die swap Partition auch auf 16 GB und openSuSE tumbleweed.
Seither gibt es keine Probleme mehr.
Es kann jetzt natürlich der größere Arbeitsspeicher sein, oder aber auch die größere swap Partition, oder aber auch der Systemwechsel von leap15 zu tumbleweed sein.
Gruß
Hugo Egon Maurer
Hallo Egon,
ich war erschrocken, keine Angaben zu swap mit df bzw. di.
Aber es gibt eine Swap-Partition mit ca. 53GB. Den würde ich erst mal deaktivieren und gucken, was dann passiert. 16GB RAM sollten allemal reichen
Gruß Manfred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 03.09.2018 um 20:32 schrieb Hugo Egon Maurer:
Am 03.09.18 um 16:57 schrieb Karl Brandt:
darf ich mal fragen, wie groß Deine swap Partition ist?
Ich hatte bis vor ca drei Wochen openSuSE leap15.0 64bit, xfce Desktop, 8GB Arbeitsspeicher und 4GB swap Partition.
Früher, da war alles besser, da wurde Swap kaum benötigt;-) Jetzt unter Kubuntu 18.04.1 16GB RAM, 10GB Swap, Kernel 4.15.x, Bildbearbeitung plus andere Software, da konnte ich sehen, wie Swap zulief, schließlich stieg KDE aus. Unter Tumbleweed, gleiche Bedingung, dies bisher nicht beobachtet. Vielleicht liegt es am Kernel 4.18.x Gruß Peter -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Mon, 3 Sep 2018 16:57:03 +0200 schrieb Karl Brandt <kmbrandt@ewetel.net>:
Habt ihr eine Idee wo ich ansetzen kann. Die Probleme mit VirtBox und Windows10 sind erst einmal völlig nebensächlich. Mir würde es schon reichen, wenn ich auch unter Linux spüre, dass ich ein (hoffentlich) leistungsfähiges System habe.
Das Hilfsprogramm htop installieren. In einem Terminal mit dem Befehl htop -u dein-benutzername aufrufen und schauen welche Prozesse auf Benutzerebene ausufern. Ohne -u dein-benutzername werden IMO _alle_ Prozesse gelistet. Damit kannst Du weiter sehen und gezielt handeln. -- MfG Jan-Uwe Kögel
Zur Info und diejenigen die es interessiert: So erster Leistungsfresser gefunden. Es ist KPat mit und ohne Wayland. Mitten im Spiel steigt die Prozessorlast auf > 100% und die Lüfter drehen hoch. Das System ist dann für einige Sekunden nicht mehr nutzbar. Bei KPat habe ich das so zum ersten mal erlebt. Das Verhalten von KPat kann aber auch mit anderen KDE-Macken zusammenhängen. Seit dem letzten Update von KDE bzw. KDE-Anwendungen funktioniert z.B. das automatische Ablegen von Karten nicht mehr. Mit freundlichem Gruß Karl Brandt Jan-Uwe Koegel wrote:
Am Mon, 3 Sep 2018 16:57:03 +0200 schrieb Karl Brandt <kmbrandt@ewetel.net>:
Habt ihr eine Idee wo ich ansetzen kann. Die Probleme mit VirtBox und Windows10 sind erst einmal völlig nebensächlich. Mir würde es schon reichen, wenn ich auch unter Linux spüre, dass ich ein (hoffentlich) leistungsfähiges System habe.
Das Hilfsprogramm htop installieren. In einem Terminal mit dem Befehl
htop -u dein-benutzername
aufrufen und schauen welche Prozesse auf Benutzerebene ausufern. Ohne -u dein-benutzername werden IMO _alle_ Prozesse gelistet. Damit kannst Du weiter sehen und gezielt handeln.
-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Tue, 4 Sep 2018 13:50:28 +0200 schrieb Karl Brandt <kmbrandt@ewetel.net>:
Bei KPat habe ich das so zum ersten mal erlebt. Das Verhalten von KPat kann aber auch mit anderen KDE-Macken zusammenhängen. Seit dem letzten Update von KDE bzw. KDE-Anwendungen funktioniert z.B. das automatische Ablegen von Karten nicht mehr.
Da bin ich weg. Denn den Patienten KDE habe ich vor Jahren schon als vollständig unheilbar aufgegeben. -- MfG Jan-Uwe Kögel
participants (11)
-
Daniel Lord -
Eric Schirra -
Helga Fischer -
Hugo Egon Maurer -
Jan-Uwe Koegel -
Karl Brandt -
Karl Sinn -
Manfred Kreisl -
Mike Philipp -
Norbert Zawodsky -
Peter McD