Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:101647 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 38216 invoked from network); 21 Jan 2018 12:26:57 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 21 Jan 2018 12:26:57 -0000 Authentication-Results: pb1.pair.com smtp.mail=php@fleshgrinder.com; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=php@fleshgrinder.com; sender-id=unknown Received-SPF: error (pb1.pair.com: domain fleshgrinder.com from 77.244.243.82 cause and error) X-PHP-List-Original-Sender: php@fleshgrinder.com X-Host-Fingerprint: 77.244.243.82 mx101.easyname.com Received: from [77.244.243.82] ([77.244.243.82:58179] helo=mx101.easyname.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id BA/01-28995-D07846A5 for ; Sun, 21 Jan 2018 07:26:55 -0500 Received: from cable-81-173-135-182.netcologne.de ([81.173.135.182] helo=[192.168.178.20]) by mx.easyname.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1edEi3-00070S-Dr; Sun, 21 Jan 2018 12:26:51 +0000 Reply-To: internals@lists.php.net To: Nikita Popov , PHP internals References: Message-ID: Date: Sun, 21 Jan 2018 13:26:46 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-DNSBL-PBLSPAMHAUS: YES X-DNSBL-SURBL: YES Subject: Re: [PHP-DEV] OPCache: invalidate vs unlink From: php@fleshgrinder.com (Fleshgrinder) On 1/21/2018 1:04 PM, Nikita Popov wrote: > Unless you are running specifically into the max files limit (and not the > memory limit), unlinking from the hashtable will not provide any benefit. > It does exactly what it says on the tin, and in particular it's not going > to free up any space. > > The reason why opcache has a restart mechanism, is that it does not track > which files are currently (potentially) in use. During a restart it waits > until all workers stop using SHM, at which point the memory can be safely > reset. To improve this some more precise tracking of SHM usage would be > necessary (not necessarily per-file, but more than just "yes or no"). > > Nikita > Many thanks. :) -- Richard "Fleshgrinder" Fussenegger