Justement, il ne faut pas tamponner dans ce cas, mais opérer directement avec les appels système open / write (puisqu'on dispose déjà d'une grande quantité de données).
L'utilisation de open(O_DIRECT) a de multiples contraintes, mais pourrait être envisageable (à voir, économise une copie mémoire...).
Pour "flusher" un fichier ouvert avec fopen(), c'est plutôt fflush() que sync. flush() envoie les données de l'espace utilisateur vers le noyau.
"sync" n'est pas flush : sync écrit les données encore en RAM sur le support physique, pour TOUS les systèmes de fichiers : c'est très lourd (il existe fsync() pour faire cela par fichier). En l'occurrence, je ne sais pas si c'est ce que cherche à faire fabricius ?
Deux threads suffisent : un premier qui fait select() ou epoll() sur les sockets + remplit la ram, et un second qui vide la ram sur le disque (modèle classique producteur / consommateur).
Sauf architecture SMP, je ne pense pas que davantage de threads permettent de gagner en performance...
[^] # Re: File mapping
Posté par Laurent Morel . En réponse au message DMA en C++ ?. Évalué à 2.
L'utilisation de open(O_DIRECT) a de multiples contraintes, mais pourrait être envisageable (à voir, économise une copie mémoire...).
Pour "flusher" un fichier ouvert avec fopen(), c'est plutôt fflush() que sync. flush() envoie les données de l'espace utilisateur vers le noyau.
"sync" n'est pas flush : sync écrit les données encore en RAM sur le support physique, pour TOUS les systèmes de fichiers : c'est très lourd (il existe fsync() pour faire cela par fichier). En l'occurrence, je ne sais pas si c'est ce que cherche à faire fabricius ?
Deux threads suffisent : un premier qui fait select() ou epoll() sur les sockets + remplit la ram, et un second qui vide la ram sur le disque (modèle classique producteur / consommateur).
Sauf architecture SMP, je ne pense pas que davantage de threads permettent de gagner en performance...