Je développe une application qui rassemble une liste avec tous les fichiers du disque dur Et aussi ensuite, il écrit des fichiers sur le disque dur.
Je veux demander: quel est le nombre optimal de threads simultanés qui feront cette tâche?
Je veux dire combien de threads devrais-je avoir qui lire le disque dur sans faire le disque dur Pour être lent car tant de threads le lisent simultanément.
Merci!
7 Réponses :
Au début, je dis un!
Cela dépend effectivement si les données à lire nécessitent des calculs complexes pour être élaborés. Dans ce cas, il pourrait être pratique d'instancier plus d'un thread pour élaborer différentes données de disque; Mais cela ne convient que si vous avez une CPU multiple sur le même système.
Sinon, plusieurs threads rendent le disque dur plus stressé que nécessaire: les lectures simultanentes de différents threads émettront des opérations rechercher pour la lecture des blocs de fichiers (*), introduisant une générale qui pourrait ralentir le système, en fonction du nombre de fichiers lecture et de la taille des fichiers.
lire les fichiers séquentiellement.
(*) Le système d'exploitation essaie vraiment de stocker les mêmes blocs de fichiers de manière séquentielle afin d'accélérer les opérations de lecture. La fragmentation des disques se produit, de manière non séquentielle, des fragments non séquentiels nécessitent une opération de recherche qui nécessitait vraiment plus de temps respecter l'opération de lecture au même endroit. Essayez de lire plusieurs fichiers en parallèle, provoquera un tas de recherches, car les blocs de fichiers simples sont contigus, tandis que plusieurs blocs de fichiers ne pouvaient pas être contigus.
wow merci à vous tous pour vos réponses. C'est ma première question sur Stackoverflow et je suis impressionné.
Bien que la plupart des réponses disent une opération par disque, je souhaite ajouter qu'avec le courant SSD SSD , vous pouvez utiliser plus d'une opération en même temps sans avoir un impact sur les performances de la lecture / écriture IO.
Je dirais qu'un seul fil est suffisant. La CPU pourrait peut-être exécuter de nombreux filets, mais la vitesse du disque dur est de nombreuses ordres de grandeur sous la CPU. Même si vous courez plus de threads ont fait les demandes d'E / S plus rapidement (dont je ne suis pas certain), cela ne ferait que le disque dur réellement lire plus vite. Cela pourrait probablement même le ralentir.
S'il arrive un seul disque dur, vous souhaitez minimiser les temps de recherche. Alors utilisez un seul fil pour lire et écrire sur le disque.
Un fil. Si vous lisez et que vous écrivez en même temps et que votre destination est un disque différent de votre source, puis de 2 threads. Je vais ajouter que si vous faites d'autres opérations aux fichiers (par exemple, la décompression), la partie décompressez peut être effectuée sur un troisième thread.
Pour faire quelques exemples (j'ignore les jonctions, reparé des points ...)
Je travaille sur la présomption selon laquelle un disque peut effectuer une opération à la fois, et chaque fois qu'il "multitâches" bascule entre différentes lectures / écrites, il perd la vitesse. Les disques mécaniques ont ce problème (mais techniquement, la NCQ pourrait aider). Disques d'état solides Je ne sais pas (mais je sais que les bâtons USB sont très lents si vous essayez de faire 2 opérations à la fois)
J'ai cherché comment vous le faites ... Je n'ai trouvé aucun exemple "spécifique", mais j'ai des liens vers Windows API où vous pourrez commencer:
Affichage des chemins de volume: http://msdn.microsoft.com/en-us /Library/cc542456%28Vs.85%29.aspx
getvolumepathName: http: // msdn.microsoft.com/en-us/library/aa364996(v=vs.85).aspx
getvolumeinformationbyhandlew http: // msdn .microsoft.com / fr-US / US / Bibliothèque / AA964920 (V = VS.85) .aspx
Est-ce que cet extrapolate? Si je lisez 10 fichiers et écrivez 10 fichiers en même temps, quel devrait être le nombre de threads?
@Sanjeevakumar Disons que vous copiez du C: à C: (sans envisager de jonctions ...), 1 Total de fil. Vous copiez de C: à D:, mais sur le même disque (2 partitions), 1 fil. Vous copiez du C: à D :, Deux disques physiques: 2 threads.
@xanatos j'ai lu cette réponse Stackoverflow.com/questions/38973929/... et il dit que si je lisais à partir d'un tampon Mémoire principale et écrire sur le disque (voir la question pour plus de détails) Je peux faire les écritures en parallèle, alors je reçois de meilleures performances si j'utilise Multhreading (plus que 2 threads sur 4 noyau). Mais si j'ai bien compris, vous dites le contraire. Je suis sur Windows, pouvez-vous recommander une source qui explique comment écrit sur le disque. Est-ce que l'OS n'utilise-t-il vraiment qu'un seul fil pour écrire sur le disque: o? Merci
@Lads La réponse que vous avez citée concernait une question très basique C ++. Dans l'un des commentaires qu'il a écrites aussi, les disques distraires de la filature sont plus rares de la journée, un SSD n'a pas les problèmes de positionnement c'est exactement l'exception que j'ai donné il y a 5 ans: des disques d'état solides je ne sais pas
Que dois-je faire si j'ai quelques threads au sein de l'OI Opérations? Produisez les opérations simultanément et exécutez-les un seul fileté. Nous avons un conteneur, comme un Concurrentqueue
Vous devriez ajouter sauf dans les SSD;)
@hdkrus Oui SSD est différent. Mais un appareil ne devrait pas dépendre de l'endroit où il est déployé. Donc, le modèle de producteur-consommateur est recommandé.
Beaucoup de réponses font référence à la quantité de disque dur. N'oubliez pas que cela dépend également du nombre de contrôleurs. Parfois, deux disques durs sont gérés par un seul contrôleur. En outre: deux partitions sur le même disque dur ne sont pas deux disques disques!
Comme la balise "C #" implique, je suppose que vous écrivez une application gérée pour effectuer des E / S du disque.
Dans ce cas, je suppose que le nombre de threads géré au niveau de l'utilisateur ne sont pas pertinents car ils ne sont pas ceux qui effectuent réellement un disque d'E / S.
Autant que je sache, les demandes d'E / S du disque à partir des threads géré au niveau de l'utilisateur seront en file d'attente dans la file d'attente APC au niveau du noyau et les threads d'E / S Windows les traiteront.
Donc, je dirais que la fréquence des demandes d'E / S du disque d'être en file d'attente dans la file d'attente APC sera plus pertinente pour votre question.
Je n'ai vu aucun API de filetage .NET qui permet de lier les tâches utilisateur aux fils d'E / S Windows. Toutefois, veuillez noter que ma réponse est basée sur une vieille information relative dans le lien suivant threads d'E / S Windows / threads d'E / S gérés .
Si quelqu'un connaît mieux sur le modèle actuel de la piscine Thread Windows 7 différente des informations du lien, veuillez partager les informations pour m'éduquer également.
En outre, vous pouvez trouver le lien suivant utile pour comprendre les opérations d'E / S de fichier Windows: E / S synchrone et asynchrone
Toute raison spécifique que ce processus doit être multiplié?
serverfault.com/questions/826163/...