Estive usando o cloudfusion por um bom tempo e precisava mudar para a versão mais recente do AWS sdk e ter vazamentos de memória. O vazamento de memória foi relatado por cerca de um ano, sem uma solução real. Após muita leitura, executando testes e investigando resultados, o daemon simples a seguir reproduz o problema

#! /usr/bin/env php
<?php class httpsTest{
    function curlHttps($memLeak=false){
        $curl = curl_init();
        curl_setopt($curl, CURLOPT_URL, 'https://sqs.us-east-1.amazonaws.com');
        curl_setopt($curl, CURLOPT_SSL_VERIFYHOST, 2);
        curl_setopt($curl, CURLOPT_SSL_VERIFYPEER, $memLeak);
        curl_setopt($curl, CURLOPT_RETURNTRANSFER, true);
        curl_exec($curl);
        curl_close($curl);
    }
}
gc_enable();
$myPid = getmypid();$i=0;
$test  = new httpsTest();
while ($test){
    $test->curlHttps(true);
    echo $i++ ." PHP Info MemUsage: ".memory_get_usage() ."    Linux Info ";
    system('cat /proc/' .$myPid .'/status|grep '.'"VmSize"');
    sleep(1);
}

Então, ao usar o CURLOPT_SSL_VERIFYPEER com valor true, ele vaza 132 kbytes a cada 18 iterações. Para ter certeza de que não estou vencendo, o sistema fedora 14 foi atualizado com php 5.3.10, libcurl 7.24.0.-1.0, nss-3.12.10-7, openssl-1.0.0e-

Não consigo imaginar que ninguém tenha se deparado com isso antes, embora pareça tudo bem quando você confia apenas nos relatórios de memória php. Para ter certeza, eu relatei isso aos especialistas em php, mas parece que o php está fazendo certo e o vazamento é criado nas bibliotecas usada

O que eu poderia fazer para coletar informações úteis para resolver esse problema, verifiquei o monte de vazamentos e pude ver claramente uma diferença na situação de vazamento e nenhum vazamento. Na situação de vazamento, a parte superior do heap era preenchida com objetos de 16 bytes, com um endereço e ainda mais vazios. Portanto, parece que os objetos estão sendo esvaziados, mas não liberado

Muito obrigado por qualquer sugestão