LUG-TReffen Mittwoch
Hallo Pinguin-Freunde, wir haben ein kleines Problem: Morgen ist Nachtwanderung und mit Band abbauen und Klub aufräumen werden wir es wohl nicht bis Mittwoch abend geschafft haben. Jetzt meine Frage: wäre es für euch möglich das Treffen kurzfristig zu verschieben. vieleicht um eine Woche? Sorry das ich mich erst so spät melde aber ich gebe zu ich hatte es vergessen... Falls das nicht funktioniert dann sagt bitte schnellst möglich bescheid, dann bekommen wir das schon irgendwie hin, wird nur stressig. Gebt mir bitte auf jeden Fall eine Antwort. Teuflische Grüße! Tobi Kellerklub GAG 18 e.V. Telefon 471 90 85 Telefax 472 43 63 http://www.gag18.de___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: PostgreSQL
Zitat von Marcus Obst : On 09.05.2011 12:22, andr...@a-kretschmer.de wrote: Aua. Diese Config ist so spartanisch, daß man dann mit Deinen Anforderungen nicht zurecht kommen KANN. IIRC ist z.B. als Default shared_buffers auf 24 MB gesetzt, das ist arg wenig. Je nach Hardware des Servers und anderen Bedingungen (dedizierter Server?) ist da einiges anzupassen. Hab ich geändert, hat etwas gebracht (schafft jetzt 10 MB/s). Aber ist jetzt auch nicht so der Knaller. Wieviel Zeilen hat die Tabelle insgesamt? Möglicherweise fehlt ein Index, aber dazu müßte wissen, wieviel Zeilen in der Tabelle sind. Im Moment ca. 300.000 (frisch eingefügt). Die will ich unmittelbar danach mittels DELETE FROM measurements; alle einfach wieder löschen -> dauert Wenn Du ALLES aus einer Tabelle löschen willst: TRUNCATE - shared_buffers auf etwa 25% des vorhandenen RAM (bei dediziertem Server) - effective_cache_size korrekt setzen - work_mem von aktuell 1MB auf vielleicht erst mal 4, aber das hängt von vielen Dingen ab - wal_buffers erhöhen - checkpoint_segments (aktuell IIRC 3 auf vielleicht 30) Danke. Größter Kritikpunkt ist eigentlich nach wie vor, dass es hier nicht möglich ist die 20GB zw. 300.000 INSERT Statements in einen Transaktionsblock zu stecken ohne das ich eine Out-Of-Memory Exception bekomme. Mir ist nicht ganz klar, wo die her kommt. Stand diese Meldung im Log von PG An und für sich kann PG sowas. Ach ja: wenn Du kannst, verwende COPY anstelle INSERT, wenn es Bulk-Inserts sind. Ist um Größenordnungen schneller. Ich kann Dir auch das Hosting hier bei uns anbieten ;-) Hm, mittelfristig soll der Datenbankserver im Messauto mitfahren, ich denke das wird schwierig :) Das ist kein Ausschluß ;-) Einner unserer Kunden hat z.B. $GANZ_VIELE GPS-Boxen im Einsatz, die ständig ihre Position melden. Da geht schon ganz schön die Post ab ... ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: PostgreSQL
On 09.05.2011 12:22, andr...@a-kretschmer.de wrote: > Aua. Diese Config ist so spartanisch, daß man dann mit Deinen > Anforderungen nicht zurecht kommen KANN. > > IIRC ist z.B. als Default shared_buffers auf 24 MB gesetzt, das ist arg > wenig. Je nach Hardware des Servers > und anderen Bedingungen (dedizierter Server?) ist da einiges anzupassen. Hab ich geändert, hat etwas gebracht (schafft jetzt 10 MB/s). Aber ist jetzt auch nicht so der Knaller. > Wieviel Zeilen hat die Tabelle insgesamt? Möglicherweise fehlt ein > Index, aber dazu müßte wissen, > wieviel Zeilen in der Tabelle sind. Im Moment ca. 300.000 (frisch eingefügt). Die will ich unmittelbar danach mittels DELETE FROM measurements; alle einfach wieder löschen -> dauert > - shared_buffers auf etwa 25% des vorhandenen RAM (bei dediziertem Server) > - effective_cache_size korrekt setzen > - work_mem von aktuell 1MB auf vielleicht erst mal 4, aber das hängt von > vielen Dingen ab > - wal_buffers erhöhen > - checkpoint_segments (aktuell IIRC 3 auf vielleicht 30) Danke. Größter Kritikpunkt ist eigentlich nach wie vor, dass es hier nicht möglich ist die 20GB zw. 300.000 INSERT Statements in einen Transaktionsblock zu stecken ohne das ich eine Out-Of-Memory Exception bekomme. > Ich kann Dir auch das Hosting hier bei uns anbieten ;-) Hm, mittelfristig soll der Datenbankserver im Messauto mitfahren, ich denke das wird schwierig :) Danke. Marcus ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: segfault bei malloc() [Solved]
2011-05-09 13:45, Konrad Rosenbaum skrev: On Monday 09 May 2011 12:05:29 Fabian Hänsel wrote: Ah, das erklärt auch, warum das Problem sogar dann auftrat, wenn ich statt srcsrc = malloc(..) nur malloc() verwendet habe (und also gar keine meiner Daten auf dem Stack landen). Danke euch beiden& Viele Grüße Fabian (der nie wieder um sich Pointer zu ersparen der Einfachheit halber den Heap zumüllen wird) Ich glaube Du hast hier gerade Stack und Heap verwechselt: Oh ja, stimmt. Danke dir! Viele Grüße Fabian ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: segfault bei malloc() [Solved]
On Monday 09 May 2011 12:05:29 Fabian Hänsel wrote:
> Ah, das erklärt auch, warum das Problem sogar dann auftrat, wenn ich statt
>srcsrc = malloc(..)
> nur
>malloc()
> verwendet habe (und also gar keine meiner Daten auf dem Stack landen).
>
> Danke euch beiden & Viele Grüße
>Fabian (der nie wieder um sich Pointer zu ersparen der Einfachheit
>halber den Heap zumüllen wird)
Ich glaube Du hast hier gerade Stack und Heap verwechselt:
Stack ist das wo lokale Variablen landen. Heap ist das wo globale Variablen
sind und wo malloc und new Daten hinlegen.
Beispiel:
int ich_bin_auf_dem_heap_und_global;
void funktion()
{
int ich_bin_auf_dem_stack;
char *ich_zeige_auf_den_heap = malloc(1024);
int *ich_zeige_auf_den_stack = &ich_bin_auf_dem_stack;
/* nicht vergessen: */
free(ich_zeige_auf_den_heap);
}
void absturz()
{
int hmm;
int ich_bin_zu_gross[11*1024*1024];
int buuh;
/*je nach Speicherlayout verursacht einer von beiden den Absturz:*/
hmm=buuh=1;/*SIGSEGV*/
}
int main()
{
int ich_bin_auch_auf_dem_stack;
funktion();
absturz();
return 0;
}
Konrad
signature.asc
Description: This is a digitally signed message part.
___
Lug-dd maillist - Lug-dd@mailman.schlittermann.de
https://ssl.schlittermann.de/mailman/listinfo/lug-dd
AW: Ext4 über Ext3 recover möglich?
Hallo, ich habe nur überflogen, kann über ext? Gerade nicht nachdenken aber zu folgender Frage antworten, weil ein Kunde das gerade wollte: > Gibt es eine Firma die ggf. ein Recover durchführen kann? Ja. Z.B.: "kroll ontrack". Ca. EUR 2.000,- für 43gb NTFS neulich. Mit freundlichen Grüßen / With kind regards Ronny Seffner -- Ronny Seffner | Alter Viehweg 1 | 01665 Triebischtal www.seffner.de | ro...@seffner.de | +49 35245 72950 > -Ursprüngliche Nachricht- > Von: lug-dd-boun...@mailman.schlittermann.de [mailto:lug-dd- > boun...@mailman.schlittermann.de] Im Auftrag von Alexander Wendland > Gesendet: Sonntag, 8. Mai 2011 20:40 > An: lug-dd@mailman.schlittermann.de > Betreff: Ext4 über Ext3 recover möglich? > > Hallo, > > ich habe hier gerade das Notebook einer Freundin da, auf dem ein neues > Ubuntu draufgespielt werden sollte. Bei der Installation wurde für die > Homepartition ext4 ausgwählt obwohl es eine ext3 war. Statt zu > konvertieren hat der Installer ohne Vorwarnung formatiert. > > Natürlich gibt es nur ein Teilweises Backup. Dort fehlen ein paar > wichtige Dateien. > > Nun habe ich schon verschiedene Werkzeuge (testdisk, photorec) probiert > und habe damit kein vernüftiges Ergebnis erreichen können. > > Ihm Rahmen der Installation wurde die ext3-Partition auch noch > vergrößert. Da waren die Daten noch da. > > Gibt es noch irgendeine Möglichkeit, die ursprüngliche > Verzeichnisstruktur samt Daten wiederherzustellen? > > Entweder auf der jetzt größeren Ex-ext3 ext4-Partition oder der > kleineren vorigen ext3-Partion. > > Die einzigen Daten die geschrieben wurden sind die ext4-Formatierung und > das lost+found dir. > > Die original-Blöcke sind schon da. > > Ich habe bereits ein Image mit dd angelegt und mit Kopien davon > Rettungsversuche unternommen. > > > Gibt es eine Firma die ggf. ein Recover durchführen kann? > > > Viele Grüße, > > Alex > > ___ > Lug-dd maillist - Lug-dd@mailman.schlittermann.de > https://ssl.schlittermann.de/mailman/listinfo/lug-dd ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: PostgreSQL
Zitat von Marcus Obst :
On 09.05.2011 09:21, andr...@a-kretschmer.de wrote:
Die Datenbank läuft auf einem Windows-Server in der 32-Bit Version.
*GNA*. Wäre ein Wechsel zu einem OS denkbar?
Erstmal nicht :)
Wie sieht die postgresql.conf aus? Habt Ihr die so belassen, oder aber
verändert?
Ist Standard, so wie sie bei Postgres 9.0 ausgeliefert wird.
Aua. Diese Config ist so spartanisch, daß man dann mit Deinen
Anforderungen nicht zurecht kommen KANN.
IIRC ist z.B. als Default shared_buffers auf 24 MB gesetzt, das ist
arg wenig. Je nach Hardware des Servers
und anderen Bedingungen (dedizierter Server?) ist da einiges anzupassen.
2) Ganz blauäugig dachte ich mir, dass man um das INSERT der 500.000
Datensätze, die ja alle logisch zu einem Messdatensatz gehören, mit
einer Transaktion klammern kann. Wenn ich das mache, bekomme ich nach
ca. 5GB importierten Daten eine Exception, die mir mitteilt, dass auf
Serverseite irgendwelcher Speicher alle wäre?
Wie lautet die Meldung *genau*? An und für sich ist Deine Idee richtig.
Aber wenn Du das in der PG-Default-Congfig machst, würde mich dies als
Resultat nicht wirklich wundern.
Ich hab hier mal rauskopiert was ich in der Exception finden konnte:
{Error: 53200: Speicher aufgebraucht}
".\src\backend\utils\mmgr\aset.c"
"Fehler bei Anfrage mit Grö�e 8388608."
Line Number: 589
ProcedureName "AllocSetAlloc"
Wenn ich weniger Daten importiere gibt es keine Exception. Dafür bekomme
ich beim finalen Commit der Transaktion ein Timeout.
3) Das löschen von Messdaten (wider 500.000 Zeilen) mit einer Query ala
DELTE FROM measurements WHERE session_id = 34
dauert ewig und kommt meist Client-seitig mit einem Timeout zurück.
Was sagt ein "EXPLAIN ANALYSE SELECT * FROM measurements WHER ID = 34;" ?
explain analyse select * from measurements where session_id = 77;
QUERY PLAN
---
Seq Scan on measurements (cost=0.00..17308.40 rows=153072 width=762)
(actual time=0.043..174.420 rows=158699 loops=1)
Filter: (session_id = 77)
Total runtime: 179.649 ms
(3 rows)
Wieviel Zeilen hat die Tabelle insgesamt? Möglicherweise fehlt ein
Index, aber dazu müßte wissen,
wieviel Zeilen in der Tabelle sind.
Ein anschließendes
delete from measurements where session_id = 77;
dauert wie schon beschrieben ewig.
Hier sind weitere Parameter zu prüfen/anzupassen. Z.B. Anzahl der WAL-Files.
Anpassen solltest Du:
- shared_buffers auf etwa 25% des vorhandenen RAM (bei dediziertem Server)
- effective_cache_size korrekt setzen
- work_mem von aktuell 1MB auf vielleicht erst mal 4, aber das hängt
von vielen Dingen ab
- wal_buffers erhöhen
- checkpoint_segments (aktuell IIRC 3 auf vielleicht 30)
Das mal als Anfang.
Ich kann Dir auch das Hosting hier bei uns anbieten ;-)
Andreas
___
Lug-dd maillist - Lug-dd@mailman.schlittermann.de
https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: segfault bei malloc() [Solved]
Hej Holger! 2011-05-09 08:02, holger.die...@arcor.de skrev: Unklar ist mir, wieso ich in dem Fall nicht bei CALL einen Heap Overflow oder ähnliches gemeldet bekomme. Weil vor dem malloc() noch keine Schreiboperationen im Speicher erfolgen. Die Definition von data[] setzt erstmal bloss den Stackpointer deutlich nach unten. Erst das Schreiben des Arguments zu malloc() oder der Ruecksprung- Adresse (je nach Call-Konvention) in den Stack zeigt das Problem. Ah, das erklärt auch, warum das Problem sogar dann auftrat, wenn ich statt srcsrc = malloc(..) nur malloc() verwendet habe (und also gar keine meiner Daten auf dem Stack landen). Danke euch beiden & Viele Grüße Fabian (der nie wieder um sich Pointer zu ersparen der Einfachheit halber den Heap zumüllen wird) ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: PostgreSQL
On 09.05.2011 09:21, andr...@a-kretschmer.de wrote:
>> Die Datenbank läuft auf einem Windows-Server in der 32-Bit Version.
>
> *GNA*. Wäre ein Wechsel zu einem OS denkbar?
Erstmal nicht :)
> Wie sieht die postgresql.conf aus? Habt Ihr die so belassen, oder aber
> verändert?
Ist Standard, so wie sie bei Postgres 9.0 ausgeliefert wird.
>> 2) Ganz blauäugig dachte ich mir, dass man um das INSERT der 500.000
>> Datensätze, die ja alle logisch zu einem Messdatensatz gehören, mit
>> einer Transaktion klammern kann. Wenn ich das mache, bekomme ich nach
>> ca. 5GB importierten Daten eine Exception, die mir mitteilt, dass auf
>> Serverseite irgendwelcher Speicher alle wäre?
>
> Wie lautet die Meldung *genau*? An und für sich ist Deine Idee richtig.
> Aber wenn Du das in der PG-Default-Congfig machst, würde mich dies als
> Resultat nicht wirklich wundern.
Ich hab hier mal rauskopiert was ich in der Exception finden konnte:
{Error: 53200: Speicher aufgebraucht}
".\src\backend\utils\mmgr\aset.c"
"Fehler bei Anfrage mit Größe 8388608."
Line Number: 589
ProcedureName "AllocSetAlloc"
>> Wenn ich weniger Daten importiere gibt es keine Exception. Dafür bekomme
>> ich beim finalen Commit der Transaktion ein Timeout.
>>
>> 3) Das löschen von Messdaten (wider 500.000 Zeilen) mit einer Query ala
>>
>> DELTE FROM measurements WHERE session_id = 34
>>
>> dauert ewig und kommt meist Client-seitig mit einem Timeout zurück.
>
>
> Was sagt ein "EXPLAIN ANALYSE SELECT * FROM measurements WHER ID = 34;" ?
explain analyse select * from measurements where session_id = 77;
QUERY PLAN
---
Seq Scan on measurements (cost=0.00..17308.40 rows=153072 width=762)
(actual time=0.043..174.420 rows=158699 loops=1)
Filter: (session_id = 77)
Total runtime: 179.649 ms
(3 rows)
Ein anschließendes
delete from measurements where session_id = 77;
dauert wie schon beschrieben ewig.
Danke.
Marcus
___
Lug-dd maillist - Lug-dd@mailman.schlittermann.de
https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: Ext4 über Ext3 recover möglich?
2011-05-08 20:39, Alexander Wendland skrev: Hallo, ich habe hier gerade das Notebook einer Freundin da, auf dem ein neues Ubuntu draufgespielt werden sollte. Bei der Installation wurde für die Homepartition ext4 ausgwählt obwohl es eine ext3 war. Statt zu konvertieren hat der Installer ohne Vorwarnung formatiert. Unbedingt den Bug in Ubuntus Launchpad melden! Nun habe ich schon verschiedene Werkzeuge (testdisk, photorec) probiert und habe damit kein vernüftiges Ergebnis erreichen können. Ich vermute, du wirst mit besagten "Hausmitteln" nicht weiterkommen. Gibt es eine Firma die ggf. ein Recover durchführen kann? Da gibt es eine handvoll Firmen, die in diesem Fall mutmaßlich sogar helfen könnten, allerdings sind die außerordentlich teuer. Kroll Ontrack[0] ist wohl Marktführer (gibt sogar eine kostenlose Nummer, um sich ein Angebot machen zu lassen). Viele Grüße Fabian [0] http://www.krollontrack.com/data-recovery/ ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: segfault bei malloc() [Solved]
On Monday 09 May 2011 08:02:40 holger.die...@arcor.de wrote:
> Fabian Hänsel :
> > Lösung gefunden: das malloc() selbst hat nur wenig mit dem segfault zu
> > tun. Ursache ist ein voller Heap.
> >
> > Ich hatte sinngemäß Folgendes:
> >void func_with_malloc(int length)
> >{
> >
> > char data[length];
> > unsigned char *srcsrc;
> >
> > srcsrc = (unsigned char*) malloc(length);
> >
> >}
> >
> > Wenn nun length zu groß wurde, fühlte sich das anschließende malloc
> > bedrängt.
> >
> > Unklar ist mir, wieso ich in dem Fall nicht bei CALL einen Heap Overflow
> > oder ähnliches gemeldet bekomme.
>
> Weil vor dem malloc() noch keine Schreiboperationen im Speicher erfolgen.
> Die Definition von data[] setzt erstmal bloss den Stackpointer deutlich
> nach unten. Erst das Schreiben des Arguments zu malloc() oder der
> Ruecksprung- Adresse (je nach Call-Konvention) in den Stack zeigt das
> Problem.
Guter Einwurf! Ich hatte die dynamische Stack-Allocation nicht gesehen.
Es ist im Allgemeinen keine gute Idee sehr grosse Datenblöcke auf dem Stack
abzulegen. Ein wenig googeln sagt uns, dass das Stack-Segment eines Thread zw.
8 und 10MB groß werden darf - normalerweise ist das jenseits alles
Notwendigen, aber Dein Code kann das locker überspringen. Bei embedded
Systemen kann die erlaubte Stackgröße sogar darunter liegen (ich habe schon
Werte von 32kB in freier Wildbahn gesehen).
Kleiner Hinweis: mit GNU LibC ist jedes Programm ein multi-thread Programm.
Spätestens, wenn Du nach einer IP-Adresse fragst macht die Libc einen Helper-
Thread auf.
Wenn Du C++ verwendest kannst Du das Problem sehr leicht umgehen, indem Du Dir
eine Array-Klasse schreibst, die die eigentlichen Daten auf den Heap legt.
(QByteArray und QString aus Qt machen das so.)
Konrad
signature.asc
Description: This is a digitally signed message part.
___
Lug-dd maillist - Lug-dd@mailman.schlittermann.de
https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: PostgreSQL
Zitat von Marcus Obst : Hallo Liste! Ich glaube mich zu erinnern, dass es hier einige gibt, die sich mit Datenbanken und im speziellen sogar mit PostgreSQL ziemlich gut auskennen. Wir verwenden hier in Chemnitz seit einiger Zeit eine Postgres-Datenbank um unsere Messdaten zu speichern. Eigentlich halte ich die Anforderungen für sehr moderat, dennoch bin ich mit der ,,Gesamtsituation'' bisher etwas unzufrieden. Ich versuch mal kurz zu skizzieren was wir machen (wollen) und wo es im Moment klemmt. Die Datenbank besteht im Prinzip aus einer Tabelle die pro Datensatz eine ID, einen Zeitstempel, einen Blob sowie noch drei String Felder enthält. Da wir die PostGIS-Erweiterung benutzten ist auch noch eine Feld mit Koordinaten vorgesehen. In dem Blob-Feld fügen wir Binärdaten der Größe 100 Byte - 300kb ein, das ist aber ständig variable. Insgesamt ist perspektivisch mit eine Datenvolumen von ca. 1 Terrabyte zu rechnen, also eigentlich nix aufregendes. Wenn ich einen Satz Messdaten importiere sind das ca. 20GB-Daten, die auf 500.000 Datensätze verteilt sind. Die Datenbank läuft auf einem Windows-Server in der 32-Bit Version. *GNA*. Wäre ein Wechsel zu einem OS denkbar? Client-seitig verwenden wir c# mit dotConnect von devart. Jetzt zu den Problemen: 1) Der Import der Daten gestaltet sich aus meiner Sicht ziemlich langsam. Der Importer schafft im Moment lediglich eine Datenrate von 8 MB/s wenn er in die Datenbank schreibt. Beschaffen könnte er die Daten theoretisch mit 50M/s. Wie sieht die postgresql.conf aus? Habt Ihr die so belassen, oder aber verändert? 2) Ganz blauäugig dachte ich mir, dass man um das INSERT der 500.000 Datensätze, die ja alle logisch zu einem Messdatensatz gehören, mit einer Transaktion klammern kann. Wenn ich das mache, bekomme ich nach ca. 5GB importierten Daten eine Exception, die mir mitteilt, dass auf Serverseite irgendwelcher Speicher alle wäre? Wie lautet die Meldung *genau*? An und für sich ist Deine Idee richtig. Aber wenn Du das in der PG-Default-Congfig machst, würde mich dies als Resultat nicht wirklich wundern. Wenn ich weniger Daten importiere gibt es keine Exception. Dafür bekomme ich beim finalen Commit der Transaktion ein Timeout. 3) Das löschen von Messdaten (wider 500.000 Zeilen) mit einer Query ala DELTE FROM measurements WHERE session_id = 34 dauert ewig und kommt meist Client-seitig mit einem Timeout zurück. Was sagt ein "EXPLAIN ANALYSE SELECT * FROM measurements WHER ID = 34;" ? Hat jemand vielleicht einen Ansatzpunkt? Jede Menge... Andreas ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Re: segfault bei malloc() [Solved]
Hallo Fabian,
Fabian Hänsel :
> Lösung gefunden: das malloc() selbst hat nur wenig mit dem segfault zu
> tun. Ursache ist ein voller Heap.
>
> Ich hatte sinngemäß Folgendes:
>
>void func_with_malloc(int length)
>{
> char data[length];
> unsigned char *srcsrc;
>
> srcsrc = (unsigned char*) malloc(length);
>}
>
> Wenn nun length zu groß wurde, fühlte sich das anschließende malloc
> bedrängt.
>
> Unklar ist mir, wieso ich in dem Fall nicht bei CALL einen Heap Overflow
> oder ähnliches gemeldet bekomme.
Weil vor dem malloc() noch keine Schreiboperationen im Speicher erfolgen.
Die Definition von data[] setzt erstmal bloss den Stackpointer deutlich nach
unten. Erst das Schreiben des Arguments zu malloc() oder der Ruecksprung-
Adresse (je nach Call-Konvention) in den Stack zeigt das Problem.
Holger
___
Lug-dd maillist - Lug-dd@mailman.schlittermann.de
https://ssl.schlittermann.de/mailman/listinfo/lug-dd
Ext4 über Ext3 recover möglich?
Hallo, ich habe hier gerade das Notebook einer Freundin da, auf dem ein neues Ubuntu draufgespielt werden sollte. Bei der Installation wurde für die Homepartition ext4 ausgwählt obwohl es eine ext3 war. Statt zu konvertieren hat der Installer ohne Vorwarnung formatiert. Natürlich gibt es nur ein Teilweises Backup. Dort fehlen ein paar wichtige Dateien. Nun habe ich schon verschiedene Werkzeuge (testdisk, photorec) probiert und habe damit kein vernüftiges Ergebnis erreichen können. Ihm Rahmen der Installation wurde die ext3-Partition auch noch vergrößert. Da waren die Daten noch da. Gibt es noch irgendeine Möglichkeit, die ursprüngliche Verzeichnisstruktur samt Daten wiederherzustellen? Entweder auf der jetzt größeren Ex-ext3 ext4-Partition oder der kleineren vorigen ext3-Partion. Die einzigen Daten die geschrieben wurden sind die ext4-Formatierung und das lost+found dir. Die original-Blöcke sind schon da. Ich habe bereits ein Image mit dd angelegt und mit Kopien davon Rettungsversuche unternommen. Gibt es eine Firma die ggf. ein Recover durchführen kann? Viele Grüße, Alex ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
PostgreSQL
Hallo Liste! Ich glaube mich zu erinnern, dass es hier einige gibt, die sich mit Datenbanken und im speziellen sogar mit PostgreSQL ziemlich gut auskennen. Wir verwenden hier in Chemnitz seit einiger Zeit eine Postgres-Datenbank um unsere Messdaten zu speichern. Eigentlich halte ich die Anforderungen für sehr moderat, dennoch bin ich mit der ,,Gesamtsituation'' bisher etwas unzufrieden. Ich versuch mal kurz zu skizzieren was wir machen (wollen) und wo es im Moment klemmt. Die Datenbank besteht im Prinzip aus einer Tabelle die pro Datensatz eine ID, einen Zeitstempel, einen Blob sowie noch drei String Felder enthält. Da wir die PostGIS-Erweiterung benutzten ist auch noch eine Feld mit Koordinaten vorgesehen. In dem Blob-Feld fügen wir Binärdaten der Größe 100 Byte - 300kb ein, das ist aber ständig variable. Insgesamt ist perspektivisch mit eine Datenvolumen von ca. 1 Terrabyte zu rechnen, also eigentlich nix aufregendes. Wenn ich einen Satz Messdaten importiere sind das ca. 20GB-Daten, die auf 500.000 Datensätze verteilt sind. Die Datenbank läuft auf einem Windows-Server in der 32-Bit Version. Client-seitig verwenden wir c# mit dotConnect von devart. Jetzt zu den Problemen: 1) Der Import der Daten gestaltet sich aus meiner Sicht ziemlich langsam. Der Importer schafft im Moment lediglich eine Datenrate von 8 MB/s wenn er in die Datenbank schreibt. Beschaffen könnte er die Daten theoretisch mit 50M/s. 2) Ganz blauäugig dachte ich mir, dass man um das INSERT der 500.000 Datensätze, die ja alle logisch zu einem Messdatensatz gehören, mit einer Transaktion klammern kann. Wenn ich das mache, bekomme ich nach ca. 5GB importierten Daten eine Exception, die mir mitteilt, dass auf Serverseite irgendwelcher Speicher alle wäre? Wenn ich weniger Daten importiere gibt es keine Exception. Dafür bekomme ich beim finalen Commit der Transaktion ein Timeout. 3) Das löschen von Messdaten (wider 500.000 Zeilen) mit einer Query ala DELTE FROM measurements WHERE session_id = 34 dauert ewig und kommt meist Client-seitig mit einem Timeout zurück. Hat jemand vielleicht einen Ansatzpunkt? Vielen Dank! Marcus ___ Lug-dd maillist - Lug-dd@mailman.schlittermann.de https://ssl.schlittermann.de/mailman/listinfo/lug-dd
