Je ne vois pas comment un memory mapping en 32-bits peut mapper la totalité d'un fichier qui ne tient pas dans un seul segment mémoire virtuel 32 bits.
A mon avis il faut recompiler une version 64 bits de l'application (et utiliser un OS installé en 64 bits pour le supporter). Sinon tu auras beau faire mies les pointeurs mémoire 32 bits ne pourront pas accéder à tout le fichier. Autre solution : que le logiciel ne fasse plus un mémory mapping aussi grand mais fasse des I/O classiques à la demande avec un buffer classique assez grand pour éviter de multiplier les I/O. D'autant plus que les accès à ce fichier pendant le décodage sont essentiellement séquentiels (par un parseur, même si le format du fichier PBF est binaire et contient des offsets 64 bits pour indexer ses différentes sections), et demandent assez peu d'accès aléatoires pendant le traitement. Ca complique un peu le programme qui doit gérer des caches pour les index mais ce n'est pas infaisable et cela améliorerait même les performances en évitant justement de solliciter le gestionnaire mémoire plus que nécessaire (au delà de 4 Mo environ, il n'y a plus beaucoup d'intérêt réel à utiliser le memory mapping, les I/O seront plus performantes en mettant moins de charge sur le système). On peut garer un memory mapping sur les segments importants d'index du fichier PBF si cela peut aider, mais pas pour le plus gros de ses données. 2013/3/21 Lucas Nussbaum <lucas.nussb...@loria.fr>: > On 21/03/13 at 13:55 +0100, Vincent Pottier wrote: >> Le 21/03/2013 11:57, Lucas Nussbaum a écrit : >> >Que dit: >> >strace -f /home/vincent/Documents/cartographie/sh/france.osm2sql.sh >> >? >> > >> >Lucas >> Good guess ! >> Je ne comprends pas tout mais voici un extrait vers la fin : >> >> [pid 25569] write(2, "\nReading in file: /home/vincent/"..., 58 >> Reading in file: /home/vincent/tmp/france-latest.osm.pbf >> ) = 58 >> [pid 25569] time(NULL) = 1363869357 >> [pid 25569] brk(0xa51e000) = 0xa51e000 >> [pid 25569] mmap2(NULL, 33558528, PROT_READ|PROT_WRITE, >> MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x643df000 >> [pid 25569] mmap2(NULL, 33558528, PROT_READ|PROT_WRITE, >> MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x623de000 >> *[pid 25569] open("/home/vincent/tmp/france-latest.osm.pbf", >> O_RDONLY) = -1 EOVERFLOW (Value too large for defined data type)* > > D'après open(2): > > EOVERFLOW > pathname refers to a regular file that is too large to be opened. > The usual scenario here is that an application compiled on a > 32-bit platform without -D_FILE_OFFSET_BITS=64 tried to open a > file whose size exceeds (2<<31)-1 bits; see also O_LARGEFILE > above. This is the error specified by POSIX.1-2001; in kernels > before 2.6.24, Linux gave the error EFBIG for this case. > > Donc recompiler l'appli avec -D_FILE_OFFSET_BITS=64 devrait aider. (ou > passer sur un système 64 bits) > >> J'ai mis en gras ce qui me semble être un indice de ce qui ne va pas. >> D'après ce que je viens de voir[1] mmap2 effectue une projection en >> mémoire d'un fichier. Peut-être que ma machine manque de mémoire >> pour traiter ce fichier de 2.4 Go (3.4 Go de RAM). > > non, au pire ça swappera. > -- > | Lucas Nussbaum Assistant professor @ Univ. de Lorraine | > | lucas.nussb...@loria.fr LORIA / AlGorille | > | http://www.loria.fr/~lnussbau/ +33 3 54 95 86 19 | > > _______________________________________________ > dev-fr mailing list > dev-fr@openstreetmap.org > http://lists.openstreetmap.org/listinfo/dev-fr _______________________________________________ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr