ich fragte ja nach einen "UpSize" ...
klar gäbe es auch andere Wege. ich würde die DBF als CSV importieren.
Moderator: Moderatoren
ich fragte ja nach einen "UpSize" ...
Hallo WernerWerner_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).
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.
Leider nicht ganz so einfach.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?
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.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?
hab ich was verpasst das Upsize mit mehreren CPU funktioniertsteffen.pirsig hat geschrieben: ↑Di, 23. Jul 2019 10:47 Voreingestellt versucht der DbfUpsize mit 4 Threads die PostgreSQL zu sättigen
tja ... und da sind wir wieder beim Thema Minuten vs. Sekundensteffen.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.
Jimmy, dass DU Threads und CPUs verwechselst, kann ich kaum glaubenAUGE_OHR hat geschrieben: ↑Mi, 24. Jul 2019 5:27hab ich was verpasst das Upsize mit mehreren CPU funktioniertsteffen.pirsig hat geschrieben: ↑Di, 23. Jul 2019 10:47 Voreingestellt versucht der DbfUpsize mit 4 Threads die PostgreSQL zu sättigen
bei einer Single-CPU App bringen Thread KEINEN Geschwindigkeitsvorteilbrandelh hat geschrieben: ↑Mi, 24. Jul 2019 6:35Jimmy, dass DU Threads und CPUs verwechselst, kann ich kaum glaubenAUGE_OHR hat geschrieben: ↑Mi, 24. Jul 2019 5:27hab ich was verpasst das Upsize mit mehreren CPU funktioniertsteffen.pirsig hat geschrieben: ↑Di, 23. Jul 2019 10:47 Voreingestellt versucht der DbfUpsize mit 4 Threads die PostgreSQL zu sättigen
klar ... macht wohl die Hitze das DU nur wirres Zeug verstehst...
Vorher hast Du noch Threads und Kerne verwechselt.eine Xbase++ läuft nur auf 1 x CPU und Thread bringen NICHTS an "zusätzlicher" Geschwindigkeit da nicht mehr als 100% CPU geht.
Genau. Wo ich doch als so feige und unterwürfig bekannt bin.oder traust du dich nicht gegenüber Steffen
Unbedingt! Gerade Du!
Ich kann mich dem nur anschliessen. Gute und schnelle Arbeit.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!
Das rettet mir echt den Tag, so viele Wutsmileys von Dir.Sorry, aber das mußte jetzt einfach mal raus.
Das ist so nicht richtig! Ich rede hier gegen Wände!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!
Für die Akten: Ein Thread auf einer CPU skaliert unter exakt zwei Randbedingungen:AUGE_OHR hat geschrieben: ↑Mi, 24. Jul 2019 20:15 hi Tom,klar ... macht wohl die Hitze das DU nur wirres Zeug verstehst...
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 ... 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
Hallo Steffensteffen.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.