J'écris des terrains et beaucoup de données qui ne seront plus lus pour des semaines - car mon programme exécute la quantité de mémoire libre sur la machine (affichée avec «GRATUIT» ou «TOP») très rapidement, le montant de mémoire mon application utilise n'augmente pas - la quantité de mémoire utilisée non plus par d'autres processus.
Cela me conduit à croire que la mémoire est consommée par le cache de systèmes de fichiers - car je n'ai pas l'intention de lire ces données pendant une longue période, j'espère contourner les tampons de systèmes, de sorte que mes données sont écrites directement sur le disque. . Je n'ai pas de rêves d'améliorer les perfs ou d'être un Super Ninja, mon espoir est de donner un indice au système de fichiers que je ne reviendrai pas pour cette mémoire à tout moment, alors ne passez pas de temps à optimiser pour ces cas. < / p>
sur Windows J'ai fait face à des problèmes similaires et corrigé le problème à l'aide de fichiers_flag_no_buffering | File_flag_write_through - la mémoire des machines n'a pas été consommée par mon application et la machine était plus utilisable en général. J'espère dupliquer les améliorations que j'ai vues mais sur Linux. Sous Windows, il y a la restriction d'écriture dans des pièces de la taille sectorielle, je suis content de cette restriction pour la quantité de gain que j'ai mesuré.
Y a-t-il un moyen similaire de le faire sous Linux?
3 Réponses :
L'équivalent le plus proche des drapeaux Windows que vous mentionez, je peux penser, c'est ouvrir votre fichier avec le accordé, essayant de faire des recherches sur ce drapeau pour confirmer que c'est ce que vous voulez, j'ai trouvé Cette pièce intéressante vous dit que les E / S ignorés sont une mauvaise idée, Linus la décrivant comme« endommagé cérébral ». Selon que vous devriez utiliser Ouvrir (2) drapeaux O_Direct | O_sync : MADVISE () au lieu de dire au noyau comment cacher les pages. Ymmv.
Comme mon programme exécute la quantité de mémoire libre sur les gouttes de la machine très rapidement
Pourquoi est-ce un problème? La mémoire gratuite est la mémoire que ne servit aucun but utile . Quand il est utilisé pour cacher des données, au moins, il y a une chance qu'il sera utile.
Si l'un de vos programmes demande plus de mémoire, les caches de fichiers seront la première chose à faire. Linux sait qu'il peut relire que les données du disque chaque fois qu'il le souhaite, il va donc récolter la mémoire et lui donner une nouvelle utilisation.
Il est vrai que Linux par défaut attend environ 30 secondes (c'est la valeur utilisée pour être de toute façon) avant la rinçage écrit sur le disque. Vous pouvez accélérer cela avec un appel à
FSYNC () . Mais une fois que les données ont été écrites sur le disque, il y a pratiquement zéro coût pour garder une cache des données en mémoire.Voir comme vous écrivez dans le fichier et ne le lisez pas, Linux devinera probablement que ces données sont les meilleures à jeter, de préférence à d'autres données en cache. Donc, ne perdez pas l'effort d'essayer d'optimiser à moins que vous n'ayez confirmé que c'est un problème de performance.
Ce n'est qu'un problème car l'effet est le cache est utilisé pour quelque chose qui ne sera jamais utilisé. Le cache est extrait d'autres personnes qui pourraient utiliser et je vois une augmentation d'E / S.
Vous pouvez utiliser O_Direct, mais dans ce cas, vous devez faire le bloc IO vous-même; Vous devez écrire dans des multiples de la taille du bloc FS et sur les limites des blocs (il est possible qu'il n'était pas obligatoire, mais si vous ne sachez pas que la performance ne sucer x1000 parce que chaque écriture non alignée aura besoin d'une lecture en premier).
Un autre moyen d'arrêt beaucoup moins d'empêchement de vos blocs en utilisant le cache OS sans utiliser O_Direct, est d'utiliser POSIX_FADVISE (FD, OFFSET, LEN, POSIX_FADV_DONTNEED). Sous Linux 2.6 Les noyaux qui le soutiennent, cela rejette immédiatement les blocs (propres) du cache. Bien sûr, vous devez utiliser FdataSync () ou tel comme tout d'abord, sinon les blocs peuvent toujours être sales et donc ne seront donc pas éliminés du cache.
C'est probablement une mauvaise idée de fdatasync () et de posix_fadvise (... posix_fadv_dontneed) Après chaque écriture, mais attendez-vous jusqu'à ce que vous ayez fait un montant raisonnable (50m, 100m peut-être).
donc en bref
Certains utilisateurs ont constaté que des éléments tels que des fichiers journaux à croissance rapide peuvent facilement souffler «plus utile» du cache du disque, ce qui réduit le cache frappe beaucoup sur une boîte qui doit avoir beaucoup de cache de lecture, mais aussi Écrit les journaux rapidement. C'est la principale motivation de cette fonctionnalité.
Cependant, comme toute optimisation
a) vous n'allez pas en avoir besoin si
b) ne le faites pas (encore)