ru.cgi.perl

 
 - RU.CGI.PERL ------------------------------------------------------------------
 From : Victor Wagner                        2:5020/400     10 Apr 2003  12:02:53
 To : Oleg Ivanenko
 Subject : Re: mod_perl: parallel requests
 -------------------------------------------------------------------------------- 
 

 Oleg Ivanenko <ash@aska.com.ua> wrote:
 
 OI> 1. Кто как ловит memory leaks при использовании mod_perl (про 
 OI> Apache::Leak я знаю, но в моем случае его тяжеловато использовать, да и 
 OI> реакция программы какая-то непредсказуемая на leak_test)?
 
 Поставить апачу лимит на virtual address space (или memory size, если
 оно работает). После этого смотришь в логи - если на каком-то запросе
 апач регулярно пришибают, значит там с памятью не все кругло.
 
 Вообще, достаточно часто замести проблему с memory leaks под ковер,
 посредством выставления достаточно маленького MaxRequestPerChild в
 апаче.
 
 Там память расходуется не только в случае явных глюков в перловом коде.
 Есть во-первых, некоторые проблемы с динамическими библиотеками при
 graceful restart-е, во-вторых, плохое взаимодействие с системным Copy on
 Write.
 
 OI> 2. Hе сталкивался ли кто с глюками при использовании 'use lib' в 
 OI> программах для mod_perl? У меня такое впечатление, что иногда, причем 
 
 Hе сталкивался. Ровно потому как не сталкивался с "программами для
 mod_perl". Программа для mod_perl есть одна, называется apache (ну
 исполняемый файл может httpd называться). Все остальное является
 модулями. Даже скрипты, на которые PerlHandler Apache::Registry повешен.
 Советую на этот счет почитать исходный текст Registry.pm. Очень
 просветляет.
 
 Сложные вещи вообще не стоит делать через Registry. Hадо писать честные
 модули, которые являются честными хэндлерами запросов. Перечитывать при
 изменениях кода apache их автоматически не будет (чем уже сэкономит
 немало памяти из-за CoW), зато работать будет прямее и надежнее.
 
 OI> закономерности я уловить не могу, эта прагма не выполняется и библиотеки 
 OI> просто не могут быть найдены perl.
 
 OI> 3. Если программа аварийно завершается, то при этом в mod_perlовой 
 OI> заглушке для этой программы, не происходит автоматическая очистка памяти 
 
 Я совсем запутался в твоей терминлогии. Что такое программа? Судя по
 всему - явно не хреновина, выполнение которой порождает отдельный
 процесс. За отдельным процессом память чистит операционная система, и
 чистит хорошо. Что такое модперловая заглушка?
 
 Вообще в перле есть garbage collector, и он работает. Есть, конечно,
 ситуации, с которыми он не справляется. Hапример
 
 sub leak {
 my $a={t=>"a long string"};
 my $b={t=>"another long string"};
 
 $a{'b'}=$b;
 $b{'a'}=$a;
 }
 
 Hо их можно аккуратно избегать. А так объектный стиль программирования и
 аккуратно написанные деструкторы позволяют убирать за собой не только
 память, но и файловые дескрипторы, коннекты к БД, временные файлы и
 многое другое, независимо от того каким образом прекратил существование 
 объект, то ли посредством присваивания переменной, содержащей последнюю
 ссылку на него, чего-то другого, то-ли просто выходом этой переменной за
 пределы scope.
 
 OI> занимаемой объектами и, соответственно, мусор накапливается с каждым 
 OI> запросом. Кто как справляется с такой проблемой?
 -- 
 --- ifmail v.2.15dev4
  * Origin: Free Net of Leninsky,45 (2:5020/400)
 
 

Вернуться к списку тем, сортированных по: