Gibt es so etwas wie einen hartnäckigen Widderantrieb?

Nach was Sie suchen, ist etwas, das die fs-Daten im Speicher speichert und wenn möglich fortsetzt, aber keine Sorge über den Verlust Ihrer Daten macht (z. B. wenn jemand die Stromversorgung ausschaltet).

Sie könnten in Cachefs nachschauen und sehen, ob Sie es so konfigurieren können, dass es beim Schreiben wirklich faul ist.

Ich bin auch misstrauisch, dass Sie das richtige Problem lösen. Mit einer angemessenen Menge an Arbeitsspeicher sollten Sie diese Schreibvorgänge nicht blockieren.

Sie können auch die Writeback-Mount-Option für Ihr Dateisystem festlegen. Siehe zum Beispiel dies .

Sie könnten ein einfaches rcSkript schreiben, das dies tut. Ich erinnere mich, dass ich an DOS-Tagen (mit autoexec.bat) ein ähnliches Verfahren für den schnellen Zugriff auf einige Dateien ausgeführt habe.

Erwägen Sie stattdessen den Kauf eines SSD- oder RAM-Laufwerks mit Festplattenschnittstelle.

Der Umgang mit RAM-Disks unter Linux ist ziemlich trivial. Sie können sie je nach Ihren Anforderungen auf verschiedene Arten erstellen und verwenden. Kopieren Sie dann den Inhalt (mit cp oder dd) vor dem Herunterfahren der Box auf hdd oder in einem geplanten Intervall, um Datenverlust für ein unerwartetes Herunterfahren zu vermeiden. Sehen Sie sich diese Anleitungen an, ich denke, sie sind einfach genug:

http://www.vanemery.com/Linux/Ramdisk/ramdisk.html

http://wiki.archlinux.org/index.php/Ramdisk

M

Eine Ramdisk ist wahrscheinlich der Weg zu gehen. Wenn Sie jedoch etwas Geld ausgeben und eine wirklich dauerhafte Lösung wünschen, sollten Sie sich auch SSD-Festplatten ansehen . Die Technologie ist recht jung und noch nicht so robust wie die klassische Festplatte, aber sie wird immer reifer und erschwinglicher.

Wenn Ihre App klein genug ist, können Sie ein 30-GB-Solid-State-Laufwerk für Ihre Maschine nutzen. Benchmarks zeigen, dass sie 3x oder 4x schneller lesen als herkömmliche Laufwerke (und etwa 2,4x so schnell wie Laufwerke mit 10.000 U / min). Die größeren Laufwerke kosten ein Paket, aber die 30-Gig-Laufwerke kosten knapp 200 US-Dollar.

Obwohl dies nicht direkt mit RAM-Platten zusammenhängt, kann dies dazu beitragen, dass Sie Ihr Problem umgehen.

Sie können zwei MySQL-Server ausführen, von denen einer auf der Ramdisk vorhanden ist und der andere ein Slave ist, der alle Daten auf einer Festplatte speichert.

Auf diese Weise können Sie den ramdisk-basierten mysql-Server nach dem Ausschalten oder was auch immer starten, Sie können einfach ..

cat mysqldump -uroot -hslaveServer Datenbankname | mysql -uroot -hramdiskServer Datenbankname

Das Betriebssystem macht dies bereits für reguläre Dateisystemzugriffe (puffert die Schreibvorgänge in den RAM-Speicher und leert sie später). Um jedoch robuster zu sein, müssen viele Datenbanken dann ein fsync () ausführen, um das Betriebssystem dazu zu zwingen, die Puffer auf die Festplatte zu leeren, was die Abläufe verlangsamt.

Die Steuerung, ob MySQL einen Synchronisierungsvorgang ausführt, wird auf der Ebene der zugrunde liegenden Datenbank durchgeführt. Ich habe mir InnoDB angesehen und es ist nicht möglich, fsync zu deaktivieren.

Bei der Suche habe ich jedoch libeatmydata gefunden, die fsync für einen Prozess deaktivieren kann, der Ihnen das Verhalten geben soll, nach dem Sie suchen.

Sie sagen, dass Sie dies auf einem Notebook-Computer ausführen. Funktioniert die "Ruhezustand" - und Wiederaufnahmefunktion konsequent darauf? Wenn ja ... können Sie dies konsequent verwenden und auch eine oder beide dieser beiden völlig getrennten Dinge tun, um die Zugriffszeiten für beide Webseiten und für MySQL-Abfragen zu verbessern:

• (a) Einrichten und Verwenden eines Ramfs für Ihren DOCROOT; google für "Linux Ramdisk mini-HOWTO" für weitere Informationen. Dies zahlt sich möglicherweise nicht aus. Sie sollten möglicherweise den RAM für die Verwendung durch MySQL (dh (b) unten) speichern, insbesondere wenn sich in diesen MEMORY-Tabellen viele Daten befinden.

• (b) Migrieren Sie Ihre MySQL-Datenbanktabellen, auf die am häufigsten zugegriffen wird, auf die MEMORY-Speicher-Engine. Stellen Sie sicher, dass Ihre Tabellenstruktur keine BLOB- oder TEXT-Spalten erfordert. Wenn ja, funktioniert das nicht. Lesen Sie dies hier: http://dev.mysql.com/doc/refman/5.0/de/memory-storage-engine.html

Für jeden der oben genannten Punkte müssen Sie etwas planen, um die In-Memory-Images regelmäßig auf die Festplatte zu kopieren. Der Vorteil ist, dass Sie nur gelegentlich auf diese langsame Festplatte schreiben - eine Art Zeitlupensynchronisation - anstatt mit jeder Änderung an einer MySQL-Tabelle und jeder Änderung an einer Datei in DOCROOT zu schreiben. In beiden Fällen können Sie mit CRON ein "Backup" planen:

• Im Fall von ramfs könnten Sie ein tar-Archiv aller Inhalte im Dateisystem erstellen.

• Für die MySQL-Tabellen können Sie eine Reihe von Anweisungen ähnlich der folgenden erstellen:

  einfügen in someInnoDBdatabase.tablename select * from someMemoryDatabase.tablename

  Angenommen, Ihre Tabelle in beiden Datenbanken hat genau dieselbe Struktur, die alles aus der Tabelle in someMemoryDatabase in die gleichnamige someInnoDBdatabase-Tabelle kopiert, wodurch die MEMORY-Tabelle auf der Festplatte gesichert wird.

Beim Erstellen dieser Tabellen in der Speicherdatenbank:
Angenommen, Sie haben jetzt Tabellen, die von einer On-Disk-Engine verwaltet werden, Sie können "show create table tablename" verwenden, damit MySQL Ihnen genau die SQL liefert, die Sie zum erneuten Erstellen dieser Tabelle benötigen ... ändern Sie dann den Engine-Teil, um anzugeben, dass die MEMORY-Engine verwendet werden soll, und führen Sie diesen aus.

Hoffe das hilft!
-pbr

Was Sie erreichen möchten, ist in der Tat sehr gut möglich, aber mir sind keine fertigen Lösungen bekannt. Sie müssten die entsprechenden Skripte mehr oder weniger selbst schreiben. Ich habe das Gefühl, dass diese Tatsache allein ein Dealbreaker für Sie ist, aber wenn Sie die Aufgabe übernehmen wollen, bin ich zuversichtlich, dass Sie alle Hilfe erhalten, die Sie brauchen.

"The OS already does that for regular file system accesses (buffers the writes to RAM and then flushes them later). But to be more robust, many databases then do a fsync()..." -- R Samuel Klatchko

So to speed up your unit tests, so they don't sit around waiting for each and every write to be completely fsync'ed, there are several things you can try:

• run the tests in a virtual machine that lets you turn on "unsafe" write-back caching, which effectively turns fsync() into an extremely fast no-op. (But only do this for unit testing, not on a production database).
• run the tests in a virtual machine with a -snapshot option such as QEMU -- this redirects all writes to a log file. During the test, it redirects some reads to that log file to maintain the illusion. Relatively linear writes to the log file are likely to be faster than writes that are scattered all over the disk platter.
• somehow minimize the number of writes in your unit test -- does it really need to be writing to the test database?

• If you can trim the test database used by your unit tests to fit entirely in RAM, perhaps getting the OS to pre-cache the entire database in one go (rather than read and cache a little bit at a time, as needed in the test) might make tests faster; with something like

  cat the_test_database.db > /dev/null

• run the tests on a machine with RAID-0 striping to speed up reads and writes. (I've been looking for laptops that support RAID -- alas, laptops that support RAID are very rare).