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 (231)-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
