Upsize und ISAM-Emulation

Hier dreht es sich um den PostGre Server

Moderator: Moderatoren

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Upsize und ISAM-Emulation

Beitrag von AUGE_OHR »

Werner_Bayern hat geschrieben: Di, 16. Jul 2019 15:27 Ein dbeval() mit insert. 8)
ich fragte ja nach einen "UpSize" ...

klar gäbe es auch andere Wege. ich würde die DBF als CSV importieren.
gruss by OHR
Jimmy
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: Upsize und ISAM-Emulation

Beitrag von Tom »

Mach doch. Und hör damit auf, Threads zuzufüllen, zu denen Du nichts Produktives beizutragen hast. Danke.
Herzlich,
Tom
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Upsize und ISAM-Emulation

Beitrag von AUGE_OHR »

hi Tom,

ich finde mich schon ziemlich Produktive wenn ich (unbequeme) Fragen stelle und dann im Forum Antworten von Usern bekomme. durch die Fragen haben sich ja auch (unbeabsichtigte) Antworten ergeben wie z.B. das PgDBE nur ein "Übergangstadium" sein soll.

Frage : würdest du heute noch jemanden den "Hybrid" Modus empfehlen wenn er nach GUI will ?

JA ich bin den Weg gegangen und deshalb würde ich es keinem mehr empfehlen der nach GUI will weil es einfach Zeitverschwendung ist. das selbe nun mit der PgDBE wo die Leute dann mit grossen Datenmengen merken das die Performance noch schlechter ist als mit DBF.

---

Die PgDBE "übersetzt" xBase Befehle in eine SQL Qwery die einem Anfänger helfen soll.
wenn sich nun ansieht was hinter solchen Qwery steckt wird festellen das es "wenig" ist was man für xBase braucht.

wer sich nun mit SQL beschäftigt wird nicht darum vorbei kommen selbst die SQL Qwery zu erstellen z.b. mit PgAdmin.
also wenn dann wie Werner gleich "pass through" =D>
... aber dafür benötigt man dann nicht die internen Index FIELD

und damit sind wir wieder bei UpSize Tool welches diese internen FIELD anlegt ...
gruss by OHR
Jimmy
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Re: Upsize und ISAM-Emulation

Beitrag von ramses »

Werner_Bayern hat geschrieben: Di, 16. Jul 2019 12:58 Sind alle von mir gemeldet, weitere folgen, wenn ich Zeit hab. Meine Motivation dafür geht aber gegen 0 - aus Gründen, die ich hier nicht schreiben möchte (sie wurden schon des Öfteren angesprochen).
Hallo Werner

das geht mir momentan auch so. Motivation = 0

Wie Steffen hier gewünscht hat habe ich mich betr. Server Config und Performance an den Support gewandt.
Die können mir aber ohne ein genaues Beispiel inkl. Datenbanken und Systembeschreibung welches das Problematische Verhalten (Schlechte Performance) zeigt keine Tips geben und gar nicht weiterhelfen. Ein solches Muster zu bauen ist ja auch ein ziemlicher Aufwand.

Es scheint als wäre ich der einzige mit Performanceproblemen mit dem PGDBE ISAM-EMU ....

MIt einer anderen Tabelle in der Datenkank mit der ich direkt mit Aufrufen über die libpq.dll arbeite zeigt keinerlei Performanceprobleme.
Und diese liegt auf den gleichen Server und hat nur ca. 454'000'000 Datensätze und die Aufgaben/Zugriffe sind vergleichbar.......
Valar Morghulis

Gruss Carlo
Benutzeravatar
Werner_Bayern
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2120
Registriert: Sa, 30. Jan 2010 22:58
Wohnort: Niederbayern
Hat sich bedankt: 29 Mal
Danksagung erhalten: 70 Mal

Re: Upsize und ISAM-Emulation

Beitrag von Werner_Bayern »

ramses hat geschrieben: Do, 18. Jul 2019 7:05 Es scheint als wäre ich der einzige mit Performanceproblemen mit dem PGDBE ISAM-EMU ....
Nein, das haben wir ja schon erörtert, bei großen Datenmengen (ca. > 50000 DS, je nach Struktur und Inhalt etc.) wird es halt langsam und das Upsize dauert auch seine Zeit. Bei Dir jedoch wesentlich länger als bei mir. Das wäre halt interessant, mit dem Support zu erörtern. Ich hab denen auch schon mal meine Artikel.dbf mit 400k DS geschickt, daraufhin wurden einige Anpassungen gemacht, die z. B. dazu geführt haben, dass ein use mit set index to danach um Welten schneller ging.

Manchmal ist es den Aufwand schon wert. 8)
In Deinem Fall wäre es doch relativ einfach? upsize-Datei und die DBF dazu?
es grüßt

Werner

<when the music is over, turn off the lights!>
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Re: Upsize und ISAM-Emulation

Beitrag von ramses »

Werner_Bayern hat geschrieben: Do, 18. Jul 2019 15:08 In Deinem Fall wäre es doch relativ einfach? upsize-Datei und die DBF dazu?
Leider nicht ganz so einfach.
Nach Steffens "Einsprachen" wollte ich doch noch einen Versuch machen.
Deshalb versuche ich jetzt ein Testfall zusammen zu stellen der das Verhalten nachstellen kann.
Valar Morghulis

Gruss Carlo
Benutzeravatar
steffen.pirsig
Cut&Paste-Entwickler
Cut&Paste-Entwickler
Beiträge: 24
Registriert: Fr, 04. Nov 2011 12:09
Wohnort: Eschborn, Deutschland
Danksagung erhalten: 6 Mal
Kontaktdaten:

Re: Upsize und ISAM-Emulation

Beitrag von steffen.pirsig »

Hallo Carlo,
ramses hat geschrieben: Fr, 12. Jul 2019 23:00 Also gut. Einen mache ich noch. Wie sollte denn die "optimal" angepasste Konfiguration des PG Servers aussehen damit die Geschwindigkeit so genial wird wie du sagts?

Ich habe ein Sub. ohne Support. Wie reagiert denn da euer Support wenn ich da Anrufe und dauernd nach Dingen Frage die eigentlich in der Doku und Code Beispielen stehen sollten?
Ich habe nicht gesagt das die Geschwindigkeit genial wird - ich habe nur ausgeführt das es vielfältige Ursachen für deine Performance geben kann. Und leider muss ich dich enttäuschen, es kann wohl nicht von Alaska Software verlangt werden die PostgreSQL zu dokumentieren. Dazu gibt es Sekundärliteratur.

Fangen wir mal an das ganze Problem der mangelhaften Performance beim Upsize oder der PostgreSQL zu betrachten:

1.) Wie mittlerweile erkennbar ist ein PostgreSQL Server oder generell jeder SQL Server eine "relativ" komplizierte Geschichte. Der Grund liegt im Prinzip daran, das der Server mit dem Planer versucht euch als Mensch zu ersetzten. In ISAM habt Ihr das Datenmodel im Kopf, auch die Anforderungen an das System in Bezug auf welcher Auswertungen und Analysen werden gebraucht. Im Code schreibt Ihr dann das alles runter und habt ein hoch spezialisiertes aber auch hoch performantes System - idealerweise :)

Bei einem SQL Server übernimmt sozusagen das Code Schreiben der Planer und Optimizer die nehmen eure Anfrage (SQL Statement) und planen dann die ISAM operationen. Dazu wird die Hardware betrachtet, welches Kosten verursacht ein Tabellen Read, ein Tabellen Scan, ein Index Search ein Index Scan, was kostet ein Festplattenzugriff und es wird betrachtet welche Daten wie in der Tabelle/Index vorliegen - also eher ähnliche Daten oder alles unterschiedlich oder Clusterbildungen von Schlüsselwerten und,so weiter und so fort. Für diejenigen die es interessiert, EXPLAIN ANALYZE vor einem SQL SELECT z.b. liefert kein Ergebnis aber den genauen Plan den der Server berechnet hat um an die Daten zu kommen.

Lange Rede kurzer Sinn, wenn die Konfiguration des PostgreSQL Servers nicht korrekt auf die Hardware abgestimmt ist dann kann der Server:
a.) keine korrekten Pläne erstellen und alles geht langsamer vonstatten
b.) kann der Server die Hardware nicht vollständig Nutzen und kommt dann in sogenannte Race-Conditions (Erkennbar wenn die Performance im Verlauf einer Operationssequenz (z.b Upsize) immer langsamer wird.

Die erste Maßnahme ist deshalb die Konfiguration anzupassen, dazu gibt es ein Tool das einem zumindest den Grundsatz abnimmt hier:
https://pgtune.leopard.in.ua/#/

Diejenigen die High Transaction Raten (mehr als 500 Transaktionen/Sekunde) haben sollten Online Transaction Processing System als DB Type wählen.

Die Konfigurationsparameter werden in der Datei postgresql.conf geändert, diese Datei findet sich im Datenverzeichnis des Servers. Damit die Änderungen wirksam werden muss der Server neu gestartet werden, also Services -> PostgreSQL -> Restart.

Auf jeden Fall sollte nach der entsprechenden Konfiguration des PostgreSQL Servers ein DbfUpsize zu einer schönen Sägezahn Kurve im Task-Manager -> Performance (logical CPU View) führen. Dies mit einer 30%-70% CPU Last. Der Hauptspeicher den die PostgreSQL Prozesse benötigen darf über die Operation/DbfUpsize leicht ansteigen - eine Kurve mit 10%-15% Steigung für die Speicherlast ist OK, sollte aber im Verlauf flacher werden. Voreingestellt versucht der DbfUpsize mit 4 Threads die PostgreSQL zu sättigen, idealer Weise sollten alle 4 Balken mehr oder minder gleichzeitig voranschreiten, gibt es da ein Mißverhältniss dann bedeutet dies, das euer PostgreSQL Server mit dieser Last (zu viele Parallele Aufgaben) nicht klar kommt. Sollte der Server mit PGtune bereits korrekt konfiguriert sein dann probiert bitte DbfUpsize -st <upsize-definition> siehe Xbase++ DbfUpsizer Dokumentation oder -? auf der Kommandozeile. Die Ursache ist dann wahrscheinlich ne billige CPU == viele Kerne aber wenig Cache und wenig Speicher I/O Kanäle oder aber ein sch… OnBoard SATA Controller der alles von der CPU machen läßt. Wichtig, PGtune fragt nach CPU Kernen, nicht logischen CPUs welche via Hyperthreading (HT) zur Verfügung stehen. HT nützt bei einem DB Server rein gar nichts und ist überflüssig.

Eine SAS Platte sollte ungefähr die 2-3 fache Performance wie eine SATA liefern, ein RAID10 also Striped Mirror sollte das ganze nochmal verdoppeln.

2.) Der zweite wichtige Punkt ist, was könnt Ihr von einem PostgreSQL Server oder generell einem SQL Server an Performance erwarten. Nun da müssen wir erst einmal anschauen welche Garantien der Server gibt. Im Falle eines SQL Servers sind das im Regelfall die ACID (4)Eigenschaften - gerade die letztere D=Durability (4) ist entscheidend für die Performance. Von einem SQL Server wird erwartet das nach einem COMMIT der Strom ausfallen darf und keine Daten verloren gehen die vor dem COMMIT übertragen wurden. Klingt erst mal gut, bedeutet aber das der Server im Falle eines COMMIT immer alle Daten auf der Festplatte gespeichert haben muss. Und mit Festplatte meine ich die kleinen ferromagnetischen Glas oder Aluminiumscheiben im Gehäuse der HD und nicht der Puffer des HD Controllers oder den Cache des File Systems.

Wenn aber eine bessere Festplatte mit 7200 RPM dreht, dann kann diese Festplatte maximal 120 unterschiedliche Sektoren in der Sekunde anfahren! Das ist bei Festplatten konstruktionsbedingt so. Wenn wir also idealerweise eine Rekord pro Sektor annehmen dann könnte wir mit der Durability Garantie nur 120 Records / Sekunde wegschreiben - PENG! Mit meiner DBF ohne commit schaffe ich circa 20.000 Records/Sekunde auf meinen Laptop - WOW.

Aufgrund des vorgenannten ist es wichtig einen SQL Server und natürlich auch den PostgreSQL je nach Workload szenario entsprechend zu konfigurieren (Hardware und Software).

Wen eine neue Datenbank aufgebaut und geladen werden soll macht es Sinn folgende Konfigurationsparameter des Servers anzupassen:

a1: synchronous_commit = OFF
a2: wal_writer_delay = 5000ms

Dadurch wird es dem Server erlaubt das Schreiben auf die Festplatte zu verzögern, um genau zu sein um 15 Sekunden maximal ( 3 x wal writer delay ), dadurch sollte der Upsize Prozess schneller werden. Ich schreibe sollte weil es so in der PostgreSQL Server Dokumentation und der Sekundärliteratur (3) steht, aber leider nicht immer sich so verhält. Hier muss also probiert werden.

Natürlich könnt ihr auch die Hardware optimieren, das ist im Regelfall günstiger und bringt mehr als alles andere denn eine Samsung 850 PRO SSD schafft etwa 36.000 Random Writes/Sekunde und ist damit um ein vielfaches schneller als die 7200 RPM HD, höherwertige Enterprise SSDs gehen da noch höher.

Wichtig beim Umstieg auf die SSD ist die TBW (Tera-Bytes-Written) bzw. die DWPD (Drive-Writes-Per-Day) beide Werte geben im Prinzip an wieviel Daten auf die SSD geschrieben werden können bis die SSD ausfällt. Ihr müsst also ungefähr abschätzen wie hoch die Arbeitslast der SDD sein wird und entsprechend dimensionieren - sonst droht der Ausfall der SSD.

Abschließend noch die Feststellung, bitte keine Echtzeit-Messdaten in einem SQL Server verwalten, das macht einfach keinen Sinn weil ein SQL Server für Transaktionen und Zuverlässigkeit konzipiert wurde und nicht für Hochgeschwindigkeits-Datenverarbeitung. Genau deshalb gibt es ja NoSQL Datenbanken die dann auf eine oder mehrere der ACID Eigenschaften verzichten. In der Praxis werden dann derart große Datenmengen (Multi-Million Zeilen pro Tabelle) von der NoSQL (z.B. mehrere DBF Tabellen) Datenbank in einen Cube (OLAP Würfel) geladen denn dort können die Daten beliebig und effizient Analysiert werden. Dieser Ladeprozess hat aber nichts mehr mit einem Upsize zu tun. Auch der Cube muss erst einmal Entworfen werden.

Soweit so gut, nachfolgend die Quellenverweise, das wichtigste ist und bleibt aber die korrekte Konfiguration des Servers daran führt kein Weg vorbei, gerade die Race-Conditions wie bei dir Carlo sind ein klassisches Anzeichen für eine nicht durchgeführte Konfiguration.

Steffen F. Pirsig
Alaska Software Inc.


Quellen:
1) https://www.amazon.de/PostgreSQL-10-Pra ... way&sr=8-1
2) https://www.amazon.de/PostgreSQL-Admini ... way&sr=8-4
3) https://www.postgresql.org/docs/11/non-durability.html
4) https://en.wikipedia.org/wiki/ACID
5) https://de.wikipedia.org/wiki/OLAP-W%C3%BCrfel
6) https://en.wikipedia.org/wiki/NoSQL

P.S.:
Die dd202001.dbf (229545 Records, 188MB dbf table size) mit NTX benötigt circa 5 Minuten für einen Upsize auf einen remote Zielsystem (Hyper-V Guest) das 2 virtuelle Prozessoren und 3GB RAM unter W7 32Bit mit PG94 korrekt konfiguriert hat. Das System hatte allerdings eine 10K RPM SAS Platte. Ein normales SATA System sollte also maximal 10 - 15 Minuten brauchen.
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Upsize und ISAM-Emulation

Beitrag von AUGE_OHR »

hi Steffen,

Danke für deinen Ausführlichen Bericht wie man eine PG Server konfiguieren sollte.
steffen.pirsig hat geschrieben: Di, 23. Jul 2019 10:47 Voreingestellt versucht der DbfUpsize mit 4 Threads die PostgreSQL zu sättigen
hab ich was verpasst das Upsize mit mehreren CPU funktioniert :?:
steffen.pirsig hat geschrieben: >Die dd202001.dbf (229545 Records, 188MB dbf table size) mit NTX benötigt circa 5 Minuten für einen Upsize auf einen remote Zielsystem (Hyper-V Guest) das 2 virtuelle Prozessoren und 3GB RAM unter W7 32Bit mit PG94 korrekt konfiguriert hat. Das System hatte allerdings eine 10K RPM SAS Platte. Ein normales SATA System sollte also maximal 10 - 15 Minuten brauchen.
tja ... und da sind wir wieder beim Thema Minuten vs. Sekunden

---

das Xbase++ gegenüber anderen Sprachen langsam ist kann man auch mit viel Technik nicht ausgleichen.
spätestens wenn eine "andere" App auf den (selben) PG-Server zugreift fängt der Kunde an Fragen zu stellen. :^o

wieso nur auf 1 x CPU :?:
wieso kann man nicht auf Daten > 4 GB zugreifen ... 32 Bit :?:
wieso dauert der Bildschirm Aufbau einer (gleichen) Maske so viel länger :?:
wieso nur RGB :?:
wieso kein DropDrop nach ... :?:

all diese Fragen haben NICHTS mit dem PG-Server zu tun den der Kunde hat. [-X
der Auftrag lautet lediglich eine Client App zu liefern wobei dem Kunden EGAL ist welche "Sprache" genutzt wird.
gruss by OHR
Jimmy
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15688
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: Upsize und ISAM-Emulation

Beitrag von brandelh »

AUGE_OHR hat geschrieben: Mi, 24. Jul 2019 5:27
steffen.pirsig hat geschrieben: Di, 23. Jul 2019 10:47 Voreingestellt versucht der DbfUpsize mit 4 Threads die PostgreSQL zu sättigen
hab ich was verpasst das Upsize mit mehreren CPU funktioniert :?:
Jimmy, dass DU Threads und CPUs verwechselst, kann ich kaum glauben ;-)
Gruß
Hubert
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Re: Upsize und ISAM-Emulation

Beitrag von ramses »

Hallo Steffen

ich möchte doch kurz auf deine Antwort zurückkommen. Danke für die umfassende Stellungnahme.

Niemand verlangt von Alaska eine Dokumentation für Postgres zu erstellen. Um Himmels Willen NEIN.
Wo würde das enden.... Die von Postgres verfügbare Postgres Doku ist wirklich ausgezeichnet!

Das was besser sein sollte wäre die Dokumentation der Alaska PGDBE und deren Möglichkeiten.

Die von dir erwähnte Datei dd202001.dbf hätte wenn es meine wäre 535'680 Datensätze in 440 MBytes.
229'000 Records oder so ist das was im ISAM-EMU Modus noch mit "relativ" guter Performance weggeschrieben wird
danach wirds stockig.

Es kann durchaus Sinn machen sog. Echtzeit-Messdaten mit einem SQL Server zu verarbeiten. Besonders dann wenn diese Mess und
Produktionsdaten der Qualitätssicherung und dem Nachweis eines korrekten Umwelt- und Qualitäts bezogenen Herstellungsprozess dienen und für eine gewisse Frist (Garantiezeit und amtliche Kontrollen) aufbewahrt werden müssen. Das bedeutet auch dass Produkte für die keine, lückenhafte oder nur fehlerhafte Herstelldaten vorhanden sind vernichtet werden müssen. Die Aufbewahrung dieser Daten bedingt absolute Zuverlässigkeit mit der höchsten Priorität. Zudem ist das wegschreiben eines Datensatz alle 5 Sekunden höchstens Echtzeitmessung am "untersten Ende der Skala"

Mit NoSQL Datenbanken haben wir bis jetzt gearbeitet. Diese als Monatsdateien vorgehaltenen Dateien sind
aus verschiedenen Gründen nicht mehr erwünscht.

Meine Tests des PG-ISAM-EMU habe ich wie beschrieben gegen einen Server mit angepassten Speichereinstellungen gefahren.
Die Hardware war ein HP-ML350G9 mit 2 CPU's mit je 10 Kernen und 192 GB RAM einem 16 Port P840 4GB FBWC Smart-Array Controller und 16 SAS 15k Drives. SSD Laufwerke sind zur Zeit keine im Einsatz. Die Ausfallraten waren viel zu hoch.
Als Betriebsystem ist Freebsd 12.0 mit Postgres 11.4 in Verwendung.
Mit einem WindowsServer 2012 kam es immer zu schlechteren Peformance-Werten.

Schon damals vor vielen vielen Jahren als Alaska erst Ankündigungen zu Postgres machte haben wir aus der Not heraus begonnen eigene Tools
zur Nutzung von Postgres zu erstellen. In den letzten Jahre haben wir sehr viel Zeit in die Entwicklung dieser eigenen Tools (xbase Klassen) gesteckt.
Inzwischen arbeiten die auch in einigen Programmen perfekt und rasend schnell. Auch mit Datenbeständen von über 400 Mio Datensätzen in einer Tabelle hatten wir noch nie irgendwelche Performance-Probleme. Performance Problem kammen erst mit der PG-DBE auf.
So schlecht kann also unsere Hardware und PG-Konfiguration auch nicht sein.


Inzwischen hat mein Arbeitgeber jedoch das Performance Problem auf seine Art endgültig und abschliessend gelöst.

Das Arbeiten bezw. Verwenden der PG-DBE oder der ISAM-EMU ist mir nun ausdrücklich untersagt.

Dazu beigetragen hat auch dass es die EDV Abteilung nicht zulässt dass Xbase in der Systemdatenbank "Postgres" Tabellen "alaska....." anlegt so wie es das Upsize.Tool macht und natürlich der Umstand dass die Programme so oder so auch für die PG-ISAM-EMU überarbeitet werden müssen. Dass dann die Wahl auf schnelles, bestehendes und bewährtes fällt dürfte wohl auch klar sein.

Ich habe nun die strikte Weisung ausschiesslich mit unseren eigenen selbst erstellten und bewährten Tools weiterzuarbeiten und sämtliche Experimente (was die Arbeit für meinen Arbeitgeber betriffft) mit neuen "Dingen" zu unterlassen.

Das Upsize aller 60 Monatsdateien "Messdaten" mit ca. 31 Mio Datensätzen hat ein Programm mit den erwähnten Tools in knapp 3 Stunden erledigt.
Der Flaschenhals dabei war aber vermutlich der ADS-Server der die Live-Daten alle lesen musste.

Seit 00:00 läuft nun parallell auch das Schreiben der Daten in eine SQL-Tabelle bis jetzt problemlos.

Es muss bei der PG-ISAM-EMU wohl doch noch etwas enthalten sein was extrem sinnlos Rechenleistung frisst.....
Valar Morghulis

Gruss Carlo
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Upsize und ISAM-Emulation

Beitrag von AUGE_OHR »

brandelh hat geschrieben: Mi, 24. Jul 2019 6:35
AUGE_OHR hat geschrieben: Mi, 24. Jul 2019 5:27
steffen.pirsig hat geschrieben: Di, 23. Jul 2019 10:47 Voreingestellt versucht der DbfUpsize mit 4 Threads die PostgreSQL zu sättigen
hab ich was verpasst das Upsize mit mehreren CPU funktioniert :?:
Jimmy, dass DU Threads und CPUs verwechselst, kann ich kaum glauben ;-)
bei einer Single-CPU App bringen Thread KEINEN Geschwindigkeitsvorteil [-X
gruss by OHR
Jimmy
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: Upsize und ISAM-Emulation

Beitrag von Tom »

Jim, Du redest wirr.
Herzlich,
Tom
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: Upsize und ISAM-Emulation

Beitrag von AUGE_OHR »

hi Tom,
Tom hat geschrieben: Mi, 24. Jul 2019 18:49Jim, Du redest wirr.
klar ... macht wohl die Hitze das DU nur wirres Zeug verstehst... :lol:

eine Xbase++ läuft nur auf 1 x CPU und Thread bringen NICHTS an "zusätzlicher" Geschwindigkeit da nicht mehr als 100% CPU geht.

mit 4 x Thread einen PostgreSQL Server zu "füllen" ist ein Witz :badgrin: ... das schafft sogar ein Raspberry :!:
https://opensource.com/article/17/10/se ... spberry-pi
https://timo2o1o.wordpress.com/2016/04/ ... pberry-pi/

---

Steffen will nur "ablenken" wenn er es auf den PG Server schiebt.
wie langsam Xbase++ ist "merkt" man eben erst wenn man einen Vergleich mit einer "anderen" Sprache macht.

also Tom : wenn du zu dem Thema was zu sagen hast ... oder traust du dich nicht gegenüber Steffen :roll:
gruss by OHR
Jimmy
Benutzeravatar
Werner_Bayern
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2120
Registriert: Sa, 30. Jan 2010 22:58
Wohnort: Niederbayern
Hat sich bedankt: 29 Mal
Danksagung erhalten: 70 Mal

Re: Upsize und ISAM-Emulation

Beitrag von Werner_Bayern »

Servus Alaska-Team,

mit dem aktuellen Update 1127 habt Ihr gute und schnelle Arbeit geliefert. Erste Tests zeigen, dass im ISAM-SQL-Mode jetzt vieles korrekt funktioniert! =D>

Selbst ein dbRlock() unter PG Version 11 funktioniert jetzt, vorausgesetzt, man führt das upsize neu durch. Ansonsten bleibts beim Fehler, dass der Satz nicht gesperrt wird.

Auch funktioniert jetzt erstmalig ein XbpQuickbrowse(), damit können wir unsere Tests endlich fortsetzen. Bin schon gespannt!
es grüßt

Werner

<when the music is over, turn off the lights!>
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: Upsize und ISAM-Emulation

Beitrag von Tom »

Jim -
eine Xbase++ läuft nur auf 1 x CPU und Thread bringen NICHTS an "zusätzlicher" Geschwindigkeit da nicht mehr als 100% CPU geht.
Vorher hast Du noch Threads und Kerne verwechselt.
Und auch das (Zitierte) ist Bullshit. Wenn man Aufgaben auf Threads aufteilt, dann verhindert man, dass Wartezustände, in die eine Teilaufgabe gerät, die gesamte Aufgabe behindern. Zu einer hundertprozentigen CPU-Auslastung kommt man sowieso nur vergleichsweise selten - und nur bei Aufgaben, die fast ausschließlich auf Kosten der CPU zu bewältigen sind. Die ist aber nicht das einzige prozessrelevante Element eines Rechners.

Haben wir hier nicht irgendwo das Smiley mit dem berühmten Dieter-Nuhr-Zitat? Schade.
oder traust du dich nicht gegenüber Steffen
Genau. Wo ich doch als so feige und unterwürfig bekannt bin. 8)
Herzlich,
Tom
Benutzeravatar
Martin Altmann
Foren-Administrator
Foren-Administrator
Beiträge: 16502
Registriert: Fr, 23. Sep 2005 4:58
Wohnort: Berlin
Hat sich bedankt: 111 Mal
Danksagung erhalten: 48 Mal
Kontaktdaten:

Re: Upsize und ISAM-Emulation

Beitrag von Martin Altmann »

Tom hat geschrieben: Mi, 31. Jul 2019 14:29Haben wir hier nicht irgendwo das Smiley mit dem berühmten Dieter-Nuhr-Zitat?
Bild
:grommit:
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/

Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: Upsize und ISAM-Emulation

Beitrag von Tom »

Genau das. Danke, Martin.
Herzlich,
Tom
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: Upsize und ISAM-Emulation

Beitrag von Jan »

Tom hat geschrieben: Mi, 31. Jul 2019 14:29Genau. Wo ich doch als so feige und unterwürfig bekannt bin. 8)
Unbedingt! Gerade Du!

Sorry, aber das mußte jetzt einfach mal raus. :angry1: :angry2: :angry3: :angry4: :angry5:

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Re: Upsize und ISAM-Emulation

Beitrag von ramses »

Werner_Bayern hat geschrieben: Mi, 31. Jul 2019 13:40 Servus Alaska-Team,
mit dem aktuellen Update 1127 habt Ihr gute und schnelle Arbeit geliefert. Erste Tests zeigen, dass im ISAM-SQL-Mode jetzt vieles korrekt funktioniert!
Ich kann mich dem nur anschliessen. Gute und schnelle Arbeit.

Mein Test mit dem Upsize-Tool benötigte nun für das Upsize der oben beschriebene Datei nicht mehr über 14 Stunden sondern schaffte dies in ca. 3 MInuten. Natürlich lief der Test mit den selben Geräten.

Der Schatten der noch über dieser guten Leistung liegt sind Steffens Bemerkungen dass das Problem überall nur nicht an der Alaska-ISAM-EMU liegt.....
Nun nach 7 Tagen sind Steffens Aussagen wiederlegt, das Problem lag beim Alaska Tool.

Dennoch gute Arbeit!
Valar Morghulis

Gruss Carlo
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: Upsize und ISAM-Emulation

Beitrag von Tom »

Äh, Jan.
Sorry, aber das mußte jetzt einfach mal raus.
Das rettet mir echt den Tag, so viele Wutsmileys von Dir. :cry:
Herzlich,
Tom
Benutzeravatar
Jan
Marvin
Marvin
Beiträge: 14641
Registriert: Fr, 23. Sep 2005 18:23
Wohnort: 49328 Melle
Hat sich bedankt: 21 Mal
Danksagung erhalten: 87 Mal
Kontaktdaten:

Re: Upsize und ISAM-Emulation

Beitrag von Jan »

Tom,

die waren ganz eindeutig NICHT an Dich gerichtet!

Jan
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: Upsize und ISAM-Emulation

Beitrag von Tom »

Aha. 8)
Herzlich,
Tom
Benutzeravatar
steffen.pirsig
Cut&Paste-Entwickler
Cut&Paste-Entwickler
Beiträge: 24
Registriert: Fr, 04. Nov 2011 12:09
Wohnort: Eschborn, Deutschland
Danksagung erhalten: 6 Mal
Kontaktdaten:

Re: Upsize und ISAM-Emulation

Beitrag von steffen.pirsig »

ramses hat geschrieben: Mi, 31. Jul 2019 15:19 Ich kann mich dem nur anschliessen. Gute und schnelle Arbeit.

Mein Test mit dem Upsize-Tool benötigte nun für das Upsize der oben beschriebene Datei nicht mehr über 14 Stunden sondern schaffte dies in ca. 3 MInuten. Natürlich lief der Test mit den selben Geräten.

Der Schatten der noch über dieser guten Leistung liegt sind Steffens Bemerkungen dass das Problem überall nur nicht an der Alaska-ISAM-EMU liegt.....
Nun nach 7 Tagen sind Steffens Aussagen wiederlegt, das Problem lag beim Alaska Tool.

Dennoch gute Arbeit!
Das ist so nicht richtig! Ich rede hier gegen Wände!

Zum allerletzen mal. Wenn du eine Performance-Degradierung beim Upsize hast, dann ist der Server falsch konfiguriert. Ende der Diskussion. Das war und ist meine Kernaussage in meinem vorherigen längeren Post in dem ich dies alles erklärt habe.

Alles andere, auch deine absoluten Messdaten sind irrelevant in dieser Betrachtung.

Das jetzt bei dir der Upsize durchläuft und oder du jetzt einen messbaren Performance Gewinn verzeichnest hängt doch nur damit zusammen das durch unsere Performance-Verbesserungen dein Server nicht mehr in eine Race-Condition rennt. Das wird er aber früher oder später je nach Last-Szenario wieder passieren können und dann sind wir wieder beim Ausgangspunkt.

Ich geb jetzt auf, an alle anderen. Bitte verwendet PGTune oder Sekundärliteratur und konfiguriert den PostgreSQL Server entsprechend.

mfg
Steffen F. Pirsig
Alaska Software Inc.
Benutzeravatar
steffen.pirsig
Cut&Paste-Entwickler
Cut&Paste-Entwickler
Beiträge: 24
Registriert: Fr, 04. Nov 2011 12:09
Wohnort: Eschborn, Deutschland
Danksagung erhalten: 6 Mal
Kontaktdaten:

Re: Upsize und ISAM-Emulation

Beitrag von steffen.pirsig »

Jimmy,
AUGE_OHR hat geschrieben: Mi, 24. Jul 2019 20:15 hi Tom,
Tom hat geschrieben: Mi, 24. Jul 2019 18:49Jim, Du redest wirr.
klar ... macht wohl die Hitze das DU nur wirres Zeug verstehst... :lol:

eine Xbase++ läuft nur auf 1 x CPU und Thread bringen NICHTS an "zusätzlicher" Geschwindigkeit da nicht mehr als 100% CPU geht.

mit 4 x Thread einen PostgreSQL Server zu "füllen" ist ein Witz :badgrin: ... das schafft sogar ein Raspberry :!:
https://opensource.com/article/17/10/se ... spberry-pi
https://timo2o1o.wordpress.com/2016/04/ ... pberry-pi/

---

Steffen will nur "ablenken" wenn er es auf den PG Server schiebt.
wie langsam Xbase++ ist "merkt" man eben erst wenn man einen Vergleich mit einer "anderen" Sprache macht.

also Tom : wenn du zu dem Thema was zu sagen hast ... oder traust du dich nicht gegenüber Steffen :roll:
Für die Akten: Ein Thread auf einer CPU skaliert unter exakt zwei Randbedingungen:
- bei der Durchführung von reinen arithmetischen Operationen
- oder wenn die Ausführung eines Threads auf eine externe Resource warten muss

Letzteres ist exakt der Fall wenn der DbfUpsizer auf das Ergebnis vom SQL Server (Client / Server Betrieb) wartet, solange kann ein anderer Thread SQL Statements erstellen und auch an den Server senden.

mfg
Steffen F. Pirsig
Alaska Software Inc.
ramses
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 2513
Registriert: Mi, 28. Jul 2010 17:16
Hat sich bedankt: 12 Mal
Danksagung erhalten: 77 Mal

Re: Upsize und ISAM-Emulation

Beitrag von ramses »

steffen.pirsig hat geschrieben: Mi, 31. Jul 2019 20:05 Das jetzt bei dir der Upsize durchläuft und oder du jetzt einen messbaren Performance Gewinn verzeichnest hängt doch nur damit zusammen das durch unsere Performance-Verbesserungen dein Server nicht mehr in eine Race-Condition rennt. Das wird er aber früher oder später je nach Last-Szenario wieder passieren können und dann sind wir wieder beim Ausgangspunkt.

Ich geb jetzt auf, an alle anderen. Bitte verwendet PGTune oder Sekundärliteratur und konfiguriert den PostgreSQL Server entsprechend.
Hallo Steffen

Ich habe immer geschrieben "modifizierte" Speicherkonfiguration 96GB Ram für Postgres sind wohl sicher genug.
Das ganze läüft aber aus Sicherheitsgründen mit dem ZFS Filesystem und verwendet "Copy on Write" und "Checksum" und "Copies" das muss auch immer berücksichtigt werden.
Valar Morghulis

Gruss Carlo
Antworten