Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.os.unix.linux.hardware > #24004 > unrolled thread

Test Postgresql-DB mit Drehplatte

Back to article view | Back to de.comp.os.unix.linux.hardware

Contents

  Test Postgresql-DB mit Drehplatte Patrick Rudin <taxi_bs@gmx.ch> - 2026-04-24 13:24 +0200
    Re: Test Postgresql-DB mit Drehplatte Marco Moock <mm@dorfdsl.de> - 2026-04-28 06:41 +0200
      Re: Test Postgresql-DB mit Drehplatte Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2026-04-28 08:47 +0200
        Re: Test Postgresql-DB mit Drehplatte Marco Moock <mm@dorfdsl.de> - 2026-04-28 16:12 +0200
          Re: Test Postgresql-DB mit Drehplatte Nomen Nescio <nobody@dizum.com> - 2026-04-28 14:37 +0000
          Re: Test Postgresql-DB mit Drehplatte Patrick Rudin <taxi_bs@gmx.ch> - 2026-04-28 18:12 +0200
            Re: Test Postgresql-DB mit Drehplatte Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-04-28 22:37 +0200
          Re: Test Postgresql-DB mit Drehplatte "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-04-28 19:25 +0200
            Re: Test Postgresql-DB mit Drehplatte Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2026-04-29 09:10 +0200
              Re: Test Postgresql-DB mit Drehplatte "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-05-01 23:38 +0200
              Re: Test Postgresql-DB mit Drehplatte "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-05-01 23:55 +0200
                Re: Test Postgresql-DB mit Drehplatte Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2026-05-02 00:20 +0200
                  Re: Test Postgresql-DB mit Drehplatte Marco Moock <mm@dorfdsl.de> - 2026-05-02 15:20 +0200
                    Re: Test Postgresql-DB mit Drehplatte Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2026-05-02 15:49 +0200
                    Re: Test Postgresql-DB mit Drehplatte "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-05-02 16:41 +0200
                      Re: Test Postgresql-DB mit Drehplatte Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2026-05-02 17:04 +0200
                        Re: Test Postgresql-DB mit Drehplatte "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-05-02 17:41 +0200
                          Re: Test Postgresql-DB mit Drehplatte Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2026-05-03 09:27 +0200
                    Re: Test Postgresql-DB mit Drehplatte Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-05-02 16:46 +0200
                      Re: Test Postgresql-DB mit Drehplatte Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2026-05-02 17:13 +0200
                        Re: Test Postgresql-DB mit Drehplatte Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-05-02 19:05 +0200
                Re: Test Postgresql-DB mit Drehplatte Ralph Aichinger <ra@h5.or.at> - 2026-05-02 10:25 +0000
                  Re: Test Postgresql-DB mit Drehplatte "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-05-02 15:05 +0200
                    Re: Test Postgresql-DB mit Drehplatte Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2026-05-02 14:18 +0000
                      Re: Test Postgresql-DB mit Drehplatte Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2026-05-02 17:11 +0200
                      Re: Test Postgresql-DB mit Drehplatte "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-05-02 17:23 +0200
                        Re: Test Postgresql-DB mit Drehplatte Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2026-05-02 17:28 +0000
                Re: Test Postgresql-DB mit Drehplatte Marco Moock <mm@dorfdsl.de> - 2026-05-02 15:21 +0200
                  Re: Test Postgresql-DB mit Drehplatte Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2026-05-02 15:50 +0200
                  Re: Test Postgresql-DB mit Drehplatte "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-05-02 16:58 +0200
                  Re: Test Postgresql-DB mit Drehplatte Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-05-02 17:07 +0200
          Re: Test Postgresql-DB mit Drehplatte Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-04-28 22:33 +0200
          Re: Test Postgresql-DB mit Drehplatte Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2026-04-29 09:07 +0200
            Re: Test Postgresql-DB mit Drehplatte Marco Moock <mm@dorfdsl.de> - 2026-04-29 17:30 +0200
              Re: Test Postgresql-DB mit Drehplatte "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2026-05-01 23:52 +0200
                Re: Test Postgresql-DB mit Drehplatte Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2026-05-02 00:31 +0200
              Re: Test Postgresql-DB mit Drehplatte Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2026-05-02 00:32 +0200
      Re: Test Postgresql-DB mit Drehplatte Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-04-28 10:11 +0200
        Re: Test Postgresql-DB mit Drehplatte Marcel Mueller <news.5.maazl@spamgourmet.org> - 2026-04-28 21:01 +0200
          Re: Test Postgresql-DB mit Drehplatte Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-04-28 22:22 +0200
            Re: Test Postgresql-DB mit Drehplatte Marc Haber <mh+usenetspam2616@zugschl.us> - 2026-04-29 07:47 +0200
              Re: Test Postgresql-DB mit Drehplatte Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-04-29 08:47 +0200
            Re: Test Postgresql-DB mit Drehplatte Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2026-04-29 22:43 +0000
            Re: Test Postgresql-DB mit Drehplatte Patrick Rudin <taxi_bs@gmx.ch> - 2026-04-30 11:56 +0200
              Re: Test Postgresql-DB mit Drehplatte Arthur Erhardt <usenet2026@erhardt-net.de> - 2026-04-30 11:10 +0000
              Re: Test Postgresql-DB mit Drehplatte Marcel Mueller <news.5.maazl@spamgourmet.org> - 2026-04-30 18:02 +0200
      Re: Test Postgresql-DB mit Drehplatte Patrick Rudin <taxi_bs@gmx.ch> - 2026-04-28 13:34 +0200

Page 1 of 3  [1] 2 3  Next page →

#24004 — Test Postgresql-DB mit Drehplatte

Mancher mag sich vielleicht noch erinnern, dass ich hier nach dem Sinn 
einer HDD für eine grosse Postgresql-DB gefragt habe. Dank einer edlen 
Spende eines Regulars (eine ältere 2 TB-HDD) habe ich das inzwischen mal 
getestet.

Konkret: Asrock X300-Kiste mit Ryzen 5 4600G-Prozessor und 2x32 GB 
DDR4-RAM. Also nicht die absolute Leistungskanone, aber durchaus in der 
Lage, eine HDD zu beschäftigen.

In der Postgres.conf habe ich nach langem googeln shared_buffers auf 16 
GB erhöht, work_mem auf 8 GB und maintenance_work_mem auf 12 GB. Ob das 
die Krönung an Einstellungen ist, weiss ich nicht.

Aus Zeitgründen habe ich mich auf eine Datenbank mit 2,7 Milliarden rows 
und 32 Feldern beschränkt. 5 Indexfelder. Tabelle benötigte 818 GB, dazu 
5x17 GB für die Indizes.

Booten und Installieren erinnerte natürlich an alten Zeiten, aber 
immerhin brach beim Befüllen der DB nicht plötzlich (wie bei der SSD) 
die Schreibleistung ein. Wie auch immer, Kernpunkt war für mich die 
Leseleistung.

Und hier ist eine DB in dieser Grösse durchaus benutzbar: Die übliche 
Abfrage via Indexfeld dauerte 2-3 Minuten. "Warm" auch deutlich kürzer, 
weil wohl der Index teilweise schon im Hauptspeicher ist.

Problem ist halt, dass ich gelegentlich eben doch herumstreune und 
deshalb Bestände aggregieren möchte, für die er die ganze DB durchackern 
muss. Das dauert reproduzierbar jeweils 6,5 Stunden.

Die ursprünglich verwendete 4 TB-SSD dient inzwischen woanders, daher 
habe ich für den Test eine alte Crucial MX100 mit 960 GB an den 
SATA-Port gehängt. Wegen des Befüllungsgrades sind es nur 2 Milliarden 
rows, für ein vollständiges Durchnudeln der DB braucht der Rechner 38 
Minuten. Übliche Abfrage per Index dafür 10-20 Sekunden.

Fazit: Pro Monat kämen bei der vollen DB rund 70 Millionen rows dazu, 
vollständig läge ich inzwischen bei rund 7 Milliarden rows. Das wäre 
dann selbst mit gebifurkateten(tm) Consumer-SSDs eher schlecht 
handelbar, und bei HDD würden die 6,5 Stunden schon optimistisch linear 
hochgerechnet etwa 16 Stunden ergeben. Für eine simple fishing-Query, 
die dann eine zweite detailliertere Abfrage nach sich zieht, die 
ebensolang bräuchte?

Kurzum: Datenbestand wird massiv reduziert, vorerst sollte die 960 
GB-SSD sogar ausreichen. Und ich einem Jahr oder zwei schaue ich mal, 
wie sich die SSD-Preise entwickelt haben...


Grüsse

Patrick

[toc] | [next] | [standalone]

#24005

On 24.04.2026 13:24 Patrick Rudin wrote:

> Booten und Installieren erinnerte natürlich an alten Zeiten, aber 
> immerhin brach beim Befüllen der DB nicht plötzlich (wie bei der SSD) 
> die Schreibleistung ein. Wie auch immer, Kernpunkt war für mich die 
> Leseleistung.

Ist die HDD denn schneller als die SSD?

Konntest du die Ursache finden, warum die SSD nach einer gewissen Zeit
langsamer wurde?
War das ggf. einfach nur der Cache vom OS im RAM?

[toc] | [prev] | [next] | [standalone]

#24006

Marco Moock <mm@dorfdsl.de> wrote:

> On 24.04.2026 13:24 Patrick Rudin wrote:
> 
> > Booten und Installieren erinnerte natürlich an alten Zeiten, aber 
> > immerhin brach beim Befüllen der DB nicht plötzlich (wie bei der
> > SSD) die Schreibleistung ein. Wie auch immer, Kernpunkt war für
> > mich die Leseleistung.  
> 
> Ist die HDD denn schneller als die SSD?
> 
> Konntest du die Ursache finden, warum die SSD nach einer gewissen Zeit
> langsamer wurde?

Das ist durchaus üblich. Ibs. bei NVMEs, die liefern gerne mal 90s
mehrere GB/s, um sich dann auf SSD-Niveau (500-600MB/s) zu begeben.

> War das ggf. einfach nur der Cache vom OS im RAM?

DBen, die sich beim Schreiben auf OS-Caches verlassen, sind mäßig
brauchbar.

-- 
Denkst Du noch, oder promptest Du schon?

[toc] | [prev] | [next] | [standalone]

#24009

On 28.04.2026 08:47 Dietz Proepper wrote:

> Marco Moock <mm@dorfdsl.de> wrote:
> > War das ggf. einfach nur der Cache vom OS im RAM?  
> 
> DBen, die sich beim Schreiben auf OS-Caches verlassen, sind mäßig
> brauchbar.

MariaDB nimmt in der Standardeinstellung ein Verzeichnis mit ein oder
mehreren Dateien auf dem eh vorhandenen Dateisystem. In so einer
Konstellation hat die DB auf das Verhalten des Dateisystems keinen
Einfluss.

Wenn die Kontrolle darüber haben soll, braucht die eine eigene
Partition ganz für sich allein ohne ein Dateisystem (und RAID, LVM &
Co.).

Ist sowas üblich?

[toc] | [prev] | [next] | [standalone]

#24010

Marco Moock <mm@dorfdsl.de> wrote:

> Wenn die Kontrolle darüber haben soll, braucht die eine eigene
> Partition ganz für sich allein ohne ein Dateisystem (und RAID, LVM &
> Co.).
>
> Ist sowas üblich?

Vor langer Zeit, als der DBA noch entscheiden musste, auf welchen Spindles 
Daten und Index liegen.

[toc] | [prev] | [next] | [standalone]

#24011

Marco Moock wrote:
> In so einer
> Konstellation hat die DB auf das Verhalten des Dateisystems keinen
> Einfluss.

Weshalb es Empfehlungen gibt, welches Dateisystem man idealerweise 
nutzen sollte.

https://archive.fosdem.org/2024/events/attachments/fosdem-2024-3605-postgres-vs-linux-filesystems/slides/22850/postgres-vs-filesystems-fosdem-2024_QQG6Ha7.pdf


Gruss

Patrick

[toc] | [prev] | [next] | [standalone]

#24016

Patrick Rudin <taxi_bs@gmx.ch> wrote:
> Marco Moock wrote:
>> In so einer
>> Konstellation hat die DB auf das Verhalten des Dateisystems keinen
>> Einfluss.
>
> Weshalb es Empfehlungen gibt, welches Dateisystem man idealerweise 
> nutzen sollte.

Blind geraten: "Nimm ext4 oder XFS und einen aktuellen Kernel"?

> https://archive.fosdem.org/2024/events/attachments/fosdem-2024-3605-postgres-vs-linux-filesystems/slides/22850/postgres-vs-filesystems-fosdem-2024_QQG6Ha7.pdf

Ok, klar, wie erwartet.

Man liest sich,
             Alex.
-- 
"Opportunity is missed by most people because it is dressed in overalls and
 looks like work."                                      -- Thomas A. Edison

[toc] | [prev] | [next] | [standalone]

#24012

On 2026-04-28 16:12, Marco Moock <mm@dorfdsl.de> wrote:
> On 28.04.2026 08:47 Dietz Proepper wrote:
>
>> Marco Moock <mm@dorfdsl.de> wrote:
>> > War das ggf. einfach nur der Cache vom OS im RAM?  
>> 
>> DBen, die sich beim Schreiben auf OS-Caches verlassen, sind mäßig
>> brauchbar.

Je länger ich über diesen Satz nachdenke, desto weniger Sinn kann ich
ihm entnehmen.


> MariaDB nimmt in der Standardeinstellung ein Verzeichnis mit ein oder
> mehreren Dateien auf dem eh vorhandenen Dateisystem.

Es wird aber (so wie andere RDBMS auch) zumindest bei jeder Transaktion,
wahrscheinlich aber häufiger, die Daten mittels fsync o.ä. auf die
Platte zwingen. Bei PostgreSQL z.B. ist ein WAL-Segment (per default)
16MB groß: Spätestens nach 16 MB wird also auf jeden Fall auf die Platte
geschrieben.

> In so einer Konstellation hat die DB auf das Verhalten des
> Dateisystems keinen Einfluss.

Das Dateisystem stellt Mechanismen zur Verfügung, die das RDBMS nützt.
Wie das RDBMS diese Mechanismen nützt, hat einen großen Einfluss auf die
Performance, die Datensicherheit, etc.

> Wenn die Kontrolle darüber haben soll, braucht die eine eigene
> Partition ganz für sich allein ohne ein Dateisystem (und RAID, LVM &
> Co.).
>
> Ist sowas üblich?

Nein, davon ist man schon in den 90er-Jahren weitgehend abgekommen, weil
es in der Praxis wenig bringt. Oracle (die Firma) hat für den "Real
Application Cluster" z.B. ein eigenes Filesystem entwickelt und nicht
direkt auf Blockdevices aufgesetzt, obwohl Oracle (das RDBMS) das
unterstützt hat.

        hjp

[toc] | [prev] | [next] | [standalone]

#24020

"Peter J. Holzer" <hjp-usenet4@hjp.at> wrote:

> On 2026-04-28 16:12, Marco Moock <mm@dorfdsl.de> wrote:
> > On 28.04.2026 08:47 Dietz Proepper wrote:
> >  
> >> Marco Moock <mm@dorfdsl.de> wrote:  
> >> > War das ggf. einfach nur der Cache vom OS im RAM?    
> >> 
> >> DBen, die sich beim Schreiben auf OS-Caches verlassen, sind mäßig
> >> brauchbar.  
> 
> Je länger ich über diesen Satz nachdenke, desto weniger Sinn kann ich
> ihm entnehmen.

Aha. Wo hört die Sinnentnahme auf? Bei "DB", "Schreiben" oder "Cache"?

> > MariaDB nimmt in der Standardeinstellung ein Verzeichnis mit ein
> > oder mehreren Dateien auf dem eh vorhandenen Dateisystem.  
> 
> Es wird aber (so wie andere RDBMS auch) zumindest bei jeder
> Transaktion, wahrscheinlich aber häufiger, die Daten mittels fsync
> o.ä. auf die Platte zwingen.

*Hüstel*. Das ist genau da, was ich oben ausdrücken wollte.

> Bei PostgreSQL z.B. ist ein WAL-Segment
> (per default) 16MB groß: Spätestens nach 16 MB wird also auf jeden
> Fall auf die Platte geschrieben.

Auch Postgres müsste einen Modus haben, wo nach Beenden der Transaktion
*zuverlässig* alles geschrieben wurde, oder?

-- 
Denkst Du noch, oder promptest Du schon?

[toc] | [prev] | [next] | [standalone]

#24026

On 2026-04-29 09:10, Dietz Proepper <dietz.usenet@rotfl.franken.de> wrote:
> "Peter J. Holzer" <hjp-usenet4@hjp.at> wrote:
>> On 2026-04-28 16:12, Marco Moock <mm@dorfdsl.de> wrote:
>> > On 28.04.2026 08:47 Dietz Proepper wrote:
>> >> Marco Moock <mm@dorfdsl.de> wrote:  
>> >> > War das ggf. einfach nur der Cache vom OS im RAM?    
>> >> 
>> >> DBen, die sich beim Schreiben auf OS-Caches verlassen, sind mäßig
>> >> brauchbar.  
>> 
>> Je länger ich über diesen Satz nachdenke, desto weniger Sinn kann ich
>> ihm entnehmen.
>
> Aha. Wo hört die Sinnentnahme auf? Bei "DB", "Schreiben" oder "Cache"?

Bei "verlassen". Der dedizierte Zweck eines Schreib-Caches ist, Daten
*nicht* sofort auf das Device zu schreiben. Wer sich also "beim
Schreiben auf OS-Caches verlässt", verlässt sich darauf, dass manche
Daten nicht auf der Platte stehen und bei einem Crash verloren gehen
werden. Es sagt mir, dass Du das nicht gemeint hast ;-)


>> > MariaDB nimmt in der Standardeinstellung ein Verzeichnis mit ein
>> > oder mehreren Dateien auf dem eh vorhandenen Dateisystem.  
>> 
>> Es wird aber (so wie andere RDBMS auch) zumindest bei jeder
>> Transaktion, wahrscheinlich aber häufiger, die Daten mittels fsync
>> o.ä. auf die Platte zwingen.
>
> *Hüstel*. Das ist genau da, was ich oben ausdrücken wollte.
>
>> Bei PostgreSQL z.B. ist ein WAL-Segment
>> (per default) 16MB groß: Spätestens nach 16 MB wird also auf jeden
>> Fall auf die Platte geschrieben.
>
> Auch Postgres müsste einen Modus haben, wo nach Beenden der Transaktion
> *zuverlässig* alles geschrieben wurde, oder?

Siehe oben: "zumindest bei jeder Transaktion". Beim Commit wird das WAL
jedenfalls geschrieben und ge-fsync-t, und das Commit kehrt auch erst
zurück, wenn das abgeschlossen ist[1]. Aber eine Transaktion kann
natürlich mehr als 16 MB an Daten ändern (ich habe ziemlich regelmäßig
Transaktionen, bei denen zig GB geschrieben werden), und da wird dann
halt kontinuierlich in 16-MB-Segmenten geschrieben (und jedes Segment
ge.fsync-t).

        hjp

[1] Per Default. Wie vieles bei PostgreSQL ist natürlich auch das
    konfigurierbar.

[toc] | [prev] | [next] | [standalone]

#24028

On 2026-04-29 09:10, Dietz Proepper <dietz.usenet@rotfl.franken.de> wrote:
> "Peter J. Holzer" <hjp-usenet4@hjp.at> wrote:
>> On 2026-04-28 16:12, Marco Moock <mm@dorfdsl.de> wrote:
>> > On 28.04.2026 08:47 Dietz Proepper wrote:
>> >> Marco Moock <mm@dorfdsl.de> wrote:  
>> >> > War das ggf. einfach nur der Cache vom OS im RAM?    
>> >> 
>> >> DBen, die sich beim Schreiben auf OS-Caches verlassen, sind mäßig
>> >> brauchbar.  
>> 
>> Je länger ich über diesen Satz nachdenke, desto weniger Sinn kann ich
>> ihm entnehmen.
>
> Aha. Wo hört die Sinnentnahme auf? Bei "DB", "Schreiben" oder "Cache"?

Bei "verlassen". Der dedizierte Zweck eines Schreib-Caches ist, Daten
*nicht* sofort auf das Device zu schreiben. Wer sich also "beim
Schreiben auf OS-Caches verlässt", verlässt sich darauf, dass manche
Daten nicht auf der Platte stehen und bei einem Crash verloren gehen
werden. Etwas sagt mir, dass Du das nicht gemeint hast ;-)


>> > MariaDB nimmt in der Standardeinstellung ein Verzeichnis mit ein
>> > oder mehreren Dateien auf dem eh vorhandenen Dateisystem.  
>> 
>> Es wird aber (so wie andere RDBMS auch) zumindest bei jeder
>> Transaktion, wahrscheinlich aber häufiger, die Daten mittels fsync
>> o.ä. auf die Platte zwingen.
>
> *Hüstel*. Das ist genau da, was ich oben ausdrücken wollte.
>
>> Bei PostgreSQL z.B. ist ein WAL-Segment
>> (per default) 16MB groß: Spätestens nach 16 MB wird also auf jeden
>> Fall auf die Platte geschrieben.
>
> Auch Postgres müsste einen Modus haben, wo nach Beenden der Transaktion
> *zuverlässig* alles geschrieben wurde, oder?

Siehe oben: "zumindest bei jeder Transaktion". Beim Commit wird das WAL
jedenfalls geschrieben und ge-fsync-t, und das Commit kehrt auch erst
zurück, wenn das abgeschlossen ist[1]. Aber eine Transaktion kann
natürlich mehr als 16 MB an Daten ändern (ich habe ziemlich regelmäßig
Transaktionen, bei denen zig GB geschrieben werden), und da wird dann
halt kontinuierlich in 16-MB-Segmenten geschrieben (und jedes Segment
ge.fsync-t).

        hjp

[1] Per Default. Wie vieles bei PostgreSQL ist natürlich auch das
    konfigurierbar.

[toc] | [prev] | [next] | [standalone]

#24029

"Peter J. Holzer" <hjp-usenet4@hjp.at> wrote:

> On 2026-04-29 09:10, Dietz Proepper <dietz.usenet@rotfl.franken.de>
> wrote:
> > "Peter J. Holzer" <hjp-usenet4@hjp.at> wrote:  
> >> On 2026-04-28 16:12, Marco Moock <mm@dorfdsl.de> wrote:  
> >> > On 28.04.2026 08:47 Dietz Proepper wrote:  
> >> >> Marco Moock <mm@dorfdsl.de> wrote:    
> >> >> > War das ggf. einfach nur der Cache vom OS im RAM?      
> >> >> 
> >> >> DBen, die sich beim Schreiben auf OS-Caches verlassen, sind
> >> >> mäßig brauchbar.    
> >> 
> >> Je länger ich über diesen Satz nachdenke, desto weniger Sinn kann
> >> ich ihm entnehmen.  
> >
> > Aha. Wo hört die Sinnentnahme auf? Bei "DB", "Schreiben" oder
> > "Cache"?  
> 
> Bei "verlassen". Der dedizierte Zweck eines Schreib-Caches ist, Daten
> *nicht* sofort auf das Device zu schreiben. Wer sich also "beim
> Schreiben auf OS-Caches verlässt", verlässt sich darauf, dass manche
> Daten nicht auf der Platte stehen und bei einem Crash verloren gehen
> werden. Etwas sagt mir, dass Du das nicht gemeint hast ;-)

Eigentlich hatte ich genau dies gemeint ;-). Marco vermutete doch, dass
Einbrüche der Schreibgeschwindigkeit mit OS-Caches zu tun habe.

-- 
Denkst Du noch, oder promptest Du schon?

[toc] | [prev] | [next] | [standalone]

#24034

Am 02.05.26 um 00:20 schrieb Dietz Proepper:
> "Peter J. Holzer" <hjp-usenet4@hjp.at> wrote:
> 
>> On 2026-04-29 09:10, Dietz Proepper <dietz.usenet@rotfl.franken.de>
>> wrote:
>>> "Peter J. Holzer" <hjp-usenet4@hjp.at> wrote:
>>>> On 2026-04-28 16:12, Marco Moock <mm@dorfdsl.de> wrote:
>>>>> On 28.04.2026 08:47 Dietz Proepper wrote:
>>>>>> Marco Moock <mm@dorfdsl.de> wrote:
>>>>>>> War das ggf. einfach nur der Cache vom OS im RAM?
>>>>>>
>>>>>> DBen, die sich beim Schreiben auf OS-Caches verlassen, sind
>>>>>> mäßig brauchbar.
>>>>
>>>> Je länger ich über diesen Satz nachdenke, desto weniger Sinn kann
>>>> ich ihm entnehmen.
>>>
>>> Aha. Wo hört die Sinnentnahme auf? Bei "DB", "Schreiben" oder
>>> "Cache"?
>>
>> Bei "verlassen". Der dedizierte Zweck eines Schreib-Caches ist, Daten
>> *nicht* sofort auf das Device zu schreiben. Wer sich also "beim
>> Schreiben auf OS-Caches verlässt", verlässt sich darauf, dass manche
>> Daten nicht auf der Platte stehen und bei einem Crash verloren gehen
>> werden. Etwas sagt mir, dass Du das nicht gemeint hast ;-)
> 
> Eigentlich hatte ich genau dies gemeint ;-). Marco vermutete doch, dass
> Einbrüche der Schreibgeschwindigkeit mit OS-Caches zu tun habe.

Was auch sein kann, weil der erstmal dafür sorgt, dass es auf den ersten 
Blick aus Sicht der Anwendung schneller geht, weil die signalisiert 
bekommt, dass der Inhalt geschrieben ist, auch wenn der noch gar nicht 
auf der Platte ist.
Kann man mit dd sehr gut sehen, wenn man ein sync macht oder mit eject 
den Datenträger auswerfen will.

-- 
Gruß
Marco

Spam bitte an abfalleimer2001@stinkedores.dorfdsl.de

[toc] | [prev] | [next] | [standalone]

#24036

Marco Moock <mm@dorfdsl.de> wrote:

> Am 02.05.26 um 00:20 schrieb Dietz Proepper:
> > "Peter J. Holzer" <hjp-usenet4@hjp.at> wrote:
> >   
> >> On 2026-04-29 09:10, Dietz Proepper <dietz.usenet@rotfl.franken.de>
> >> wrote:  
> >>> "Peter J. Holzer" <hjp-usenet4@hjp.at> wrote:  
> >>>> On 2026-04-28 16:12, Marco Moock <mm@dorfdsl.de> wrote:  
> >>>>> On 28.04.2026 08:47 Dietz Proepper wrote:  
> >>>>>> Marco Moock <mm@dorfdsl.de> wrote:  
> >>>>>>> War das ggf. einfach nur der Cache vom OS im RAM?  
> >>>>>>
> >>>>>> DBen, die sich beim Schreiben auf OS-Caches verlassen, sind
> >>>>>> mäßig brauchbar.  
> >>>>
> >>>> Je länger ich über diesen Satz nachdenke, desto weniger Sinn kann
> >>>> ich ihm entnehmen.  
> >>>
> >>> Aha. Wo hört die Sinnentnahme auf? Bei "DB", "Schreiben" oder
> >>> "Cache"?  
> >>
> >> Bei "verlassen". Der dedizierte Zweck eines Schreib-Caches ist,
> >> Daten *nicht* sofort auf das Device zu schreiben. Wer sich also
> >> "beim Schreiben auf OS-Caches verlässt", verlässt sich darauf,
> >> dass manche Daten nicht auf der Platte stehen und bei einem Crash
> >> verloren gehen werden. Etwas sagt mir, dass Du das nicht gemeint
> >> hast ;-)  
> > 
> > Eigentlich hatte ich genau dies gemeint ;-). Marco vermutete doch,
> > dass Einbrüche der Schreibgeschwindigkeit mit OS-Caches zu tun
> > habe.  
> 
> Was auch sein kann, weil der erstmal dafür sorgt, dass es auf den
> ersten Blick aus Sicht der Anwendung schneller geht, weil die
> signalisiert bekommt, dass der Inhalt geschrieben ist, auch wenn der
> noch gar nicht auf der Platte ist.

Dann ist der Cache kaputt, sorry.

> Kann man mit dd sehr gut sehen, wenn man ein sync macht oder mit
> eject den Datenträger auswerfen will.

Das "D" in "ACID" steht nicht für "gammle irgendwo in caches rum".

-- 
Denkst Du noch, oder promptest Du schon?

[toc] | [prev] | [next] | [standalone]

#24039

On 2026-05-02 15:20, Marco Moock <mm@dorfdsl.de> wrote:
> Am 02.05.26 um 00:20 schrieb Dietz Proepper:
>> Eigentlich hatte ich genau dies gemeint ;-). Marco vermutete doch, dass
>> Einbrüche der Schreibgeschwindigkeit mit OS-Caches zu tun habe.
>
> Was auch sein kann, weil der erstmal dafür sorgt, dass es auf den ersten 
> Blick aus Sicht der Anwendung schneller geht, weil die signalisiert 
> bekommt, dass der Inhalt geschrieben ist, auch wenn der noch gar nicht 
> auf der Platte ist.
> Kann man mit dd sehr gut sehen, wenn man ein sync macht oder mit eject 
> den Datenträger auswerfen will.

dd ist aber keine Datenbank. Wie bereits geschrieben, rufen Datenbanken
sehr häufig fsync auf, um die Daten auf die Platte zu zwingen. Zumindest
das Journal, aber mit etwas Verzögerung auch die Datenfiles. Der Inhalt
auf der Platte muss zu jedem Zeitpunkt konsistent sein und den Zustand
des letzten Commit widerspiegeln. Da ist kaum jemals mehr als ein GB
"dirty", im Normalfall wohl eher nur ein paar MB. Auch bei Bulk-Imports
kommt es nicht vor, dass da erstmal das RAM vollgeschrieben und dann
erst auf die Platte gesynct wird.

        hjp

[toc] | [prev] | [next] | [standalone]

#24041

"Peter J. Holzer" <hjp-usenet4@hjp.at> wrote:
> ein paar MB. Auch bei Bulk-Imports kommt es nicht vor, dass da
> erstmal das RAM vollgeschrieben und dann erst auf die Platte gesynct
> wird.

Naja, bei bulk imports ist es ja durchaus nicht unüblich, in eine
Transaktion n inserts zu packen und den Importer (idealerweise)
idempotent zu machen. Was bei ausreichend großen chunks durchaus auch
interessante Auswirkungen auf die Laufzeit haben kann ...

Davon unabhängig, der DB ist es letztendlich freigestellt, bei Zeiten
auch eigene oder OS-Caches zu verwenden. Sobald der commit zurück kommt
muss sichergestellt sein, dass die Daten permanent geschrieben wurden.

-- 
Denkst Du noch, oder promptest Du schon?

[toc] | [prev] | [next] | [standalone]

#24047

On 2026-05-02 17:04, Dietz Proepper <dietz.usenet@rotfl.franken.de> wrote:
> "Peter J. Holzer" <hjp-usenet4@hjp.at> wrote:
>> ein paar MB. Auch bei Bulk-Imports kommt es nicht vor, dass da
>> erstmal das RAM vollgeschrieben und dann erst auf die Platte gesynct
>> wird.
>
> Naja, bei bulk imports ist es ja durchaus nicht unüblich, in eine
> Transaktion n inserts zu packen und den Importer (idealerweise)
> idempotent zu machen.

Das ändert aber (bei PostgreSQL) nichts daran, dass auch diese Inserts
mitgeloggt werden und somit spätestens beim nächsten WAL-Switch ein
fsync passiert. Außer man verwendet unlogged Tables, aber die verlieren
bei einem Crash den Inhalt, können nicht repliziert werden, etc.

Oracle hat Direct Path Imports, die direkt in die Tabellen schreiben,
aber wenn ich die technischen Details dazu jemals gekannt habe, habe ich
sie inzwischen vergessen. Auch das hat aber hat aber sichergestellt,
dass man immer einen konsistenten Zustand hatte.

        hjp

[toc] | [prev] | [next] | [standalone]

#24050

"Peter J. Holzer" <hjp-usenet4@hjp.at> wrote:

> On 2026-05-02 17:04, Dietz Proepper <dietz.usenet@rotfl.franken.de>
> wrote:
> > "Peter J. Holzer" <hjp-usenet4@hjp.at> wrote:  
> >> ein paar MB. Auch bei Bulk-Imports kommt es nicht vor, dass da
> >> erstmal das RAM vollgeschrieben und dann erst auf die Platte
> >> gesynct wird.  
> >
> > Naja, bei bulk imports ist es ja durchaus nicht unüblich, in eine
> > Transaktion n inserts zu packen und den Importer (idealerweise)
> > idempotent zu machen.  
> 
> Das ändert aber (bei PostgreSQL) nichts daran, dass auch diese Inserts
> mitgeloggt werden und somit spätestens beim nächsten WAL-Switch ein
> fsync passiert. Außer man verwendet unlogged Tables, aber die
> verlieren bei einem Crash den Inhalt, können nicht repliziert werden,
> etc.
> 
> Oracle hat Direct Path Imports, die direkt in die Tabellen schreiben,
> aber wenn ich die technischen Details dazu jemals gekannt habe, habe
> ich sie inzwischen vergessen. Auch das hat aber hat aber
> sichergestellt, dass man immer einen konsistenten Zustand hatte.

Ack.

-- 
Denkst Du noch, oder promptest Du schon?

[toc] | [prev] | [next] | [standalone]

#24043

Marco Moock <mm@dorfdsl.de> wrote:
> Am 02.05.26 um 00:20 schrieb Dietz Proepper:
>> "Peter J. Holzer" <hjp-usenet4@hjp.at> wrote:
>> 
>>> On 2026-04-29 09:10, Dietz Proepper <dietz.usenet@rotfl.franken.de>
>>> wrote:
>>>> "Peter J. Holzer" <hjp-usenet4@hjp.at> wrote:
>>>>> On 2026-04-28 16:12, Marco Moock <mm@dorfdsl.de> wrote:
>>>>>> On 28.04.2026 08:47 Dietz Proepper wrote:
>>>>>>> Marco Moock <mm@dorfdsl.de> wrote:
>>>>>>>> War das ggf. einfach nur der Cache vom OS im RAM?
>>>>>>>
>>>>>>> DBen, die sich beim Schreiben auf OS-Caches verlassen, sind
>>>>>>> mäßig brauchbar.
>>>>>
>>>>> Je länger ich über diesen Satz nachdenke, desto weniger Sinn kann
>>>>> ich ihm entnehmen.
>>>>
>>>> Aha. Wo hört die Sinnentnahme auf? Bei "DB", "Schreiben" oder
>>>> "Cache"?
>>>
>>> Bei "verlassen". Der dedizierte Zweck eines Schreib-Caches ist, Daten
>>> *nicht* sofort auf das Device zu schreiben. Wer sich also "beim
>>> Schreiben auf OS-Caches verlässt", verlässt sich darauf, dass manche
>>> Daten nicht auf der Platte stehen und bei einem Crash verloren gehen
>>> werden. Etwas sagt mir, dass Du das nicht gemeint hast ;-)
>> 
>> Eigentlich hatte ich genau dies gemeint ;-). Marco vermutete doch, dass
>> Einbrüche der Schreibgeschwindigkeit mit OS-Caches zu tun habe.
>
> Was auch sein kann, weil der erstmal dafür sorgt, dass es auf den ersten 
> Blick aus Sicht der Anwendung schneller geht, weil die signalisiert 
> bekommt, dass der Inhalt geschrieben ist, auch wenn der noch gar nicht 
> auf der Platte ist.

Dann ist irgendwo was extrem oberfaul und massiv kaputt:
 - Datenbank
 - OS
 - Festplatte (ja, Platten die zu "flush" gelogen haben gab es auch
   schon, war gut für bestimmte Benchmarks)

> Kann man mit dd sehr gut sehen, wenn man ein sync macht oder mit eject 
> den Datenträger auswerfen will.

Wenn die DB sich nicht an ACID hält, kann man sie direkt wegwerfen. Oder
der Konkurrenz andrehen, wenn man selbige für hinreichend unfähig hält.

Man liest sich,
            Alex.
-- 
"Opportunity is missed by most people because it is dressed in overalls and
 looks like work."                                      -- Thomas A. Edison

[toc] | [prev] | [next] | [standalone]

#24045

Alexander Schreiber <als@usenet.thangorodrim.de> wrote:

> Marco Moock <mm@dorfdsl.de> wrote:
[wann werden unter welchen Bedingungen Caches geflushed?]
> > Kann man mit dd sehr gut sehen, wenn man ein sync macht oder mit
> > eject den Datenträger auswerfen will.  
> 
> Wenn die DB sich nicht an ACID hält, kann man sie direkt wegwerfen.
> Oder der Konkurrenz andrehen, wenn man selbige für hinreichend
> unfähig hält.

Alexander! Das ist nicht web scale!

-- 
Denkst Du noch, oder promptest Du schon?

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | de.comp.os.unix.linux.hardware

csiph-web