Contexte:
J’ai une application Java qui effectue des E / S intensives sur des fichiers mappés en mémoire assez volumineux (> 500 Mo). Le programme lit les données, écrit des données et parfois les deux.
Toutes les fonctions de lecture / écriture ont une complexité de calcul similaire.
J’ai comparé la couche IO du programme et j’ai remarqué d’étranges caractéristiques de performance des fichiers mappés en mémoire:
- Apache Commons Exec – parfois un thread ne peut pas ouvrir un fichier local sous Linux
- Pourquoi ScheduledExecutorService.shutdown () utilise-t-il 100% de mon processeur?
- Pourquoi la commande alternatives est-elle utilisée lors de l’installation de Java sur une machine Linux
- Linux: Comment tuer les programmes utilisant le port 1935?
- Pourquoi la JVM consum-t-elle moins de mémoire que -Xms spécifié?
- Il effectue 90 000 lectures par seconde (lire 1 Ko à chaque itération au hasard)
- Il effectue 38 000 écritures par seconde (écrivez 1 Ko chaque itération séquentiellement)
- Il effectue 43k écritures par seconde (écrire 4 octets à chaque itération au hasard)
- Il effectue seulement 9k opérations combinées en lecture / écriture par seconde (lire 12 octets puis écrire 1 Ko à chaque itération, au hasard)
Les programmes sur JDK 1.7, Linux 3.4 64 bits.
La machine est un PC Intel ordinaire avec 8 threads CPU et 4 Go de mémoire physique. Seulement 1 Go a été affecté au segment de mémoire JVM lors de la réalisation du test.
Si plus de détails sont nécessaires, voici le code de référence: https://github.com/HouzuoGuo/Aurinko2/blob/master/src/test/scala/storage/Benchmark.scala
Et voici l’implémentation des fonctions de lecture, écriture, lecture / écriture ci-dessus: https://github.com/HouzuoGuo/Aurinko2/blob/master/src/main/scala/aurinko2/storage/Collection.scala
Donc mes questions sont:
Je vous remercie.
Les performances du fichier mappé en mémoire dépendent des performances du disque, du type de système de fichiers, de la mémoire disponible pour le cache du système de fichiers et de la taille des blocs de lecture / écriture. La taille de la page sur Linux est 4K. Donc, vous devriez vous attendre à la plupart des performances avec lecture / écriture 4k. Un access à une position aléatoire provoque un défaut de page si la page n’est pas mappée et va extraire une nouvelle page. Généralement, vous voulez un fichier mappé en mémoire si vous voulez voir les fichiers en tant que tableau de mémoire unique (ou ByteBuffer en Java).