questions sur les flux et la gestion de la mémoire

bonjour,

je programme en C sous LINUX

J'ai quelque questions a propos des flux et gestion de la mémoire, je vous prie de me répondre.


1 . Comment peut-t-on savoir la quantité de mémoire disponible (qu'on peut allouer)

2. Pour optimiser le transfert du fichier (sur disque) dans un buffer : on indique une taille de de buffer multiple de la taille retournée par la fonction stat(..) (à l'aide de la fonction sutbuf()).

appelons cette taille sizeB. Est ce que sizeB est l'unité de transfert entre le fichier et le buffer ?

3. Quand on effectue un balayage séqeuntiel sur un fichier,

exemple de fichier : bloc1;bloc2;bloc3...;blocn.

Si Bufsize = 2 blocs, le systeme transfert les deux premiers blocs dans le buffer. mais quand on a fini de lire les 2 blocs, on demande à lire le bloc 3 , est ce que le systeme charge le bloc 3 et 4 ou uniquement 3 (à la place de 1 par exemple)


merci

le tout est de connaitre le contexte de l application :

1) la commande free te donne l'occupation de la memoire (ps , vmstat aussi)
Depuis un programme tu ne peut pas connaitre la memoire que tu peut allouer car celle-ci est differente de celle libre (le systeme peut swapper des blocks (ou ne peut plus) pour te les allouer. Il te faut donc tester le retour des fnctions d'allocation et/ou alloué par block et tanter de réaouller plus grand .....

2) non pas forcement, la taille du transfert est induite par le hard du disque (son cache), la taille du block unitaire du filesystem et seulement ensuite la taille du buffer de lecture que tu indique.

3) depend de la reponse precedente avec toutefois le principe que tu evoques est valable aux limitation precedente.

Voila en esperant t'avoir un peut eclairé

bonjour,
merci pour les eclaircissements.
en fait, je voudrai implémenter quelques opérations de l'algebre relationnelle (selection, jointure ...).

merci encore

bonjour,


j'ai besoin de savoir la quantité de mémoire libre pour effectuer mes opérations relationnelles (ex : dans une jointure par boucles imbriquées, le nombre de pages ou blocs à charger à la fois dépend de la quantité mémoire disponible, plus y a de mémoire, plus je charge de blocs à la fois, plus le traitement s'accélère).


La comande "free" donne des informations sur l'état de la mémoire (physique, swappée ...), voici ce que ça donne :

Code:

---

1 2 3 4 5

igor:~$ free total used free shared buffers cached Mem: 256952 249564 7388 0 3764 117404 -/+ buffers/cache: 128396 128556 Swap: 602396 196 602200

---

Je crois que je peux utiliser les informations fournies par free, bon c'est pas très précis (au moment de l'exécution de la jointure par exemple), mais au pire des cas il y aura un swapping de quelques kilos.

J'aimerais avoir vôtre avis sur ce sujet.

une autre question :

Est-il préférable d'allouer les blocs de façon contigue ou chainée. J'aimerais savoir si la mémoire disponible (libre indiquée par "free" est contigue) ?

merci d'avance.

la meoire donnée par la commande free est indicative et global, rien ne te permet d'affirmer quelle est contigue (elle ne l'est surement pas ).

Dans la mesure ou tu es sur un systeme multitache, tu ne peut pas faire de calcule sur la place memoire avant de l'utiliser, un aure process a pu, entre temps en occupper ou liberer.
C'est le travail du kernel que de gerer la memoire dans son ensemble, pas celui de ton application. tu ne peut donc que "supputer" a l aide d'aproximation.

Alloué un grand bloc contigue a plus de chance d'etre refusé que plusieur bloc non contigue (blocs chainés), la methode par blocs chainée est toutefois plus couteuse en temps (adressage indexé), sensible sur de tres nombreuse boucle touefois.

bonjour
merci pour la réponse.

pour ce qui est de l'espace contigue, pas de problème, je vais gérer ça, même avec des blocs chainés je ne perds pas grand chose, car dans tous les cas, il faudrait balayer tous les blocs.

Citation:

---

la meoire donnée par la commande free est indicative et global,

---

Citation:

---

Dans la mesure ou tu es sur un systeme multitache, tu ne peut pas faire de calcule sur la place memoire avant de l'utiliser, un aure process a pu, entre temps en occupper ou liberer.
C'est le travail du kernel que de gerer la memoire dans son ensemble, pas celui de ton application. tu ne peut donc que "supputer" a l'aide d'aproximation.

---

Je n'entends pas faire une gestion optimale, mais l'proximation est interessante (quelques kilos en swap n'est pas très influent). Et pour ne pas étouffer le systeme, on peut prévoir de ne pas allouer toute la mémoire disponible par exemple.


J'ai encore une question:

On peut obtenir la taille "préferée" du bloc pour les E/S dans un systeme donnée grace à l'appel stat().

Est-il préférable d'organiser le fichier en blocs de taille st_blksize (ou multiple)

merci encore pour les réponses.

bonjour
j'ai essayé une commande sur deux pc (je crois que c'est "stat systeme_de_fichier", j'ai oublié le nom exact de la commande, ça fait deux jours que je l'ai essayé), et la je me connecte ailleurs (sous windows) .....

bon, en tout cas cette commande donne la taille du bloc d'entrée/sortie du systeme de fichier (ou peut etre du périphérique). sur les deux pc j'ai eu 4096 (je suppose 4Ko).

donc pour une meilleure utilisation des buffers d'E/S, je créee un fichier organisé en blocs de taille égale au bloc d'IO. n'est-ce pas ?


merci

bonjour

Citation:

---

Envoyé par igorigor

j'ai essayé une commande sur deux pc (je crois que c'est "stat systeme_de_fichier", j'ai oublié le nom exact de la commande

---

c'est iostat et non stat

merci