News Micron QuantX mit 3D XPoint: 1,8 Mio. IOPS deklassieren Flash-SSD-Flaggschiff

[Holt]

Im Vergleich zu einer Samsung 850 pro kann ich subjektiv keinerlei Verbesserung in Alltag feststellen ausser ich schiebe grosse Dateien innerhalb der 750

Dann hast Du nicht die nötigen Anwendungen dafür, die Intel 750 ist ja im Grunde eine Enterprise SSD und kann sich erst bei sehr vielen parallelen und bei sehr langen Zugriffen von einer so schnellen SATA SSD wie der 850 Pro überhaupt abheben. Surfen, Office und Gaming sind eben nicht die Anwendungen bei denen man da einen Unterschied merken kann, die fordern die SSD viel zu wenig.

Die Menge an dauerhafter I/O Zugriffen im professionellem Bereich zu erzeugen ist leicht. Große Datenbankserver mit dicken CPUs und mehreren Sockeln schaffen das recht problemlos

Die müssen aber wirklich dick sein, sehr schnell angebunden und sehr gut ausgelastet. Aber auch eine Datenbank muss mehr machen als nur auf die Laufwerke zugreifen, sie muss zumindest feststellen worauf zu zugreifen muss und dann auch noch prüfen, ob sie das wirklich darf oder nicht einer gerade die Daten gesperrt hat weil er sie verändert und beim Schreiben ist der Aufwand noch höher. Mit so wenig CPU Last wie in einem Benchmark kommt man da auch bei weitem nicht aus.

wobei sowas heutzutage wenn irgendmöglich im Ram vorgehalten wird, da die Latenzen von Festspeichern viel zu groß ist (einige hunderttausend mal in der Sekunde auf µs Latenz warten läppert sich).

Und eben dafür ist ja das 3D XPoint als DRAM gedacht, damit kann man viel größeren RAMs als mit DRAM bauen und mehr im RAM halten, eben weil die Anbindung so noch weniger Latenz als wie als SSD über PCIe hat.

Wobei bei großen DBS typischerweise viele Abfragen nahezu unbegrenzt* parallel lesend ablaufen können.

Die Parallelität ergibt sich normalerweise auf der hohen Zahl der Nutzer, da reicht es wenn für jede Verbindung zur DB ein Thread gestartet wird um alle Kerne gut auslasten zu können.

Insofern sehe ich in den Bereichen wo sich die Hardware anfangs ansiedeln wird kaum Probleme das Zeug sinnvoll einzusetzen.

Sinnvoll schon, aber die Frage ist bis zu welchem Limit man die treiben kann und wenn man davon weit genug weg bleibt, macht es keinen Sinn noch schnellere (eben z.B. x16 angebundene) QuantX Laufwerke zu nehmen.

wenn mit 3D Xpoint der Ram obsolet wird und die Geschwindigkeiten um ein vielfaches höher sind

3D XPoint ist aber langsamer als RAM und zwar deutlich, erst recht wenn es als SSD per PCIe eingesetzt wird.

Wenn man danach geht dürfte Intel auch keine 1000€ CPU anbieten, der Unterschied zu einem 300€ i7 ist nämlich verschwindend gering

Für Gamer vielleicht, aber die sind ja auch nicht Zielgruppe einer 1000€ CPU und die wahre Zielgruppe hat meist schon Anwendungen bei denen der Unterschied alles andere als gering ist.

Ich sehe hier eine SSD, die bei vier PCIe 3.0 Lanes durch die Schnittstelle limitiert wird und bei acht Lanes deutlich besser performt.

In Benchmarks, aber lässt sich davon irgendwas in die Praxis übertragen? Schaffen es z.B. selbst die dickten DB Server so eine SSD die mit 4 oder 8 PCIe Lanes angebunden ist, diesen dann nichts ans Limit zu treiben, dann macht es überhaupt keinen Sinn ein Modell mit 16 PCIe Lanes zu bringen, außer man will eben mit Rekorden auf sich aufmerksam machen.

Wenn ich also eine solche SSD über den Z170 PCH anbinde, laufe ich in genau das gleiche Limit.

Aber auch nur in Benchmarks oder beim Kopieren große Dateien innerhalb des Laufwerks, im Alltag merken die meisten nicht einmal einen Unterschied zwischen einer schnellen SATA SSD und einer viel schnelleren PCIe SSD, siehe Fruuky.

Da bringen noch so viele PCIe Lanes am PCH Ausgang nichts, wenn das Interface zur CPU limitiert, durch das diese alle geswitcht werden.

Das ist schon richtig, nur geht es ja auch weniger darum die maximalen Transferraten zu steigern, als vielmehr darum die Möglichkeit zu schaffen mehr solcher PCIe x4 SSDs anbinden zu können und wenn diese eben nicht immer zeitgleich in die gleiche Richtung Daten übertragen, was ja eben vor allem bei einem RAID der Fall ist, dann merkt man vom Flaschenhals auch wenig. Wer mehr will, muss eben zum großen S. 2011-3 greifen, da haben die CPUs 40 PCIe 3.0 Lanes, wenn man nicht gerade die kleinesten i7 nimmt und wenn man sich so viele so schnelle SSDs leisten kann, sollten es an den Kosten für den Unterbau auch nicht scheitern.

 

[Kowa]

Ich nutze sowohl die Samsung 950 Pro als auch die 850 Evo im selben System und merke ehrlich gesagt keinen Unterschied im täglichen Gebrauch/QUOTE]
Kopier mal ein Backup, mit 20-30GB auf die Evo.
https://www.computerbase.de/2016-03...ramm-dauertransferrate-schreiben-h2benchw-316
Die Budget-SSDs gehen da sehr schnell in die Knie.

In großen Firmen dauern die Beschaffungsprozesse oft Jahre um am Ende das billigste HDD-Storage zum höchsten Preis zu kaufen. Ich sehe den Einsatz eher bei kleineren Firmen, oder bei Studenten, engagierten IT-Spezis, die im privaten eine Hochleistungsdatenbank aufbauen um für ein Projekt Vorarbeiten zu leisten, ohne Kohle für die fetten Server auf den Tisch legen zu können.

Ergänzung (11. August 2016)

Im Privatmarkt wohl tatsächlich "sinnfrei".

Ich kann mich erinnern, in einem Jahr schon 3 opulente Win10-Installationen durchlebt zu haben (Win7-Upgrade, 1511, 1608) und jedesmal klemmte es an der Rumkopiererei von 30GB auf der 4k-Systempartition. Gefühlt eine halbe Stunde sitzt man vor der Kiste und starrt auf den großen Windows-Kreis mit "14%".

Beim anschließenden Backup War es dann meist auch die SSD, die 100% busy ist und nur 250-150MB liefert. Für sowas Nerviges muß ich bis zu 7 Minuten einplanen, in denen ich auf Balken starre.

 

[Piktogramm]

Die müssen aber wirklich dick sein, sehr schnell angebunden und sehr gut ausgelastet. Aber auch eine Datenbank muss mehr machen als nur auf die Laufwerke zugreifen, sie muss zumindest feststellen worauf zu zugreifen muss und dann auch noch prüfen, ob sie das wirklich darf oder nicht einer gerade die Daten gesperrt hat weil er sie verändert und beim Schreiben ist der Aufwand noch höher. Mit so wenig CPU Last wie in einem Benchmark kommt man da auch bei weitem nicht aus.

Sehr dick ja, aber unüblich sind solche Kisten nicht. Das ganze Prüfen und Datensätze heraussuchen ist für DBS Tagesgeschäft und kein Problem. Wobei bei gerade durch den Einsatz von Festspeicher (XPoint als persistenter Speicher ist für mich Festspeicher) als Substitut für RAM das Heraussuchen von Einträgen ja über diesen Festspeicher läuft und da sind dann auch entsprechende IOPs fällig.

Und eben dafür ist ja das 3D XPoint als DRAM gedacht, damit kann man viel größeren RAMs als mit DRAM bauen und mehr im RAM halten, eben weil die Anbindung so noch weniger Latenz als wie als SSD über PCIe hat.

Diese neuen persistenten Speicher die DRAM ersetzen sollen müssen nicht geringere Latenzen als SSD via PCIe haben, sondern sie müssen zwingend Latenzen auf dem Level klassischen DRAMs haben bzw. am besten noch eine Ecke schneller arbeiten. Anonsten taugt der kram zumindest für Datenbankanbindungen nicht.

Die Parallelität ergibt sich normalerweise auf der hohen Zahl der Nutzer, da reicht es wenn für jede Verbindung zur DB ein Thread gestartet wird um alle Kerne gut auslasten zu können.

Ein Maschinchen mit Dual bis Quadsockel und einer Vollbestückung von Anfangs sicher sehr teurem "DRAM-Festspeicher" stellt man sich normalerweise auch nur hin, wenn man den Bedarf hat. Als Spielzeug kostet der Spaß doch zu viel .
Wobei viele moderne DBS Systeme versuchen einzelne Abfragen in möglichst vielen Threads abzuhandeln. Auf realen Datenbanken kommt es schon mal vor, dass an einer Abfrage auf die normalisierte Datenbankstruktur eine zweistellige Anzahl an Threads losmarschiert. Parallelität ist daher nicht nur durch mehr Nutzer erreichbar.
Den ganzen Spaß, dass man irgendwann anfängt die DB zu denormalisieren, zu aggregieren und generell viel schwarze Magie anzuwenden lassen wir mal raus.

In Benchmarks, aber lässt sich davon irgendwas in die Praxis übertragen? Schaffen es z.B. selbst die dickten DB Server so eine SSD die mit 4 oder 8 PCIe Lanes angebunden ist, diesen dann nichts ans Limit zu treiben, dann macht es überhaupt keinen Sinn ein Modell mit 16 PCIe Lanes zu bringen, außer man will eben mit Rekorden auf sich aufmerksam machen.

Wenn ich den Firmenvertretern (aus der Entwicklungs, Adminstration, Hardwarebeschaffung also eher weniger Anzugträger) mit denen ich Kontakt hatte glauben darf ist das Leiden groß. Da werden von EMC dicke "All-Flash-Storage" Units gekauft und auf diesen dann via softwaredefined Storage die Daten massiv redundant vorgehalten, damit die Daten schnell genug ausgeliefert werden können, da eine Kiste allein zu lahm wäre. Da sind also besagte Quadsockelbiester die nichts anderes machen als Flashstorage vorzuhalten und Daten ins Netzwerk zu kippen am Limit. Wobei da gern mal alles limitiert. CPU zu lahm, Dram zu lahm, Festspeicher zu lahm und Netzwerk sowieso zu lahm.

Vorteil ist da aber, dass da jetzt nur wenige Racks mit sau teuren Maschienchen rumstehen, wo vorher der ganze Gang im Rechenzentrum mit Storage vollgepackt war.

Ergänzung (11. August 2016)

ich versteh einfach nicht warum nicht reine kopie oder verschiebe Anweisungen übers PCH laufen. So das dafür nur noch Befehle und Indices durchs DMI laufen müssen. Oder erweitert sogar direkt SSD (mit M.2/U.2 Anbindung) fähig gemacht wird _auch_ neben der CPU, daten zur GPU zu schaufeln... Die Logik dahinter wär doch gar nicht so kompliziert...

Kollisionsfreie, sichere Handhabung komplexer Dateisysteme/Protokolle bei einer Verbindung die nicht mehr exklusiv nur zwischen zwei Geräten? Da muss ich deiner Einschätzung widersprechen. Das wäre abartig komplex.

 

[Holt]

Kopier mal ein Backup, mit 20-30GB auf die Evo.
https://www.computerbase.de/2016-03...ramm-dauertransferrate-schreiben-h2benchw-316
Die Budget-SSDs gehen da sehr schnell in die Knie.

Die 850 Evo ist aber keine Budget SSD und wenn man viele GB am Stück schnell darauf schreiben können möchte, sollte man die 850 Evo mit 500GB und mehr nehmen, die können auch bei vollem Pseudo-SLC Schreibcache noch mit 500MB/s schreiben, was meines Wissens sonst keine SATA SSD mit TLC NANDs schafft. Die BX200 ist dagegen absolut das Negativbeispiel und die anderen liegen irgendwo dazwischen.

In großen Firmen dauern die Beschaffungsprozesse oft Jahre um am Ende das billigste HDD-Storage zum höchsten Preis zu kaufen.

Das hängt sehr von der Firma und der Nutzung des Systems ab, bei geschäftskritischen Anwendungen ist man meist sehr darauf bedacht auf bewährte Technologie zu setzen, bei Forschung und Entwicklung gilt das weniger und man nimmt dort auch gerne mal neue Technologie wenn sie Vorteile oder gar die Lösung von Problemen verspricht, die anderes überhaupt nicht lösbar wären. 3D X-Point zielt eher auf letztere Anwendungen wie eben Bigdata und da sind bestimmte Anwendungen nur machbar, wenn man genug Daten schnell genug analysiert bekommt.

Ich sehe den Einsatz eher bei kleineren Firmen, oder bei Studenten, engagierten IT-Spezis, die im privaten eine Hochleistungsdatenbank aufbauen um für ein Projekt Vorarbeiten zu leisten, ohne Kohle für die fetten Server auf den Tisch legen zu können.

Würde Micron das genauso sehen, würden sie auch ein Modell für Privatkunden bringen.

Beim anschließenden Backup War es dann meist auch die SSD, die 100% busy ist und nur 250-150MB liefert. Für sowas Nerviges muß ich bis zu 7 Minuten einplanen, in denen ich auf Balken starre.

Keine Ahnung was Du da konkret machst, aber wenn viele kleine Dateien gelesen werden müssen, dann schaffen auch SSDs bei QD1 eben keine 500MB/s, bei 4k sind es eben meist so zwischen 20 und 50MB/s und dabei wird die SSDs trotzdem 100%ig ausgelastet, denn das ist aus Windows Sicht der Fall, wenn ständig mindestens ein Zugriff darauf erfolgt, auch wenn der Controller der SSD sich damit sicher noch nicht ausgelastet fühlt.

XPoint als persistenter Speicher ist für mich Festspeicher

Dann hast Du wohl noch nicht ganz verstanden, was Intel mit dem 3D XPoint machen möchte, gerade wenn es in einem RAM Slot gesteckt wird. Da kommt es dann nämlich nicht so darauf an das die Daten persistent gehalten werden, sondern da nutzt man die Tatsache das diese 3D XPoint im Vergleich zu DRAM eine größere Datendichte hat und damit mehr Kapazität bei gleichzeitig geringeren kosten ermöglicht. Man könnte dann wieder eine RAM Disk darauf anlegen, aber das dürfte wegen das Ziel sein als eben einen Rechner mit TB-weise RAM zu schaffen, auch wenn davon eben nur ein paar GB wirklich DRAM sind und vor allem als Cache für das 3D XPoint dient. Der Vorteil gegenüber der Nutzung als Disk ist eben, dass die Datenstukturen dort dann direkt so wie im RAM vorliegen und die CPU sofort direkt darauf zugreifen kann, was eben nochmals schneller geht als wenn diese von einem Speichermedium geladen und ins RAM geschafft werden müssen, selbst wenn das Speichermedium eine RAM Disk ist.

Diese neuen persistenten Speicher die DRAM ersetzen sollen müssen nicht geringere Latenzen als SSD via PCIe haben, sondern sie müssen zwingend Latenzen auf dem Level klassischen DRAMs haben bzw. am besten noch eine Ecke schneller arbeiten.

3D XPoint hat schlechtere Latenzen als DRAM, aber wenn es als RAM genutzt wird, dann sind diese in jedem Fall besser als wenn die Daten erst über PCIe übertragen werden müssen. Die Latenzen müssen eben nicht schneller als die von DRAM sein, dafür ermöglicht es eben einen viel größeren RAM Ausbau und damit vermeidet man viele Daten auf den Platten zu laden, seinen dies nur HDDs, NAND SSDs oder 3D XPoint SSDs und damit erzielt man für Anwendungen die so viel RAM sinnvoll nutzen können, dann eben trotz der schlechteren Latenzen einen Vorteil.

Anonsten taugt der kram zumindest für Datenbankanbindungen nicht.

Es geht nicht um Anbindung, sondern um Nuzen und gerade bei Datenbanken wird der Vorteil enorm sein, weil man dann InMemory Datenbanken mit einer Größe realisieren kann, an die heute einfach noch nicht zu denken ist. Beschäftige Dich noch mal genauer mit dem 3D XPoint und dem was Intel bisher dazu veröffentlich hat, dann wirst Du es hoffentlich auch besser verstehen.

Auf realen Datenbanken kommt es schon mal vor, dass an einer Abfrage auf die normalisierte Datenbankstruktur eine zweistellige Anzahl an Threads losmarschiert. Parallelität ist daher nicht nur durch mehr Nutzer erreichbar.

Das hängt von der jeweiligen DB ab, von Oracle kenne ich es nur, dass dort pro Connection ein Thread läuft.

Wobei da gern mal alles limitiert. CPU zu lahm, Dram zu lahm, Festspeicher zu lahm und Netzwerk sowieso zu lahm.

Wenn alles limitiert wäre es doch optimal, denn dann hätte man ein komplett ausgewogenes System in dem es keinen echten Flaschenhals gibt und damit die anderen Komponenten im Grunde überdimensioniert sind, also den Idealzustand der optimalen Resourcennutzung aller Komponenten. Nur erreicht man sowas in der Praxis eigentlich nie.

Das wäre abartig komplex.

Eben, deshalb ist die CPU eben immer noch die Central Processing Unit, weil alles andere kaum zu realisieren ist und einen unheimlichen Abstimmungsaufwand erfordern würde. Das wäre nicht nur extrem komplex zu implementieren, es würde auch einen gewaltigen Overhead bei der Kommunikation zwischen den Komponenten erfordern, denn da müsste jeder wissen was der andere tun, sobald er auch was machen will, damit sie sich nichts in Gehege kommen. Das ist schon bei der SW Entwicklung eine Herausforderung die viele überfordert und dabei weiß der Entwickler schon beim Programmieren ob die Daten des einen Threads mit denen der anderen etwas zu tun haben und wenn das der Fall ist, muss er synchronisieren, also ein Thread muss waren bis der andere einen bestimmten Punkt erreicht hat und schon nimmt die Parallelität ab.

 

[Piktogramm]

Xpoint als Erweiterung Arbeitsspeichers sehe ich eben nicht. Dazu ist die Latenz eben zu groß und wenn man Slots des Arbeitsspeichers nutzt um da quasi Festspeicher zu installieren verliert man eine Menge X an nicht bestücktem DRAM mit geringerer Latenz. Je nach genauem Anwendungsfall kann das gehen, wenn aber bei einer vollbestückten Maschine alle Daten um Arbeitsspeicher heiß sind, wäre XPoint schlicht ein Nachteil durch die Latenz. Denn mehr Ram bringt nix, wenn die Latenzen zu groß werden.
Das müsste man aber wohl bei der Größenordnung je nach Fall evaluieren.

Was die Storagelösungen angeht, da heulen unterschiedliche Leute mit unterschiedlichen Lastfällen über unterschiedliche Flaschenhälse. Würde alles gleichzeitig am Limit laufen, wäre das dann auch ein Zeichen, dass etwas überhaupt nicht stimmt.


Oracle RDBMS kann parallel Query. Arbeitet also für einige Aktionen Abfragen mit mehreren Prozessen ab. Generell ist es bei den großen DBS aber sowieso noch weit komplexer. Für jede Verbindung ein Thread stimmt. Normalerweise wickeln die aber "nur" die Kommunikation ab und die eigentliche Abfrage geht durch div. Stufen von Compiler, QueryPlaner, Shedulern, Workern etc. pp. die je nach Datenbanksystem je über verschiedene Grade von Multitasking verfügen können. Das ist aber auch notwendig, ansonsten wären einige Datensätze kaum ausreichend schnell zu handhaben.
Extrem vereinfacht: Jede gejointe Tabelle kann man einen Thread spendieren.

 

[Holt]

Xpoint als Erweiterung Arbeitsspeichers sehe ich eben nicht.

Intel sieht es aber anderes.

wenn man Slots des Arbeitsspeichers nutzt um da quasi Festspeicher zu installieren verliert man eine Menge X an nicht bestücktem DRAM mit geringerer Latenz.

Vergiss das es Festspeicher ist und betrachte es als RAM mit dem man sehr viel mehr Arbeitsspeicher realisieren kann als mit DRAM überhaupt möglich wäre.

wenn aber bei einer vollbestückten Maschine alle Daten um Arbeitsspeicher heiß sind, wäre XPoint schlicht ein Nachteil durch die Latenz. Denn mehr Ram bringt nix, wenn die Latenzen zu groß werden.

Klar wäre es für die Performance besser wenn man den gleichen RAM Ausbau mit DRAM realisieren könnte, Intel verspricht die vierfache Kapazität, die dazu passende Purley-Plattform wird einen 6 Kanal RAM Controller bekommen. Damit wären nun z.B. 1.5TB RAM oder 512GB RAM und 4TB 3D XPoint machbar, bzw. das Doppelt oder Vierfache, ist ja egal. Hat man nun 1TB Hot Data, fährt man mit den 1.5TB RAM besser, keine Frage, aber wenn man nun 3TB Hot Data hat, müsste man dann ständig die Daten über PCIe zwischen dem RAM und dem Massenspeicher hin und herschaufeln, also Swappen und selbst mit dem 3D XPoint als Massenspeicher dürfte das eben klar langsamer sein als sie in einem RAM mit zu halten welches eben 250nanosekunden statt nur 100 an Latzen hat.

Das müsste man aber wohl bei der Größenordnung je nach Fall evaluieren.

Eben, pauschale Aussagen was schneller ist, werden nicht möglich sein, aber Fälle in denen 3D XPoint als RAM Vorteile bringt, wird es sicher geben.

Was die Storagelösungen angeht, da heulen unterschiedliche Leute mit unterschiedlichen Lastfällen über unterschiedliche Flaschenhälse.

Das dürfte den unterschiedlichen Lasten geschuldet sein.

Würde alles gleichzeitig am Limit laufen, wäre das dann auch ein Zeichen, dass etwas überhaupt nicht stimmt.

Nein, gerade nicht. Unendliche Geschwindigkeit gibt es nicht, wenn alles gleichzeitig am Limit hängt, hat man das optimal ausgewogene System ohne Flaschenhals hier und Überdimensionierten (und damit i.d.R. zu teuren) Komponenten dort, also den Optimalfall. Es mag sein das dann das Gesamtsystem für den Bedarf zu klein dimensioniert ist, aber in sich ist es dann optimal.

Extrem vereinfacht: Jede gejointe Tabelle kann man einen Thread spendieren.

Also ich bin kein DBA, aber ich sehen immer wieder das bei einem komplizierten Queres mit 11R2 auch über viele Tabellen und mit einer schnellen SSD bzw. wenn die Daten sowieso schon im RAM stehen, dass dann ein Kern bei Linux auf 100% geht und die anderen praktisch nur Idle sind. Keine Ahnung ob das an der Ediiton liegt oder eine Konfigrationsfrage ist ( im normalen Betrieb hängen da ja auch viele Client dran), aber meine Beobachtungen zeigten das bisher auf allen Systemen so, sofern die eben gerade mal Ruhe hatten und nur ich dort drauf war.

 

[cruse]

Die 850 Evo ist aber keine Budget SSD

war aber lange zeit mit die billigste SSD auf Amazon, wenn ich mich recht entsinne. 750, BX usw kamen alle etwas später raus oder waren etwas teurer.

 

[Holt]

Ja, aber dann kamen die andere Modelle mit planaren TLC NANDs und haben die 850 Evo preislich unterboten und heute spürbar billiger zu haben sind. Die würde ich als Budget SSDs bezeichnen.

 

[Vitec]

Also ich würde es durchaus gerne sehen XPOINT Speicher direkt auf den high end Mainboards verlötet zu sehen, müssen ja wie in der SSD Anfangszeit nur 80-100 GB sein.
Da drauf dann das Os und die wichtigsten Programme gepackt und das ganze gleich direkt an die CPU angebunden, ähnlich wie Hauptspeicher nur halt ne Ecke langsamer.
Vielleicht auch wie Ram als Module wo man die Grösse anpassen kann.

Bräuchte man ja nur neben den Ram Slots noch 1-2 xoint Slots dranklatschen.

Dann würde man Pci-e Lanes sparen und den xpoint speicher gleich optimal ohne Leistungseinbussen anbinden können.

 

[Piktogramm]

@Holt

Wenn alles Flaschenhals ist, ist kacke. Bauernregel: Mehr als 80% Auslastung will man "längerfristig" in der Regel nicht, da dadurch Antwortzeiten deutlich überproportional steigen. Daher, wenn alles limitiert, läuft irgendwas falsch.

Ich kenne mich im Detail nicht mit RDBMS von Oracle aus. Die Doku dokumentiert parallel Query und div. Möglichkeiten den Spaß zu konfigurieren. Ob man die Option in der endlosen Oracle Aufpreisliste ersteinmal buchen muss oder die Standardkonfig einfach nach dem Motto "bitte nutze nur 1 der 32 linzensierten Kerne unseres 10.000€ Servers") -> keine Ahnung.
Gut nachvollziehbar ist es bei Microsoft SQL Server und deren grafischem FrontEnd, einfach Ausführungsplan anzeigen lassen und schon ist es recht gut nachvollziehbar wie das Ganze abläuft. Da kann es aber auch sein, dass die kleine Expressversion mit ihrer Limitierung auf 2 Kerne den Effekt wesentlich weniger deutlich zeigt als die großen Varianten. PostgreSQL bekommt ab 9.6 auch endlich mal parallel Query und für andere größere DBS ist es auch verfügbar. An MySQL kann man Parallelität bei Abfragen auch irgendwie anflanschen. Insofern, parallel Query ist unter verschiedenen DBS weit verbreitet.

 

[Holt]

Wenn alles Flaschenhals ist, ist kacke.

Es kann nie alles Flaschenhals sein.

Mehr als 80% Auslastung will man "längerfristig" in der Regel nicht, da dadurch Antwortzeiten deutlich überproportional steigen. Daher, wenn alles limitiert, läuft irgendwas falsch.

Und ich kann Dir auch sagen was: Das System ist zu klein dimensioniert, aber wenn eben alle am Limit hängt, dann ist es in sich korrekt dimensioniert, weil eben alle Komponenten am Limit arbeiten und nicht eine die Leistung der anderen einschränkt, also wirklich ein Flaschenhals ist. Wenn Du das so nicht sieht, tun Du bzw. Dein Arbeitgeber und Deine Kunden mir leid.

 

[Piktogramm]

Du widersprichst dir. Ein System kann nicht gleichzeitig zu klein dimensioniert und korrekt dimensioniert sein. Ein System kann ausgewogen dimensioniert sein, was in einer halbwegs gleichen Auslastung aller kritischen Komponenten mündet. Das ist auch das Ziel. Wenn das darin endet, dass die Kisten jedoch im Ganzen zu hoch ausgelastet sind, dann sind die Kisten trotzdem falsch dimensioniert, da wie festgestellt Leistung fehlt.

 

[Hallo32]

Den wirklichen Vorteil von XPoint sehe bei der geringen Latenz.
Gibt es eigentlich schon Werte, wie sich XPoint verhält wenn parallel Lese- und Schreibzugriffe stattfinden?
(Git zuckelt gerade mit knapp 20MB/s über ~29GB.)

 

[Holt]

Piktogramm, nein, ich widerspreche mir nicht, denn es gibt einmal um die Dimensionierung des Gesamtsystems, welches zu klein ist und zu anderen um die Dimensionierung der Komponenten innerhalb dieses Systems, welche optimal ist wenn alle Komponenten gleichzeitig voll ausgelastet werden. Das ist wie bei Colin Chapmans Spruch: "Der beste Rennwagen ist derjenige, der nach der Ziellinie zusammenbricht," wenn also alle Teile so ausgelegt sind, dass sie gerade mal das Rennen überstehen, dann wurde nichts zu stabil und damit zu schwer gebaut (damals musste die Teile ja nicht mehrere Rennen halten wie es heute ist), nur muss der Rennwagen deswegen noch immer nicht der schnellste im Feld sein.

Es wird eben die gleichen Auslastung aller kritischen Komponenten erzielt, nur ist das eben die Vollauslastung. Daher ist hier eben genau wie Du es ja auch sagst und wie ich es geschrieben habe, die Kiste als Ganzen zu klein, wo ist also der Widerspruch?

Hallo32, nein, dazu habe ich noch nichts gefunden. Da aber 3D XPoint Byteweise adressiert werden kann (sonst wäre es RAM kaum tauglich) und PCIe ja die Daten bidirektional überträgt, dürfte es alleine vom Controller abhängen wie gut sich 3D XPoint bei gleichzeitigen Lese- und Schreibzugriffen schlägt.

 

[Hallo32]

@Holt

Auch wenn der Speicher byteweise adressiert werden kann, so dürfte immer der ganze "Zellstapel"(Reihenschaltung der Speicherzellen), der jeweils ein Bit des Bytes beinhaltet blockiert sein. Ein paralleles Lesen und Schreiben innerhalb eines Zellstapels dürfte somit nicht möglich sein.

Des Weiteren stellt sich die Frage, ob nach einen Schreibzugriff direkt wieder das identische Bit oder ein Bit in physikalischer Nähe innerhalb des Zellstapels sofort ohne Probleme gelesen werden kann, oder ob eine gewisse kleine Zeit gewartet werden muss, bis der Zustand des geschriebenen Bits stabil ist und das Lesen nicht durch Störeffekte, die durch transiente Vorgänge des Schreibvorgangs verursacht werden könnten, beeinflusst wird.

Okay, das ist viel Theorie aber der Gedankengang steckte hinter der obigen Frage des parallelen Lesen und Schreiben.

 

[Holt]

Wenn man erst eine Weile waren muss um ein geschriebenes Bit zu lesen, würde ich doch erwarten, dass Intel dies durch einen Cache für den Controller abfängt und so Daten die direkt nach dem Schreiben gelesen werden, dann auch diesem Cache liefert.

 

[Hallo32]

So etwas würde ich gerne bestätigt haben und nicht nur erwarten.

 

[Holt]

Ist es dafür nicht noch ein wenig zu früh? Gedulde Dich wie alle anderen bis die Dinger auf dem Markt sind und die Reviews dazu erscheinen, einige Reviewer werden das sich auch testen. Außerdem scheint IMFT mit dem 3D XPoint auch nicht alleine zu bleiben, nachdem Samsung irgendwas schnelles angekündigt hat, kommt nun auch WD mit 3D ReRAM:

 

[Hallo32]

Ja, die Frage ist früh aber deshalb nicht weniger interessant.

ReRAM usw. ist alles nicht neu. Es stellt sich nur die Frage zu welchen Preis es produziert werden kann und in welchen Volumen.

Die ersten Prototypen mit diversen "neuartigen" Speicher gab es schon damals als die 64/128GB(?) Flash basierten SSDs so langsam bei den Freaks aufschlugen. Diese Produkte scheiterten damals am Preis und der Verfügbarkeit der "neuartigen" Speicher.

 

[Holt]

Zum Preis steht doch da: HDD 1x, SSD x5, 3D ReRAM (Storage Cass Memory) x20-x25, DRAM x100, wonach es also pro GB 4 bis 5 mal so viel kosten dürfte wie eine SSD (welche auch immer man da zugrunde legt) bzw. ein Viertel bis ein Fünftel von DRAM. Sagen wir also mal grob 80ct bis ein Euro pro GB, denn SSDs gehen bei 20ct/GB los und RAM gibt für etwas unter 4€/GB.