BLOBArray merging index

Hier finden YaCy User Hilfe wenn was nicht funktioniert oder anders funktioniert als man dachte. Bei offensichtlichen Fehlern diese bitte gleich in die Bugs (http://bugs.yacy.net) eintragen.
Forumsregeln
In diesem Forum geht es um Benutzungsprobleme und Anfragen für Hilfe. Wird dabei ein Bug identifiziert, wird der thread zur Bearbeitung in die Bug-Sektion verschoben. Wer hier also einen Thread eingestellt hat und ihn vermisst, wird ihn sicherlich in der Bug-Sektion wiederfinden.

BLOBArray merging index

Beitragvon Anmibe » Fr Mai 29, 2009 11:16 am

Mein Peer hat sich bei einem Neustart bzw. Update (svn 5972 auf 5974) entschlossen die die Dateien im Ordner RICELL zu bearbeiten:
I 2009/05/26 15:41:51 BLOBArray merging index.20090525152748132.blob with index.20090525174907608.blob
I 2009/05/26 15:41:53 kelondroBLOBHeapWriter wrote a dump for the 5366 index entries of index.20090526134151646.blob in 232 milliseconds.
I 2009/05/26 15:46:17 RICELL-shrink1 unmountBestMatch(2.0, 268435456)
I 2009/05/26 15:46:17 HeapReader using a dump of the index of /Applications/Kommunikation/yacy/DATA/INDEX/freeworld/TEXT/RICELL/index.20090526134151646.blob.

Dies tut er nun seit dem 26.05.2009 ununterbrochen und die Anzahl der Dateien in dem Ordner hat sich inzwischen von rd. 3.800 auf 2.500 reduziert. Rein rechnerisch benötigt er also noch weitere sechs Tage um den Berg abzuarbeiten bis er den Startvorgang zu Ende bringen kann. Ich habe bisher dem Ordner RICELL keine allzu große Beachtung geschenkt, aber ist es nortmal, daß sich dort derart viele Dateien ansammeln? Und warum fällt ihm jetzt ein die alle zu vereinigen?
Anmibe
 
Beiträge: 48
Registriert: Mo Nov 24, 2008 12:44 pm
Wohnort: Berlin

Re: BLOBArray merging index

Beitragvon Orbiter » Fr Mai 29, 2009 11:24 am

dafür gibts mehrere Gründe (das er das jetzt erst tut), einige Bugfixes, denn du solltest dort nur eine Hand voll Files haben.
Das sollte aber nicht nur im Startvorgang ablaufen, sondern einfach im Hintergrund. Das kann an jederzeit unterbrechen, killen, etc, denn der Vorgang ist transaktionssicher, d.h. es bleiben dabei weder Reste noch geht was verloren, wenn du den prozess unterbrichst.
Orbiter
 
Beiträge: 5798
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: BLOBArray merging index

Beitragvon Anmibe » Fr Mai 29, 2009 12:27 pm

Orbiter hat geschrieben:soltest dort nur eine Hand voll Files haben.

Soetwas hatte ich mir gedacht, fragt sich halt warum sich dort derart viel angesammlt hat.
Orbiter hat geschrieben:Das kann an jederzeit unterbrechen, killen, etc, denn der Vorgang ist transaktionssicher, d.h. es bleiben dabei weder Reste noch geht was verloren, wenn du den prozess unterbrichst.

Gut, transaktionsicher ist fein, aber Yacy versucht ja gerade zu starten. Selbst wenn ich Yacy abschieße, muß es beim nächsten Neustart wieder durch diese Prozedur durch und setzt seine Arbeit an der Stelle fort wo ich es abgeschossen habe (ist tatsächlich so, habe es soeben ausprobiert). Ich werde also die sechs (?) Tage warten müssen, bis mein Peer wieder im Netz wiederfindet. Für die Zukunft scheint mir hie ein überdenkenswertes Problem vorzuliegen. Denn die Frage ist letzendlich, warum sich bei derart viele Dateien angesammelt haben. Yacy hat in den Tagen vorher kräftig gecrawlt, die URL-Dateien wurden permanent aktualisiert, aber die indexdateien blieben unverändert, soweit hatte ich das beobachtet.
Anmibe
 
Beiträge: 48
Registriert: Mo Nov 24, 2008 12:44 pm
Wohnort: Berlin

Re: BLOBArray merging index

Beitragvon Orbiter » Fr Mai 29, 2009 12:43 pm

das mergen ist definitiv kein Startprozess. Es wird durch ein Index-Update nach dem Startup getriggert und läuft als Hintergrundprozess. Da files nach dem mergen gelöscht werden, musst du auch nicht durch den ganzen Prozess durch, solltest du abbrechen, stoppen, neu starten oder sollte YaCy crashen.

Bekommst du wirklich kein Online-Interface, während merges ablaufen?
Orbiter
 
Beiträge: 5798
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: BLOBArray merging index

Beitragvon dulcedo » Fr Mai 29, 2009 1:01 pm

Das kenne ich, dann reicht irgendeine Ressource nicht, er läuft aber bedient den Port nicht. Wenn sich im Log was tut möglichst aussitzen.
Dann auf jeden Fall noch den RWI-Puffer so klein wie nur möglich, 5k reichen und ihm alles an RAM zuweisen was nach dem BS übrig ist.
Und ihm gemächlich was zu tun geben, sonst merged er nicht, kann das sein Orbiter?
dulcedo
 
Beiträge: 1006
Registriert: Do Okt 16, 2008 6:36 pm
Wohnort: Bei Karlsruhe

Re: BLOBArray merging index

Beitragvon Orbiter » Fr Mai 29, 2009 1:18 pm

der merge läuft wahrscheinlich nicht, wenn der indexing-Prozess wegen short mem cycles nicht läuft. Dass aber der Server nicht hochläuft kann ich mir nicht vorstellen, denn startet gleich als erstes, bevor überhaupt die Indexierungs-Threads da sind, die ja das mergen triggern. Sonst aber so wie du es schreibst.
Orbiter
 
Beiträge: 5798
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: BLOBArray merging index

Beitragvon PCA42 » Fr Mai 29, 2009 3:17 pm

Er läuft leider nicht ohne Merge hoch, wenn viele kleine Blobs aus einem vorherigen Lauf vorhanden sind. Ich hab mir dabei nichts Gedacht. Machte für mich Sinn, den Datenbestand aufzuräumen und dann den Server zu starten.

Beispiel vom Home-Server, der auch grade viele kleine Blobs erzeugt hatte:
Code: Alles auswählen
I 2009/05/29 16:09:40 HeapReader using a dump of the index of /yaychd/yacy/DATA/INDEX/freeworld/TEXT/RICELL/index.20090527215138111.blob.
I 2009/05/29 16:09:40 HeapReader using a dump of the index of /yaychd/yacy/DATA/INDEX/freeworld/TEXT/RICELL/index.20090528235816024.blob.
I 2009/05/29 16:09:40 HeapReader using a dump of the index of /yaychd/yacy/DATA/INDEX/freeworld/TEXT/RICELL/index.20090527183810758.blob.
I 2009/05/29 16:09:40 HeapReader using a dump of the index of /yaychd/yacy/DATA/INDEX/freeworld/TEXT/RICELL/index.20090528191411499.blob.
I 2009/05/29 16:09:40 HeapReader using a dump of the index of /yaychd/yacy/DATA/INDEX/freeworld/TEXT/RICELL/index.20090528111717809.blob.
I 2009/05/29 16:09:40 HeapReader using a dump of the index of /yaychd/yacy/DATA/INDEX/freeworld/TEXT/RICELL/index.20090526235741540.blob.
I 2009/05/29 16:09:40 HeapReader using a dump of the index of /yaychd/yacy/DATA/INDEX/freeworld/TEXT/RICELL/index.20090529054805936.blob.
I 2009/05/29 16:09:41 RICELL-shrink1 unmountBestMatch(2.0, 268435456)
I 2009/05/29 16:09:41 BLOBArray merging index.20090529014157954.blob with index.20090529034603467.blob
I 2009/05/29 16:09:41 IODispatcher appended merge job of files index.20090529014157954.blob, index.20090529034603467.blob to index.20090529140941236.blob
I 2009/05/29 16:09:41 RICELL-shrink1 unmountBestMatch(2.0, 268435456)
I 2009/05/29 16:09:41 IODispatcher appended merge job of files index.20090528184232676.blob, index.20090529095151124.blob to index.20090529140941398.blob
I 2009/05/29 16:09:41 RICELL-shrink1 unmountBestMatch(2.0, 268435456)
I 2009/05/29 16:09:42 kelondroBLOBHeapWriter wrote a dump for the 19415 index entries of index.20090529140941236.blob in 81 milliseconds.
I 2009/05/29 16:09:42 HeapReader using a dump of the index of /yaychd/yacy/DATA/INDEX/freeworld/TEXT/RICELL/index.20090529140941236.blob.
I 2009/05/29 16:09:42 BLOBArray merged index.20090529014157954.blob with index.20090529034603467.blob into /yaychd/yacy/DATA/INDEX/freeworld/TEXT/RICELL/index.20090529140941236.blob
I 2009/05/29 16:09:42 BLOBArray merging index.20090528184232676.blob with index.20090529095151124.blob
I 2009/05/29 16:09:42 IODispatcher appended merge job of files index.20090527011940412.blob, index.20090529040535715.blob to index.20090529140941502.blob
I 2009/05/29 16:09:43 RICELL-shrink1 unmountBestMatch(2.0, 268435456)
I 2009/05/29 16:09:43 kelondroBLOBHeapWriter wrote a dump for the 19549 index entries of index.20090529140941398.blob in 16 milliseconds.
I 2009/05/29 16:09:43 HeapReader using a dump of the index of /yaychd/yacy/DATA/INDEX/freeworld/TEXT/RICELL/index.20090529140941398.blob.
I 2009/05/29 16:09:43 BLOBArray merged index.20090528184232676.blob with index.20090529095151124.blob into /yaychd/yacy/DATA/INDEX/freeworld/TEXT/RICELL/index.20090529140941398.blob
PCA42
 
Beiträge: 621
Registriert: Mi Jan 23, 2008 4:19 pm
Wohnort: @Home

Re: BLOBArray merging index

Beitragvon bluumi » Fr Mai 29, 2009 11:49 pm

PCA42 hat geschrieben:Er läuft leider nicht ohne Merge hoch, wenn viele kleine Blobs aus einem vorherigen Lauf vorhanden sind. Ich hab mir dabei nichts Gedacht. Machte für mich Sinn, den Datenbestand aufzuräumen und dann den Server zu starten.

Kann ich definitiv bestätigen, der Peer mit den damals über 66'000 Blobs mergte damals auch vor dem aufstarten und nicht erst wenn er oben war. Ich hatte ja auch geschrieben, dass er über 20x schneller merget wenn ich jeweils nur 700 -1500 Blobs habe, kann ich Dir, Anmibe, empfehlen mit nur der Hälfte an Blobs zu starten.
bluumi 4.Mai hat geschrieben:Da ich ja nun weiss, dass der Merge mit 1500 Files 22x schneller geht als mit 4000 Files, werde ich wohl jetzt als erstes 10'000 Blobs wegverschieben :)
bluumi
 
Beiträge: 388
Registriert: Mi Okt 08, 2008 7:27 am

Re: BLOBArray merging index

Beitragvon dulcedo » Sa Mai 30, 2009 3:56 am

Das erklärt auch meine Beobachtung dass er nur dann merged wenn er auch Arbeit hat.
dulcedo
 
Beiträge: 1006
Registriert: Do Okt 16, 2008 6:36 pm
Wohnort: Bei Karlsruhe

Re: BLOBArray merging index

Beitragvon dulcedo » Sa Mai 30, 2009 11:46 am

Unter Windows habe ich nun ein seltsames Verhalten:
Zuerst hatte ich die Standardeinstellungen für die Dateigrösse, er hat auch 2GB als Limit benutzt, jedoch wirklich alle Dateien dann auch so gross, ausser der aktuellsten. Im Unterschied zu Linux. Wörter gingen von 50mio auf 40mio zurück.
Dann habe ich max.win=max.other gesetzt mit dem Effekt dass ich von 60GB Ricell nur noch 6GB übrig hatte in 3 Dateien, eine davon 30GB. Die Wörter demenstprechend auf 5mio zurückgegangen. Das muss ein Fehler sein, so viel Müll kann sich nicht gesammelt haben, bei den Linux Peers stimmt es.
Im zweiten Versuch habe ich die Dateigrösse auf 5GB festgelegt, das merged er grade neu, momentan passt auch die Anzahl Wörter mit etwas über 30mio.
Wenn er fertig ist versuche ich es nochmal mit einem grösseren Wert kleiner max.other und schaue was dann herauskommt.
dulcedo
 
Beiträge: 1006
Registriert: Do Okt 16, 2008 6:36 pm
Wohnort: Bei Karlsruhe

Re: BLOBArray merging index

Beitragvon Anmibe » Sa Mai 30, 2009 1:37 pm

1.) Die gute Nachricht: Mein Peer hat die Blobs abgearbeitet und von urpsrünglichen 3.800 im 20 kByte-Bereich sind nur noch 5 übrig geblieben (um 200 MByte).
2.) Mit sinkender Zahl der Blobs ging das mergen deutlich schneller.
3.) Yacy ist defintiv erst nach Abschluss des Mergens hochgelaufen. Auch im Logbuch taucht bspw. die "ECOTABLE initialization of" erst nach dem mergen auf.
Anmibe
 
Beiträge: 48
Registriert: Mo Nov 24, 2008 12:44 pm
Wohnort: Berlin

Re: BLOBArray merging index

Beitragvon dulcedo » So Mai 31, 2009 1:37 am

Der Fall oben genauer überprüft, Ausganspunkt ist der Windowspeer mit 55mio URLs und 45mio Worten bei 2GB Dateigrösse, Ricell belegt 60GB.

(Tippfehler von oben korrigiert)
2GB: 55 / 40 (60GB)
5GB: 55 / 35 (55GB)
10GB: 55 / 30 (50GB)
32GB: 55/ 5 (6GB)

Was geht im letzten Fall (max.other) schief, diese geringe Anzahl Wörter kommt auch bei Wiederholung zustande.
dulcedo
 
Beiträge: 1006
Registriert: Do Okt 16, 2008 6:36 pm
Wohnort: Bei Karlsruhe

Re: BLOBArray merging index

Beitragvon dulcedo » Mo Jun 01, 2009 9:48 am

Ich habe den Versuch wiedeholt, bis ca 10GB maxfilesize.win verringert er die Anzahl der Wörter im Rahmen, also das Verhältnis ist noch sinnvoll. Erhöhe ich darüber hinaus dann werden es plötzlich sehr wenige Worte die nach dem Mergen übrigbleiben. Sie sind auch definitv weg weil dann auch die Gesamtgrösse der Dateien in RICELL drastisch abnimmt.

Was geht dann verloren, welche Worte? Ich sehe im Freeworld einige Peers mit ähnlichen SVNs die beispielsweise über 30mio URLs aber weit unter 10mio Worte haben.
Das ist jetzt das umgekehrte Extrem alledings wesentlich kritischer als die Redundanz vorher weil diese Worte jetzt verloren sind. Ich arbeite mit einem Backup das ich angelegt habe, max=2GB und erhöhe dann jeweils den Wert von max.filesize.win, immer vom selben Backup ausgehend.
Unter Linux tritt bei mir das Problem nicht auf, obwohl dort max.filsize.other auf 30GB steht.
dulcedo
 
Beiträge: 1006
Registriert: Do Okt 16, 2008 6:36 pm
Wohnort: Bei Karlsruhe

Re: BLOBArray merging index

Beitragvon bluumi » Di Jun 02, 2009 12:06 pm

dulcedo hat geschrieben:10GB: 55 / 30 (50GB)
32GB: 55/ 5 (6GB)

:) Dann bin ich da wohl auch voll reingerannt :) Meine Win Peers hab ich auf 16Gbyte FileSize gesetzt, weil es ja bei Collection auch mit 16GB klappte, und nun habe ich zwei Peers mit
40 / 3 bzw. 45 /5 und das ist dann schon um einiges weniger als zuvor. Aber was solls :lol: ... EIner WinXP, einer Win7, also nicht blos Windows XP betroffen.
Hab nun auf 8Gbyte FileSize statt 16GB gesetzt und die werden sich sicher wiedermal etwas erholen...
[edit] Lustig ist, beim Win7 Peer habe ich jetzt 110 BlobFiles, keines war grösser als 4 Gbyte, 3 stk. um 1 Gbyte und der Rest kleiner 1Gbyte. (bei 16Gbyte maxFile)[/edit]
Nach der Einstellung auf 16Gbyte weiss ich hat es min. 2 Files ~ 8 Gbyte gegeben, d.h. es hat diese dann nach und nach wieder zersplitert. :?:
[altes RiColletion belegte 62Gbyte // RiCell belegt nur noch 12gbyte :) ]
[edit] 10 Std. nach herabsetzten des MaxFileSize von 16Gb auf 8Gbyte habe ich bereits doppelte Anzahl Words :) [/edit]
bluumi
 
Beiträge: 388
Registriert: Mi Okt 08, 2008 7:27 am

Re: BLOBArray merging index

Beitragvon dulcedo » Mi Jun 03, 2009 2:57 am

Ich habe versucht es zu verstehen, bei mir eben genauso seltsames Verhalten, wo nimmt er die denn dann wieder her, bzw wo packt er sie hin? Wenn das bitte jemand mal erklären könnte dann könnte man das ganze auch besser einsetzen. Ist ja nicht gerade unwichtig.
dulcedo
 
Beiträge: 1006
Registriert: Do Okt 16, 2008 6:36 pm
Wohnort: Bei Karlsruhe

Re: BLOBArray merging index

Beitragvon Orbiter » Mi Jun 03, 2009 11:20 am

so wie das da oben aussieht scheint es ggf. doch ein Problem bei Windows und großen Dateien zu geben?

Ansonsten kann ich folgende Erklärung für stark fallende Wortzahlen bieten: Wenn ein Merge statt findet, werden die Indexdateinen vorher logisch aus dem Index entfernt, d.h. sie sind zwar als Datei dort wo sie halt sind, sind aber nicht mehr im Index registriert, und daher auch nicht zugreifbar. Das ist so, damit es keine Seiteneffekt oder Störungen beim Merge gibt, beispielsweise durch ein Delete in den zu mergenden Index zur falschen Zeit...
Daher muss die Wortzahl zur Zeit des Merge stark wegsacken, und steht dann nach dem Merge und dem Einbinden des neu entstandenen Index wieder auf einem höheren Stand. Die geringen Zahlen liessen sich also erklären, wenn die Messung genau während dem Merge statt gefunden haben.
Orbiter
 
Beiträge: 5798
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: BLOBArray merging index

Beitragvon bluumi » Mi Jun 03, 2009 12:24 pm

Orbiter hat geschrieben:so wie das da oben aussieht scheint es ggf. doch ein Problem bei Windows und großen Dateien zu geben?
wenn die Messung genau während dem Merge statt gefunden haben.


Grundsätzlich hat Win7 NTFS und kann Dateien bis mehreren Terra Filegrösse ansprechen. Ich vermute jedoch, dass die Java Lib für Windows nur Files bis zu 8?Gbyte korrekt adressiert.
Meine Messungen sind von Peers welche mehrere Tage mit dem Wert 16Gybte unter Windows liefen, und somit eigentlich nicht mehr am mergen waren.
Die Messung betreffen
ksba-yacy Aktuell: Links: 40.258.763 | Words: 7.165.261
Ksba-250 Aktuell: Links: 42.281.886 | Words: 10.791.250
Gestern 14:00, als ich den Wert von 16Gbyte auf 8 Gbyte reduziert habe, machte es innerhalb einer Stunde einen Sprung um 3.1Mio (bzw. 6Mio) Word aufwärts :)
bluumi
 
Beiträge: 388
Registriert: Mi Okt 08, 2008 7:27 am

Re: BLOBArray merging index

Beitragvon dulcedo » Do Jun 04, 2009 4:23 am

8GB könnte hinkommen, ich starte noch einen Versuch. Eventuell habe ich bei 10GB nicht lange genug gewartet und es werden noch weniger.
Eine andere Erklärung fällt mir nicht ein, das von Orbiter erklärte beschreibt es nicht weil die Zahlen konstant sind.

Was ich wirklich nicht verstehe sind die Sprünge aufwärts, wo kommen diese Worte dann her?
dulcedo
 
Beiträge: 1006
Registriert: Do Okt 16, 2008 6:36 pm
Wohnort: Bei Karlsruhe

Re: BLOBArray merging index

Beitragvon bluumi » Do Jun 04, 2009 12:01 pm

dulcedo hat geschrieben:Was ich wirklich nicht verstehe sind die Sprünge aufwärts, wo kommen diese Worte dann her?

ja. Ich dachte auch, dass der Sprung "zurück nach oben" 10 Std. benötigt hatte, weil ich erst nach 10 Std. wieder geschaut hatte.. Aber nach der Anzeige auf YacyStats ging der Sprung ja innerhalb einer Stunde, beim anderen Peer war der Sprung sogar erst 13 Mio gross, dann fiel es nochmals 3 + 4 Mio zurück.
Wie auch immer, die grösse aller Files zum Zeitpunkt "max 16gb" war enorm klein und nach dem setzten auf 8Gbyte wieder ok.
Aber die Grafische ansicht auf YacyStats zeigt sehr deutlich, dass worte verlohren gingen. Zu oberst, der YacyPeer unter Linux, die Anzahl Worte ging gesamthaft leicht nach oben. Die zwei Windows Peer sind aber beide trotz "dem Sprung" nach dem herabsetzten der Filegrösse, auf deutlich weniger Anzahl Worte. (70% / 50%)
lost.JPG
Verlauf Anzahl Worte
lost.JPG (54.17 KiB) 1056-mal betrachtet
bluumi
 
Beiträge: 388
Registriert: Mi Okt 08, 2008 7:27 am

Re: BLOBArray merging index

Beitragvon Quix0r » Do Jun 04, 2009 1:41 pm

Mal so am Rande erwähnt: Wenn eure Nodes sehr viele Blobs (also weit ueber 2000) angelegt haben, empfehle ich euch diese Varriante. Ist etwas müselig, geht aber deutlich fixer, als tagelanges Warten! Ich habe mal die 200 herausmarkiet, damit ihr ungefähr sehen könnt, wo ihr loslesen müsst.

Es ist eigentlich ein gruppenweises mergen und hat sich bis jetzt - bis auf das händische mergen halt - gut bewehrt. Und ja, ich kann mal hartnäckig sein... :D :twisted:
Quix0r
 
Beiträge: 1347
Registriert: Di Jul 31, 2007 9:22 am
Wohnort: Krefeld

Re: BLOBArray merging index

Beitragvon dulcedo » Fr Jun 05, 2009 8:32 am

Orbiter hat geschrieben:so wie das da oben aussieht scheint es ggf. doch ein Problem bei Windows und großen Dateien zu geben?

Ansonsten kann ich folgende Erklärung für stark fallende Wortzahlen bieten: Wenn ein Merge statt findet, werden die Indexdateinen vorher logisch aus dem Index entfernt, d.h. sie sind zwar als Datei dort wo sie halt sind, sind aber nicht mehr im Index registriert, und daher auch nicht zugreifbar. Das ist so, damit es keine Seiteneffekt oder Störungen beim Merge gibt, beispielsweise durch ein Delete in den zu mergenden Index zur falschen Zeit...
Daher muss die Wortzahl zur Zeit des Merge stark wegsacken, und steht dann nach dem Merge und dem Einbinden des neu entstandenen Index wieder auf einem höheren Stand. Die geringen Zahlen liessen sich also erklären, wenn die Messung genau während dem Merge statt gefunden haben.


Das habe ich nun geprüft, anhand der Grösse des RICELL-Verzeichnisses gegengeprüft. Wenn die Datenmenge und die Anzahl abnimmt sind die Worte weg, wo sollen sie sonst auch sein. Seltsam ist nun die Grenze bei der dieser Effekt auftritt, ganz genau habe ich sie noch nicht.
8GB ist es allerdings wohl nicht obwohl dann auch schon die Gesamtgrösse abnimmt, in gewissem Rahmen soll sie das ja aber, Duplikate löschen.

Ausgangspunkt wieder 0.82 (5986) mit Dateigrösse 2GB, ich spiele immer diese Version ein und erhöhe dann die Dateigrösse:
U: / W: / GB
55 / 40 / 50

Dateigrösse:
5GB: 55 / 35 / 50
8 MiaB: 55 / 39 / 48
10MiaB: 55 / 30 / 36
15MiaB: 55 / 7 / 6
20MiaB: 55 / 8 / 6
32GB: 55 / 5 / 6

Fällt jemandem eine Begrenzung ein die zwischen 10 und 15 GB wirksam wird? 12 vielleicht, ich habe über die Java-VM nichts gefunden.
Edit: nach dem Ergebnis von 8 Milliaren Bytes scheint bei 8GB die Grenze zu liegen.
Zuletzt geändert von dulcedo am Fr Jun 05, 2009 5:10 pm, insgesamt 2-mal geändert.
dulcedo
 
Beiträge: 1006
Registriert: Do Okt 16, 2008 6:36 pm
Wohnort: Bei Karlsruhe

Re: BLOBArray merging index

Beitragvon Quix0r » Fr Jun 05, 2009 9:32 am

Hier ein passender Beitrag auf heise.de für ext3/4:
http://www.heise.de/open/Das-Linux-Date ... kel/138431

Für FAT32 (noch immer viel verbreitet) steht dort leider nichts.
Quix0r
 
Beiträge: 1347
Registriert: Di Jul 31, 2007 9:22 am
Wohnort: Krefeld

Re: BLOBArray merging index

Beitragvon dulcedo » Fr Jun 05, 2009 5:14 pm

Bluumi und ich verwenden NTFS, daran kann es nicht liegen. Es muss die JVM für Windows sein, ich verwende 64-bit, aktuelle Version von Sun.
dulcedo
 
Beiträge: 1006
Registriert: Do Okt 16, 2008 6:36 pm
Wohnort: Bei Karlsruhe


Zurück zu Fragen und Antworten

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 4 Gäste

cron