Conseils pour garder Perl utilisation de la mémoire faible

Mes deux dimes.

1. Ne threads créés en Perl empêcher la copie module Perl bibliothèques en mémoire pour chaque thread?

   • Il ne le fait pas, c'est juste un processus, ce qui n'est pas répété dans la pile du programme, chaque thread doit
     avoir sa propre.

2. Est fils (fils) le moyen le plus efficace (ou la seule) façon de créer des threads en Perl?

   • OMI Toute méthode appelle éventuellement la bibliothèque pthread Api qui fait réellement le travail.

3. Dans les fils, je peux spécifier un stack_size paramater, que doit-je considérer lors de l'
   la spécification de cette valeur, et quelle est son incidence sur l'utilisation de la mémoire?

   • Depuis threads s'exécute dans le même espace de processus, la pile ne peut pas être partagé. La taille de la pile
     raconte pthreads à quelle distance ils devraient être les uns des autres. Chaque fois qu'une fonction est appelée
     les variables locales sont allouées sur la pile. Si la taille de la pile des limites de profondeur de manière récursive.
     vous pouvez allouer aussi peu que possible de l'étendre que votre application fonctionne toujours.

Avec les threads en Perl/Linux, ce qui est la méthode la plus fiable pour déterminer le montant réel de l'utilisation de la mémoire
sur une base par thread?

* Stack storage is fixed after your thread is spawned, heap and static storage is shared and
  they can be used by any thread so this notion of memory usage per-thread doesn't really
  apply. It is per process.


Comparing fork and thread:

* fork duplicate the process and inherites the file handles

  advantages: simpler application logic, more fault tolerant.
              the spawn process can become faulty and leaking resource
              but it will not bring down the parent. good solution if
              you do not fork a lot and the forked process eventually
              exits and cleaned up by the system.

  disadvantages: more overhead per fork, system limitation on the number
              of processes you can fork. You program cannot share variables.

* threads runs in the same process with addtional program stacks.

  advantages: lower memory footprint, thread spawn if faster and ligther
              than fork. You can share variables.

  disadvantages: more complex application logic, serialization of resources etc.
              need to have very reliable code and need to pay attention to
              resource leaks which can bring down the entire application.

IMO, depends on what you do, fork can use way less memory over the life time of the 
application run if whatever you spawn just do the work independently and exit, instead of
risking memory leaks in threads.

En plus de brian d foy les suggestions, j'ai trouvé le suivant aussi BEAUCOUP aidé.

1. Si possible, ne pas "utiliser" des modules externes, vous ne savez pas combien de mémoire qu'ils utilisent. J'ai trouvé par le remplacement de la LWP et HTTP::Request::Common des modules avec Curl ou de Lynx réduit l'utilisation de la mémoire par la moitié.
2. Réduit de nouveau en modifiant nos propres modules et en tirant dans seules les sous-programmes à l'aide de "besoin" plutôt que d'une bibliothèque complète de inutiles subs.

3. Brian mentionne l'utilisation de variables lexicales avec le plus petit de la portée. Si vous êtes à la bifurcation, à l'aide de "undef" permet également de par immédiatement libérer de la mémoire pour Perl pour le ré-utiliser. Vous déclarez donc un scalaire, tableau, hachage ou même des sous, et lorsque vous avez terminé, utilisez :

   ma (@divs) = localtime(time);
   $VAR{minute} = $divs[1];

   le fnud @divs;
   le fnud @tableau;
   undef $scalaire;
   le fnud %hash;
   le fnud &sous;

4. Et ne pas utiliser n'importe quel unnecssary variables pour rendre votre code plus petits. Il est préférable de coder tout ce qui est possible pour réduire l'espace de noms d'utilisation.

Puis, il y a un tas d'autres trucs que vous pouvez essayer selon les fonctionnalités de votre application. Le nôtre a été exécuté par cron toutes les minutes. Nous avons constaté que nous pourrions fourche à la moitié du processus avec un sleep(30), de sorte moitié exécuter et terminer dans les 30 premières secondes, libérant ainsi de la cpu et de la mémoire, et l'autre moitié de courir après un délai de 30 secondes. Réduit de moitié l'utilisation des ressources à nouveau. Tous, nous avons réussi à réduire l'utilisation de la RAM de plus de 2 GO en bas à 200 mo, une économie de 90%.

Nous avons réussi à obtenir une assez bonne idée de l'utilisation de la mémoire avec

top -M

que notre script a été exécuté sur une relativement stable serveur avec un seul site. Donc, regarder "ram libre" nous a donné une assez bonne indication de memery utilisation.

Aussi "ps" grepping pour votre script, et si fourches, de tri, soit par la mémoire ou de l'utilisation de l'uc a été d'une bonne aide.

ps -e -o pid,pcpu,pmem,stime,etime,command --sort=+cpu | grep scriptname | grep -v grep

Essayez d'utiliser plus de la mise en cache. La logique de la mise en œuvre de la mise en cache de routine est toujours la même, de sorte que vous pouvez automatiser à l'aide de module CPAN Memoize. Utilisation Devel::Taille pour vérifier la quantité de mémoire.