Советы по низкому использованию памяти Perl

Мои два десятилетия.

• Создаются ли потоки, созданные в Perl, для копирования библиотек модулей Perl в память для каждого потока?

  • Это не так, это всего лишь один процесс, который не повторяется в стеке программ, каждый поток должен имеют свои собственные.

• Является ли поток (использовать потоки) наиболее эффективным способом (или единственным) способом создания потоков в Perl?

  • IMO Любой метод в конечном итоге вызывает API-библиотеки pthread, которые фактически выполняют эту работу.

• В потоках я могу указать параметр stack_size, что конкретно следует учитывать, когда указывая это значение и как оно влияет на использование памяти?

  • Поскольку потоки выполняются в одном и том же пространстве процессов, стек не может использоваться совместно. Размер стека говорит pthreads, как далеко они должны быть друг от друга. Каждый раз, когда вызывается функция локальные переменные выделяются в стеке. Таким образом, размер стека ограничивает глубину регенерации. вы можете выделить как можно меньше, чтобы ваше приложение все еще работало.

С потоками в Perl/Linux, что является самым надежным методом определения фактического использования памяти по каждому потоку?

* 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.

Если вы действительно в отчаянии, вы можете попытаться установить некоторую память в качестве файловой системы (tmpfs/ramdisk) и читать/писать/удалите на нем файлы. Я предполагаю, что реализация tmpfs достаточно умна, чтобы освободить память при удалении файла.

Вы также можете mmap (см. File:: Map, Sys:: Mmap) огромный файл на tmpfs, идея, которую я получил от Cache:: FastMmap.

Никогда не пробовал, но он должен работать:)

В дополнение к предложениям brian d foy, я обнаружил, что следующее также помогло LOT.

• По возможности, не используйте внешние модули, вы не знаете, сколько памяти они используют. Я обнаружил, заменив LWP и HTTP:: Request:: Common модули либо с помощью использования Curl, либо Lynx для сокращения использования памяти наполовину.
• Сбросил его снова, изменив наши собственные модули и выполнив только требуемые подпрограммы, используя "require", а не полную библиотеку ненужных подписчиков.

• Брайан упоминает использование лексических переменных с наименьшим возможным масштабом. Если вы используете forking, использование "undef" также помогает, сразу освобождая память для Perl для повторного использования. Таким образом, вы объявляете скаляр, массив, хеш или даже суб, и когда вы закончите с любым из них, используйте:

  my (@divs) = localtime (время); $ VAR {минута} = $divs [1];

  undef @divs; undef @array; undef $scalar; undef% hash; undef & sub;

• И не используйте лишние переменные, чтобы сделать ваш код меньше. Лучше всего жестко закодировать все возможное, чтобы уменьшить использование пространства имен.

Тогда есть много других трюков, которые вы можете попробовать в зависимости от функциональности вашего приложения. Каждую минуту нас управлял cron. Мы обнаружили, что мы можем разбить половину процессов со сном (30), поэтому половина будет работать и заканчиваться в течение первых 30 секунд, освобождая процессор и память, а другая половина будет работать после 30 секундной задержки. Уменьшилось использование ресурсов снова. При этом нам удалось сократить объем использования ОЗУ с более чем 2 ГБ до 200 МБ, что составляет 90% экономии.

Нам удалось получить довольно хорошее представление об использовании памяти с помощью

top -M

поскольку наш script был выполнен на относительно стабильном сервере с одним сайтом. Поэтому просмотр "свободного барана" дал нам довольно хороший признак использования памяти.

Также "ps" grepping для вашего script, и если forking, сортировка по памяти или использованию процессора была хорошей помощью.

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

Оба потока и вилки будут записывать страницы памяти CoW (копировать по записи). С помощью потоков вы можете определить общие переменные, но по умолчанию скопируйте свои переменные в поток. В обоих случаях вы можете ожидать более высокую загрузку памяти.

Я не знаю, с какими приложениями вы сталкиваетесь, но вы можете захотеть написать свое приложение с помощью модели Event Driven вместо процессов Parent/Child. Я бы рекомендовал вам взглянуть на AnyEvent, это довольно просто и при условии, что приложение станет однопоточным (или процессом), которое вы сохраните некоторая память (и даже быстрее в некоторых случаях). Люди даже писали веб-серверы с AnyEvent с очень хорошей производительностью, и вы почти не заметили, что он однопоточный. Посмотрите, например, на Twiggy

Попробуйте использовать больше кеширования. Логика для реализации процедуры кэширования всегда одинакова, поэтому вы можете автоматизировать использование модуля CPAN Memoize. Используйте Devel:: Size, чтобы проверить фактический объем памяти.