iMac 27" Performance Problem ? Bitte mal lesen und Teilnehmen.

dansch

dansch

Aktives Mitglied
Thread Starter
Dabei seit
24.09.2007
Beiträge
422
Reaktionspunkte
12
Hallo zusammen,

kürzlich ist mein i5 iMac 27" gekommen.
Habe festgestellt,daß er anscheinend unter Performanceproblemen leidet. Selbiges konnten wir bei einem i7 feststellen.

Probiert doch mal bitte folgendes auf euren Kisten:

1) Terminal öffnen
2) eingeben: cat /dev/random > /dev/null
3) Finder auf machen, neues Programm starten, Statusleiste versuchen zu verwenden und so weiter.
4) beenden mit Strg+c

Klappt das bei euch ohne Probleme ? Bei mir nicht auch bei dem i7 nicht - seltsamerweise macht das mein 2.4GHz MacBook Unibody problemlos mit!

Auf meinem i5 hängt der Finder, es gehen keine Programme mehr auf und die Statusleiste hängt mit dem Beachball of Death. Fenster bewegen geht nur mit Verzögerung, Safari läd keine Seite. iTunes dagegen spielt fröhlich weiter Musik.
Sobald cat mit Strg+c beendet wurde, läd Safari die Webseite und die Menus die ich zuvor angeklickt habe poppen auf.

Alles das tritt auf meinem wesentlich schwächeren MacBook _NICHT_ auf. Safari läd die Seite, zwar langsamer als normal aber es geht immerhin beispielsweise.

Frisch installiert habe ich schon.

Danke für eure Unterstützung!

P.S. bei Punkt 2 gibt er einfach nur Zufallszahlen in das Null device aus. Also nichts schlimmes, könnt es ruhig ausprobieren.
 
Zuletzt bearbeitet:
Ist bei meinem i5 dasselbe. Finder öffnen geht noch, Programm nicht mehr.
Was ist das für ein Befehl, den du da im Terminal eingibst?
Hast du eine Erklärung für diesen `Hang-Up´?
 
Nein, kann ich bei meinem i7 nicht nachvollziehen. cat hat zwar eine CPU-Auslastung von 100% und alles geht einen Tick langsamer, kann aber trotzdem normal weiter Arbeiten.
 
Versuche grade den 2nd Level bei Apple damit zu konfrontieren.

cat = ausgabe
/dev/random = erzeugt zufallszahlen, belastet somit einen kern des prozessors zu 100%
/dev/null = null device, quasi die rundablage (mülleimer) des unix unterbaus.

d.h. er generiert zufallszahlen und löscht sie quasi gleich wieder.
das erzeugt die auslasung von 100% auf einem kern.

und wir haben 4 kerne zur verfügung, d.h. 3 müssen übrig sein für anderes. wie es beim macbook auch ist. dort erledigt der verbleibende 2. kern die restlichen arbeiten -> zwar langsamer, was auch okay ist. zumindest besser als garnicht bei bei unseren imacs.

und das ist nicht okay.

der 1st level war damit total überfordert :)


@Maverick79: safari öffnet auch eine webseite während der befehl läuft ?
 
COOL Dansch, bleib dran!
Danke schon mal, auch für die Erklärungen.
 
Ich glaube du hast nicht die identischen Bedingungen für deinen Test. Zufallszahlen werden bei unterschiedlichen CPU unterschiedlich in Software oder Hardware produziert. Das löschen wiederrum ist auch keine Null-Operation.

Soll heissen ich glaube so kannst du keine zuverlässige Vergleichsaussage treffen. Vieles lastet eine CPU zu 100% aus, dies ist auch der Sinn einer CPU.

Technisch gesehen lastet eh alles eine CPU immer zu 100% aus, nur über die Zeit und das Multitasking gesehen ergibt sich hier eine Verschiebung der Werte.

Ob das System dabei performant bleibt, ist Sache des Schedulers...
 
ich würde mal folgendes ausprobieren:

... von /dev/zero nach /dev/null
... von /dev/random in eine Datei schreiben
... von der Datei nach /dev/null


Klingt für mich wie ein Bug, nur wer startet schon einen Prozess der unsinnigerweise von einem device ins jenseits schreibt :)
 
Jup,geht ohne Probleme. Auch mehrere hintereinander.
 
Du könntest mal eine Performancemessung mit :

"time echo "scale=1000; 4*a(1)" | bc -l"

auf der Shell ausführen, der Scalewert kann entsprechend angepasst werden.
Der Befehl berechnet die 1000 Nachkommarstellen von PI und gibt im Anschluss die Zeit aus, die der Ablauf gebraucht hat.

Ist jedoch SingleCore und lastet nur eine CPU aus (logisch nur 1 Prozess, kein Multithreading).

Startet man mehre davon lastet man weitere CPUs aus, gut um zu testen, ob die Kühlung mitmacht.
 
Ich glaube du hast nicht die identischen Bedingungen für deinen Test. Zufallszahlen werden bei unterschiedlichen CPU unterschiedlich in Software oder Hardware produziert. Das löschen wiederrum ist auch keine Null-Operation.

Soll heissen ich glaube so kannst du keine zuverlässige Vergleichsaussage treffen. Vieles lastet eine CPU zu 100% aus, dies ist auch der Sinn einer CPU.

Technisch gesehen lastet eh alles eine CPU immer zu 100% aus, nur über die Zeit und das Multitasking gesehen ergibt sich hier eine Verschiebung der Werte.

Ob das System dabei performant bleibt, ist Sache des Schedulers...

Das ist ja auch okay so was du sagst.

Aber es dreht sich hier um die ganz einfache Frage:

Warum gehts auf dem wesentlich Schwächeren MacBooks und auf diversen 27er iMacs die viel Leistungsstärker sind nicht ?

Der Sinn und Zweck der Berechnungen, und alternativen stehen überhaupt nicht im Vordergrund :)
 
und wir haben 4 kerne zur verfügung
Genau genommen sogar 8, die virtuellen Kerne des i7 mitgerechnet. Und von diesen "8" Kernen lastet das Programm bei meinem iMac i7 genau einen voll aus. Die anderen tuckern mehr oder weniger im Leerlauf vor sich hin. Während das Testprogramm lief hatte ich noch die Aktivitätsanzeige geöffnet, auf iTunes eine CD importiert während ich gleichzeitig Musik höre, Coverscout ein passendes Cover suchte und ich mit Safari surfe.
 
Der Stand ist folgender:

Die nette Dame vom 2nd Level Support (sei hiermit gegrüßt) wird sich den Thread hier anschauen und das was ihr hier an Ergebnissen einbringt mit aufnehmen. Also bitte alle mal Lächeln :)

Ich weiß nicht wie kritisch es ist Seriennummern zu posten, aber eventuell Hilft es bei dem Problem weiter damit direkt die Hardwareausstattung von Apple eingesehen werden kann.

Morgen kann ich von ihr ein kleines Feedback erwarten.
 
Warum gehts auf dem wesentlich Schwächeren MacBooks und auf diversen 27er iMacs die viel Leistungsstärker sind nicht ?

Womöglich:

- Andere Kernel-Version
- Andere Kernel-Bereiche für die CPU, weil andere CPU-Typ

Daraus kann resultiert:
- Andere Berechnung von Zufallszahlen
- Andere Behandlung von /dev/null

Ich wollte dir ne alternative Möglichkeit bieten die CPU unabhängig von Devicesystem (/dev/urandom /dev/null) auszulasten, um deine Annahme überprüfen zu können.
 
Womöglich:

- Andere Kernel-Version
- Andere Kernel-Bereiche für die CPU

Daraus resultiert:
- Andere Berechnung von Zufallszahlen
- Andere Behandlung von /dev/null

Ich wollte dir ne alternative Möglichkeit bieten die CPU unabhängig von Devicesystem (/dev/urandom /dev/null auszulasten, um deine Annahme überprüfen zu können.

Danke habe es mit deinem Ansatz probiert und zu folgendem Ergebnis bin ich gekommen:

Ich habs mal mit 10.000 nachkommastellen probiert sonst ist der Befehl zu schnell zuende.
Damit hat er keine Probleme. Muss also irgendwas in Richtung IO-Last sein.


Nochmal für Apple in Kurzfassung:

Der Befehl 'time echo "scale=10000; 4*a(1)" | bc -l' lastet einen Kern zu 100% aus, selbst bei mehrfacher gleichzeitiger Ausführung scheint das garkein Problem zu sein.

Es muss also irgendwas mit der IO-Last zutun haben.
 
Damit hat er keine Probleme. Muss also irgendwas in Richtung IO-Last sein.

Damit ist bestätigt, dass du keine Performance-Problem im der i5/7 CPU hast.

Du hast ebenfalls kein IO-Problem, da beide Device virtuell über den Kernel abgebildet werden (und damit über die CPU). Wie gesagt ich denke es liegt an einer nicht performanten Behandlung des CAT Befehls oder der virtuellen Devices im Scheduler des Kernels.

Ich halte dies für keinen Fehler!
 
Hallo zusammen,

kürzlich ist mein i5 iMac 27" gekommen.
Habe festgestellt,daß er anscheinend unter Performanceproblemen leidet.

mal ne ganz ernsthafte frage: aus welchem grund probierst du das aus? hat der rechner auch im normalbetrieb mucken gemacht?
 
Damit ist bestätigt, dass du keine Performance-Problem im i7 CPU hast.

Du hast ebenfalls kein IO-Problem, da beide Device virtuell über den Kernel abgebildet werden (und damit über die CPU). Wie gesagt ich denke es liegt an einer nicht performanten Behandlung des CAT Befehls oder der virtuellen Devices im Scheduler des Kernels.

Ich halte dies für keinen Fehler!

Ich hab das Problem aber Analog im Workflow. D.h. irgendwann Stockt das System und bleibt quasi hängen. Erst nach einer Weile beruhigt er sich. Und das im Nackten zustand. Deswegen bin ich erst darauf gekommen verstärkt Nachforschungen anzustellen.


Die Kernel Versionen unterscheiden sich bei mir:

iMac: Darwin scratchy.local 10.2.0 Darwin Kernel Version 10.2.0: Tue Nov 3 23:08:29 PST 2009; root:xnu-1486.2.11~3/RELEASE_I386 i38
MacBook: Darwin itchy.local 10.2.0 Darwin Kernel Version 10.2.0: Tue Nov 3 10:37:10 PST 2009; root:xnu-1486.2.11~1/RELEASE_I386 i38
 
Ich hab das Problem aber Analog im Workflow. D.h. irgendwann Stockt das System und bleibt quasi hängen. Erst nach einer Weile beruhigt er sich. Und das im Nackten zustand. Deswegen bin ich erst darauf gekommen verstärkt Nachforschungen anzustellen.

Das mag ja sein, aber es ist kein Last-Problem, dem du so auf die Schliche kommst.

Gibt es Systemmeldungen in dem Moment wo dein Rechner stockt? Programm "Konsole" -> Alle Meldungen, kann dir hier vielleicht weiterhelfen.
 
Das mag ja sein, aber es ist kein Last-Problem, dem du so auf die Schliche kommst.

Gibt es Systemmeldungen in dem Moment wo dein Rechner stockt? Programm "Konsole" -> Alle Meldungen, kann dir hier vielleicht weiterhelfen.

Leider nein, als wenn er in dem Moment an Demenz leidet. Es kommt dann absolut garnichts ins Log. Da habe ich auch als erstes Nachgeschaut um zu sehen ob etwas hängt.

Vorher alles normal, hinterher ebenfalls. Dazwischen logt er nichts.
 
Leider nein, als wenn er in dem Moment an Demenz leidet. Es kommt dann absolut garnichts ins Log. Da habe ich auch als erstes Nachgeschaut um zu sehen ob etwas hängt.

Vorher alles normal, hinterher ebenfalls. Dazwischen logt er nichts.

Ist das eine "Clean Install" von OSX?

Hast du irgendwelche Dienstprogramme oder Hardwaretreiber installiert?

Hast du irgendwelche Hardware angeschlossen, die nicht dabei war?
 
Zurück
Oben Unten