L’exécution de ‘cat’ peut-elle accélérer l’access aléatoire à des fichiers sur une machine Linux?

sur un Linux box avec beaucoup de mémoire (quelques Gigs), je dois accéder au hasard à un gros fichier aussi vite que possible.

Je pensais à faire un cat myfile > /dev/null avant d’y accéder afin que mes pages de fichiers entrent en mémoire de manière séquentielle, donc plus rapide qu’avec un access aléatoire sec.

Cette approche a-t-elle un sens pour vous?

Comme les autres l’ont dit, vous devrez le comparer dans votre cas particulier.

Il est tout à fait possible que cela se traduise par une augmentation significative des performances. Sur les supports rotatifs traditionnels (c.-à-d. Un disque dur), l’access séquentiel (fichier cat> / dev / null / fadvise) est beaucoup plus rapide qu’un access aléatoire.

Tout en posix_fadvise() le contenu du fichier dans le cache du système, il est préférable d’utiliser posix_fadvise() (avec le conseil POSIX_FADV_WILLNEED ) ou l’appel (bloquant) readahead() pour que le kernel prédéfinisse les données dont vous aurez besoin.

EDIT: vous pouvez également essayer d’utiliser le conseil POSIX_FADV_RANDOM pour désactiver le readahead. Il y a un article avec une explication décente de l’utilisation ici: Conseiller le kernel Linux sur les E / S sur fichiers

Une seule façon de s’assurer que l’optimisation (éventuellement prématurée?) Est valable: la comparer.

Cela pourrait théoriquement accélérer l’access (surtout si vous accédez à presque tout depuis le fichier), mais je ne parierais pas sur une grande différence.

La seule approche vraiment utile consiste à la comparer à votre cas spécifique.

Si vous voulez vraiment la vitesse, je vous recommande d’essayer IO mappé en mémoire au lieu d’essayer de pirater quelque chose avec cat. Bien sûr, cela dépend de la taille du fichier que vous essayez d’accéder et du type d’access que vous souhaitez. Cela peut ne pas être possible …

readahead est un bon appel aussi …

Faire “chat” sur un gros fichier peut amener les données et extraire davantage de données précieuses du cache; Ce n’est pas ce que tu veux.

Si les performances sont importantes pour vous, vous effectuerez des tests de performance réguliers (et des tests de trempage, etc.), continuez ainsi et surveillez vos graphiques, vos chiffres, etc.