I/O Wait Problem
- Thread starter Ayb
- Start date
Der I/O Wait Peak ist nun deutlich besser werden was den mysql Prozess betrifft 
Wir haben zwar immer noch teilweise kleine Peaks aber das ist dem php-cgi Prozess zu schulde zu schreiben...
Allerdings hätte ich Persönlich nie gedacht das der Unterschied HDD => SSD so deutlich ist, unsere Idee war es damals noch mehr Performance zu bekommen durch einen Dedicated Server und weg vom KVM Server wenn man bedenkt was Contabo da beim größten vServer da Preislich anbietet ist es doch erstaunlich das die Performance trotzdem noch mehr als gut ist....
Die beiden Werte hab ich eingetragen bzw. die Änderung der Log Größe muss ich noch machen, das geht ja leider nicht so im Betrieb...
Wir haben zwar immer noch teilweise kleine Peaks aber das ist dem php-cgi Prozess zu schulde zu schreiben...
Allerdings hätte ich Persönlich nie gedacht das der Unterschied HDD => SSD so deutlich ist, unsere Idee war es damals noch mehr Performance zu bekommen durch einen Dedicated Server und weg vom KVM Server wenn man bedenkt was Contabo da beim größten vServer da Preislich anbietet ist es doch erstaunlich das die Performance trotzdem noch mehr als gut ist....
Die beiden Werte hab ich eingetragen bzw. die Änderung der Log Größe muss ich noch machen, das geht ja leider nicht so im Betrieb...
dataforest
Active Member
Wie Michael schon sagte: Der reine Durchsatz kann mit einem HDD-RAID sogar durchaus höher sein, die IOPS von SSDs erreichst du so aber niemals. Und das ist bei den meisten Applikationen der Knackpunkt, wenn du nicht gerade einen Fileserver betreibst. Daher empfehlen wir für kleine Datenmengen immer SSDs.Die Leistung der vServer von Contabo kann ich persönlich leider nicht beurteilen, und sicher ist man dort (bei uns natürlich auch) noch eine ganze Ecke von der Rohleistung aller physikalisch im Host befindlichen SSDs entfernt. HDD-Arrays werden trotzdem deutlich geschlagen. Wir setzen beispielsweise immer 8-16 SSDs in einem Host ein, da kommt schon eine erhebliche Performance zusammen. Das ist dann das, was ich meine, wenn ich sage, dass günstige dedizierte Server mit guten virtuellen Servern eigentlich nicht mehr wirklich konkurrieren können.
dataforest
Active Member
Guten Morgen,
da ich gerade noch mal über den Tab gestolpert bin: Du könntest auch noch gut etwas herausholen, indem du die Mountoptionen deiner Dateisysteme optimierst. Wie sehen diese derzeit aus?
Viele Grüße
Tim
da ich gerade noch mal über den Tab gestolpert bin: Du könntest auch noch gut etwas herausholen, indem du die Mountoptionen deiner Dateisysteme optimierst. Wie sehen diese derzeit aus?
Viele Grüße
Tim
A
andreas0
Guest
Wie müßten Diese denn bezüglich ext4 aussehen? Kannst du bitte mal ein Beispiel hier reinstellen?
d4f
Kaffee? Wo?
_BITTE_ die Parameter nicht blind übernehmen, je nach Applikation oder Umgebung kann dies zu Fehlverhalten oder Datenverlust führen!
Am relevantesten ist noatime, dieser schaltet das Verhalten von ext4 ab bei jedem Lesen einer Datei den "last accessed" Timestamp zu aktualisieren was enorm viele (teure) Schreibvorgänge verursachen kann.
data=writeback benötigt noch eine Änderung der EXT4-Konfiguration:
tune2fs -o journal_data_writeback
Dieser Parameter kann riskant sein. Er ändert die Reihenfolge von Datenoperationen - bitte im Detail in der Dokumentation selber durchlesen und abwägen!
barrier=0 geht davon aus dass wenn die Festplatte die Daten erhalten hat diese auch gespeichert sind. Das ist bei Raid-Controller ohne Batterie oder Festplatten mit aktiviertem Cache NICHT der Fall also ein Risiko für Datenverlust bei Stromausfall.
nobh führt interne Optimierungen aus, funktioniert nur mit data=writeback
Am relevantesten ist noatime, dieser schaltet das Verhalten von ext4 ab bei jedem Lesen einer Datei den "last accessed" Timestamp zu aktualisieren was enorm viele (teure) Schreibvorgänge verursachen kann.
data=writeback benötigt noch eine Änderung der EXT4-Konfiguration:
tune2fs -o journal_data_writeback
Dieser Parameter kann riskant sein. Er ändert die Reihenfolge von Datenoperationen - bitte im Detail in der Dokumentation selber durchlesen und abwägen!
barrier=0 geht davon aus dass wenn die Festplatte die Daten erhalten hat diese auch gespeichert sind. Das ist bei Raid-Controller ohne Batterie oder Festplatten mit aktiviertem Cache NICHT der Fall also ein Risiko für Datenverlust bei Stromausfall.
nobh führt interne Optimierungen aus, funktioniert nur mit data=writeback
dataforest
Active Member
nobh ist allerdings schon eine ganze Weile deprecated
[netcup] Felix
New Member
Guten Morgen,
ich denke an dem Beispiel hier sehen wir recht gut, dass die "normalen" günstigen dedizierten Server langfristig nicht mit virtuellen Servern mithalten können, was die Preis / Leistung angeht. Besonders wenn wir jetzt auf einen RAID-Controller mit SSD Cache und viele parallel geschalteten SSDs zurückgreifen können, sind IOPS und auch Durchsatz besser als sie jemals ein "normaler" dedizierter Server bieten könnte.
Es gibt ja noch viele weitere Vorteile bei virtuellen Servern:
- Mehrfach redundante Netzwerk- und Strom-Anbindung im Preis in der Regel inklusive
- Weitaus bessere CPUs werden in der Regel verbaut.
- Remote-Konsole im Preis inklusive.
- Einfaches Clonen von Systemen möglich.
- Snapshots etc...
Ohne Frage kann man auch vServer so anbieten, dass sie schlechter als dedizierte Server sind. Kunden die sich aber etwas auskennen, wissen woran man gute vServer und schlechte vServer erkennen kann. Langfristig wird das vermutlich jeder Interessent wissen.
Viele Grüße
Felix
ich denke an dem Beispiel hier sehen wir recht gut, dass die "normalen" günstigen dedizierten Server langfristig nicht mit virtuellen Servern mithalten können, was die Preis / Leistung angeht. Besonders wenn wir jetzt auf einen RAID-Controller mit SSD Cache und viele parallel geschalteten SSDs zurückgreifen können, sind IOPS und auch Durchsatz besser als sie jemals ein "normaler" dedizierter Server bieten könnte.
Es gibt ja noch viele weitere Vorteile bei virtuellen Servern:
- Mehrfach redundante Netzwerk- und Strom-Anbindung im Preis in der Regel inklusive
- Weitaus bessere CPUs werden in der Regel verbaut.
- Remote-Konsole im Preis inklusive.
- Einfaches Clonen von Systemen möglich.
- Snapshots etc...
Ohne Frage kann man auch vServer so anbieten, dass sie schlechter als dedizierte Server sind. Kunden die sich aber etwas auskennen, wissen woran man gute vServer und schlechte vServer erkennen kann. Langfristig wird das vermutlich jeder Interessent wissen.
Viele Grüße
Felix
Last edited by a moderator:
IP-Projects.de
Active Member
Guten Morgen,
das zu pauschalisieren halte ich für schwierig. Wie sagt man so schön - es kommt drauf an. Sicher teilen sich deine Kunden genauso wie die PHP-Friends Kunden die Hardware mit mehreren anderen Kunden. Je nach dem wie viele Kunden du auf einen Server lädst läuft dieser eben besser oder schlechter.
Dedicated Server heißt - der Server arbeitet dediziert nur für mich.
vServer oder für dich auch "Root Server" heißt - der Host arbeitet für alle Kunden. Das können 10 Kunden sein, aber auch 100 oder 500 Kunden. Je nach dem wie diese Kunden dann wiederrum deine Storage belasten, läuft es eben genauso gut / besser oder auch schlechter.
Gebt Ihr euren Kunden Leistungsgarantien, dass das RAID Array immer 500 MB/s schafft oder gar 700 MB/s? Sicherlich nicht, sonst müsstet Ihr ja für jeden Kunden ein eigenes RAID Array im Server betreiben. Letztlich laufen vServer ja eben auch nur auf Dedicated Servern und nicht auf einer flauschigen Wolke
Sicherlich, wenn ich jetzt unseren günstigsten ECO Premium Dedicated Server mit 2x 256 GB Kingston KC400 SSDs, 8 GB RAM und einen Celeron J1900 für 23,90 € brutto / M ins rennen werfe, wird er nicht zwangsweise vergleichbare Performance liefern wie ein vServer mit SSDs im selben Preissegment. Dafür habe ich aber mehr Festplattenkapazität zur Verfügung und liege nicht auf vollgestopften vServer Hosts mit anderen Kunden, wo es abhängig ist von allen Kunden wie performant das Gesamtsystem läuft und wie die Ressourcen verteilt werden.
Ich habe mal einen Benchmark gemacht mit den Intel Celeron J1900, also einer unserer günstigsten Dedicated Server. Als kleine externe Referenz habe ich dazu den Beitrag von https://www.thomaschristlieb.de/benchmark-der-vserver-bei-php-friends/ herangezogen. Der Prozessor verfügt über 4 Cores.
Prozessor
sysbench --num-threads=1 --test=cpu --cpu-max-prime=20000 run
Threads fairness:
events (avg/stddev): 10000.0000/0.00
execution time (avg/stddev): 45.5224/0.00
Festplatte
sysbench --num-threads=1 --test=fileio --file-total-size=6G --file-test-mode=rndrw --max-time=300 --max-requests=0 --file-extra-flags=direct run
Threads fairness:
events (avg/stddev): 17.0000/0.00
execution time (avg/stddev): 0.0369/0.00
Festplatte fsync
sysbench --num-threads=1 --test=fileio --file-fsync-freq=1 --file-num=1 --file-total-size=16384 --file-test-mode=rndwr run
Test execution summary:
total time: 47.4384s
total number of events: 10000
total time taken by event execution: 0.1887
per-request statistics:
min: 0.02ms
avg: 0.02ms
max: 0.09ms
approx. 95 percentile: 0.02ms
Threads fairness:
events (avg/stddev): 10000.0000/0.00
execution time (avg/stddev): 0.1887/0.00
Festplatte write
dd if=/dev/zero of=./test.file bs=1M count=1000 oflag=direct
1048576000 Bytes (1,0 GB) kopiert, 4,74895 s, 226 MB/s
Festplatte read
dd if=./test.file of=/dev/null bs=1M count=1000
1048576000 Bytes (1,0 GB) kopiert, 3,74142 s, 282 MB/s
RAM
sysbench --num-threads=1 --test=memory --memory-block-size=1M --memory-total-size=10G run
Threads fairness:
events (avg/stddev): 10240.0000/0.00
execution time (avg/stddev): 2.6695/0.00
Natürlich stellt hier die CPU den Flaschenhals dar, aber als Dedicated Server der 4 Cores, 8 GB RAM und 256 GB SSD Speicherplatz im RAID 1 ist das Ganze schon nicht schlecht und eben dediziert.
Sicher haben Kunden verschiedene Anforderungen und Bedürfnisse, ich würde aber nicht pauschalisieren, dass es langfristig dafür keine Kunden mehr gibt nur weil irgendein vServer vielleicht gleiche oder bessere Leistungsdaten liefert. Ich kann dir zumindest bestätigen, dass unsere kleinen Server nach wie vor sehr gut gebucht sind. Unser ältestes Atom Serversystem ist vom 28.12.2010 und nach wie vor im Einsatz. Es gibt eben auch in dem Bereich Kunden, die keine Lust auf Abhängigkeiten haben. Aber auch wir werden das vServer Geschäft parallel weiter ausbauen.
das zu pauschalisieren halte ich für schwierig. Wie sagt man so schön - es kommt drauf an. Sicher teilen sich deine Kunden genauso wie die PHP-Friends Kunden die Hardware mit mehreren anderen Kunden. Je nach dem wie viele Kunden du auf einen Server lädst läuft dieser eben besser oder schlechter.
Dedicated Server heißt - der Server arbeitet dediziert nur für mich.
vServer oder für dich auch "Root Server" heißt - der Host arbeitet für alle Kunden. Das können 10 Kunden sein, aber auch 100 oder 500 Kunden. Je nach dem wie diese Kunden dann wiederrum deine Storage belasten, läuft es eben genauso gut / besser oder auch schlechter.
Gebt Ihr euren Kunden Leistungsgarantien, dass das RAID Array immer 500 MB/s schafft oder gar 700 MB/s? Sicherlich nicht, sonst müsstet Ihr ja für jeden Kunden ein eigenes RAID Array im Server betreiben. Letztlich laufen vServer ja eben auch nur auf Dedicated Servern und nicht auf einer flauschigen Wolke
Sicherlich, wenn ich jetzt unseren günstigsten ECO Premium Dedicated Server mit 2x 256 GB Kingston KC400 SSDs, 8 GB RAM und einen Celeron J1900 für 23,90 € brutto / M ins rennen werfe, wird er nicht zwangsweise vergleichbare Performance liefern wie ein vServer mit SSDs im selben Preissegment. Dafür habe ich aber mehr Festplattenkapazität zur Verfügung und liege nicht auf vollgestopften vServer Hosts mit anderen Kunden, wo es abhängig ist von allen Kunden wie performant das Gesamtsystem läuft und wie die Ressourcen verteilt werden.
Ich habe mal einen Benchmark gemacht mit den Intel Celeron J1900, also einer unserer günstigsten Dedicated Server. Als kleine externe Referenz habe ich dazu den Beitrag von https://www.thomaschristlieb.de/benchmark-der-vserver-bei-php-friends/ herangezogen. Der Prozessor verfügt über 4 Cores.
Prozessor
sysbench --num-threads=1 --test=cpu --cpu-max-prime=20000 run
Threads fairness:
events (avg/stddev): 10000.0000/0.00
execution time (avg/stddev): 45.5224/0.00
Festplatte
sysbench --num-threads=1 --test=fileio --file-total-size=6G --file-test-mode=rndrw --max-time=300 --max-requests=0 --file-extra-flags=direct run
Threads fairness:
events (avg/stddev): 17.0000/0.00
execution time (avg/stddev): 0.0369/0.00
Festplatte fsync
sysbench --num-threads=1 --test=fileio --file-fsync-freq=1 --file-num=1 --file-total-size=16384 --file-test-mode=rndwr run
Test execution summary:
total time: 47.4384s
total number of events: 10000
total time taken by event execution: 0.1887
per-request statistics:
min: 0.02ms
avg: 0.02ms
max: 0.09ms
approx. 95 percentile: 0.02ms
Threads fairness:
events (avg/stddev): 10000.0000/0.00
execution time (avg/stddev): 0.1887/0.00
Festplatte write
dd if=/dev/zero of=./test.file bs=1M count=1000 oflag=direct
1048576000 Bytes (1,0 GB) kopiert, 4,74895 s, 226 MB/s
Festplatte read
dd if=./test.file of=/dev/null bs=1M count=1000
1048576000 Bytes (1,0 GB) kopiert, 3,74142 s, 282 MB/s
RAM
sysbench --num-threads=1 --test=memory --memory-block-size=1M --memory-total-size=10G run
Threads fairness:
events (avg/stddev): 10240.0000/0.00
execution time (avg/stddev): 2.6695/0.00
Natürlich stellt hier die CPU den Flaschenhals dar, aber als Dedicated Server der 4 Cores, 8 GB RAM und 256 GB SSD Speicherplatz im RAID 1 ist das Ganze schon nicht schlecht und eben dediziert.
Sicher haben Kunden verschiedene Anforderungen und Bedürfnisse, ich würde aber nicht pauschalisieren, dass es langfristig dafür keine Kunden mehr gibt nur weil irgendein vServer vielleicht gleiche oder bessere Leistungsdaten liefert. Ich kann dir zumindest bestätigen, dass unsere kleinen Server nach wie vor sehr gut gebucht sind. Unser ältestes Atom Serversystem ist vom 28.12.2010 und nach wie vor im Einsatz. Es gibt eben auch in dem Bereich Kunden, die keine Lust auf Abhängigkeiten haben. Aber auch wir werden das vServer Geschäft parallel weiter ausbauen.
A
andreas0
Guest
@IP-Projects.de
Da die einzelnen Werte für sich allein gesehen wenig Sinn machen, habe ich die Befehle noch mal auf einen KVM-Root-Server (vServer) mit einem Intel Xeon E5-2680v4 Prozessor mit 12 vCores ausgeführt. Siehe folgendes Ergebnis:
Wenn ich mir diese Werte - erstellt so zwischen 20:00 und 20:15 Uhr - so anschaue, so muß sich der kleine dedizierte Server mit seinem Celeron Prozessor hinter einen so großen vServer (Root-Server) mit einer Xeon CPU E5-2680v4 und 12 vCores nicht verstecken.
Da die einzelnen Werte für sich allein gesehen wenig Sinn machen, habe ich die Befehle noch mal auf einen KVM-Root-Server (vServer) mit einem Intel Xeon E5-2680v4 Prozessor mit 12 vCores ausgeführt. Siehe folgendes Ergebnis:
Code:
Prozessor
sysbench --num-threads=1 --test=cpu --cpu-max-prime=20000 run
Intel Celeron J1900, dedizierter Server:
Threads fairness
events (avg/stddev): 10000.0000/0.00
execution time (avg/stddev): 45.5224/0.00
Intel Xeon CPU E5-2680v4 mit 12 vCores, Root-Server RS6000:
Threads fairness:
events (avg/stddev): 10000.0000/0.00
execution time (avg/stddev): 39.9998/0.00
Festplatte fsync
sysbench --num-threads=1 --test=fileio --file-fsync-freq=1 --file-num=1 --file-total-size=16384 --file-test-mode=rndwr run
Intel Celeron J1900, dedizierter Server:
Test execution summary:
total time: 47.4384s
total number of events: 10000
total time taken by event execution: 0.1887
per-request statistics:
min: 0.02ms
avg: 0.02ms
max: 0.09ms
approx. 95 percentile: 0.02ms
Threads fairness:
events (avg/stddev): 10000.0000/0.00
execution time (avg/stddev): 0.1887/0.00
Intel Xeon CPU E5-2680v4 mit 12 vCores, Root-Server RS6000:
Test execution summary:
total time: 10.1439s
total number of events: 10000
total time taken by event execution: 0.1569
per-request statistics:
min: 0.01ms
avg: 0.02ms
max: 1.05ms
approx. 95 percentile: 0.02ms
Threads fairness:
events (avg/stddev): 10000.0000/0.00
execution time (avg/stddev): 0.1569/0.00
Festplatte write
dd if=/dev/zero of=./test.file bs=1M count=1000 oflag=direct
Intel Celeron J1900, dedizierter Server:
1048576000 Bytes (1,0 GB) kopiert, 4,74895 s, 226 MB/s
Intel Xeon CPU E5-2680v4 mit 12 vCores, Root-Server RS6000:
1048576000 bytes (1.0 GB) copied, 23.8732 s, 43.9 MB/s
Festplatte read
dd if=./test.file of=/dev/null bs=1M count=1000
Intel Celeron J1900, dedizierter Server:
1048576000 Bytes (1,0 GB) kopiert, 3,74142 s, 282 MB/s
Intel Xeon CPU E5-2680v4 mit 12 vCores, Root-Server RS6000:
1048576000 bytes (1.0 GB) copied, 2.66224 s, 394 MB/s
RAM
sysbench --num-threads=1 --test=memory --memory-block-size=1M --memory-total-size=10G run
Intel Celeron J1900, dedizierter Server:
Threads fairness:
events (avg/stddev): 10240.0000/0.00
execution time (avg/stddev): 2.6695/0.00
Intel Xeon CPU E5-2680v4 mit 12 vCores, Root-Server RS6000:
Threads fairness:
events (avg/stddev): 10240.0000/0.00
execution time (avg/stddev): 1.5733/0.00Wenn ich mir diese Werte - erstellt so zwischen 20:00 und 20:15 Uhr - so anschaue, so muß sich der kleine dedizierte Server mit seinem Celeron Prozessor hinter einen so großen vServer (Root-Server) mit einer Xeon CPU E5-2680v4 und 12 vCores nicht verstecken.
Last edited by a moderator:
Was sind kleine Datenmenge bei dir?
ATM brauchen wir um die 350GB+ das steigt allerdings auch immer wieder.
Unzufrieden bin nicht, wenn nicht gerade ein Peak vorhanden ist läuft alles sehr gut und schnell so wie es auch gedacht war. Die Peaks sind nun auch deutlich besser geworden.
Meine Kenntnisse sind da nun aber auch nicht die besten was es noch an Möglichkeiten gibt, evtl. einen SSD Cache?
Sollte das alle in Zukunft natürlich keine Besserung bringen, müsste man sich überlegen den Server zu wechseln und einen zu nutzen, der eben SSD hat, was preislich dann natürlich auch wieder einen guten Satz nach oben macht um ähnlichen Platz zu erhalten wie jetzt auch.
A
andreas0
Guest
Damit man dein Problem eventuell noch weiter eingrenzen kann bzw. dir weitere Forummitglieder noch weitere Tipps zur Optimierung deines neuen Servers geben können: Kannst du uns mal mitteilen, aus welchen Hardwarekomponenten dein Server besteht und wie dein RAID 10 realisiert wird? Also per Software- oder Hartware-RAID und mit welcher Cache-Größe? Denn wenn ich mir deine zu Anfang rein gestellten Abbildungen so anschaue, so langweilt sich eher dein Server.
Hattest du auch mal die von @d4f vorgestellten Mountoptionen ausprobiert?
Lord Gurke
Nur echt mit 32 Zähnen
killerbees19
Member
@Lord Gurke: afaik impliziert NOATIME bereits NODIRATIME.
Nur bei letzterem gilt es ausschließlich für Verzeichnisse.
MfG Christian
Nur bei letzterem gilt es ausschließlich für Verzeichnisse.
MfG Christian
d4f
Kaffee? Wo?
Die Mountoptionen sind spezifisch für EXT4 ausser noatime welches XFS auch unterstützt. Bei XFS kannst du ggf bspw Logbuffer anpassen, hier kann ich aber mangels Erfahrung keine konkreten Parameter vorschlagen.
Bei einem HW-Raid mit einem Adaptec "XXXXE" Controller (also ohne Batterie) kannst du in jedem Fall nicht Schreibbeschleunigung durch "Cache Commit" machen da du riskierst bei einem Servercrash oder Stromausfall sonst Datenkorruption, Datenverlust bis hin zu kaputtes Dateisystem zu haben.
Ein Vorschlag am Rand; wenn deine IO-Peaks hauptsächlich lesend sind würde ich bei IPP nachfragen ob der Einbau einer günstigen SSD bei dir möglich ist und in deinem Kostenrahmen liegt. Darauf dann BCache im Writearound Modus betreiben. Alternativ wäre Writeback eine Lösung um die angesprochenen Raid-Cacheprobleme zu umgehen aber ich konnte es zumindest bei meinen Workloads (viele Logdateien und viele Emails) nicht zufriedenstellend betreiben und es setzt dann einen teuereren SSD-Verbund (RAID1) zur Datensicherung voraus. Selbstverständlich könntest du auch die Datenbank und andere kritischen Operationen dann direkt darauf betreiben...
Ich habe Bcache zwar selber erst seit paar Wochen im Produktiveinsatz aber es hat meine Erwartungen als backing device für ein LVM deutlich übertroffen insbesondere was Datenbankoperationen in den LV's angeht.
IP-Projects.de
Active Member
Ist nicht grundsätzlich eine Neuinstallation notwendig um bcache einzusetzen? Laut Thomas Krenn ist es nicht ohne Weiteres möglich, eine Partition im Nachhinein mit bache zu versorgen. Es gibt aber etwas das nennt sich Intel Cache Acceleration Software - http://www.intel.com/content/www/us/en/software/intel-cache-acceleration-software-performance.html - kostet ca. 50 $ pro Host. Ich werde mir mal einen unserer Restposten installieren und das Ganze einmal testen und im laufenden Betrieb einzubinden. Vielleicht eine einfache und nette Alternative.
d4f
Kaffee? Wo?
Ein bcache-device muss entsprechende superblocks haben, ja. Es gibt ein Werkzeug "blocks" ( https://github.com/g2p/blocks ) welches entsprechende Umwandlung vornehmen kann, natürlich ist ein Backup aber sehr, sehr empfohlen. Die Seite beinhaltet auch eine Beschreibung wie man root-Partitionen auf bcache umwandelt. Falls die Datenpartition getrennt ist würde ich aber nur diese mit bcache betreiben.
Ob man produktiv verwendete Maschinen entsprechend umbauen will oder soll, ist hier mal dahingestellt. Ich habe nur die Möglichkeit erörtert und würde eine Umwandlung vermutlich _NIE_ selber durchführen.
Mit hersteller-eigenen Lösungen (Stec Inc's Enhanceio, Facebook Flashcache, OCZ Acceleration disks) habe ich bislang ausschliesslich die schlechte Erfahrung gemacht dass irgendwann der Hersteller entweder aufgekauft wird (Stec Inc) oder das Produkt nicht mehr weiterentwickelt (OCZ) und man dann spätestens bei Updates auf dem Trocknen sitzt. Bcache ist dagegen Bestandteil des Kernels und damit deutlich zukunftsfreundlicher.
NB: Es würde mich sehr interessieren zu sehen wie Intel CAS auf einem "normalen" Server läuft. Ein kleiner Kommentar nach dem Test wäre sehr nett
Ob man produktiv verwendete Maschinen entsprechend umbauen will oder soll, ist hier mal dahingestellt. Ich habe nur die Möglichkeit erörtert und würde eine Umwandlung vermutlich _NIE_ selber durchführen.
Mit hersteller-eigenen Lösungen (Stec Inc's Enhanceio, Facebook Flashcache, OCZ Acceleration disks) habe ich bislang ausschliesslich die schlechte Erfahrung gemacht dass irgendwann der Hersteller entweder aufgekauft wird (Stec Inc) oder das Produkt nicht mehr weiterentwickelt (OCZ) und man dann spätestens bei Updates auf dem Trocknen sitzt. Bcache ist dagegen Bestandteil des Kernels und damit deutlich zukunftsfreundlicher.
NB: Es würde mich sehr interessieren zu sehen wie Intel CAS auf einem "normalen" Server läuft. Ein kleiner Kommentar nach dem Test wäre sehr nett