Consomation CPU qui augmente

Bonjour,

J'ai un programme qui réceptionne des trame sur le réseau (à l'aide de winPcap) et les enregistre sur un fichier. Ce programme tourne en boucle jusqu'a ce que l'utilisateur clique pour arrêter l'acquisition.

Le programme fonctionne pour de courte durée mais pas pour des longues...
En fait je me suis aperçu que l'utilisation du CPU augmente progressivement jusqu'à atteindre 100% d'utilisation ce qui entraine la perte de trame de mon programme d'acquisition ...

Si quelqu'un passe par là et a déjà eut le problème, je suis preneur !

Ps : Est ce que ce serait possible que ce soit du à l'écriture intensive sur disque?

Citation:

---

Envoyé par jkalzsmu

Ps : Est ce que ce serait possible que ce soit du à l'écriture intensive sur disque?

---

Oui c'est pas impossible le CPU doit permuter entre les interruptions hardware et software ce qui peut plus le solliciter.
Y'a-t-il utilisation de threads dans ce programme qui appelle wincap ?

A priori, non...
Mais il devrait être 'simple' de les mettre en commentaire pour voir.
Sinon, difficile de savoir sans regarder le code mais...

"ca mange du CPU" alors que ca ne fait que des ES (lecture réseau et écritures disques).
Note: la ou on consomme du CPU c'est plutôt dans la copie des buffers mémoire mais, il faut dans ce cas un traffic réseau conséquent.
et la consommation CPU devient insupportable lorsqu'on fait fonctionner le programme longtemps.
=> Cà boucle où? Pourquoi?
- W

Citation:

---

Envoyé par Mat.M

Oui c'est pas impossible le CPU doit permuter entre les interruptions hardware et software ce qui peut plus le solliciter.
Y'a-t-il utilisation de threads dans ce programme qui appelle wincap ?

---

Oui il y a un threads qui s'occupe de récupérer les trames reseaux (géré par winpcap). Le programme principale est l'interface graphique (visual c++).

La boucle est gérée par winpcap mais en gros voilà ce qu'elle fait :
* Lecture d'une trame.
* Copie dans le buffer de winpcap.
* Copie dans un autre buffer pour l'utilisateur.

En fait le problème n'est pas vraiment la consomation du CPU qui est grande, lorsque je lance le programme, elle est de 30%.
Le problème c'est qu'elle augmente continuellement lorsque le programme est en train de tourner.
Elle arrive à 70% de consommation seulement au bout de 5 minutes alors que la charge sur le réseau reste constante ...

Autre chose que j'ai remarqué et qui pourrait peut être vous aider : lorsque je coupe le trafic sur le réseau, la consommation CPU se remet instantanément en 0%, mais en revanche, si je fait une requête d'entrée sortie sur le disque alors elle est super lente !

Citation:

---

La boucle est gérée par winpcap mais en gros voilà ce qu'elle fait :
* Lecture d'une trame.
* Copie dans le buffer de winpcap.
* Copie dans un autre buffer pour l'utilisateur.

---

En supposant que le temps CPU ne reflète que les copies mémoires, est ce que ces buffers "augmentent" avec le nombre de paquets reçus?
En espérant que le nombre de bytes copiés n'est que fonction de ceux reçus, çà fait combien de MB occupés en mémoire?
- W

Citation:

---

Autre chose que j'ai remarqué et qui pourrait peut être vous aider : lorsque je coupe le trafic sur le réseau, la consommation CPU se remet instantanément en 0%, mais en revanche, si je fait une requête d'entrée sortie sur le disque alors elle est super lente !

---

Même lorsque le CPU est tombé à 0% d'utilisation?
Sinon, ton disque semble être saturé...
Quelle est la quantité d'information écrite?
Si tu stockes beaucoup d'informations en mémoire, tu as peut être un problème de pagination.
-W

Pour ce qui est du buffer de winpcap, sa taille est fixé par mes soins :D
C'est en fait un ring qui permet a pcap de stocker les paquets reçu mais non transmit à l'utilisateur.

Les paquets que je reçoit sont tous de la même taille (jumbo frame de 6978 octets).

Je pense pas que le disque soit saturé car il fait plus de 500 giga et marche bien (4 disques 15000 tours/min en raid0).
Moi je penserais plutôt sur une protection de L'OS envers un méchant virus qui pourrait remplir ton disque dur en 1 soirée ...

Mon collègue pense que le cpu est "dans le paté" apres avoir tourné a fond pendant longtemps. Ce qui expliquerai pourquoi, lorsque le cpu retombe à 0%, il n'arrive toujours pas à écrire sur le disque.

La quantité d'information écrite est assez grande, c'est de l'ordre de 100Mo/s mais les disques sont capable de supporter une telle charge puisque au début du programme, il n'y a pas de problèmes.

Merci de ton aide

Citation:

---

Moi je penserais plutôt sur une protection de L'OS envers un méchant virus qui pourrait remplir ton disque dur en 1 soirée ...

---

Est ce que çà fonctionne raisonnablement en commentant les écritures disques?

Citation:

---

Mon collègue pense que le cpu est "dans le paté" apres avoir tourné a fond pendant longtemps. Ce qui expliquerai pourquoi, lorsque le cpu retombe à 0%, il n'arrive toujours pas à écrire sur le disque.

---

Tant que nous n'aurons pas identifié la ressource (ou plutôt la capacité qui est sur-utilisée) en défaut...

Code:

---

La quantité d'information écrite est assez grande, c'est de l'ordre de 100Mo/s mais les disques sont capable de supporter une telle charge puisque au début du programme, il n'y a pas de problèmes.

---

Si je ne m'abuse, 100Mo/7k ~ 1500 IO/s.

RAID0 c'est bien mais à 150 IO/s par disque, tu n'as qu'une capacité de 4x150 = 600 IO/s. Les autres IOs sont en attente où?
Note: Il serait sage de faire des IOs au moins 4 fois plus grosses.

- W

Citation:

---

Envoyé par wiztricks

Est ce que çà fonctionne raisonnablement en commentant les écritures disques?

---

Oui ça marche sans problèmes !

Citation:

---

Envoyé par wiztricks

Si je ne m'abuse, 100Mo/7k ~ 1500 IO/s.

RAID0 c'est bien mais à 150 IO/s par disque, tu n'as qu'une capacité de 4x150 = 600 IO/s. Les autres IOs sont en attente où?
Note: Il serait sage de faire des IOs au moins 4 fois plus grosses.

- W

---

Pour ce qui est des disques, un rapide test m'as permit de mesurer une vitesse d'écriture d'environ 120Mo/s ce qui logiquement suffisant pour notre programme.
Et puis les disques suivent sans problèmes au début du programme alors pourquoi ce ralentissement?
Par rapport a cette histoire de IO/s, je ne connais pas du tout le fonctionnement de RAID0.

Concernant des IO plus grande, j'avais modifier mon programme pour ne plus plus demander des écritures de 6978 octets (1 trames), mais plutôt grouper les trames (par paquet de 14 ~ environ 100Ko). Le résultat était le même ...
C'est certainement du au fait qu'il y a un buffer sur le contrôleur RAID qui permet d'optimiser les appels IO.

Citation:

---

Concernant des IO plus grande, j'avais modifier mon programme pour ne plus plus demander des écritures de 6978 octets (1 trames), mais plutôt grouper les trames (par paquet de 14 ~ environ 100Ko). Le résultat était le même ...

---

Le résultat? Blocage avec 100% d'utilisation CPU ou çà marche aussi bien dans les premières minutes?

Citation:

---

C'est certainement du au fait qu'il y a un buffer sur le contrôleur RAID qui permet d'optimiser les appels IO.

---

Comme ces IOs sont séquentielles, si le contrôleur gère proprement ses buffers, çà ne devrait pas faire de différence... Sinon çà va s'accumuler quelque part.

Si cela marche raisonnablement en commentant les écritures disques, il reste peut être à confirmer que c'est un problème côte disque en faisant un programme qui écrive "bourin" par paquets de 7K assez longtemps.

Note: 100Mo/s = 1Go après 10s.
= 10Go après 1,7 mns
= 100Go après 17 mns
J'espère que les 500Go sont libres.

Concernant l'écriture par paquet de 100Ko, en fait le résultat est même pire ... car le temps d'écrire ce paquet sur le disque, la carte réseaux rejette des paquets ... De plus, le CPU continue a augmenter ...

Je vais essayer d'écrire en bourrin et je donnerais le résultat.

Ok
Pour le programme d'écriture "bourrin", essaie de paramètrer la taille des IOs pour voir comment se comporte le cache.
L'idée est de noter le temps mis pour écrire de l'ordre de 50 Go (par exemple) avec des tailles de buffers différentes.
- W